Cracking cd1xedit.exe ver 1.23a: "offline" debugging and other little marvels


By Svd, 9 January 1999
Slightly edited by Fravia+
An essay in the great Fravias tradition... and a nice lesson for protectors as well... I like this essay, full of nice little tricks (like the creation of a small bin to disassemble just the part of the code you'r interested in... of course Svd is right... and I suspect that we are all by now so used to our huge *.alf dead listings that we simply don't always remember that there's a special proud also in being EFFECTIVE without any waste :-(
BTW: I'm using an old Texas Instrument calculator for complex hexadecimal conversions as well (amazing how cheap are these little marvels once they are deemed 'obsolete' by the stupid commercial slaves)... way more effective than even the best software...

Cracking cd1xedit.exe ver 1.23a
method used: "offline" debugging
by: SvD

i cracked that proggy, at least removed the annoyed nag start-screen.
Of course, dealing the way i do, one can go further and find what-ever
else he wants. I'm not interested in the crack as a crack, but in the
method that I will call "offline" debugging.
I will try to explain ut here, coz i've used it for many years with success.
This kind of cracking is very useful, when you don't have proper tools AND
the proggie is not self-checking/protected/compressed... OR
when you have all of them, but they don't give any results :)

Tools i used:

* hiew.exe 5.15 - any hex editor + any disassembler will do;
Hiew just incorporates both of them and saves the
annoing (copy bytes out, disassemble, view) procedure;
* exehdr.exe 3.0 - exe dumper; '1992; use /verbose option some;
* some hex/dec calculator - i use my Sharp coz i have no resident one'
* BRAIN... nothing else

I have no SoftIce, especialy for win; no ida; no wdasm. it will be nice
to have these tools, but i would have to find them, to crack them, and
especially to LEARN how tyo use them... and i'm too lazy now...



[the info i had up to now was: the .exe is win16bit, with delphi
(i.e.Pascal), and some IceLock protection (i've never heard of it)
But that info could be gathered otherwise: 1) run the exehdr - it will
tell you that it is win 3.10 prog; 2) Look at any string table:
strings start with a byte of their size (which means Pascal); 3) and
the proggie itself says that it is not win32s compatible, and author
said may be soon will make it 32bit.]

copy the cd1xedit.exe to have the original somewhere else,
for example copy it as file zzzzz. You may need both the original and
the cracked thing.

so, 1st I run the PC Magz InCtl3 to listen to the activities of the
proggie. then i run it (cd1xedit.exe). Play a little, then close.
InCtl3 said nothing added to registry, win.ini, system.ini.
Anyway, the program remembers somewhere the time elapsed.
and the Time is initially 15 hours.

And then i run again and push Register button to see what happens.
There is a window with some name, password etc...

[now i will describe a wrong suggestion - if you are bored skip it]
**** bo wrong suggestion
So, i made a mistake and started to look for the strings there. I
looked for the "password:" string and i found it with hiew. But that
was some resource-grouped-structure withou code there... then i
studied it carefully and saw two suspicios strings: "ProgramKey1"
and "ProgramKey2". Search for them,... he-he, there they are used...
0x3FE1A... and just before them is the IceLock signature, some names
as strings (possibly window fields) used.
Now disassemble.
((HIEW can disassemble; if your editor can't, here is
another trick. Extract the piece of code that you are interested in,
for example, from ofs 0x3FD00 to 0x40000, write it to file named
somethng.BIN, then run Sourcer or any other disassembler to
disassemble it. A long time ago i did not have HIEW, and made a
little C program, extracting 1K parts from some .exe given a list
of offsets))

I watched there, changed some XOR AX,AX to SUB AX,AX (both are 2
bytes and zero the ax register) in order to see if the .exe is
protected-by-itself - no it was not. But i didn't continue with that
piece of code (there are 2-3 procedures), because changing some other
CMP's and JE to JMPS or NOP,NOP doesn't give any result different than
GENERAL PROTECTION.
**** eo wrong suggestion

Then i thought a little, and run the proggie again. Wait some time,
close it. Run again.... OK, i noticed that time is counted by minutes
only.
OK, multiply 15 hours * 60 mins = 900 = 0x384. Search the .exe for
bytes x84 x03. Here they are: ofs 0x178D1, in some MOV ...[], 0384;
another 2 MOV's a little after that, and a PUSH 0384 immediate. The
rest occurences are not interesting: in some strings, or offsets in
other commands (I'M WONDERING IF SOMEONE SOMETIME will figure out to
count not a simple number, but to alloc some big heap of bytes and
count them, comparing adresses, not numbers... ;-)

hmmm, let ignore whole procedure. just find the ret, (it is RETF
04 - 3 bytes) and type it into the start instead of (PUSH BP MOV
BP,SP) pair.
Run proggie. You see? "YOUR TIME HAS EXPIRED", etc... Well, restore
the bytes as they were.. We have found the time-counter initialization
routine.

[second possibly-wrong suggestion: but gives a light over the next one]
***
hmm, let's change the number in all the MOV's to some other, for
example 0x444 (i.e x44 x04 as bytes). There are come CMP's and JE
before every MOV. hmmm. they are made to ignore the MOV's if
something is zero... Let's make all of them (3) go always through the
MOV's.... Run the proggie... You see? "you have 14:59 left". Despites
that 1 minute before it was 14:42 (for example - it depends how much
we played initially)

ok, now lets see what happens if we change that immediate PUSH. make
it, for example PUSH 0x584 instead of 0x384. Run the proggie... "YOU
HAVE 18:39 left". ha-ha. ok, now we can make it as much as we want,
but how to get that nag screen out...
***

NOW, the most useful part of this comes.
you can use this anywhere in any .exe

we are intersetd how to make that functin disappear... Well, we will
simmulate the run of the stack. Find where is the function start:
0x170E5. Now, look very carefuly at the EXEHDR results: there are all
segments listed on by one, with start offsets and size + other
features.
0x170E5 is in segment 4 (starting at x14200), so the offset of out
func there is 0x2ee5. Now look after the segment table. There are ALL
the cross-references of all the CALL's in the .exe. Search for 0x2EE5,
segment 4. only once. offset 0x2A19, segment 9. Which means (adding
segment 9's start offset 0x38700) file offset 0x3B119 . Now run HIEW
and go there. And disassemble. There are some CMP+JE's somewhere
below....there is CMP+JE's a little before it ....
hmmm, if you play with the jumps after it, you will get the "YOUR TIME
HAS EXPIRED". Let make the CMP+JE's that is before to alsays skip
(i.e. change JE to JMPS).
Here we are. The nag screen disappears.

Now, if anyone is interested, or the protection you have is more
sophisticated, you can follow the same method - find func's start,
look in wchich code segment it is in EXEHDR's results; find any
references to it; explore them...

have a nice dream.
adio
SvD
P.S. for the lazy one's:
Comparing files CS1XEDIT.EXE and original
000178C6: EB 7C
000178D5: 44 84
000178D6: 04 03
000178E2: EB 7C
000178F1: 44 84
000178F2: 04 03
000178FE: EB 7C
0001790D: 44 84
0001790E: 04 03
00017972: 05 03
0003B110: EB 74
--------

svd
redhomepage redsearch_forms redlinks red+ORC redcounter measures redtools redjavascript wars
redreality cracking redacademy database redstudents' essays redantismut CGI scripts
redcocktails redacademy of anonymity redmail_Fravia
redIs reverse engineering legal?