------------------------------------------------------------------------------------
bY:ebrizzlez a suck-o.com Production All Rights Pissed Away
------------------------------------------------------------------------------------
::wELCOME!::
100000000001
Welcome their everybody. ;]
Today we'll be taking a tour in Reverse Engineering.
Links
====
Target:
Code: Select all
http://www.sendspace.com/file/tsm5v0Code: Select all
http://www.sendspace.com/file/k49s4m000000000000000000000000000000000
Reverse Engineering is peering underneath the hood of the computer, and looking straight into the memory of an application. Its an art, the act of dissecting a program to see how it functions. Reverse Engineering is taking apart a compiled program and viewing its contents inside to give a more vivid and detailed understanding of the program's interior workings.
What the hell is this useful for?
000000000000000000000000000000000
Imagine you worked for Norton. A breed of a variant of the SQL Slammer worm came out.
It has self modifying code and encrypts each functions and decrypts itself when the code is needed. How would you catch the worm in action? You would have to trace its instruction calls until you get to the decrypt function which than the worm would decrypt itself and we can view what the worm is doing and prevent its execution.
Now you are a virus writer, and you could do the same, but this time improve
that code and make it more undetectable by adding multiple encryption values with different algorithms. Or you can reverse engineer an operating system and peer inside a .DLL that has an api (Application Programing Interface) call and hook onto that call or modify it with a code cave.
Or you can put your patch on and become a pirate and sail the seas of warez. Here you'll be cracking application schemes and protections on copyrighted programs to than distribute for free while you compete with other warezing groups to realize the first crack or keygen.
Let's Get CrackiN
10000000000000001
There's a lot of uses for reverse engineering. Mainly today, I'll be reversing a
program in order to steal its code. That's right, I will be reversing a program to see
how the program functions. To put into question, what API calls does it make? How does
it create its results? What parameters are passed to other executables or dynamic linked
libraries? Well.. you'll find out soon enough my dear friend. ;]
Tools of Trade:
000000000000000
1.PeID - I recommend using my Installer to get a shit load of plugins with PeID.
2.Ollydbg - I recommend using the SnD version.. It's included with my installer. ;]
.386
.model flat,stdcall
.CODE
_Start:
Well... Today we'll be reverse engineering a program by Netix called Graphical
Patch Maker. Yes, indeed you guessed right, its a program to make patches for cracks.
A good idea to start off reversing is to see if the file is packed with a packer. "But wait, Whats a Packer?"
Imagine a packer as a winzip file. It uses special compression algorithms to compress the file to save space on the hard disk. This is done by throwing in a special program called a stub. The stub is a small file, or set of instructions, that decompress the file once its run, it is decompressed and ran into memory with all its proper instructions without damaging the file. Most packers have anti-debugging schemes that prevents execution and debugging of the application. Most cases it uses just checks to see if it has a Ring3 break on the application or checks if the program's process is being hooked onto.
Ollydbg is a ring3 debugger. That means its a user-mode debugger. They're two different types of debuggers... ring3 and ring0. Ring0 is a kernel mode debugger. Kernel mode debuggers are low level debuggers that can hook onto any global memory address, and sees the computer through the eyes of the kernel. Ring0 debuggers are idea for device driver programming and other low level programming. It allows the user to see allcalls being made to global .dlls or other applications and the whole system and whatnot. An example of such is the famous SoftIce. But in our case, Ollydbg is perfect and most likely you'll never actually have to use SoftIce.
/* Vista has a special Data Execution Prevention system. Which prevents access
to ring0 api calls or any low level call from execution unless proper administration
rights are given. */
Hm.. Let's see what PEiD brings up for us:
It seems that its packed indeed. But no need to worry, I already unpacked the file
for you, unpacking a file manually is completely out of scope of this tutorial. So lets
load the file again into PEiD (Note we are reversing unpacked.exe !!!):
Good! Seems our application was programmed in M$ Visual C++ 6. My personal favorite
compiler along side with Bloodshed's DevC++ . ;]
This means we should be expecting to see tons of juicy API calls, which we
have our api help file in hand. The winapi help file is located in the SnD version of
Ollydbg which is named: win32.hlp
/*
Windows Vista users have to download the WinHlp32.exe file to view the api help file.
The download is located here:
http://go.microsoft.com/fwlink/?LinkID=82148
*/
Now we will load the unpacked.ExE into Sir OllyDbg. AH! Olly starts off complaining
about a module 'BASSMOD' if we checked the directory of our program you can see a
BASSMOD.DLL. Olly warned us that their is a call it this file, but no harm to be done,
BASSMOD.DLL is just a xm player. ;]
AH! Help, now theirs a bunch of code. what to do what to do. No need to worry.
The first thing we want to do is simplify things. Let's think logically. Let's first
try to test run this application by making a crack. Goto Debug->Run on Olly's menu and
wait a few seconds as the program loads up and runs.
The program compares two files, the original file and cracked file as we stare
into the GUI. I provided an original file and cracked file for you... located in the
CRK directory. Load up the crackme.exe as the original file and the Cracked as CRACKED.EXE
Now click Build Patch. As you can see, you get a Patch Successfully Created message box. Take note of that. Hm.. Look at that, we have a crack.exe file now, and if we run it, it indeeds cracks the file in the CRK directory. But how was this file created? Lets look through the programs data structure. Two Folders that stun me right away are the PATCH and BIN folders.
In the bin folders we see some interesting files:
LINK.exe - A linker to compile code is a guess.
lcc.exe - LCC is a portable C compiler.
RC.exe - Another componet of LCC
Upx.exe - An executable compressor.
Hm. Seems as the program makes a .c file and compiles it using LCC. But the question
is where and how? Well. Lets check the PATCH folder and see if we get any luck. As we
do, we notice a useless Patch-Build.inf file, but we do see a SKIN folder. This seems
to be where the GUI of the Crack file is made in. Hm. So lets take note of the PATCH
folder and the BIN. And now lets go back to Olly.
Rerun the program and delete the resulting crack.exe made. This time we are going
to set some breakpoints in olly. Breakpoints allow us to step through the code and get
a better visual of how the program functions. All Olly does is set an int3 on the
instruction we select and the program pauses and its handle goes to Olly and all of
its execution is paused and Olly takes control.
Like I said before, this program must compile a .c file and than pass
specific parameters to lcc.exe,rc.exe,link.exe, and upx.exe to compile the crack.exe
file. Tedious and annoying, I know. Let's start by searching for APIs. In
the main thread window, right click, Goto Search For->All Intermodular Calls.
Now we get the whole list of apis this program uses. Sweet! But make sure
you have the win32.hlp in hand because we'll be needing to research some of these
apis soon.
Okay... woah, this is alot of apis. Wait. API THIS, API THAT, API API API. what
the hell is an api? Oh, right.. An API is an Application Programming Interface. It
allows the program to "talk" to the Operating System and handle some nitty gritty
work. Most API calls are infrastructure in the rings, yessir. Ring3 calls are user-mode
calls, APIs have this protection scheme where an RING3 indicates the RING0 which throws
back a handle, but no need to worry until I go into api hooking on later tutorials. ;]
API's are just called made to perform certain operations that are special or specific
and otherwise handled with the operating system itself.
Right click on the shit load of api's and click Sort By->Destination. Now
the APIs are all in alphabetical order. Lets scroll throw and look for some sort of
API that creates a file, and than writes into a file.
Ah ha! If you looked, you'll see a shit load of calls to CreateFileA()
and WriteFileA() . These two functions we will be studying. We also see 3 calls to
DeleteFile() api, which means our program most likely generates three files.
First set a breakpoint on CreateFile(),WriteFile, and DeleteFile. This is done
by right clicking and Selecting "Set A breakpoint on every call to ..."
When this is done, the address is highlighted red indicating we set a breakpoint on
that specific function.
Now that our breakpoints are set, run the program again. Woah. Wait...
what happened, our program just froze? and Now we are at our first breakpoint. Hm. Lets lookup information about CreateFileA()
"The CreateFile function creates or opens the following objects and returns a handle that can be used to access the object: "
In this case, its opening or creating a file named "config.ini" with the mode set to OPEN_EXISTING , which means the file already exist. This doesn't seem important to us,
no .c file being generated. Lets remove the breakpoint by right clicking on the address
Breakpoint->Toggle.
Good, now press run again(you could hit the little play button instead of going
to debug->run). Now our program runs, lets input our files to be cracked. BAM! Breakpoint
again. Lets see what now. It seems to be opening our crackme.exe file for generic read,
so it'll be reading our application here. Once again, in the Open_existing mode, no creating
a .c file here, so lets unset this breakpoint.(Shortcut:Press F2)
Press play. Now load the cracked file. BAM! breakpointed, Again as before, it
calls CreateFileA for generic reading. Remove breakpoint and letss continue..
Press play, woah... Mr. Olly sure does like alot of playing. ;] Now lets click
that Build Patch button and see what... WOAH! our first call to DeleteFile... It seems
its making sure a crack.exe file doesn't already exist so delete if one exists anyways.
;] Unset breakpoint and continue.
Hm. More generic reading on a file now called music.xm, well.. we forgot to
put this, but our crack can play a music file in the format of an .xm. Pretty neat, but
we don't really care. Unset breakpoint and continue...
BAM! wOAH. CreateFile named patch.h? If you scroll up, it makes a SetCurrentDirectory
call to the PATCH folder. hm. lets view the patch folder and see if Olly REALLY makes
this file. Unset the breakpoint press play and than go view the PATCH folder if you
don't belive me. BUT keep olly running. ;]
Aw man, 0 bytes... Olly did as it promised, it created a file named patch.h
which is going to be used to compile our crack.exe using lcc. Now we run into a
WriteFile api. It just writes some ascii text "BYTE bPatcht[] =".. lets unset this and
continue. We should really unset all writefile's because their just writing our information
but you can follow through and see your files slowly being created.
Again another call to writefile, still writing information to patch.h. Just
unset, and continue. We'll get two more calls to writefile, just unset and keep it moving again.
Essentially, we want to follow through until our program makes our patch.h , and we now
know that DeleteFile will eventually delete the patch.h file after compilation is complete.
So we must stop before DeleteFile deletes our patch.h.
Keep on setting the writefiles until you see the writefile with a parameter of
the filename being "main.c". As you can see, this is our main file, patch.h is just a
header file. Whats a header file? Well.. a header file is a bunch of variables and
functions definition that main.c uses. Main.c would be our main program while patch.h
is just a library file. ;]
Unset the breakpoints until you reach the execution of DeleteFile.
It seems now is the part of the program where it deletes our main.c and patch.h
This isn't good. We want these files, so just copy these two files into a different directory.
We basically got what we wanted. We saw how this program generated two files called
main.c and patch.h . Now here's where our programming comes into play.
We can either make our own patcher maker using the apis we've seen in thi
tutorial. Or we can make our own patcher program using the main.c and patch.h program.
As you can see, in the patch.h file, we see the bytes and offsets that are going to
be patched by our program. As well as some other important stuff that the program
calculates for us. Like the size of the music, or file, the executable name,etc.
We could now find the parameters the program makes to lcc.exe,rc.exe, link.exe,
and upx.exe by right clicking the main window, and going to Search For->All Reference
Strings. You could manually find the parameters because they're sent through as a
string.
Pretty neat huh? If you think that using this program's api is impossible to use,
my program Batch2ExeCUTE. Was made by reversing this application and using the same techniques.
It's all about style. We'll.. thats basically the end of this long ass tut.
I'll like to give a shout out to Gogeta70, Maboroshi, and HawttDawgg who I have a blast
talking to on the IRC. Also major thanks to Gogeta for providing me with the gfx for
my installer. If you want me to use gfx you made, just pm me. ;] A big shout out
to bad_brain for making suck-o possible, and a huge thanks to all those at the
suck-o community. I love you guys...
0101010101010
return 0;
0001010101010
//Prevail or fAIL!
