|
Reverse Engineering MATLAB 5
Part I: Dongle Protection
|
Dongles
|
|
12 January 1998
|
by
+Aitor
|
|
 |
Courtesy of Fravia's page of
reverse engineering
|
slightly edited
by fravia+ |
fra_00xx
980112
+Aitor
0100
NA
PC
|
I'm baffled: the level of the essays of our schoolmates is continuously improving,
yet the level of the protection schemes seems (if ever possible) to decrease... does
it depends from the fact that most programmers don't know any more (after so many years
of compelled windoze's lobotomizing) how code works? (and I mean real, mighty code,
the one you feel passing slowly your gaze on it :-)
I don't know, I don't
undertand.
Anyway I'm happy to host this essay by our schoolmate +Aitor and I agree
TOTALLY with his philosophy: "We have (now) our target
working fine -without the dongle- but we are not satisfied. We don't want
to crack this program, we are reversing it in order to learn more ... real
knowledge will be our unique satisfaction..."
Rrright so
+crackers!
(and now let's hope that +Aitor's other essays of a series of
at least three will follow rash :-)
|
|
|
There is a crack, a crack in everything
That's how the light gets in
| |
|
Rating
|
( )Beginner (x)Intermediate ( )Advanced ( )Expert
|
|
"A little essay to show beginners and intermediate reversers how a dongle can
be easily defeated"
Reverse Engineering MATLAB 5
Part I: Dongle Protection
Written by
+Aitor
I've chosen this program because it has got three levels of protection:
1) Program is dongle protected, that is, once you have installed it won't
run without plugging in the dongle.
2) With the program are included *ALL* the toolboxes (sold apart at very
expensive prices, believe me) but they're not mentioned anywhere. These
are InstallShield packed .Z files that cannot be unpacked by the
InstallShield file compressor because they are *ENCRYPTED* ... all the
.Z files in the Matlab 5 CD are encrypted.
3) Once you have built a little decryptor, and all the forbidden toolboxes
are unpacked, a license check appears ...
This essay (the 1st of a series of at least three) deals with the 1st level
of protection ...
Dongle, hardware key, security plug, motxila ... words that sound terrible
to many crackers (mainly beginners) out there. The main aim of this essay
is to show how a hardware key protected commercial application can be
cracked in less than a minute, as easily as you do with many other
shareware targets, and if you give yourself a few more seconds you'll be
able to crack the entire ready made (probably commercial) protection
system.
Soft-iCE v3.2 Win95 (v2.x will be enough; *required*)
Your favourite hex editor (only needed to test the patches)
W32Dasm v8.0 (any version will do; needed for a deeper approach)
The program *iS NOT REQUiRED* to follow the essays. Remember, we are
mainly reverse engineers, not only crackers ... this series will teach you
generic protection schemes, it's not my intention to write one more
how-to-crack to an specific application. Anyway, it's commercial software,
but (hardly) available in the net if you do know how to search.
Not too much to say. A classic among the maths/programming applications,
available for different systems. In my personal software archives (for
educational purposes only :) I've got version 3.5f for DOS dated from
1989, then was a package including PC-Matlab and AT-Matlab, with
only a serial number. Latest version I know is the target of this essay, a
CD-ROM including version 5.0 for Win95/NT and version 4.2c.1 for
Win32s, both serial number + dongle protected.
If you want to know more about this product contact with the The MathWorks
Web site or connect to one of the hundreds of Matlab related sites across the
net.
+-------------------------------------+
+ 1st APPROACH +
+ Fast non-ZEN one-minute-crack +
+-------------------------------------+
First thing we need is installing our target ... a minimal installation
will be enough.
Aurrera with our job! Fire up Soft-iCE and run matlab.exe. Inmediately
you are warned with a fatal error box: "Error checking out MATLAB".
Without closing this box pop up Soft-iCE and check the list of window
handles, you'll see something like this:
Window Handle hQueue SZ QOwner Class Name Window Proc.
------------- ------ -- ------ --------------- ------------
0268(1) 262f 32 MATLAB #32770 (Dialog) 17e7:4757
026c(2) 262f 32 MATLAB Button 17e7:102e
... an so on.
Yes, they are our error box and its OK-button. Let's make Soft-iCE break
the program execution at the moment when the error box is destroyed. Doing
so we'll be able to locate the calling instructions that make our box
appear (this is true in 95% of the protections you'll find, incredible,
isn't it?) only by PRETing within Soft-iCE. Ok, let's put our BREAKPOiNT:
bmsg 268 wm_destroy
and let the program run. After pressing the OK-button Soft-iCE pops up
again:
---USER!GETDLGCTRLiD+0017--------------------------------------
17e7:4757 push bp
17e7:4758 mov bp,sp
17e7:475a push 4793
...
-------------------------------USER(08)------------------------
A few PRET commands from here until we land on the program code:
137:41adc0 call 6b093c
137:41adc5 add esp,14
137:41adc8 mov [ebp-20],eax
137:41adcb cmp dword ptr [ebp-20],0
137:41adcf jz 41adff
137:41add1 cmp dword ptr [6ed6f0],0
137:41add8 jz 41addf
137:41adda call 441544
137:41addf push 10
137:41ade1 mov eax,6c1486
137:41ade6 push eax
137:41ade7 mov eax,6c1492
137:41adec push eax
137:41aded push 00
137:41adef call cs:[8d0ae4] ;fatal error box
--> 137:41adf6 mov dword ptr [ebp-24],0 ;bad guy
137:41adfd jmp 41ae06 ;go out!
137:41adff mov dword ptr [ebp-24],1 ;good guy, go ahead!
Incredible, eh? Can you hear it ? ... it's saying 'crack me' ;-).
Don't think it twice and try a fast non-ZEN patch:
137:41adcf jz 41adff -> 137:41adcf jmp 41adff
After live testing patching code in memory (it works fine), will be easy to
patch the code on disk:
MATLAB.EXE, 3.457.536 bytes (tiny, uhm?)
Search : 74 2e 83 3d
Replace : eb -- -- --
Now run the program and test it with a few samples and demos, everything
works well ... isn't it?!
+-------------------------------------------------+
+ 2nd APPROACH +
+ Breaking down the protection system itself +
+-------------------------------------------------+
We have our target working fine without the dongle, but we are not
satisfied. We don't want to crack the program, we are reversing it in
order to learn more ... real knowledge will be our unique satisfaction
(apart from destroying Micro$oft and see Mr. Bill Fakes crucified, of
course).
Let's take a look at the program again, and see more deeply how the
protection system works. For doing this we must restore the original
unpatched matlab.exe file. Now we are ready to begin, take a look at the
code previous to our first patch:
137:41adb2 push 23
137:41adb4 push dword ptr [ebp-1c]
137:41adb7 push dword ptr [ebp-18]
137:41adba push dword ptr [ebp-14]
137:41adbd push dword ptr [ebp-10]
137:41adc0 call 6b093c
137:41adc5 add esp,14
137:41adc8 mov [ebp-20],eax
137:41adcb cmp dword ptr [ebp-20],0
137:41adcf jz 41adff
137:41add1 cmp dword ptr [6ed6f0],0
137:41add8 jz 41addf
137:41adda call 441544
137:41addf push 10
Pay attention and tell me what's could be happening in the code above.
A series of values is been located in the heap, then a routine is called,
and finally the EAX value returned from that routine is used to check our
access to the program. Let's put a breakpoint at 137:41adc0 and trace the
called routine code. After tracing a little we land here:
-->137:94118a push ebp
137:94118b mov ebp, esp
137:94118d push ebx
137:94118e push esi
137:94118f push edi
137:941190 mov eax,[ebp+18]
137:941193 push eax
137:941194 mov eax,[ebp+14]
137:941197 push eax
137:941198 mov eax,[ebp+10]
137:94119b push eax
137:94119c mov eax,[ebp+C]
137:94119f push eax
137:9411a0 mov eax,[ebp+8]
137:9411a3 push eax
137:9411a4 call 941525
137:9411a9 add esp,14
137:9411ac jmp 9411B1
137:9411b1 pop edi
137:9411b2 pop esi
137:9411b3 pop ebx
137:9411b4 leave
137:9411b5 ret 14
This piece of code iS NOT from MATLAB itself ... where could it be located?
Take a look at our MATLAB\bin directory:
Directorio de C:\MATLAB\bin
BCCENG~1 BAT 1.426 21/11/96 15:58 bccengmatopts.bat
BCCOPTS BAT 1.632 21/11/96 15:58 bccopts.bat
CMEX BAT 2.274 21/11/96 15:58 cmex.bat
FMEX BAT 2.274 21/11/96 15:58 fmex.bat
LIBENG DLL 29.696 22/11/96 9:51 libeng.dll
LIBMAT DLL 60.416 21/11/96 12:05 libmat.dll
LIBMX DLL 40.960 21/11/96 12:05 libmx.dll
LIBUT DLL 40.960 21/11/96 12:05 libut.dll
MATLAB EXE 3.457.536 06/01/98 7:24 matlab.exe
MEX BAT 18.152 21/11/96 15:58 mex.bat
MEDIT EXE 144.896 04/12/96 13:43 medit.exe
MEXOPTS BAT 1.721 21/11/96 15:58 mexopts.bat
MFC42 DLL 1.013.520 21/11/96 12:05 mfc42.dll
MIPC50 DLL 248.320 21/11/96 12:05 mipc50.dll
MLAPP TLB 2.789 21/11/96 12:06 mlapp.tlb
ML_16 DLL 14.708 21/11/96 12:05 ml_16.dll
MLPTOOL EXE 42.496 21/11/96 12:05 mlptool.exe
MSCTOF DLL 31.744 21/11/96 12:05 msctof.dll
MSFOPTS BAT 1.649 21/11/96 15:58 msfopts.bat
MSVCEN~1 BAT 1.701 21/11/96 15:58 msvcengmatopts.bat
MSVCIRT DLL 74.752 21/11/96 12:05 msvcirt.dll
MSVCOPTS BAT 1.599 21/11/96 15:58 msvcopts.bat
MSVCRT DLL 267.536 21/11/96 12:05 msvcrt.dll
MWOLES05 DLL 43.520 22/11/96 11:51 mwoles05.dll
PERL100 DLL 525.312 21/11/96 12:05 perl100.dll
PERL EXE 36.352 21/11/96 12:05 perl.exe
SHOWDLLS EXE 49.668 21/11/96 12:05 showdlls.exe
WATENG~1 BAT 1.701 21/11/96 15:58 watengmatopts.bat
WSPTOOL EXE 60.928 21/11/96 12:05 wsptool.exe
LICENSE DAT 167 06/01/98 7:24 license.dat
W32SSI DLL 66.560 02/04/96 11:01 w32ssi.dll
31 archivo(s) 6.286.965 bytes
2 directorio(s) 46.161.920 bytes libres
Most of the files have (more or less) the same date: 21-22/11/96, but there
are four of them that have not:
MATLAB EXE 3.457.536 06/01/98 7:24 matlab.exe
MEDIT EXE 144.896 04/12/96 13:43 medit.exe
LICENSE DAT 167 06/01/98 7:24 license.dat
W32SSI DLL 66.560 02/04/96 11:01 w32ssi.dll
matlab.exe : main executable, installation date stamped
medit.exe : Matlab editor/debugger
license.dat : ASCii license file, installation date stamped
w32ssi.dll : what the hell could be this?
Take your favourite hex editor, search for our code and EUREKA! To read it
better take W32Dasm and get its dead listing (about 245 kb):
Exported fn(): wSSIEIni - Ord:000Fh
:40118A 55 push ebp
:40118B 8BEC mov ebp, esp
:40118D 53 push ebx
:40118E 56 push esi
:40118F 57 push edi
:401190 8B4518 mov eax,[ebp+18]
:401193 50 push eax
:401194 8B4514 mov eax,[ebp+14]
:401197 50 push eax
:401198 8B4510 mov eax,[ebp+10]
:40119B 50 push eax
:40119C 8B450C mov eax,[ebp+C]
:40119F 50 push eax
:4011A0 8B4508 mov eax,[ebp+8]
:4011A3 50 push eax
:4011A4 E87C030000 call 401525
If the dongle is installed this call returns EAX = 0. If not, it will
return EAX = -1 ($FFFFFFFF). The aim is clear, isn't it? ... we'll patch
this function to return always EAX=0. There are multiple solutions, e.g.:
:40118A 55 push ebp :40118A 33c0 xor eax,eax
:40118B 8BEC mov ebp,esp ---\ :40118C c21400 ret 14
:40118D 53 push ebx ---/
:40118E 56 push esi
After live testing patching code in memory (it works fine), will be easy to
patch the code on disk:
W32SSi.DLL, 66.560 bytes
Search : 55 8b ec 53 56 57 8b 45 18
Replace : 33 c0 c2 14 00 -- -- -- --
Now run the program and test it, everything should work fine ...
We don't care (by the moment) about how messy things are done inside the
hardware checking routines, but if you trace the code inside the DLL you'll
find code snippets like this:
...
:401712 push eax
:401713 mov eax,80992014
:401718 push eax
:401719 push dword ptr [4070A0]
:40171F call dword ptr [407050]
:401725 mov eax,[4070A0]
:40172A push eax
:40172B call dword ptr [407054]
:401731 mov dword ptr [4070A0],-1
:40173B jmp 40175A
:40173D mov ebp,[4076A4]
:401743 mov esi,[4076A8]
:401749 mov edi,[4076AC]
:40174F mov edx,9966
:401754 mov ax,8
:401758 out dx,ax
...
or this:
...
:40197B mov edx,9966
:401980 sub eax,eax
:401982 in ax,dx
:401984 cmp ax,9966
:401988 jne 401A67
:40198E in al,dx
:40198F cmp al,55
:401991 jne 401A67
:401997 inc edx
:401998 in al,dx
:401999 cmp al,88
:40199B jne 401A67
:4019A1 mov edx,9964
:4019A6 sub eax,eax
:4019A8 in ax,dx
:4019AA and eax,FFFF
:4019AF mov edx,eax
:4019B1 cmp ax,1000
:4019B5 jb 401A67
:4019BB and al,3
:4019BD jne 401A67
:4019C3 mov [4070A4], edx
:4019C9 mov byte ptr [4070F1],1
:4019D0 jmp 401A67
...
quite interesting material, but not for this essay ... may be in a future :)
This 2nd approach give us two iMPORTANT advantages over the 1st one:
1) Our target only calls the dongle checking routine once at startup,
but you'll find applications that make multiple callings from
anywhere at anytime during its execution. An example of this could
be AutoCAD 13 from AutoDesk. Its protection check is mainly the
same, you reach one point in the code with a call returning EAX=0 =>
good guy, and this is called not only at startup, but some more times
while the program is running. If you take the 1st approach as a model
for this kind of targets, you will must patch *any* references to the
call ...
2) When a programmer distributes part of the code in DLLs he does it in
order to reduce the size of the main EXE freeing it from the
additional load of routines that are used only one or two times along
the program, but most of the times do it to *share* routines among
different applications ... taking into consideration the date of the
w32ssi.dll file it won't be very strange to find the same DLL
in other applications out there, and if this was the case we'd have
broken down a ready made protection system ;-).
Like many other contributors to this pages English is not my mothertongue ...
... sorry for any inconvenience, be patient ;).
Greetings to all the reverse engineers from Euskal Herria (Basque Country) ...
... jotake irabazi arte !
(c) 1998 by +Aitor and the +HCU. All rights reserved.
I won't even bother explaining you that you should BUY this target
program if you intend to use it ... this is not shareware ;-). If you
own a legal copy of the program, take into consideration your country's
laws about reverse engineering. Here you got an extract from the LiCENSE.TXT
file included in the CD (read it, this is valid for any other commercial
software you own in the EU):
"In relation to the Programs which Licensee is entitled to use, Licensee shall
not decompile, disassemble or otherwise reverse engineer the Programs except
with respect to European Union Licensees whose rights are as follows:
EUROPEAN UNION: Licensee may only decompile, disassemble or otherwise
reverse engineer the Programs where any such act is necessary to create an
independent program which is interoperable with the Programs or with another
program or to observe, study, or test the functioning of the Programs solely
in order to understand the ideas and principles which underlie any element
of the Programs ("the Permitted Objective") and provided that:
(a) this may only be done if the information necessary to achieve the
Permitted Objective has not already been made available or has not been
provided by TMW within a reasonable time of a written request to TMW to
provide such information;
(b) the compilation, disassembly or reverse-engineering is confined to those
parts of the Programs necessary to achieve the Permitted Objective;
(c) the information gained is not used for anything other than the Permitted
Objective and is not disclosed to any other person except as may be
necessary to achieve the Permitted Objective; and
(d) the information obtained is not used to create a program substantially
similar in its expression to the Programs including, but not limited to,
expressions of the Programs in other computer languages, or for any other
act restricted by copyright in the Programs.
You are deep inside fravia's page of reverse engineering,
choose your way out:
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?