In memory patching: three approaches
(how to introduce breakpoints in an automated debugger and other marvels)

by Stone

(20 March 1997)

Advanced Cracking	Papers

---

Courtesy of fravia's page of reverse engineering

In memory patching

Three approaches
by Stone
20 March 1998


After reading MadMax's essay on kernel patching I decided that perhaps
it was time for an essay on "in memory patching". Contrary to the general
+HCU philosophy my approach will be purely theoretical - the sourcecode I
provide will serve as an example for you to build on. 

Is something preventing a patch? Is your target encrypted, packed,
CRC'ed or you need the program to run sometimes with the patch applied 
sometimes without (A game-trainer for instance).Wouldn't you just love 
if you could patch the program in memory after it loaded, unpacked, did 
the CRC checks etc.? 
You can. In the dos days we had TSR's to do this job. In the
windows world it's a bit more difficult as the programming interface (Win32 
API) is dynamic in contrast to dos's static interupt system. However new 
methods which in many ways are similar to TSR's are now avaible.

Kernel patching as MadMax pointed out is generally a bad idea. We need a
more gentle approach. Which critereas would we like our solution to conform
to?
The critereas I'll use are:
1) The approach should perform ok in terms of compatability. That is
work on both NT and 95 and hopefully on future versions as well.

2) The operating system should not suffer any long term effects of the
crack. That is after termination of the target the OS should be left 
unchanged.

3) Only ring 3 measures should be used. (Some of the API-functions I'll
use from ring 3 will actually switch to ring 0, but atleast there will be 
no foreign code introduced at ring 0)


Common ground
Our immediate problem is that in a preemptive operating system like
windows each process runs in it's own addressing space. Each time that the
operating system switches to another process the virtual mapping is changed 
to fit that of the current process. 
The whole idea with memory patching is providing means of patching the target 
in it's addressing space at a certain time (after unpacking, CRC'ing or 
whatever is done). However since a criterium of the memory patch is that we 
can't patch the operating system nor the program itself we need to find a way 
of gaining access to the target addressing space from another process.

The next problem we got is one of timing. Obviously the target needs to
be patched after the CRC check has been performed or after it is unpacked
in memory. And possibly it needs to be unpatched again to pass later
checks. In other words we need a reliable trigger mechanism. It is in this 
respect that the three methods I'll present here differ.


The loader approach
The critical assumption I'll make here is that the USER of the program
can tell us how to time the patch thru another program. 
This basically means we assume that the user can:
1) Identify when patching is appropriate.
2) Switch to another program to activate.

About the first assumption it can be said - if it's a trainer this will
never be a problem. Obviously the user will know when he want's to have
infinate lives. Often a messagebox or some other visable sign shows itself 
when a patch is needed. E.g. A messagebox saying "Insert correct CD in 
drive and press OK" 
It'd be easy to write a doc saying that when this occurs the
dear user should press OK in another window first, and then in the
target's obnoxious messagebox. However this is a serious shortcomming. 
Who said the program will actually let the user make a retry? Most 30-day 
trials tell the user the program has expired and the just exit or get into 
trial mode or whatever.
Perhaps many different locations has to be patch at many different time
making user-controlled patching a cumbersome solution.

On assumption 2 can it be said that many games don't like switching
tasks and it's not likely that users will enjoy having to switch out of 
their game to get a new handful of bullets or whatever.

Let's get a bit more technical. Windows is so nice to provide us with an
interface to write in other processes addressing space. The API needed
is: kernel32!WriteProcessMemory
Taking a closer look at this you'll find that what it actually does
utilize Windows's int 2eh interface to switch to ring 0 meaning that it
has ring 0 priveledges and thus is able to override the page protection. 
However the interface has build in a security feature so you cannot override
ring 0 data/code. (The int 2eh interface is for NT - I figure Windows 95 
does something similar but I havn't checked it. Anyways the result is the
same)

For WriteProcessMemory to work we need to identify by handle which
process we want patched. IMHO the best to find such a handle is to create 
the target process yourself - that is do a good old fashioned EXEC from 
within your patch/trainer code. 

The API is Kernel32!CreateProcessA
Ofcause there are different means of finding process handles.

To synthetize a in-memory-patcher of this kind:
CreateProcessA (Target)
Wait for the user to say apply patch - e.g. amessageboxWriteProcessMemory

Sourcecodes at:
http://www.one.se/~stone/general/trainnt.zip (or something)
----------------------------------------------------------------------

The API-Hook/Debug Approach

Obviously the assumptions made for the Loader Approach can be too 
restrictive. For instance 30-day trials often exit prior to offering the
user any obvious point of introducing a patch. So does a dongle. Players
might not like to switch task out of their beloved game to get another
10 bullets or whatever. What we really need is the target to trigger the
patch and this section is a way of doing this.

