Hi this is Mad typing...

TERMINATE 5.0 CRACKING: PHASE ONE

Enclosed source: tercrk.c

This is probably the hardest crack i have done, 'cause the Strainer ask to
completely explain the inner meaning of Terminate 5.00 key-based protection.
This text contains my first attack to the program, that took me 3 days of work
and revealed some interesting lack in the prog. This is not the real key
generator crack, but rather a different and more easy approach.
I've tried to keep this the more discursive as i can, cause i don't like very
much tutorials based only on: "you see the code, so do this..."

TOOLS USED
HexWorkshop 2.54 regged (any other hex editor could work)
Soft-ICE 3.22 for Windows 95
Your Brain & Patience with a pinch of Zen (these are the MOST important ones)
OPTIONAL: a compiler to get executable files from the C source
(i used Borland C++ 5.0 original)

INTRO
In the Strainer Aesculapius talks about an old 4.0 key, that will not be
anymore valid. So the first thing i've done is to download the TER500.ZIP
(Terminate 5.0), 0400TER.ZIP (Terminate 4.0), and then i started to search
for an old key generator, that i found in about 5 minutes. This is the
UCF key generator for Terminate 4.0, that produces a terminat.key file to
register your copy. Now, i've to test if Aesculapius was right ;-)
I produced my key file and put it in terminat.exe directory, run the prog and
this says, after some tests, that this was an illegally generated key.
Then i rerun all the thing using the 4.0 version, just to see what happens
when a good key is found. The key will work exactly this time, and so i get
a registered version of terminate 4.0. The program do some long check to
validate a key, but this process is executed only one time. So i asked myself:
if the second time you run the prog, it run registered, this means it will
no longer check for the key file, and how could this happen ? The answer is
easy: if the key file checking was ok, the program patch itself to store in
terminat.exe user data derived from the key. And when this process is done,
the original key can hold random data; a file named terminat.key must always
be present in terminate directory, but now it can contain anything.

AND SO WHAT I DO ?
Now i know terminat.exe could contain a flag to check if it is registered, and
eventually it needs a fake terminat.key to be really registered.
I go back to my registered terminate 4.0 and do a file compare between the
registered exe and the original file. I get a list of F5 bytes in the address
starting at 14CDC6 (to 14CEBB). This is garbled data, probably ciphered in
some way. I wrote down the first 10 bytes from the original file at offset
14CDC6 and opened terminat.exe from the 5.0 version using HexWorkshop.
A search of these 10 bytes gives me a location, at offset 161504. So between
the two versions this data area is still equal. But i could not believe this
was so easy. I go back to registered version 4.0, and select bytes from
14CDC6 to 14CEBB, then i copied these bytes to offset 161504 of terminat.exe
version 5.0. I create a fake terminat.key and run the prog: it is registered
with data from the original key.
At this point i was a little disappointed, 'cause i found out the prog is a
little too stupid. The process is a little twisted, but works, and i got a
really registered program, without running a debugger. (This logically
implies we have an old key generator - thanks to the great United Cracking
Force)

...BUT WE ARE CRACKERS, NOT LAMERS...
This approach to the file-registering-without-a-key problem lead us to find
another way out: i decided to create a key-generator for data contained in
terminat.exe. So where we should start ? We want to find a place where we
can breakpoint in the prog. The first thing i've done is to try do get a dead
listing of terminat.exe file (1.4Mb). I opened the file using HexWorkshop
to check if the header contains some packer related data strings. Most of
the time you can get some nice info on the exe (DOS exes) taking a quick view
of them. This exe contains a normal header, so we don't have to deal with
strange packers/crypters (with a file of this size that was very probable).
So i run IDA and load terminat.exe. IDA informs you programs contains overlays
and asks if it should load them. We answer yes and start to wait.
On my 486/33, after one hour the file won't get completely loaded. So, i
closed all down. I tried Sourcer, but that get swamped in overlays. So, we
aren't getting help by a dead listing. Finally we are forced to load Soft-ICE.
The first thing we could try is to breakpoint on DOS file open:
BPINT 21 IF AH==3D
and i run terminat.exe.
Soon we land in the first call. We want to see what file it is opening so we
do a: D DS:DX. This one is opening terminat.exe, for loading it in memory
(remember this is a overlaid file). We press F5 to run the prog again and we
land in another time. This time we got terminat.key. Very interesting, 'cause
we probably are in the key checking routine. But this is not what we are
seeking now. The routine we are looking at starts at CS:3FD and ends at
CS:22AA. We run it until it returns (placing a BPX CS:22AA), and we take a
look at where we are now. We see we are near the end of another call (a RETF
is some lines after).
Now, we can write down some reference:
CS:280A CALL 3FD  (tries to open terminat.key)
                  (we found out later that this is where all the key-file
                   checking happens, and this is what we are going to
                   crack black and blue)
...
CS:2810 RETF    we continue tracing back

So we go back thru the RETF and we land in a very, very interesting place:

(Here we need a small parenthesis, to explain what you could be looking after
the RETF: if you see code like INT 3F you are in the Borland Overlay Manager.
Overlays are loaded and discarded from conventional memory by this interrupt.
For this meaning you should trace thru it using F8, until you get to the
real program. The overlay program structure prevents Soft-ICE from
breakpointing on normal BPX segment:offset, so we must design a new technique
to get where we want. However breakpointing on INTs is still functional.
So, if you see a INT 3F, you should press F8, F8 again and the F10 until
you are back to the real program. If you feel the code, you know when you are
in the right place...;-)

the code you now have in front of you should look like:

CS:2027 CALL    1DF0
CS:202A CALL    0BCB:0020
CS:202F CMP     BYTE PTR [12D8],BB      <- now we are here
CS:2034 JNZ     203B
CS:2036 MOV     BYTE PTR [0064],01
CS:203B CALL    14AE

This code should look very familiar to every cracker... we have a call
to a routine that do some key-file related checking and on return we see
a check on a memory flag. Ok, this is not a standard 0/1 checking, but
who cares ?
The first time i get there i have 8B in [12D8]: i changed it in BB and
let the prog run. Hey - this is registered !!!
(As a side effect we have random data in the options screen, but this is
another problem) - (To see registered user data in Terminate you should press
Alt-O)

Now i was even more disappointed: the program can be easily cracked to obtain
a registered version with unuseful user data, but if i really needed the
professional version this was just enough...
(i should not remember you that if you *REALLY* need this program, you must
pay for it - this is one of the pieces of software paying is worth of it.)

WHAT CAN WE DO NOW ?
The aim of the Strainer is generating a valid key, but i loose this main
project trying to find out how the terminat.exe file decipher data in itself.
Now i got entry point to the routine that does all the checking, and i
want to see how it work.
In the above piece of code we see this routine starts at:
CS:202A CALL    0BCB:0020
so, we trace from there. Remember that we cannot use the BPX breakpoint,
cause for overlays structure this prevents from landing.
So when i got after the call, in the way we described before, i look at the
address of the routine with:
U BCB:0020
This refers to a long jump, in a table of jumps. And after this jump we are
in the exact entrypoint.
For me this is at 4342:2309. So i did a: D 4342:2309 and wrote down the first
17 bytes from the code location.
This must be: 55 89 E5 81 EC 44 05 80 3E 50 00 00 74 03 E9 F3 04
I run HexWorkshop and load terminat.exe (from now, we are always working on
the 5.0 version); i searched for my hex string and i found it at offset
6990C. I patched the first 2 bytes (55 89) to CD 03, to have an INT 03.
I go back to DOS prompt, switched to Soft-ICE, do a I3HERE ON, and run the
terminat.exe. We land at our routine entrypoint.
Now we must restore original code, so we change IP back to 2309.
E CS:IP and we change CD 03 to original 55 89. Now we are in the right place
and we get original code.

