UNBOX: Why and how to create complete Crack Systems
(RSAGNT32.DLL cracking and a nice trick to avoid difficult memory CRChecking)

by Pepper
(21 November 1997)

---

Courtesy of fravia's page of reverse engineering

Well, another interesting contribute by Pepper. Object oriented cracking, once more. The ideas explained by Pepper here are VERY interesting (and throw a crude light on the trustworthiness of commercial protection schemes) yet something escapes me... would it not be more effective, for the whole scene, to concentrate on MAJOR targets? What I mean is: here (and elsewhere) we have a (clever) crack system for hundred of minor targets... where are the essays explaining the cracks (say) necessary in order to run Microsoft's New Flight Simulator or Microsoft's Age of Empires without the original cd-rom? I always feel a little empty seeing how much cleverness and talent is invested on "minor" protection schemes when there are MILLION of copies of 'hugely advertised' Microsoft's programs roaming around, untamed, in the wild.
This said the recent approach towards object oriented cracking is of course the right one, as Pepper skillfully explains in this nice essay. The memory 'trick' about creating a fake, CRC-correct, file in memory in order to allow the patching and running CRC-unchecked of the 'real' one is a 'magnum opus' idea! Enjoy!

Why and how to create complete Crack Systems
(plus a nice trick to avoid difficult memory patchers)
===========================================

1. Basics
         
The typical crack story is like that:

- Release of a new Program
- Request for a Crack
- Making a Crack (KeyGen, Patch or whatever)
- New Version of the Program is released
- Updating the Crack
- The protection scheme of the Program is changed
- Again a new crack to be done

and so on. A never ending story, sometimes necessary but often
boring. Shouldn't we think of a more systematical way for our
work ? I think so and want to show how in principle such kind
of work can be done. If you are expecting detailed listings how
to crack you will be disappointed. But if you are interested in
learning and understanding the theory and the development process
of Crack Systems please continue. My goal is not to teach you how
to crack but to open your mind to a new approach of cracking.
To avoid plain theory which may be boring I decided to use some
samples which are approved to work. So lets begin...

2. Where a Crack System will be useful

More and more software is distributed on the Net by Electronic
Shopping Centers. You can download hundreds of Programs but have
to unlock before they can be used. Sometimes the program is a trial
software which will expire after a certain time. Sometimes it is
a Full Version which only can be installed after it was unlocked
in the proper way. The principle is always the same:

The original Program is encrypted or packed and you have to enter
a certain Code to make it fully functional. Shopping Centers use
a special kind of Encryption System and for all programs you get
from there the process of unlocking is the same. Here a few Samples
for Electronic Shopping Centers using different Encryption Systems:

 - ZIPLOCK
 - BuyOnet
 - UNBOX

Besides that another method has become more and more popular. 
The software author uses a tool to encrypt his product and now is able
to distribute and sell it on his own. No Shopping Center is needed.
A well established product for example is

 - SalesAgent Wrapper

So if we find a way how to unlock such programs we dont have to
create hundreds of individual cracks, patches or KeyGens. Let us
use as a first sample the programs from the Shopping House UNBOX.
I know that many cracks were made on that subject in the past.
Also some notes on their lousy protection schemes are published. 
But UNBOX is like a virus: creating more and more different versions
of their poor encryption lockers makes a crack to be a never ending
hunting game of fox and rabbit. But you will understand better when
reading the following notes.

3. A first approach to UNBOX

We run such a program in WinIce and try to break into where the
Code is checked. That's not too difficult and rather soon we find
a place where a conditional jump is made - either to start with
the unlocking process or to show an error message. So let us try
to jump to the unlocking process even we had entered a wrong Code
and let us assume it works. In fact there are a few more patches
necessary until the unlocking will work without a correct Code
(depending on the UNBOX Version we use) but that's not our subject.
We will assume that after some time we found a way to unlock a
program within WinIce.

But take care: we made all our tests in WinIce and we still are
far away from a Crack System. So lets patch the Unlocked original
Program and run again... and we get an error message of a corrupt
file. Ugly, ugly. But why shouldn't we look for the place where the
Selfcheck (CRC) of the program is done ? I tell you openly: that
can be horrible. Sometimes you will find a single location for the
CRC, sometimes not. Often the CRC is done more than once and done
on various locations. That means a lot of analyses and later on a
lot of additional patches. We can do so but I want to introduce
another way how to deal with the CRC problem.

Here is the ONE and ONLY part where you will see some Source Code.
I saw some kind of "memory patchers" which work on such stuff (crack
code which is generated during runtime) but "memory patchers" are
difficult to make and also uncomfortable to be used. So have a look
on the following trick - simple but effective.

So far we found

 - we must patch the target Program to unlock it and we know where to patch
 - if we patch the target Program it will refuse to run (CRC)

Now let us use our Brain to find a NEW way. First we analyse what
the target Program is doing step by step:

 - The Program is loaded and executed
 - The Program opens itself into memory
 - The memory content is checked -somehow- to detect modifications
 - If everything is fine the program will continue

Could we load something into memory and let the Program believe it
is "correct" ? First we must know how a Program loads a copy of
itself into memory for CRC purposes. We break into at "OpenFile" or at
"_lopen" or another of the well known Breakpoints. If we know the
location let us trace backwards and we will find something like

        push word ptr [29E2]            (Original)
        push ds
        push 31CE
        push 0104
        call GetModuleFileName
 :xxx   push ...

and we realize what happens here: The Program checks for the Name
of itself and later will use that FileName to make an "OpenFile"
followed by "Read" and so on. Can we modify the Program to accept
another FileName ? We can if we know what the pushed parameters
are:

DS:31CE is the address where GetModuleFileName will store the
FileName. So there we could write what we want to be used as File
to be opended for the CRC. Thats it! We make a copy of our original
Prog, name it to "XXX", write "XXX" to the address DS:31CE and the
CRC will always be right.

But how to write "XXX" to DS:31CE ? We only have a few bytes to
patch for that. So we decide to use the shortest FileName possible
and modify the above coding to

        mov ax,0055                     (Patch)
        mov [31CE],ax
        mov cx,1
        jmp xxx
        call GetModuleFileName
 :xxx   push ...

What does that mean ? Very simple: we have written into DS:31CE
the bytes 55 00 what is the string "U" followed by a zero byte
as indicator for end of the string. That means our FileName is
a single letter "U". We also set CX to 1 because CX should have
the length of the FileName when returning from GetModuleFileName.
Finally we ignore GetModuleFileName (we jump over).

Now all we have to do is: name the copy of the original Program to
"U" and patch the Program as above plus patches required to unlock.

Running the Program will now perform the CRC on the original file
"U" and later on the Unlock process will start.

Let us summarize how far we are:

 - we make a copy of the original Program named "U"
 - we patch the original Program to use "U" as the Program in memory
 - we run the patched Program

But still we have no Crack System - we only learned an important
trick which helps a lot for such kind of protection.

4. A deeper analyse of UNBOX

If you dump a Program from UNBOX you will see the following structure:

 - part 1 is always looking similar (roughly the first 120 kByte)
 - part 2 is always different

That means UNBOX programs consist of a header (part 1) and a body
(part 2). The header is the Program executed when loading, the body
is the encrypted program we want to unlock. The header has a fixed
length, the body is variable depending on the encrypted program.

So lets make a test and strip off the body. Result is the header
only which we name HEADER.EXE (if you dont know how to strip off
you really should learn). In HEADER.EXE we make all above mentioned
patches and run. It works. So what has happened ?

 - HEADER.EXE is loaded
 - HEADER.EXE loads "U" into memory for the CRC
 - CRC is OK ("U" is the identical copy of the original Program)
 - HEADER.EXE starts to unlock because we had patched to do so
 - HEADER.EXE uses "U" to find the body because "U" is the FileName

That simplifies the story. Now we only have to make copies of UNBOX
programs with name "U" and run HEADER. No patcher is required, an
important step to finalize our project. 

Analysing various UNBOX programs we will find a lot of different
headers. That's the reason why our patches we made with one program
will not work on all UNBOX programs. But as we found that only the
header is the subject to be cracked, our project becomes more and
more transparent. We only have to analyse a couple of UNBOX programs,
each with a different header to find where the relevant patches to be
done. So step by step we get a collection of patched headers. We will
also find that each header has somewhere a significant string with a
"FileVersion". That is helpful to identify the header type.

Finally we may have 10 or more headers according to different File
Versions like 2.10, 3.15, 3.17 and so on. Let us name the headers
according to the FileVersion and we will have a set of what we call
"Unlockers":

 - UB2_10.EXE
 - UB3_15.EXE
 - UB3_17.EXE

Do you see that we are now closer to what we call a Crack System ?
We only need a tool to check a Program whether it is an UNBOX type
and which header (FileVersion) is used. Depending on our programming
knowledge we may write in VisualBasic, Pascal, C++ or whatever.
The features of the MainProgram should be:

 - An Open File Dialog to select a Program 
 - A check to scan the selected Program for UNBOX FileVersion
 - A function to make a copy from the Program named "U"
 - A function to run the suitable Unlocker
 - A function to delete "U" when closing (to save disk space)

Finally we will have a nice Crack System with a user friendly shell
and which is modular to be prepared for further upgrades. In fact
the creating of the various "Unlockers" is hard work. Thats the real
cracking... like the work you have to do with any individual program. 
Also the FileVersion is not a fully reliable information, because UNBOX 
once or twice changed the version without changing the Version number. 
But then another scan will identifiy the differences. 
Here we only should have learned how to create a System and what are 
the benfits of such a System.

Limits: why did I use UNBOX as a sample and not ZIPLOCK or others ?
The answer is simple: UNBOX can be cracked as the encryption uses
a so called Single Key encryption (DES) and all required information
to decrypt is inside the program header. ZIPLOCK did the same and
so a crack was possible in 1996. But later ZIPLOCK switched to a
real Double Key protection (RSA). Without the second Key a decryption
is only possible using brute force. You may ask why not all use RSA
and the answer is: RSA is slow and complex, DES is fast and less
complex, some people are clever, some are stupid. No more comments
on that.

