programmers resources
  http://www.intel-assembler.it/  (c)2017 intel-assembler.it   info@intel-assembler.it
 
Search :  
Lingua Italiana    English Language   
Index
 
just an empty assembly space
just an arrow Intel Platform
just an arrow Article & Guides
just an arrow Download Software


23/01/2009 Featured Article: How to remove Buzus Virus (permalink)




:::3141108:::
Bottone Scambio Directory Pubblicitaonline.it
Home Page | Articles & Guides | Download | Intel Platform | Contacts

Google
 


Bookmark and Share
Download 
Tell a friend



How to undongle

hardware key debugging with softice

(by xoanon)

An interesting debugging session during which the author analyses and old software protected with a dongle hardware key.
During the debugging session he shows how to bypass some antidebug protection schemes.
This article is online from 4987 days and has been seen 13162 times




How to undongle by +Xoanon

     Well, i have seen some of my previous works published by the +HCU. And
     for me this is already enough... Wow! To be on a page together with
     the "Gotha" of cracking!!! So i decided to start working on a more
     serious project, a cracking subsector that only REAL +crackers can
     face: DONGLES! Eh eh.... well, i have seen that the +HCU needs
     something about dongles, so why should I not try? Let's see....

Prologue:

     First of all, i decided to try this donglecrack 'coz i don't know of
     ANY version of Cubase 3.0 working (i mean REAL 100% cracked). Maybe
     there are newer versions out (i think 3.05 or more), but i'm not sure
     if are cracked well, coz i haven't tried them.

     And, the reason of this is quite simple: many crackers tend to not
     even trying out the programs once they THINK they've cracked them, and
     since Cubase has a funny trick (to let you think you've cracked it
     after less than 2 minutes of debugging... you got it?) I think it is
     worth explaining a little its protection schemes. By the way, i tried
     cracking it 1 year ago and did the same error.

     In more understandable terms, simply NOPPING a JNZ lets you bypass the
     initial donglecheck, so cubase "runs" somehow. But try working more
     than 10 minutes (or even less)... try creating new tracks, by clicking
     4 or 5 times on the right window... try choosing "Score" from the
     menu.... TRY ANYTHING!!! It will soon crash with a "General Protection
     Failure" error report...

Some donglecracking infos you may need:

     Since dongles are a relatively "strong" way to protect a program (a
     dongle can contain locations where the program needs to jump, etc...)
     sometimes without them it's impossible to crack such protections... I
     mean, in some hard cases (i.e. when the locations of the jmps are
     stored *directly* inside the dongle) you'll need ABSOLUTELY the
     dongle, or you can't do anything... the program will not run.

     In this case (and in other ones as well) first try to "emulate" the
     dongle, if you understand how it works. If you can't, then try a BRUTE
     FORCE approach (read my tutorial) to fool the program (as i did with
     Cubase).

     This is the way to proceed in order to "bruteforcing" a dongle:

     1) Write down the locations where the program crashes/does not run
     2) Trace back and try to locate the switches (jumps) which jump to
     these locations
     3) Be sure these locations aren't used in other part of the program as
     well

