Results 1 to 8 of 8

Thread: CrackZ explanation of hiding dongle response codes

  1. #1
    corus-corvax
    Guest

    CrackZ explanation of hiding dongle response codes

    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
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  2. #2
    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:

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

  3. #3
    corus-corvax
    Guest
    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 promise that I have read the FAQ and tried to use the Search to answer my question.

  4. #4
    infern0
    Guest
    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.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  5. #5
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647
    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).
    Last edited by naides; August 10th, 2005 at 16:51.

  6. #6
    corus-corvax
    Guest
    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.
    Last edited by corus-corvax; August 10th, 2005 at 06:53.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  7. #7
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647
    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.
    Last edited by naides; August 10th, 2005 at 16:50.

  8. #8
    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.

Similar Threads

  1. Breaking a challenge response
    By squidge in forum RCE Cryptographics
    Replies: 5
    Last Post: March 16th, 2012, 10:42
  2. No response from injected code
    By joekames in forum OllyDbg Support Forums
    Replies: 4
    Last Post: October 28th, 2009, 19:54
  3. SWF Encrypt explanation.
    By unlimitedorb in forum Malware Analysis and Unpacking Forum
    Replies: 59
    Last Post: April 25th, 2009, 11:02
  4. ollydbg - explanation of short piece of assebly
    By jamiemac2005 in forum Tools of Our Trade (TOT) Messageboard
    Replies: 5
    Last Post: June 5th, 2007, 03:44
  5. auto.search.msn.com/response.asp
    By mike in forum Mini Project Area
    Replies: 11
    Last Post: July 6th, 2004, 14:09

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •