Results 1 to 7 of 7

Thread: Sentinel spro dongle protection

  1. #1
    ComanderKeen
    Guest

    Question Sentinel spro dongle protection

    There is local software named KardiLab that is protected by sentinel spro dongle. It has two versions, KardiLab 8 and 10. I dumped both dongles memories with sprodump and found that contents of the memories of two dongles exactly same except the serials (Cell 00). But its not possible to run one of them with the others dongle. Anybody knows any protection API uses the serial of a sentinel dongle or itís some kind of new trick. Anyway Iíll appreciate if someone shares his opinions with me about this subject.

    Greetings to CrackZ, Goatass and CyberHeg ( I learned everything from you)Öand reversers all around the world.

    P.S: Sorry for my un-advanced EnglishJ
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  2. #2

    I've seen it before...

    You can do lots of tricks with the serial. If you read the manual I am sure it says somewhere that if a developer orders a series of dongles the serial number will be incremented one by one for each dongle. In past I bought a developer SDK where the dongle had the serial number 0x0001. The dongle then broke after some time and the serial of the new dongle became 0x0002. Knowing this fact is useful because it can allow developers to "mark" dongles for a specific program or version. Lets say the developers of your target ordered 1000 dongles for the first version and then later again 1000 new ones for the 2nd version. It's easy then to do a check if your dongle is in the first or the 2nd range.

    Of other types of checks it's possible ofcourse to tie the serial to a real serial number which must be inputted by the user.

    Also you can use it as a dongle specific encryption. I only saw that once though (it was with a Hasp dongle though) where the program used the dongle serial as a decryption key for the dongle memory.

    A specific dongle can ofcourse also be blacklisted easily because if it's serial aswell.

    Regarding your target I can't say more unless you post more details.

  3. #3
    Hiya,

    Check if both dumps have the same Developer ID (cell 1), if they do then you should safely be able to unplug 1 of them (might save you some confusion).

    The only way a developer can read the dongle s/n (if that is the basis of the protection) is via one of the spro(Read) API's (2 of them), find those, and breakpoint them, then just follow back the s/n and see how its used.

    I have to confess I think it really unlikely any developer would just distinguish by just dongle s/n, however, if they have Cyberheg's theory sounds pretty likely, probably just a range of s/n's per version.

    Regards (let me know if you can make available the target and/or dumps) and I'll probably be able to help more.

    CrackZ.

  4. #4
    VoxQuietis
    Guest

    Just a litte side note

    Hi Crackz,

    I think you never saw an actual Superpro based hostid implemenation of Flexlm. They are doing exactly that: they have a DevId (or a small range of it, dont know) and they use the DevId and the dongles serial as Flexid=7-xxxxxxxx.

    I even think, that this is quite OK, since Flexlm's biggest advantage is its flexibility and not the security. I.e. You never would start patching the Flexlm-stuff to overcome the dongle based hostid (You'd rather go ahead with Hostid=Any .

    On the other hand, I saw an (expensive) VHDL-synthesis tool, which uses Flexlm and incorporates a small query table into its licensing mechanism. While the standard Flexlm implementation had been successfully attacked by a group called SLT, the dongle based portion of the protections doesn't seem to be compromised for the public (leeching) audience. (but be shure, that it's hacked, anyway :-P )

    Regards,
    - Vox.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  5. #5
    ComanderKeen
    Guest

    Sentinel spro dongle protection-additional info

    Since the time I sent about the post to the forum I had the chance to check the contents of two new dongles, which belongs two other versions (version 9 and 12). I checked the Dev. IDís (Cell 01) and they are exactly same with preceding dongles. And serials of dongles seem from the same serie.(4004 /4B04 /4A04/3504). I opened the .exe file with IDA and applied Killer_3Kís flirt signature. Dev. ID isnít pushed directly (which something new for me) and check the calls for sproRead and sproQuerry APIs, found something interesting. Is it something I thought? A call for the Cell 00 (serial number of the dongle)?


    00C6AFD0 sub esp, 4
    00C6AFD3 test byte ptr ds:dword_C6891C, 70h
    00C6AFDA mov [esp+4+var_2], 0
    00C6AFE1 jz short loc_C6B017
    00C6AFE3 lea eax, [esp+4+var_2]
    00C6AFE7 push eax ; store address?
    00C6AFE8 push 0 : cell to read?
    00C6AFEA push 0C5FCC8h acket record?
    00C6AFEF call sproRead
    00C6AFF4 test ax, ax
    00C6AFF7 jnz loc_C6B0E7
    00C6AFFD mov cx, ds:word_C600D0
    00C6B004 cmp [esp+4+var_2], cx
    00C6B009 jz loc_C6B0E7
    00C6B00F mov ax, 3
    00C6B013 add esp, 4
    00C6B016 retn

    00C6B0A7 ; ¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶
    00C6B0A7
    00C6B0A7 loc_C6B0A7: ; CODE XREF: sub_C6AFD0+69 j
    00C6B0A7 push 4
    00C6B0A9 mov ds:dword_C5FC60, eax
    00C6B0AE mov ds:dword_C5FC64, 0
    00C6B0B8 push 0
    00C6B0BA push 0C5FC64h
    00C6B0BF push 0C5FC60h
    00C6B0C4 push 0 ; Algorithm starting point?
    00C6B0C6 push 0C5FCC8h : packet record?
    00C6B0CB call sproQuery
    00C6B0D0 test ax, ax
    00C6B0D3 jnz short loc_C6B0E7
    00C6B0D5 mov ecx, ds:dword_C5FC64
    00C6B0DB cmp ecx, ds:dword_C6891C
    00C6B0E1 jz short loc_C6B0E7
    00C6B0E3 mov ax, 3
    00C6B0E7
    00C6B0E7 loc_C6B0E7: ; CODE XREF: sub_C6AFD0+27 j
    00C6B0E7 ; sub_C6AFD0+39 j ...
    00C6B0E7 add esp, 4
    00C6B0EA retn
    00C6B0EA sub_C6AFD0 endp
    00C6B0EA

    and I have another question about sproRead, you can see that the cell to read is pushed in eax at line 00C6B962, two lines before the byte from offset 00C5E00C moved (movzx) to eax. If the content of offset 00C5E00C is;

    00C5E00C byte_C5E00C db 0A2h ; DATA XREF: _

    which byte does it move into the eax? Is eax 0002 or 000A? Same trick is used in pushing the Dev ID before sproFindFirstUnit.

    00C6B94C cmp ds:byte_C5E00C, 0FFh
    00C6B953 jz short loc_C6B982
    00C6B955 movzx ax, ds:byte_C5E00C
    00C6B95D push 0C600CCh
    00C6B962 push eax ;Cell to read?
    00C6B963 push 0C5FCC8h
    00C6B968 call sproRead
    00C6B96D test ax, ax
    00C6B970 jnz loc_C6BA39
    00C6B976 xor eax, eax
    00C6B978 mov ax, ds:word_C600CC
    00C6B97E mov [esp+24h], eax


    I thank everybody for being patient while reading my post. Special thanks to CrackZ and CyberHeg for useful advices.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  6. #6

    First things first

    About your movzx query I see a problem here.
    The line you specified:

    movzx ax, ds:byte_C5E00C

    is actually the same as:

    mov ax, 0 ; clear only 16 lower bits of eax
    mov al, 0a2h

    So from what you wrote eax will contain: ????00a2

    Now the problem is that the cell to read is out of range but maybe thats how it should be? Maybe it's intended to be a fake check to make the dongle return values other then "good". This would actually be a simple but effective way to clear away non thinking crackers who allways believe dongles should be working in one way.

    Another thing is your query. You notice that the cell to query on is 0. This is another fake check where you need to use the manual. From the manual it says that only userwritable cells can be used for queries. These start from +8 so 0 is ofcourse a restricted cell. I can't remember if the following was specified in the manual or it was because of my own tests but in sentinel shell (automatic protector) I wrote in a essay once about the same thing since it also uses this kind of check.
    A query algorithm is 2 cells hence a DWORD long. These cells will in this case be 0 (serial) and 1 (developer id). If you do a query on these you get the same response back as you sent to the dongle as your query string. Now it should be easy to emulate since you just need to copy the query string to the response position.

    Are you sure this is not sentinel shell btw? Both checks read on cell 0 and query on shell 0 were/are used by this protector.

    Hopefully this helps.

  7. #7
    goatass
    Guest
    After the sproRead call you see this:

    00C6AFFD mov cx, ds:word_C600D0
    00C6B004 cmp [esp+4+var_2], cx
    00C6B009 jz loc_C6B0E7

    what is it comparing the return value to?

    Similarly with the sproQuery:

    00C6B0D5 mov ecx, ds:dword_C5FC64
    00C6B0DB cmp ecx, ds:dword_C6891C
    00C6B0E1 jz short loc_C6B0E7

    maybe can give you a better idea as to what you should expect in the return value.

    goatass
    I promise that I have read the FAQ and tried to use the Search to answer my question.

Similar Threads

  1. Sentinel HL dongle emulation
    By confused in forum The Newbie Forum
    Replies: 12
    Last Post: November 14th, 2013, 02:28
  2. Little problem with a Sentinel dongle...
    By Dantes in forum Advanced Reversing and Programming
    Replies: 8
    Last Post: May 28th, 2010, 01:39
  3. Analyzing Sentinel dongle?
    By foolery in forum The Newbie Forum
    Replies: 4
    Last Post: March 20th, 2010, 22:48
  4. Sentinel superpro dongle cracking help
    By warior_jal in forum Malware Analysis and Unpacking Forum
    Replies: 2
    Last Post: May 13th, 2002, 03:53
  5. Sentinel SuperPro dongle protection
    By jholmes in forum Advanced Reversing and Programming
    Replies: 3
    Last Post: November 28th, 2001, 20:21

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
  •