Let's start!!!

     Ok, are u ready with your Martini Vodka and/or cigarettes AND
     Softice???

     Good...... let's begin eradicating the initial donglecheck! (you could
     also try to emulate the dongle by setting BPIO -h on printer ports
     such as 0378/0379/037a etc... you will land in the CUBASE.VXD... and
     believe me... it's better to try another approach!)

     Well, you run Cubase and it popsup with the classic "Plug the
     dongle,idiot" screen.... Ah ah ah!! Simply rerun it, Ctrl-D before the
     nag appears, hit F12 more than once to trace back calls (p ret is for
     sure one of the best SoftICE's functions i think, without it some of
     the hard cracks couldn't be done) and you'll land in the CUBASE30CM
     module. Step step and step until you reach this code (you might need
     to set some temporaneus BPX to get rid of cycles_loops, but you will
     figure out yourself where and how... otherwise i would spend a whole
     day writing this tutorial!):

     *Initial Check

     0013.3C36 6A00                   push 0000
     0013.3C38 6A00                   push 0000
     0013.3C3A 56                     push si
     0013.3C3B 6A3F                   push 003F
     0013.3C3D 6A00                   push 0000
     0013.3C3F 90                     nop
     0013.3C40 0E                     push cs
     0013.3C41 E8A924                 call 60ED  < Tracing this call you will
                                                   see how the dongle operates,
                                                   you'll reach the VXD too.
                                                   but you better don't
                                                   consider it!Let's BRUTEFORCE!
     0013.3C44 83C40A                 add sp, 000A
     0013.3C47 8BF8                   mov di, ax
     0013.3C49 8BC7                   mov ax, di
     0013.3C4B 3DFEFF                 cmp ax, FFFE < CUBASE.386 not loaded
     0013.3C4E 7421                   je 3C71
     0013.3C50 3DFFFF                 cmp ax, FFFF < AX=FFFF? Dongle not presen
t
     0013.3C53 7402                   je 3C57      < NOPPING this lets you run
                                                     Cubase... this is why most
                                                     of the crackers think they
                                                     got rid of the protection.
                                                     Moving in AX a value like
                                                     0000 doesn't work too,
                                                     by the way.
     0013.3C55 EB4D                   jmp 3CA4

     Ok, now let's hexedit your NOPS in the CUBASESC.EXE to let the program
     run and start again. As you can see, trying the things i told you
     before makes your system crash at random times and you have to reboot
     and reload SoftICE (very very frustrating!). What can we do? Don't
     worry, +Xoanon explains!

     Well, you noticed that when your system crashes softice popsup and
     tells you WHERE the crashes happens, at which instructions. We see,
     for Cubase, that this happens here (btw, it happens here if you try to
     create more than 2 or 3 tracks doubleclicking on the right window...
     could happen also on other instructions):

     * SYSTEM CRASH *
     * Referenced by a CALL at Addresses:
     |:0015.529A, :0015.53F9, :0015.5487, :0015.5588, :0015.5CFB
     |:0015.5E1B, :0015.AB6B, :0015.AB85, :0015.AC01, :0015.B513
     |:0015.B73F, :0015.B9AA, :0015.BA51
     |
     :0015.C5C6 45                     inc bp
     :0015.C5C7 55                     push bp
     :0015.C5C8 8BEC                   mov bp, sp
     :0015.C5CA 83EC08                 sub sp, 0008
     :0015.C5CD C45E06                 les bx, [bp+06]
     :0015.C5D0 66268B4704             mov eax, es:[bx+04]   < Executing one of
     :0015.C5D5 668946FC               mov [bp-04], eax        these MOV the prg
     :0015.C5D9 C45E06                 les bx, [bp+06]         crashes....
     :0015.C5DC 66268B07               mov eax, es:[bx]        INTERESTING!
     :0015.C5E0 668946F8               mov [bp-08], eax
     :0015.C5E4 C45EFC                 les bx, [bp-04]
     :0015.C5E7 268A474A               mov al , es:[bx+4A]
     :0015.C5EB 98                     cbw
     :0015.C5EC A809                   test al, 09
     :0015.C5EE 755A                   jne C64A
     :0015.C5F0 C45EFC                 les bx, [bp-04]
     :0015.C5F3 268A4735               mov al , es:[bx+35]

     So, this can be our "ENTRY POINT" !!! Reboot (ARGH!), reload and try
     to locate in memory the instructions at C5C6. This could be a little
     hard coz the program relocate everytime... Try doubleclicking to
     create a track AND pressing CTRL-D immediately (right after
     doubleclicking), now trace back, with F12, and try U cs:C5C6 until you
     see the following instructions... you could also need some stepping
     inside the code of CUBASECM in order to find them.

     Or maybe you could try to find them in memory, with the search
     function.

     Hmm.... ok,ok... i already did it for you... i don't want you to stay
     awake the whole night trying to locate a "labile" instruction!

     Do the following:

          1) Double click to create a track, and immediately CTRL-D
          2) Do HEAP CUBSCM30 to see how the memory is occupied by Cubase
          3) The correct handle is the one with: Lenght: 0000EBC0, Type:
          Code (obvious), Seg/Resrc: 0F
          4) To be sure, do U ^THIS HANDLE^:C5C6 to see if it refers to the
          INC BP
          5) If it doesn't, maybe that segment isn't loaded in memory
          yet... simply retry once more from step 1.

     Once found (hard eh?) set a BPX on the INC BP instruction and CTRl-D
     to reenter in Cubase. Try to create more tracks and..... BOOM!

     Softice breaks at your BPX! This is interesting... we see that this
     piece of code is called ONLY when Cubase decides to crash your system.
     Therefore we can try to find a "switch" in order to bypass it.

     Ok, now begins the real hard work...

     . STACK <-- to see which calls are executed right before your BPX

        CUBSCM30(10) at 331F:019C [?]
        CUBSCM30(10) at 331F:0A41 [?]
        CUBSCM30(10) at 331F:AA9D [?]    < This is the call WHICH got us
     => CUBSCM30(0F) at 3327:c5c6        < HERE!

     Hmmm..... well, unfortunately we have to reboot again now.... but we
     found something REALLY REALLY interesting! The CALL which lead us to
     the "crash" routine. Immediately reboot and light a cigarette/sip a
     Martini Vodka, 'coz we are near the "clue"!

     Rebooted? ok! Reload and find in memory again the segment as i showed
     you before, but now set a BPX at AA9D. Once doubleclicking etc....
     you'll break here:

     :0015.AA9D E85F0B            call B5FF   < This is the call which crashes
                                                your system
     :0015.AAA0 83C404            add sp, 0004
     :0015.AAA3 5F                pop di
     :0015.AAA4 5E                pop si
     :0015.AAA5 C9                leave

     Hmm.... now a little zen: we found a call which crashes our
     systems.... so let's walk some instructions back until we find
     something (a JNZ/JZ/etc) which JUMPS OVER this evil call.

     Back back back back back back..... Found!!!!!

     :0015.AA8C 9AFFFF0000             call 0012.939Fh
     :0015.AA91 3D0200                 cmp ax, 0002
     :0015.AA94 7512                   jne AAA8   < as we see,it jumps over our
                                                    "evil call"
     :0015.AA96 16                     push ss
     :0015.AA97 8D46BE                 lea ax, [bp-42]
     :0015.AA9A 50                     push ax

     If you examine yourself how the program works, you'll find soon that
     the JNE above JUMPS when AX not = 2... maybe the dongle just checks
     something (or may be something is stored in some locations by the
     initial check with the VXD), and when AX=2 it executes the CALL at
     AA9D and it fucks up our target.

     Well, we can try this right now (a simple changing the JNE in JMP will
     not work, coz at AAA8 there is another check as you will see).

     :0015.AAA8 C746AE0000             mov word ptr [bp-52], 0000
     :0015.AAAD 9AFFFF0000             call 0012.796Dh
     :0015.AAB2 250300                 and ax, 0003
     :0015.AAB5 3D0200                 cmp ax, 0002   < if it's 2 will crash
     :0015.AAB8 7508                   jne AAC2
     :0015.AABA C7064C680300           mov word ptr [684C], 0003
     :0015.AAC0 EB35                   jmp AAF7

     So, try changing the CMP AX,002 in MOV AX,002 at AA91 (and also the
     following JNE in JMP) this will work.... YEAH! We did it!!!!

     Hmm... are we sure? Lets reboot and try some other options... We see
     that we can create as much tracks as we want, we click all over the
     screen and nothing happens... So? nice, yet... try to choose something
     from the menus, say the Score Editor... it might work 1,2,3,4,5 and
     may be some more times...yet it will surely crash again! And at a
     different location...

     Well, at this point i thought i was lost too.... there are a lot of
     locations where the programs crashes, this seems as it would be a very
     long cracking session to change them all... let's give up...

     But... i never surrend!

     Let's go back to the code at AA91. There will SURELY be a place where
     the CMP is done a first time, and destroying it should let all the
     others compare passages work right.

     Therefore... zen again: search back from AA91 until we find an
     instruction which JUMPS OVER!

     Examine again the AA91 part, BUT now, looking at some previous
     instructions, we find:

     :0015.AA76 E92A0B                 jmp B5A3      < INTERESTING!!!!
     :0015.AA79 668B4690               mov eax, [bp-70]
     :0015.AA7D 668946C2               mov [bp-3E], eax
     :0015.AA81 C45E06                 les bx, [bp+06]
     :0015.AA84 2680BFAC0001           cmp byte ptr es:[bx+00AC], 01
     :0015.AA8A 751C                   jne AAA8
     :0015.AA8C 9AFFFF0000             call 0012.939Fh
     :0015.AA91 3D0200                 cmp ax, 0002
     :0015.AA94 7512                   jne AAA8

     As we see, this part starts with a JMP.... what does this mean?

     It means that the code at AA79 (which contains our CMP AX,002 etc...)
     is CALLED (or jumped to) by some other instructions. This means also
     that we MIGHT search for some "CALL AA79" or "JNZ/JZ/etc. AA79".

     Ok, let's try examining the code back, starting from this point. Back
     back back back back back and...... FOUND!!!!!

     :0015.A9B5 9AFFFF0000             call 0012.7470h
     :0015.A9BA 83C402                 add sp, 0002
     :0015.A9BD 0BC0                   or ax, ax
     :0015.A9BF 0F84B600               je AA79
     :0015.A9C3 C45E06                 les bx, [bp+06]
     :0015.A9C6 2680BFAC0001           cmp byte ptr es:[bx+00AC], 01
     :0015.A9CC 0F85A900               jne AA79

     As we can see, there are 2 JE/JNE which refers to AA79!!! Examining
     how the program act when it crashes, we found that every time it does,
     it jumps.

     So, what's better than nopping both the jumps? Well, it's enough to
     NOP the first one! THE END!

     Change your bytes in the file, reload it and .... NOW EVERYTHING
     WORKS!

     Happy sequencing with the best in MIDI programs!

     DONGLES? Ciao ciao (First phase)

                                                                 By +Xoanon
                                                                 .PiNNACLE.



