Hi all,

I was just perusing this paragraph on the CrackZ dongle page:

-------8<-----------
Remember it can sometimes be impossible to recover exact response codes because you'll sometimes end up with TEST [ESI+38], 1 as a check (this example from a real dongle btw :-) ).
-----------8<-----------

My x86 asm is a bit rusty, but why would it be so hard to recover the response code from this location? Isn't it just an offset from the address in the index register?

corus corvax

TEST [ESI+38], 1 does only test if the last bit at this pointer is set. what crackz means is that you will not be able to discover the full value of the dongle just by this check. you have 127 possibilities for the checked byte to be true -> 010101011111b for example... and a lot more ending with 1b. :-)

read about assembly commands here:

hxxp://www.woodmann.com/crackz/Tutorials/Drme2.htm

So he's implying this is just one test of many, with the value of the dongle being shifted? Because just a one-bit test would be a joke.

i see some using of this technics. So you make
test responce, mask,
where mask for example tests 5-10 bits, and then (if succeed) the _entire_ responce are _used_ in algo.

corus: If the protector were testing a dongle read value, in this example located at [ESI+38] by using

cmp [ESI+38], 247B

They would be giving away the word that the program is expecting from the dongle query: 247B, game over. This is typical of weak, poorly implemented Dongle protections.

by using

TEST [ESI+38], 1

they only reveal one bit, in this case the 0 bit

Another area of the program may check

TEST [ESI+38], 00100001b

and you only know that bits 5 and 0 need to be 1, so they never reveal the whole expected value that the dongle should return. (Of course, if you had the dongle, you could always tell, just by reading the word at [ESI+38], but that is another story).

Ah, that makes sense. But it would make for some very convoluted code testing 1 or 2 bits at a time at different times and places. Especially since the value returned by the dongle would most likely be different each time.

Convoluted is the name of the game. Testing a miserable bit or bits from the dongle response offers little software protection, but if you follow the test with using the numbers stored in the dongle as keys to decrypt critical areas of the code, you'll get a pretty tough ride cracking the program.

Thanks to HaRdLoCk, naides and infern0 for writing what I was probably too lazy to do myself (*WILL FIX*) ;-).

My basic premise was that working out the precise contents of an original dongles memory might be problematic if the check isn't totally explicit, e.g:

cmp dword ptr [dongleMem], 12345678h
jz good_return_from_dongle

else do_bad_stuff_here

That example was from a CAD program that embedded various bit tests against this single DWORD for just about every piece of functionality. In many implementations a check against single bits of a return value ought to be a red flag that other bits are going to be checked elsewhere.

Regards

CrackZ.