HOW THE INNER REGISTRATION OF TERMINAT.EXE WORKS
First of all i must say this is not the right way to solve the strainer.
Why have i decided to work this way ? Mainly for two reasons:
- i believe all this work could in some way help me in protection
  understanding
  (at the end of this part i'll know a new lack in terminat.exe protection)
- the process of auto-registering worked between versions 4.0 and 5.0 in the
  same way, so i think this is a more straight approach to our problem

However, this work would reveal unuseful at the end (at least for the mere
registration need), cause we obtain a perfectly registered terminat.exe,
but the Termail program (installed only in the Full Pack) will depends on
the correct key-file existence. At the same time we have that Termail will
accept key-file generated illegally for the 4.0 version. So we could have
in a very, very twisted mood, a full 5.0 pack.

Now, i'll try to explain how i got a user-data-generator for terminat.exe.
I'll be rather fast in this discussion, cause this is not the main aim of
our work. I'll leave the complete understanding of this routine to the reader.
I've obtained a functional generator in 2 days.

We are looking at the entrypoint of our routine at address 4342:2309.
This routine basically does 3 things:
checks if at address 161504 of terminat.exe there is a 77 byte.
77 means the file has already been registered / BD means not registered
if file is registered, it calculates a CRC of user data and compares it with
the stored one. (at 4342:24BB) Then it checks for another CRC if it is present
if the file is not registered, it checks for the presence of terminat.key and
calls the routine at 3FD (at 4342:280A) - this is where we land if we put
a BPINT 21 IF AH==3D how we do before.

At this point i opened terminat.exe and patched byte at 161504 with 77.
At address 1615D1 i inserted the CRC calculated by the prog (trace the
call at 4342:24BB until the CMPSB and then do a D DS:SI - this is our CRC)
After this 8 bytes we have another CRC, preceded by 08 (this is CRC length)
If this CRC is 00, the prog continues, so we NULL 9 bytes from 1615DA to
1615E2. We save terminat.exe and we run it (remember the INT 3 breakpoint).
Now we have a registered one, but user data is still random.

To completely understand user data deciphering, we must enter the prog, and
trace the routine called when we press Alt-O. This is the only place where
the inner data contained in terminat.exe gets deciphered. I'll not explain
how i found out this (this is a mere tracing work). You don't need to know
from where data is derived, cause when you see it for the first time it is
in its original form.
For the try&experiment reader i'll give the routine entrypoint to put a
breakpoint. The routine starts at 3CD0:A3F (the CS segment is ALWAYS relative,
cause the overlay manager) with bytes:
55 89 E5 81 EC 6C 0F 80 3E 98 62 01 75 07 C6 06 DC 17 71
change the first two to CD 03 and use previously explained technique to get
there. You have to trace to various memory copying routines, until you
get where data is deciphered. This involves 3 consecutive steps, so prepare
to be patient. You will see the 4 lines of user data appearing on your screen,
one after the other.
What i do at this time is to write down all the data used by the program to
decipher user (this was a tiring work at midnite), 400 bytes.
This bytes were calculated using a random number stored at the end of the
terminat.exe registering block.
The registering block in terminat.exe (from 161504 to 1615F9) is so structured:
77 (means registered) 32 (string length) 32h bytes of user data (name)
32 (string length) 32h bytes of user data (address)
32 (string length) 32h bytes of user data (zip/city)
32 (string length) 32h bytes of user data (country)
08 (CRC length) 8 bytes CRC
9 x 00 (this is the second CRC nulled by us)
23 bytes containing other data (random number seed)
This is enough to write down our generator, following this rules:
- first byte must be 77
- every string must be preceded by its length (PASCAL style) and filled with
  spaces when data length is less than 50 bytes
- we must have only one CRC preceded by 08 (its length) and the other one
  nulled (this prevents the prog from doing others checking)
- data at the end (23 bytes) must always be the same, cause upon this reside
  our ciphering process (if we would to change this data too, we should trace
  and reverse all the deciphering routine, but this isn't the case)
- we are not going to crack the CRC calculating routine (even if later we
  have to do it for another task - the real key generator), so we confine
  ourselves to read the program calculated one.

For a more detailed program description, check the source...
This process is intentionally kept tricky, to discourage lamers from getting
a registered copy of Terminate.

END OF THE FIRST ATTACK
                                                        bye, Mad