Top
Download 
Tell a friend
Bookmark and Share



Similar Articles

Applied Binary Code Obfuscation
Obfuscation in assembler
(by N.George, G.Charalambous)

Avoiding Windows Rootkit Detection
Bypassing PatchFinder 2
(by Edgar Barbosa)

Bifurcation of variables
An approach at protecting program functions
(by Lord Soth)

Binary Protection Schemes
Code Protection under Linux
(by Andrew Griffiths)

Copylok
Documento tecnico di analisi sul Copylok
(by Kilby)

Extending DOS Executables
How to modify a Windows executable relocating code
(by Digital Alchemist)

SoftIce : breakpoint Win32 API
Entrypoint of most used Win32 routines
(by +gthorne)

Softice Debugger Usage Manual
A very good manual for SoftIce Usage
(by unknown)

Static Detection of Vulnerabilities in x86 Code
Analysis of assembly code for security problems
(by M.Cova V.Felmetsger G.Banks G.Vigna)

Windows Debugging Tutorial v1.00
Piccolo esempio d'uso del SoftIce
(by ED!SON)

Write an assembly program using DEBUG
Example of creating a binary executable
(by JES)

Xoanon-flags
A debugging session in some old protection scheme
(by Xoanon / Pinnacle)

Xoanon-timelock
A debugging session on an old protection scheme
(by Xoanon / Pinnacle)

Yodas Protector 1.02
An exe protector with antidebug, antidump
(by Ashkbiz Danehkar)

 Tags: debug, protection


webmaster jes
writers rguru, tech-g, aiguru, drAx

site optimized for IE/Firefox/Chrome with 1024x768 resolution

Valid HTML 4.01 Transitional


ALL TRADEMARKS ® ARE PROPERTY OF LEGITTIMATE OWNERS.
© ALL RIGHTS RESERVED.

hosting&web - www.accademia3.it

grossocactus
find rguru on
http://www.twitter.com/sicurezza3/
... send an email ...
Your name

Destination email

Message

captcha! Code