The whole idea here is to hook an API-call, and make it perform to our
desire. That can be return fake values under certain circumstances
it could be to patch the main program or it's dll's in memory. In short
what we wish to do is to let the api-call the program performs be
surrounded by our code so that we can make it perform in every way we wish. 
Certain side benefits will come along as well. The code I present will
show how it's possible to introduce breakpoints in an automated debugger
which is indeed something very useful for the creation of for instance
unpackers.

Again let's get down to it. A PE-file "imports" the functions it wishes
to make use of. Because MS-developers decieded on a dynamic structure for
API's it's obviously neasesary for each program to declare what functions it
uses.
This is done in a so called import table. Let's now take a deeper look
into what takes place between the importtable in the PE-file and the
execution of an API call by the target.


3 basic types of information is stored in the importtable. The first is
DLL names, the second is function names and the third is a Thunk-RVA.
The information is stored in a structure that looks something like this:

	DLL1-Name
		Function1-from-dll1- name or ordinal
			Thunk-RVA of Function 1 of DLL 1
		Function2-from-1dll-name or ordinal
			Thunk-RVA of Function 2 of DLL 1
		....

	DLL2-Name
		Function1-from-dll2- name or ordinal
			Thunk-RVA of Function 1 of DLL 2
		Function2-from-1dl2-name or ordinal
			Thunk-RVA of Function 2 of DLL 2
		....
	...

What windows does while loading the PE-file is traverse thru this table 
following this "pseudo code":

  While more DLL's do
     { Load DLL into process addressing space 
         While More Functions imported from current DLL do 
            { Find address of Function and write this to the Thunk-VA
for
              this Function 
             } 
      }
	END Load Imports

The function may be listed by name or something called ordinal. In every
DLL each function that it exports for use by other programs is listed in an 
export directory (which is where windows find the address of the
imported function) in this list each DLL is assigned a number and usually 
a name too.
The number is called ordinal. Importing can be done either by
referencing this ordinal value or by using the name.
             
What the program then does when it's in need of the API-function it is
this: CALL Dword ptr [Thunk VA of needed function]

Lets for a second imagine that we could stop execution of the target
process right before it started and then inject our own code in to it's
addressing space. Then we could simply replace the value at any Thunk-VA 
with a pointer to our own code and our code would be executed every time 
the program decieded to use this API. 

We could even save the old pointer and use this to chain
the original intended API-code. Weeeeeee.. "Isn't this just great?" as
Oprah Winfrey would say. "No, it is not", as I would reply.
  
We are left with a new problem. Or rather two. The first is stopping 
Execution of the target process before the program runs the first 
instruction so that we can be sure that our new pointers are in order.
Second we're left the great problem of having code in the target's addressing
space.

Solving a problem at the time we start by examining how we can stop our 
target process. Many people always state that windows is overbloated and
perhaps they are right - but in this case I'd say that it's damn
convinient that MS-engeneers made a full-featured debug interface while 
designing API calls so that we could with the greatest of ease program a 
debugger without having to do the low-level work ourselves. 

Infact they made it so that not one line of ring 0 code has to be 
written to make an application debugger.
"Isn't this just great?" as Oprah would phrase it? "Yes it is, maam" as
I would reply. Because it get's even better. Windows engineers must've 
actually been thinking the day they made windows. What good is a 
full-featured debug interface if the poor programmer has to make a
PE-loader before he can even start debugging. Hey after all they already 
made a loader and they decieded to be helpful. CreateProcessA can open a
process in Debug mode. 
This means that inside of most windows's procedures hides status
breakpoints that'll turn over the control to our debugger thru that
interface. One of these status breakpoints triggers just before windows
is about to turn over control to the just loaded PE-file. Convinient!

Obviously if a process is in debug mode execution is suspended everytime
a debug event occurs. A debug event is any non-handled exception.
Pagefaults, breakpoints, division overflows, etc. 

And there are 6 different types of status breakpoints inside windows 
that'll be triggering like Rambo in Iraq.
So basically we need to send a message from our debugger process that
it's ok to continiue every time we have encountered such an event. Ofcause if
it's the event we've been looking for we need to do whatever it is we wish to
do before giving the green light to run on. This is the reason behind the
loop of kernel32!WaitForDebugEvent and kernel32!ContiniueDebugEvent
in my code.

So now we know how to stop the program before it actually started. If
you read the previous section you'll know how to exchange pointers. This
leaves us with a grave problem. Injecting our code into the target's 
addressing space.
Now this can be done in many ways indeed. We'll just be looking the one
I chose.

What I'll try to obtain is making the program load a DLL for me. This
ofcause isn't something th program is willing to do without force. Fortunately
for the moment I'm President Clinton and the security counsil has agreed to
bomb the target until it conforms to my ideas. The scene is set at the status
breakpoint just before the target is about to start execution. It is
fully loaded and ready to go. However we're sitting comfortably with it
suspended far far away in our own addressing space. The first thing we got to
agree on is how it is we actually want's the target to do. Load OUR dll, find
the process address of OUR function, replace the one found at the THunk-VA
of the original. We now constuct code that will do just that in deltaoffset
so that it can be inserted anywhere. Prior to actually running the program
we found a page within the target that allowed execution. Most pages in the
target allows execution but we just need one. We now read the page out
the Process space of the target into our own and stores it safely. This is
done thru another subfunction of INT 2eh which ofcause also overrides
pageprotection etc. The API is: kernel32!ReadProcessMemory
See Natzguls essay for a more thourough breakdown of this function. Now
we write our own code that loads a DLL, finds the address of our function
and replaces the Thunk-VA entry of the function with ours. 

Now were ready to go? No. We're left with the problem that execution
should be left otherwise unchanged so that we've written a page somewhere is
bad news.  So in addition to the code we appended we add an INT 3 which will
when executed cause a debug event and once more suspend the target allowing
us to restore the page. Unfortunately EIP of the target does not
neassesarely point to our page, further we use all the registers and those 
needs to be restored too. 

So where do we turn? Windows internal knowledge. Upon creation
that is prior to running any actual program code any one process has one
and one thread only. Further windows allows debuggers to fetch the Context
of a thread. That is all relevant information about the threads current
status. Such a context was originally intended for preemptive multitasking so
that when ever the OS suspended execution of the thread to do another the
context was saved, the address space swapped and another threads context was
restored it's process's address space swapped in place and it was allowed to
continue.
One should be aware that while a thread indeed has full context it's
partly shared with that of the other threads in the process. E.g. the FPU is
shared between threads in a process. Since we only got one thread in our
process the terms of thread and process is incidental.
We ofcause now read the context of our target's single thread, saves it
then changes the EIP in it an resets it to point to our page of code in the 
target processspace. Ofcause our code will now execute till the int 3 we
inserted is reached, then it's suspended and control is back with us. We
now reset the context of the thread and restore the page we abused for
our code. Then we simply let it run.

There is one last unfortunate thing about letting it run. If a process
was created in Debug mode it stays in debug mode till it's terminated. That
means that we need to stay in a loop of WaitForDebugEvent/COntiniueDebugEvent
until that time where the process is actually terminated or the program will 
suspend itself and wait for our instructions. This wasn't too smart MS!

Practical notes on the debug approach
A last side note should be mentioned here. While I was doing this code I
encountered a bug in windows NT workstation 4.0 build 1381. It might
exist on other versions too. Code inside windows looks like this:
mov eax, [offset of Context Storeing space in debugger code]
		; this is obvioulsy a parameter
mov ebx, [Temporaly variable containing ring level of debugger]
test eax,ebx
jnz insuficient_security
everything Ok.
Obviously this is wrong. To overcome this bug make sure that the offset
where you store your context and'ed with 3 is 0.

Further finding the ChunkVA of an imported function can easily be done
by dumping the PE-file with Matt Pietreks PE-dump or similar. He gives the
first chunk for each DLL, if your function isn't the first you add 4 bytes
each time you need to move a line down to find our function.

The sourcecodes for this can be found at:
http://www.one.se/~stone/general/stnapih.arj

---------------------------------------------------------------------

The MessageHook Approach

Forthcoming


source is forthcoming 

---------------

Literature

MadMax! (1998) - madmasu.htm: Cracking useing kernel32??, by MadMax Feb 1998.
	       @ http://fravia.org
Natzgul (1998) - natz_mp2.htm: How to access the memory of a process, a Tutorial, 
               by Natzgul Feb 1998, @ http://fravia.org

Pietrek, Matt - Windows 95 System Programming Secrets, IDG books 1995.


Various sourcecodes by Me :).. all can be found on my page
http://www.one.se/~stone

Thanks must go to:
Patriarch / PWA, friend roomate and local expert.
Random / Xforce, God of the PE-format
Net Walker / Brazil
United Cracking Force, my personal benefactor.
All of which I had many enlightning discussions with.


email: stone(at)one(point)se
http://www.one.se
Stone/UCF'98
2nd&mi!
-----
doc end

kind regards

Stone / United Cracking Force '98

Back to Advanced cracking


Back to the Papers section

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