After having read +Aesculapius great challenge, I decided to give it a try because it's always fun
to sink your teeth into a new challenge. Most of the time you'll also end up having learned
something new on the way, and this was defintly no exception!
A good choice is problaby NOT to read it all at one time, instead read one part at a time. That way hopefully it wont be that confusing (trust me - it's confusing enough already :))
So, enjoy (or dont) my answer to the 1999 HCU strainer!
(oh, and please excuse me for all spelling mistakes)
Output: Terminate v5.0 keygen source and executable
Ah, this program sure brings back some memories! I myself used it quite alot in the good old days when calling BBS's. As I knew nothing about cracking at that time
I used the shareware version, but now with my newly gained cracking skills I thought it was time for revenge! Look out Mr. Bo Bendtsen, I'm out to get you! Well, at second thought I think I'll just
settle with cracking his program. :)
Did +Aesculapius leave any hints when introducing the program in the strainer perhaps? Yes he did, he told us that Terminate uses a "missing key file" protection. Ouch, these are often
pretty tough to crack (and this is no exception), but as long as you have patience, you'll do fine. So, let's start out by creating a bougs file called "TERMINAT.KEY". Fill it with some bogus
text and we're off to cracking land! My fake file was around 5 kb.
As we're dealing with a DOS program we'll have to put breakpoints on an interrupts and not API functions. Int 21, Function 3Dh is "open file using handle" and is used alot
when opening files in DOS, so lets put a breakpoint on that one. "bpint 21 if ah==3d". There, now run the program and you'll find that softice pops up pretty soon.
As you should know (otherwise you can look it up) dx holds the offset to the filename, so "d dx" and we'll see the name of the file beeing opened. Bah, no luck this time
because as you see the name of the file beeing opened is called TERMINAT.EXE, and this is not the file we're interested in. Keep the breakpoint, and leave softice. Back again in softice,
so type "d dx" again and look at the data window. Yeah! The name of the file that the program tries to open this time
is called "TERMINAT.KEY" and this is the keyfile we're trying to reproduce. If this was a windows program we would have put a breakpoint on the "readfile" function by now, but as this is dos
we'll have to use the interrupts once again. This time we'll be using Int 21, Function 3Fh which is "read from file or device using handle".
If you dont know these things, I recomend HelpPC - a great program where you can look up most of the interrupts.
Ok, remove the old breakpoint and instead use "bpint 21 if ah==3f" this time. As this function will read data from file to ds:dx, type d dx again when sice breaks in.
That way you'll see the data beeing read in the data window. Number of bytes beeing read is held in ax once the interupt has been called, so you can see that 162h (=354 dec) bytes has been read (that is if your file was big enough. Otherwise
create a bigger one, around 4-5 kb's or so). Now these newly read bytes must be checked somehow, so let's place a BPR on them, and let the program run again.
Step 1 - The first checksum check
If everything went ok, you should now land in a code that looks like this:
; --- CHECKSUM function --- Checksum: inc word ptr [17D2] ;Increase the counter mov di,[bp+6] ;These couple of lines just increases di with one. les di,ss:[di+FEFA] mov ax,es push ax mov di,[17D2] pop es *mov al,es:[di] ;Get one byte from the read-buffer in al push ax mov di,[bp+6] push word ptr ss:[di+fef8] ;Storage value 2 (first time this value will be FFFFh) push word ptr ss:[di+fef6] ;Storage value 1 (same here, preset to FFFFh) pop bx ;bx = Storage value 1 pop dx ;dx = Storage value 2 pop cx ;cl = the byte we got from the read buffer and ch will be a bogus value (first part of ES actually) push dx ;Save storage value 2 push bx :Save storage value 1 xor bx,cx ;XOR storage value 1, with cx. xor bh,bh ;Set bh to zero, that way we just keep the result from "xor bl,cl" which is : XOR the lower part of "storage value 1" with the byte we got from the read-buffer. Result saved in BL, and BH will be 0. So, BX will hold the result. shl bx,1 ;Shift left one time, thus multiplying bx with 2 shl bx,1 ;Shift left once again, multiplying bx with 2 again add bx,[E320] ;The value at offset E320 is 2014h (atleast for me - most likely the same for you). Add that to BX mov ax,[bx] ;Mov the word that BX points to to ax. mov cx,[bx+2] ;Mov the word that BX+2 points to to cx As you problaby understand, BX works as an offset into a lookuptable. We have to include this lookuptable in our keygen later on. We'll can call ax for lookup value 1 and cx for lookup value 2. pop bx ;bx = storage value 1 pop dx ;dx = storage value 2 push cx ;save cx so we dont destroy it. mov cx,0008 *1: ;Here starts a small inner loop shr dx,1 ;shift right one time (divide dx with 2) rcr bx,1 ;rotate with carry bx one step loop *1 ;jump back to *1, decreaing cx. When cx=0 the loop is done and dx,00FF pop cx ;Restore cx xor ax,bx ;Xor ax (=lookup value 1) with bx (this value comes originally from Storage value 1 The result is the new Storage value 1 mov bx,cx ;move cx, which is lookup value 2, to bx xor dx,bx ;xor dx (originally came from Storage value 2) with bx which is lookup value 2. The result is the new Storage value 2. mov di,[bp+6] mov ss:[di+FEF6],ax ;Save new storage value 1 mov ss:[di+FEF8],dx ;Save new storage value 2 mov ax,[17D2] ;The value at 17D2 works as a counter cmp ax,[bp-4] ;bp-4 will point to the value 15D. jnz checksum cmp word ptr [17D4],01 ;Another counter, we call it counter2 jnz ... (* = You'll land here the first time)Ok, hopefully you understand what this code does by looking at my comments. If not, dont worry to much about it and read on instead. Conclusion so far: 162h bytes is read, but only 15E bytes are beeing processed in this loop (You must remember that the first value is zero, but that also counts, so 15D+1=15E), thus leaving 4 bytes. The only output we got is two words, which I called "Storage value 1" and "Storage value 2". We also know that we have to include a lookuptable in our keygen!
Ok, so far so good. If you continue tracing through the code you'll see that counter2 is beeing compared with 1. Counter2 does equal 1 (because this is the first time we execute this checksum function), and so we're doing some more checks. You'll see that the B'th value in our read-buffer is compared to "46h". If it equals, you'll find that the 1B'th byte is compared to 2F, and so on for a couple of bytes. You dont have to worry about this, as our bytes WONT be equal (that is if you havnt had an extreme bad luck when filling your keyfile), but please try changing these bytes so they do match and you'll see what happends.
Anyway, Let's continue. You'll see that counter2 is beeing increased by one, another 162 bytes is beeing read to our read-buffer (the old info in the read-buffer will thus be deleted), and that the checksum function above is beeing executed again. Trace through the code (I recomend a bpx on the "cmp word ptr [17D4]" line. What happends now is that the first byte in our read-buffer is compared to the second. It they matches, the third is also checked, and so on to the fifth byte. If the all matches we'll add 329h to the "Storage Value 1". This will be true if you for example just filled the whole keyfile with zero bytes.
After this the story repeats itself again - counter2 is beeing increased, 162h new bytes are beeing read and the checksum function is beeing executed again. Counter2 is compared to 5 this time, but counter2 is only equal to 3, so nothing strange happends. The same happends as before, until counter2 is equal to 5. Now something REALLY important happends, but we dont understand much of it yet. But trust me - it will be very important later on. The two last words from the read-buffer is beeing moved into ax and dx (note as these are the two last bytes in the read-buffer, they havnt been processed in the function above). Then some calls are made, and depending on the values we had in ax and dx before the calls, three new bytes has been generated and saved. You dont really have to care about how they got generated, the important thing to remember is where they got saved, and that they got generated from these two values. But anyway, this doesnt concern us yet, so happily we continue!
Nothing strange will happend now for a while, the procedure goes on as usual until counter2 is equal to Bh. Now the 12C'd value in the read-buffer is compared to the 12D'th. If they matches, the 12E'th value are also compared and so on to the 130'th value. If they all match counter2 is beeing increased with 192h. After this a small check simular to the check that was made when counter2 was equal to 1 is executed. Same thing here - dont care about it as they WONT match unless you have one big bad unlucky day!
After this we have finally reached the first real check! Look at this:
mov ax,ss:[di+FEF6] ;This is storage value 1 mov dx,ss:[di+FEF8] ;And this is storage value 2 les di,ss:[di+FEFA] ;This sets di to zero cmp dx,es:[di+160] ;Yeah! the first check! Compares storage value 2 with the last word in the read-buffer. They must match! jnz nogood cmp ax,es:[di+15E] ;Second check! Compares storage value 1 with the 2'nd last word in the read-buffer. These must also match! jnz nogoodOk, now we can make some things a bit clearer. For starters we can figure out the filesize (well, not really, but we can make a very good guess). We know that 162 bytes are beeing read each time the "Checksum function" is beeing executed. We also know that this function will be executed B (=11 dec) times. So, a good guess of the filesize is 162*B=F36h = 3894 dec. Now, how to crack this first check? It's fairly easy actually. The last two words of the file must match these "storage values"! Because if we have a filesize of 3894 bytes, the last two words of the last read-buffer will be the last two words of the keyfile!
Step 2 - The second checksum check
Ok, now that you got the hang of it, I wont desribe HOW to get to the interesting places (it's a couple of BPINT's and some BPR's) as it's pretty easy. Instead I'll try to explain the different protections.
The next thing that happends (if you succesfully managed to get through the last check) is that the decryption algorithm starts. It starts by reading 162h bytes from the begining of our file into a read-buffer. You might think that these bytes are somehow processed later, but this is not the case! These bytes are overwritten with the next 162h bytes, and even they are untouched. So, also these values are overwritten with the next 162h bytes. Finally something happends. A byte from location 5Bh in the read-buffer is moved into al. By now you should be able to figure out what location this byte has in the real keyfile. 162h*3h+5bh=481h. So, 481h is the location in the keyfile of this byte. Anyway, this byte is XOR'ed with FFh, and moved back to the read-buffer again. The next byte is processed the same way, and so it all goes on like this until it has processed the 161'th byte in the read-buffer. A total of 106h bytes has then been processed. Then the next decrytion part begins. I'll describe that one as well, but I'll start by describing another function which I call the "getvalue" function. You might wonder why, but that's because the next decryption algorithm is using it.
; --- GETVALUE function --- push bp mov bp,sp mov ax,[24E6] ;Seed value 1 (preset to 7) mov bx,[24E8] ;Seed value 2 (preset to 0) mov cx,ax ;Move Seed value 1 to cx mul word ptr [12BC] ;The value at offset 12BC is always equal to 8405h ;Output will be in both ax and dx shl cx,1 ;shift left one time shl cx,1 ;same as above shl cx,1 ;same as above add ch,cl ;ch+cl add dx,cx add dx,bx ;bx is seedvalue2 shl bx,1 shl bx,1 add dx,bx add dh,bl mov cl,05 shl bx,cl add dh,bl add ax,0001 adx dx,00 mov [24E6],ax ;the new seed value 1 mov [24E8],dx ;the new seed value 2 xor ax,ax mov bx,[bp+6] ;[bp+6] will always be 100 or bx,bx jz *1 xchg ax,dx div bx xchg ax,dx *1: pop bp retf 0002 ;End of the functionAlright! Now, it isnt very important to understand exactly what every little instruction does in this function. The important thing is that the output value is saved in ax, and that it's generated from two word variables which I called "seed value 1" and "seed value 2".
; --- DECRYTION function --- inc word ptr [17D2] ;Increase the counter mov ax,0100 push ax call getvalue ;The getvalue function. Output is in ax. mov dx,ax ;Move output value from the function above to dx mov di,[bp+6] mov di,ss:[di+FEFA] mov ax,es push ax mov di,[17D2] ;Works like a counter pop es mov al,es:[di] ;Get a byte from the read-buffer xor ah,ah ;Set ah to zero so AX holds the byte xor ax,dx ;Xor ax = the byte from the read-buffer with dx = output from the "getvalue" function mov dl,al ;al is the only interesting part, this is moved into dl mov di,[bp+6] les di,ss:[di+FEFA] mov ax,es push ax mov di,[17D2] ;mov the counter to di pop es mov es:[di],dl ;Move new, decrypted value into the read-buffer again mov ax,[17D2] ;17D2 is the counter, remember? cmp ax,[bp-4] ;bp-4 = 161h jne...There you have it! The output from the "getvalue" function is xor'ed with one byte from the read-buffer and saved again in the read-buffer. Then the counter is increased by one and the next byte is xor'ed with the next output from the getvalue function and so on...
After this algorithm, there are two more that looks exactly the same. The only difference is that the "seed variables" that the getvalue function uses are preset to other values
at each start of a new algorithm. At the start of the next algorithm they are preset like this:
Seed value 1 = 325Ch
Seed value 2 = 0
and at the start of the second algorithm that follows, they are set like this:
Seed value 1 = 904h
Seed value 2 = 33EEh
Apart from that, the functions are identical.
Ok, now we get yet another function that you might recognize. It's the old checksum function that was used for the first check. Both of the "storage values" are first of all preset to FFFFh (just like they were the first time). It works exactly the same way as before, but this time only the bytes from 5Bh to 15Dh in the readbuffer is processed. Just as before, the output will be the two word variables which I called "storage value 1 and 2". After all 15D-5B=102h bytes has been processed another check is done, you problaby recognize it:
mov ax,es:[di+15E] ;Move the second last word of the read-buffer into ax mov dx,es:[di+160] ;Move the last word of the read-buffer into dx mov di,[bp+6] ;Sets di to zero cmp dx,ss:[di+FEF8] ;Compare dx with Storage value 2 jnz nogood ;It they dont match, we take the jump cmp ax,ss:[di+FEF6] ;Compare ax with Storage value 1 je good ;If they match, take the jump jmp nogood ;If they dont match, this jump will be takenHmm, this check is somewhat more difficult to crack than the first one, as all bytes from 5B-161 in the read-buffer is decrypted. That means that the two last words in the read-buffer is also decrypted, and so we cant crack it like the first check. But dont worry - if we're making a keyfile generator (which we ARE going to do) it's pretty simple. As we're not decrypting anything in our keygen, quite the opposite - we're encrypting instead, we already have the decrypted information from start (the name, address, city and country in this case).
So, how to crack it? Let's think a for a moment (yeah, sometimes that can be usefull). We want the two last words
in the read-buffer after they have been decrypted to match the checksum values that are calculated from the decrypted
bytes. It's really no big deal. In our keygen we'll just execute the checksum function on the registraion information
(which we already know is 102h bytes, and stored begining at offset 481h in the keyfile) and we'll get as output these
two words. We'll then save these words after the real registration information in the keyfile! As we in our keygen will later ENcrypt all the registraion
information AND the four checksum bytes with the same (but in reverse order of course) algorithms that is used by Terminate to DEcrypt
the information, the checksums will match!
Ok, I know it might sound a bit complicated, but it's really not so hard. Read the above lines a few times and you'll soon
get it (or else you can email-bomb me or something). Another good thing is to check out my keygen source to see how it works.
Step 3 - The complicated final check
Alright, we have one more check left, and this is the most complicated one. But fear not - As you will soon see it looks a whole lot more complicated than
it really is.
After the above check, we'll see that some other values are created using our two "storage values" as key source. This is done
through a couple of different function, all of them features quite a lot of XOR's, SHL's and other bit manipulation
instructions, trace them if you want. As we dont want to make our work any harder than it already is, let's just step over these functions for now as
we first of all want to find where the check(s) is done. Then we can concentrate on how to crack the checks.
We'll soon get to this piece of code:
push word ptr ss:[di+FEE2] push word ptr ss:[di+FEE0] push word ptr ss:[di+FEDE] push word ptr ss:[di+FEE8] push word ptr ss:[di+FEE6] push word ptr ss:[di+FEE4] push word ptr ss:[di+FEDC] push word ptr ss:[di+FEDA] push word ptr ss:[di+FED8] call Big_checkHey! This must be interesting, so many push'es before a call. This just HAS to be interesting (can you feel it?). For now, lets just step over this call and see what happends.
Performing integrity check on Terminate, before registering...
Hmm, nice, but one thing that isnt very nice is that we never get the control back. The "Big_check" call never finnishes! So, we can now guess that if the keyfile was valid the call would reach an "retf" instruction somewhere and thus letting us have control again. "Our mission, if we choose to except it, it to make the "Big_check" call reach the end (an "retf" function). This message will self destruct in 10 seconds..."
So, now it's time to trace the call. Geeez, that's one big happy function! If you step through all the calls you'll find that there are only three ways that we can reach the "retf" function...there are three checks:
cmp byte ptr [17DC],0 jz perhaps_ready mov ax,[17E4] or ax,[17E6] jz perhaps_ready cmp byte ptr [1802],0 jnz perhaps_ready ... perhaps_ready: mov ax,[BP-4E] mov bx,[BP-4C] mov dx,[BP-4A] mov cx,DB94 mov si,1894 mov di,0731 call checkit jb alrighty jmp loooser alrighty: mov ax,[bp-54] mov bx,[bp-52] mov dx,[bp-50] mov cx,358D mov si,BA5E mov di,747B call checkit ja alrighty2 jmp loooser alrighty2: ...You will see at the offset that I call "perhaps_ready" there will be 5 new checks (I only included 2 of them it above code snippet). If everythink went well here we would reach the end of this call, and that means that we (hopefully) will be fully registered!
But first of all lets concentrate on the first three checks. Do we have to care at all? Lets try to put a breakpoint on the "perhaps_ready" offset (for me this was cs:1ADC). If we dont break we have to fully investigate the whole function and as you know it's HUGE! On the other hand, if we DO break on this breakpoint there is a slim chance that we dont have care about the whole function, just the 5 later checks. So, place the bpx and cross your fingers!
The "bla bla, performing integrity check bla bla" shows up and we'll see the progress-meter doing its work. Hey! After a while we DO break on our breakpoint! Great, if we only would get through these last 5 checks we would reach the end of the function! Lets see what happends...first check went ok...so does the second and third...but oooh no...we fail at the fourth check (this could be a bit different for you depending on what kind of information you filled you keyfile with. I filled it with zero bytes)! To bad! Just to see if we are on the correct path, let's change the carry flag so we DO take the jump. WHOA! We get the "thanks for registering" message!
Lets take a moment or two to think about it (a moment of clarity perhaps? :)). As we know 9 word values are pushed
right before this call. So - based on these 9 pushed values this routine decides if it's a valid key or not.
At the "perhaps_ready" offset you'll see that for each check there are three constants (the cx,si and di regiters) and three
variabels. A good and clever guess is that these varaibles have their origins in the 9 pushed values.
We can therefor draw a conclusion (one should'nt really draw conclusions based on guesses, but what the heck :)):
The nine values pushed right before the call is executed decides if it's a valid key or not.
Of course, our next question will then be How is the 9 word values created? We already know that our two checksum values from check #2 is used, but in what way? What happends??? Let's investigate that! Here is what happends right after the second check has been made:
mov ax,ss:[di+FEF6] ;Storage value 1 mov dx,ss:[di+FEF8] ;Storage value 2 call 2CAE:170B ;What happends here?If we trace the call we'll see that this is the interesting part:
mov al,A0 or dx,dx jnz dxnotzero ... dxnotzero: or dx,dx js blah here: dec al add bx,bx ;bx = storage value 1 adc dx,dx ;dx = stroage value 2 jns here or ch,ch js end and dh,7F end: retAx will hold a max value of 9Fh (A0-1). You can see for yourself whats happening to the storage values. Depending on the sign flag after the "adc dx,dx" instruction the loop may go on. At the end "AND DH,7F" will be executed. As you will see soon it's not very important to understand EVERY part of this call but it is important that you remeber the three output values and how they got created.
Let's continue browsing the code. You will see that the output from the previous call (ax,bx,dx) will be saved away and used in the next call. Cx, si and di is set to zero. If you trace this call you'll see that the output will be the same, no matter what! So, this call is just to confuse a cracker. The next piece of code we'll come to doesnt include our values (they are safly saved away) and thus we dont have to care about it (atleast not now). What we are doing now is truley zen - feeling what code is interesting for us and what is not. Finally we come to an interesting part again:
mov ax,ss:[di+FED8] mov bx,ss:[di+FEDA] mov dx,ss:[di+FEDC] mov cx,0084 xor si,si mov di,2000 call 2CAE:16E5 ...Just as the previous interesting call, we dont really have to understand everything, we just need to know what the output is and how it got created. If you step over the call you'll see that the only value (that we're intersted in) that's changing is BX. How you might ask? By tracing the call you'll find that 14h (=20d) is added to the original value a number of times. The number of times depends on the value in al:
al=9F - add bx,014h
al=9E - add bx,014h*2
al=9D - add bx,014h*4
...
Now we'll see this piece of code:
mov di,[bp+6] mov cx,ss:[di+FEDE] ;Where did these value come from?? mov si,ss:[di+FEE0] mov di,ss:[di+FEE2] call 2CAE:1707 ;Lets call this the "master-check" je 0D7D ;Hmm...a conditional jump here? ...If you trace this call you'll see that:
dx is compared with di
al is compared with cl
bx is compared with si
And as we know ax,bx and dx holds the output values from out previous call and cx,si and di hold some other values that we dont know where they came from (atleast not yet). It's always easier to relate to values if you give them names, so let's call ax,bx and dx for "final check values".
If all these values matches the jump after the call will be executed. If you arent extremely lucky the values will NOT match, so fake the carry flag and take the jump anyway and let the program run.
BOOM - The program is registered!
Great! We dont even have to bother about anything else but making the program take this jump in order to crack it! This jump will produce nine "good" values that are pushed before the "Big_check" call and therefor the program will be registered. First of all we have to figure out where the three values moved into cx,si and di came from. You can do this in a number of ways, I wont even bother to explain how (hint: a bpr is a good start).
Remember when I described the first checksum protection that terminate used I also said something like "this is very important, but we dont have do care about that right now"? Well, now it's time to care about that :). So, go back to where the first checksum function was executed and check out whats happening when "counter2" is equal to 5:
mov di,[bp+6] les di,es:[di+FEFA] mov ax,es:[di+015E] ;Hey! This is interesting! mov dx,es:[di+0160] ;And so is this :) call 2CAE:170BAs you see a word value from the good old "read-buffer" is moved into ax and another one into dx. Lets come up with a name for these two values as well. Lets call them "key values". These values has not been processed in any way and we can really easy find out what offset in the keyfile these values has. 4*162+15E=6E6h (4*162 bytes has already been read and this is the 5'th time) is the the offset for the first one and 4*162+160=6E8h the offset for the second. Then these values are used as input for the call. If you have a good memory (not RAM, we're talking brain here :)) you'll recognize the offset of the call. If you dont, trace it and you will problaby recognize it. It's the same call that is executed right after the second checksum check, but that time the input values was the two storage values. Continue stepping through the code and you'll see that nothing else happends: Another call is executed but that wont change the values (my guess is that it's only good for confusing crackers). A jump is taken and the three new values are saved away.
In case you havnt already figured it out - these are the three values that are used in the call I called "master check". So, we now know the final task - making these three values match the three "final check values". That way we will have a fully functional reg-key!
Ok, it's time to sum up what we already know:
1 - The three "final check values" are created from the two storage values we got from the last checksum check.
2 - Only two calls are executed on these these two storage values in order to create the three final check values.
3 - The first call that is executed on the two storage values is also executed on the two "key values".
Ok, as you see there is not much that differs between how we get "final check values" and the "key values". The only difference is a call that is executed when we're dealing with the "final check values" but this call doesnt do that much. As we already know all that call does is that it add's 14h to bx a number of times depening on the value in AL. That's the only difference!
If that call wouldnt exist it would have been a VERY easy job for us - we would just have saved the two storage values that we got after the second checksum check and used them as the two "key values". But fear not - the solution is pretty easy anyway.
We know that both the storage values will be multiplied with atleast 2 (this is the work of the first call).
We also know that storage value 1*2 will be added with atleast 14h (the second call does this).
The third thing we know is that also the "key values" is multiplied with atleast 2 (the first and only call for them).
Our common sence tells us that we have to add something
to "key value 1" in order to make is match with "storage value 1", and now we can make a simple equation:
x=storage value 1 y=how much we must add to "key value 1" in order to make it match storage value 1 2x+14=(x+y)*2 = 2(x+A)=2(x+y) = x+A=x+y = y=aThere we have it! We just need to add Ah (=10dec) to the storage value we got from the second checksum check and save it as "key value 1". We also need to save the storage value 2 as "key value 2". We already know the offset of the keyfile where these key values must be stored and by knowing that Terminate v5.0 has been cracked! If you want to check out your registration info, just enter ctrl-O when you are in your newly cracked terminate. Hmm, just a bunch of garbage, but from this garbage it's easy to figure out where the offset in the keyfile where the registraion information should be saved. If you're lazy just check out the source for my keygen.
Step 4 - The old-cracked-keyfile check
+Aesculapius mentioned something about "Design a technique to assure that your generated key will be valid in any futher version of terminate..."
Ah, yet another check then. What I did was that I downloaded an already made keygenerator for terminate v4.0 (made by UCF btw) and tried a key generated from
that with terminate v5.0...oops, guess +Aesculapius knew what he was talking about. Terminate does recognize it as an old cracked keyfile and refuses to accept it.
Let's see where the check is made!
Start debuging the program (you should know how it works by now). You'll see that it works just like it would with a normal key, every check is made and it looks like it works perfectly. What I did was that I stepped through the code after the call which I called the "big_check" (you know, the one with 9 values pushed before) keeping an eye open for any suspicious checks. Also I looked if anything was written to the screen by using the rs command in softice. It took a while but finally I saw what was going on, and hopefully so will you. Two words of the decrypted registration information is checked with a number of hardcoded values. If these two word values matches any of a number of hardcoded values terminate terminates (hehe) and says that's it's a cracked key. So, it wasnt really anything complicated with this - the author of terminate has problaby downloaded every single keygenerator or cracked keyfile he could find and then written down the word values at two locations of the decrypted registraion information (they are located near the end of the reg-info). Then he simply made a check to see if the word values of the current keyfile matches any of the "forbidden" values. If they do match - Exit with the error message!
Conclusion - Terminate:
A very nice protection scheme! First a checksum of the whole keyfile, then a checksum of
the decrypted registraion information. These values along with two other word sized values
are then used to make sure that the keyfile is valid. Last but not least is an old-cracked keyfile check
which is acomplished using a check of known cracked keyfiles. These four checks along with some code
that only confuses a cracker makes this protection a very nice one!
Output: Patcher source and executable
Ok, time for some real coding. I decided to use assembler even if +Aesculapius did include an asm example. The main reason for this was that I didnt have any other compiler than TASM that could generate win32 programs. I tried to use some other functions and methods in order to make it a bit different from +Aseculapius's. Not much else to say about this - take a look at the source code instead!
Output: Brains Breaker v2.1 crack
Indeed a fun game to play! In fact I spent about 2-3 hours just playing the game before I started to crack it. It seems like some puzzles are only demos? Hmm, must be a nasty bug...but mr. Juan Trujillo Tarradas dont have to worry, we'll fix that for him! We'll just go to the "enter registraion name/serial" window and crack it like any other program... yeah...right...eh..only one problem... where is it?! At times like this I always go to the helpfile to try to find some usefull information, and look what I found:
Once your payment is processed, you'll receive an e-mail message containing your registration code with the instructions to enter it in the program that makes fully playable all the puzzles (if registered the Full pack) or the puzzles in the Entry set.Ah...The registration window is hidden! How to find it then?
Step 1 - finding the registration window!
I choosed to disasemble the program, and searched after some well-
choosen strings like "registration". I found this hit (after disasming with Wdasm, no need to use IDA if we dont have to):
* Possible StringData Ref from Data Obj ->"Registration info. Program version "Interesting indeed! I browsed down a bit through the code and found alot of even more interesting strings there, including "Pack", "Name", "Your ID" and "Key:". Looks like this could be the place where we enter our registration details. Now we want to know how we execute this code, so we browse upwards through the code. We notice that this code is called from another location:
* Referenced by a CALL at Address: |:0044C881Now we know where this code was executed from. Go up to that location and have a look: