Cubase -Dongle protection cracking
The main tricks

by Xoanon
(16 May 1997, slightly edited by Reverser)

Courtesy of Reverser's page of reverse engineering

Well... dongle protection cracking, old crackers' songs sing it, old crackers paintings idealize it... let's begin to do it, let's show the world how useless even hardware protections are. This project has been allowed thank to this first sound contribution from Xoanon

I may remark that at the end Xoanon wrote "First phase"... Hey, Xoanon...
dov' la SECONDA fase?

                           Cubase 3.0 UNDONGLED!
                      courtesy of +XoanoN/PiNNACLE 1997

Well, i have seen some of my previous works published by the +HCU.
And for me this is already enough... Wow! To be on "the" site 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: 
Eh eh.... well, i have seen that the +HCU needs something about dongles, so 
why should I not try? Let's see....

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
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!

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 present
0013.3C53 7402                   je 3C57             < NOPPING this lets you run Cubase...
this is how most of the crackers THOUGHT 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):

 * Referenced by a CALL at Addresses:
: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.class" 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.class" 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 EVRYTHING WORKS! Happy sequencing with the best in MIDI

DONGLES? Ciao ciao (First phase)

By Xoanon .PiNNACLE. 
(c) Xoanon, 1997. All rights reversed.
You are deep inside reverser's page of reverse engineering, choose your way out:

Back to project 3
homepage links red anonymity +ORC students' essays tools cocktails
academy database antismut search_forms mail_fravia
is reverse engineering legal?