Suggested classification: paper (I think there's nothing advanced
here; but not for absolute newbies; and also the method is very widely
usable - on any computer,any language,any OS)

Suggested essay name: "offline" debugging
---------------------

Here's a 2-hour crack-and-write-essay using particularly SIMPLE method.

About: cracking cd1xedit.exe ver 1.23a
Method used: "offline" debugging

I cracked that proggie, at least removed the annoying nag start-screen.
Of course, dealing the way I do, one can go further and find what-ever
he wants. I'm not interested in the crack nor in the proggie, but in the
method. And will try to explain it here, because 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; the hiew
 just incorporates both of them and saves the annoying (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 because I have no resident one
* BRAIN... nothing else

I have no SoftIce, especially for win; no Ida; no Wdasm. It would be
nice to have these tools, but i must find them, crack them, LEARN
them... and I'm too lazy now...

(if u want, read the 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 -
don't care, it has no any meaning what the protection is)

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. AND IF you crack it wrong, just copy/unzip it
back.

So, 1st I run the PC Magz InCtl3 to listen to the activities of the
proggie (I never ever done this before, but now just tried, because
it's better not to be surprised with some password-check code put
as a registry-item).
Then I run it (cd1xedit.exe). Played 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 initialy 15 hours.

And then I run again and push Register button to see what happens.
There is a window wanting 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 without code there... then I
studied it carefully and saw two suspicious 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, so nothing changes really) 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 FAULT.

**** 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 occurrences 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 allocate some big heap of bytes and
every time zero one, comparing addresses, not numbers... ;-)

Hmmm, let skip the whole function. Just find the RET, (it is RETF
0004, so 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 3 of them 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 executable

We are interested how to make that function disappear... Well, we will
simulate the run (or the stack). Find where is the function start:
0x170E5. Now, look very carefully 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 our
func there is 0x2EE5. Now look just 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 always 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 which code segment it is in EXEHDR's results; find any
references to it; explore them...; etc... by the executing tree...



Here are some more additional tips around this method:

- If you're trying to figure out if some branch of an IF-THEN is
executed, and no visible indication, you can check this by causing an
exception there. If the exception occurs, the branch is executed.

1) type 0xCC which is for INT 03 or something else (INT 77, for
example). IF the proggie is protected mode (386+), that interrupt will
be almost sure not used/allocated and you will get "INVALID INTERRUPT
XX" exception caught by most of the DOS-extenders and 32bit OSes
(win/OS/2/novell/unix..);

2) typing several 0xFF's there. 5 and more contiguous FF's stop any i86x
processor - if your proggie is protected mode (or running over
prot.mode OS) you will get an "INVALID CODE EXECUTED" exception;

- The same tip could be used to figure out if some string is
used/where it is used. Just change the string very obviously (put 5
q's there, for example). After that run the proggie and look
carefully on the screen or at the output file...

- in some (pseudo) interpreter driven programs, the strings are the
only thing you can hook to. So to see if some named
variable/string/field/anything is used where you expect, rename it.
The interpreter usually will stop or will make some obvious stupidity

And, lastly. ALWAYS KEEP some "version-track" of the cracking path
you travelled. It could be impossible/NASTY to restore the crack up to
the previous step - the humans forget... (e.g. make safe-copies of
the most important intermediate states)

Lesson:
IF YOU COULD figure out and use simpler method to do something, go.
Sophisticated techniques are very productive, but are more or less
specific. While the simplest ones are usually very general.


Have a nice drink.
adio
SvD Jan99

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