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 reversers 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...
(if u want, read my other essay at
fravia.org/bulg_1.htm
for
Data
Reversing Techniques. They are useful here)
As it was required, i'll
explain also how i guessed things right.
[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