BtW: the System is available as UBXWIN v1.9 with 13 Unlockers

5. SalesAgent - a wrapper for anyone.

SalesAgent is an excellent example how to make money. Develop an
encryption system and sell it to others so they can protect their
software and create Trial-Ware or BUY-Ware. It has been established
since a long time in many different versions. A wonderful challenge
for a Crack System. But first we must find the crack itself before
we can think of a System. That's not the subject here. It can be found
using WinIce. But we want to avoid cracking each individual.

So first lets have a look on the so called TRY and BUY software.
Whenever you run such a program you get a trial period. Afterwards
you only can BUY. Set back your date: it will not work. I saw a
fine essay about patching such progs but we want to go "shopping"
without running hundreds of individual cracks.

All that TRY and BUY programs use a special DLL named RSAGNT32.DLL
There is also a 16-Bit DLL around but seldom used. We will find
that some patches in RSAGNT32.DLL will enable to "buy" any program
without a valid KeyCode - as far as we do it running WinIce. Now
lets patch RSAGNT32.DLL and run the TRY and BUY Program. How bad,
a CRC error is shown. So we have to find where the CRC is done and
how to proceed. We will find the check is made in the TRY and BUY
Program. So lets patch the Program and try again. It works.

But we are not done. There are so many versions of RSAGNT32.DLL
around. The latest one seems to be v2.5.0.5 Should we crack each
individual ? And how to see which one is used ? Also we will find
that not every TRY and BUY Program can be patched at the same
address in the same way. And we find that some Programs that will
refuse to work if patched (CRC on its own). Now its time to sort
out everything:

We find 2 basic Types of TRY and BUY Programs:

 - Type 1 makes a CRC on the DLL but if patched it will work
 - Type 2 makes a CRC on itself but not on the DLL

We also find that a patched DLL of Version 2.5.0.5 is accepted
by Programs which originally are supplied with another DLL version.
And we find that during the installation of a TRY and BUY program
the RSAGNT32.DLL usually is copied to the actual folder, but some times
not. If so we find it either copied to the Win95 or the Win95/System
folder. A wonderful mixup of possibilities which all have to be sorted
out before a crack will work. I guess you will understand that one
crack only will work on one Program. So its really time for a System.

We decide to make a Crack System with a MainProgram like for UNBOX:

 - An Open File Dialog to select a Program 
 - A check to scan the selected Program for SalesAgent Type
 - A check to search for RSAGNT32.DLL and a scan for it
 - A check to scan where the Program to be patched and how
 - A function to backup the Program before patching
 - A function to run the patched Prog
 - A function to delete patched Program (to save disk space)

Of course we create a "Crack DLL" named RSAG2505.DLL which has to
be located in the Windows Path. Now depending of the SalesAgent
type detected our MainProg

 - either patches the Program to use our RSAG2505.DLL (Type 1)
 - or rename the RSAG2505.DLL to RSAGNT32.DLL (Type 2)

Also depending on the scan of the Program we make the right patches at
the right addresses. So what we have is a complete system that works
on all kind of TRY and BUY progs as long as RSAGNT32.DLL is used.
And we are modular, what means if we see that our crack DLL does not
work with a special Program we can add another one like RSAGxxxx.DLL

You will agree that its worth to analyse the structures of SalesAgent
protected programs because finally we get a mighty user friendly 
cracking tool.

During our analyses we will find another SaleAgent protection: not
using an external DLL. Here the DLL structure is part of the Program.
That makes scanning even more difficult. But also here we find several
significant byte sequences which allow to make the suitable patches.
That kind of programs are usually BUY only Programs.

All of them are different, and so for all an individual patch would
have been necessary. But if we find a way to do the right scans we
only need one single MainProgram - another kind of a System Crack.

BtW: both Systems are available as PC-RSAG v1.3 and PC-RSBUY v1.6

6. Conclusions

Its obvious that systematical work is more effective than discovering the
wheel every time. The samples above are only highlights but the principle
will work in many more cases. Always remember

 - A patched DLL often is the Key to work with other programs too.
 - Try to find protection schemes and find the common of them.

If you still dont believe that a DLL crack is better than a Prog
crack: please see my note on MSACCESS 2.0. I found a
way to read locked DataBases (*.MDB) patching MSACCESS.EXE but that
was only the beginning. Later I saw that patching MSAJT200.DLL is
much more effective: it enables to read and write to any *.MDB
independently of the kind of protection for the *.MDB

Believe me - its worth to have a deeper look at a scheme after first success !

With greetings to our good old friend Saltine...

Pepper [PC]                                        November 1997

homepage links anonymity +ORC students' essays academy database
tools cocktails antismut CGI-scripts search_forms mail_fravia
Is reverse engineering legal?