Reverse Engineering a Compressed Target (Phase I) A surgical attack (we cut open the target, repair the damage, then stitch it up again)	Packers
5 May 1998	by +ReZiDeNt	+Cracker
	Courtesy of Fravia's page of reverse engineering	"Europaized" by fravia+ :-)
fra_00xx 980505 +Rezident 0110 PU PC	An essay by +ReZiDeNt! There is actually no need for comments, Yet I will comment it nevertheless... 1) I have added "Phase I" to the title because I hope there will be some phase II, III, IV, you name it... I love +crackers that EXPLAIN things instead of simply (and boringly) cracking a given, hyperspecific, target's protection :-) 2) Am I mistaken or +ReZiDeNt is working quite a lot on 'his' "beep" cracking techniques? :-) 3) This essay is a MUST for all reversers that want to understand how to tackle packed files. 4) This essay reminds us (once more) of the NEED to crack "oldies" (i.e. DOS targets) in order to better understand reversing... so strange it may seem for some of you: the last windows protections are (often, not always) very easy to reverse and the old DOS protections are (often, not always) very cleverly drafted... speak of programmers' development and progress... it's an aera of programming "decadence"... unfortunately, and you should thank Billyboy for this :-(
	There is a crack, a crack in everything That's how the light gets in
Rating	( )Beginner (x)Intermediate ( )Advanced ( )Expert

Before I start I want to make something clear. I am reversing this program because I want to see what "makes it tick", or put another way, to learn. In most parts of the world (and most definitely within those countries swallowed by the "European Union") this is perfectly legal and legitimate. I do not use this program (it has been deleted from my computer) and I have not released a patch for it - and don't let me catch you making a crack with the info from this essay - if you do you will be regarded as a "lamer" by +all! You have been warned.

I'm going to abandon our beloved SoftICE for now, and instead turn our

attentions to a clever little program called TR. This incredible tool is

easily available as shareware all over the internet (you do know how to

search don't you? If not, go away and learn, come back and rejoin the rest

of the +class later), and it has some very nice features. It is very

compact, has an interface very similar to SoftICE and it can also be used

to unpack files. It works find in a DOS box under Windoze 95, and although

it can only debug DOS programs it is still very useful. It is capable of

evading quite a few tricks that would crash other debuggers/tracers.



On to the target, Simply Docs 3.0. This is a program that you can use to

create self-displaying text files, with a nice little menu, options to

print, load as a TSR etc. This is a fairly old program, you might have

trouble locating it, I don't think it is being sold anymore.



Anyway, any document EXE you create with the shareware version of this

application has a little nag screen at the beginning. This nag screen is

preceded by an irritating beep, and in order to get past the nag screen

you must push the random number indicated. Presumably this is to ensure

that the nag screen lives up to its name.



If we want to remove the nag, we run into a little problem. Since the

program generates EXEs, how can we stop it from inserting the nag? There

is no way of registering the application (the author will instead snail

mail you a floppy with the complete version), so where do we start? Well,

first use the program to create a little test EXE. Stepping through it

with TR, we find the below call:





:065B  9A0200A443   CALL FAR  43A4:0002      ; beep!





Continuing our exploration, we step over a number of repetitious

instructions that display the nag, before we arrive at the below:





:075B  833E10031B   CMP       [WORD 0310],1B ; did the user push a key?

:0760  7503         JNE       0765           ; jump if not 'ESC'

:0762  E9D513       JMP       1B3A           ; exit from program

:0765  A19C02       MOV       AX,[029C]      ; load key user must push

:0768  053000       ADD       AX,0030        ; add 0x30 to get ASCII char

:076B  3B061003     CMP       AX,[0310]      ; compare with key pushed

:076F  75E7         JNE       0758           ; beggar off if wrong

:0771  A11203       MOV       AX,[0312]      ; else end the nag!





So to jump over the nag we can just replace the call to the beep function

with 'JMP 0771' - well, not quite. Try to search for the necessary hex

chars in the test EXE, you won't find them. The reason for this is that

the EXE is compressed, so it's time to get out our next tool, UNP, to

unpack the EXE. You will find that UNP reports that the EXE was compressed

using LZEXE V0.91 or V1.00a. Unpack the EXE and patch it (no, I'm not

going to give you the hex string - I'm writing this to show you a method,

not to give you a crack).



Once we have done this we can patch the EXE and run it without the nag.

CRASH! No, it doesn't work! This is because the program has been generated

believing it is compressed, uncompressing it messes it up. We need to

recompress the EXE, so enter the third tool, LZEXE (get version 1.00a from

http://www.suddendischarge.com). Using this we can repack the EXE and now

it works nicely, no nag at all.



OK, but this is nothing special, we've haven't actually reversed Simply

Docs at all, so let's get to work on it. This is where a little 'Zen' is

needed. Looking in the Simply Docs directory, you will notice two little

files called SDOC1.OVL and SDOC2.OVL - if you look at them with a hex

editor you will see that they have an EXE header, and they are also

compressed with LZEXE. These overlay files are where Simply Docs stores

the code which it 'wraps' around your textfile to make a self-displaying

EXE. Using just a little intelligence, you should immediately realise that

this is where the protection is hidden.



Uncompress SDOC1.OVL and step through it using TR (yes, you can step

through it!) - let it run and it will exit with the message 'unable to

open document'. This confirms our suspicions that this is where the reader

code resides. Using a hex editor you can patch this file in exactly the

same way as the test EXE we made earlier (search for the same hex string

and patch it)! Now recompress the patched SDOC1.OVL using LZEXE and make

another test EXE - no nag! Simply Docs will now make nag-free

self-displaying EXEs.



You might be wondering what SDOC2.OVL is for - if you look around the

Simply Docs program, you will find that there are two version of the

reader - a full version and a 'lite' version, with fewer options. The

SDOC1.OVL contains the reader code for the full version, while SDOC2.OVL

stores the code for the 'lite' version. I'll leave it as an exercise to

the reader to investigate the SDOC2.OVL, but it can be patched in the very

same way (but the hex string is a little different).



Anyway, the moral of this story is that we should not neglect old DOS

targets, there are often many ingenious and unusual protections lurking

inside them, and reversing them can be a lot of fun and a good way to

sharpen your 'claws' (as I did with this target).





Good Hunting,

+ReZiDeNt

Keep an eye out for older programs with interesting protections! 

Back to projunpa

homepage links search_forms +ORC students' essays academy database
reality cracking how to search javascript wars
tools anonymity academy cocktails antismut CGI-scripts mail_fravia+
Is reverse engineering legal?