And here my second "script"

Pepper [PC]

===============================================================



Information Manager - another joke to write Registration Schemes.

Or how MS helps to open a nice program...



Have you ever found a program which resists any attack by WinIce

and where no Decompiler exists ? Even no other tool works ? No,

I dont talk about ugly VB 4.0 (thanks to Razzia and others we 

learned a lot on that stuff). Let me introduce a very interesting

set of programs:



Information Manager 2.0

Information Manager ViP 2.0

Music Manager 2.0



All from the same Software House and using a similar Registration

Scheme: just enter a RegCode, no Name, nothing else. So it is no

Shareware to be registered to someone but a Try and Buy program

and maybe excellent (?) protected. Hunting around with WinIce shows

a lot but no final solution. So let us check what kind of Language

is used, perhaps a useful tool, Decompiler or whatever may help.



When breaking into the code we never get into a typcal EXE-File but

tracing around sometimes we run into MSACCESS. Is that a Language ?

Yes, it is more than a Database but has implemented a Basic like

Language. So let us open the Database. It is always a file named

xxx.MDB and really when we open the main MDB-File using MSACCESS

we see: there are not only Data Bases but also Messages, Reports

AND MODULES ! Thats it. A group of modules like xxx.BAS is there.

Now let us open a Module.



Ahh, not possible. We know MsAccess is a complex program and has

features for several protection levels (the User's right to open,

view or modify datas and whatever). Now its time to run WinIce again

but not on the program to be registered. No, we run WinIce and open

MSACCESS. Then open the MDB-File and try a few BPX. Fastest success

is with MessageBeep (DialogBox... also will work). Anyway we jump

right into MSACCESS close to our ErrorMessage "access to the module

is not possible".



I used MsAccess 2.0 (16-bit) in Win 3.11 and all addresses are

from that Version. If using other versions you hopefully will find

the same principle.



When we break into the ErrorMessage let us jump over (F11) and

trace until we pass 2 or 3 RET instructions. Then have a look

some codelines back and you will see a conditional jump:



   MSACCESS(44):203    cmp ax,0

                       jne ...



Here set a BPX and next time let us jump (JMP instead JNE).

Wow! We get another Message: Write Protected, but we can

open and read. Fine, we never asked for more. So let us open

the Module. Great, we got it all. Lets open one after the

other and with a Module "Main..." we see something like:



   x = Format(Now, "########")

   y = (x * 6) / 2

   z = Hex(y)

   ... some kind of compare follows ...



The Source Code looks exactly like VB Code and indeed it is

(both are from MS - thanks to "Billy the Gate"). Now we see

the trick and why there is no simple RegCode: it is generated

from the actual Date:



"Now" is today and "Format ########" converts the Date to an

integer number. Rest is simple. The Compare is done with the

right 5 digits of "z". A KeyGen is now easy and we may create

8 digits where the left 3 digits maybe random and the right 5

are calculated from actual Date.



So far so good. But for further projects we should create a

"special" tool. And why not also enable full access on any

MDB-File, also writing ? We may need it for further projects.



The above patch from JNE to JMP only enables to read a file

if locked in a certain way. For those using MSACCESS 2.0 here

is a "final" solution. After some more tracing we find that a

special DLL is used whenever a decision is made wether access

is allowed or not:



   MSAJT200.DLL



That DLL is a standard one of MS and used for many purposes.

Changing one single byte is the solution for all our problems:



   MSAJT200.DLL    absolute offset 0x3B0F1 is 0x99

                                     patch to 0x90



0x99 is CWD and sets a flag for the later instructions. We disable

that flag by 0x90, the well known NOP. As the DLL is very small

we make a MSAJT200.PAT and a MSAJT200.ORI and whenever we need

our "special" tool we copy the PAT to the DLL (the ORI we may use

to get back our original DLL). Or we write a patcher switching

between - why not.



I think the most exciting was to see: some difficult looking

protection is often very weak. Take one night sleep, think a bit

of the theory and next day there is the AHH! - lets work others

for us like MS.



Pepper [PC]                                  November 1997