What is a relocation item?

Imagine a program that wish to utillize a MessageBox to communicate something
to the user. Written in C code it might very well look like this:

OK ==      MessageBox(NULL, &szCaption, &szText, MBOK);

What does this look like when it's compiled - something like this:

Mem Address	Hex	 	   Code
0x401000	6A 00	 	   PUSH         0		
0x401003	68 00 20 40 00 	   PUSH    402000	; String reference -> 
							; "this is a lame caption"
0x401007	68 00 21 40 00	   PUSH    402100	; String reference ->
							; "this is a lame information text"
0x40100b	6A 00		   PUSH	        0
0x40100d	E8 0C 30 40 00     CALL    User32!MessageBoxA	

Now imagine this being a DLL file. When This DLL file is loaded by a program
either because it's part of the import section or because of a call to
Kernel32!LoadLibrary
This code will be placed at address 0x401000 and forward. Now what would happen
if the program already had a DLL loaded at this address? Both cannot
be loaded at 0x401000 Therefore the operating system loads the second instance
of the code at a different address. The only problem now is that that the 
address of the string is no longer correct 0x402000 would be an address in an
entirely different DLL/EXE file. Obviously Windows designers thought of this.
For each time the compiler sees a fixed address it writes it down in a table
and this table is appended to the file. Normally you'd see it as ".reloc" 
section of your DLL/EXE file. When the operating system loads your file it 
checks if the addresses is already occupied and if they are, it loads it 
somewhere else, then traverse the table and add the difference to each place
that had such a fixed address. Such a fixed address is called a relocation item.


Now Imagine that we're an evil hacker that wishes for some unknown reason
to patch the area from 0x401003 with nop's (90h). 
We patch so it looks like this:
Mem Address	Hex	 	   Code
0x401000	6A 00	 	   PUSH         0		
0x401003	90 		   NOP			; Previously 68
0x401004        90 		   NOP			; Previously 00
0x401004        90                 NOP			; Previously 20
0x401004        90                 NOP			; Previously 40
0x401004        90                 NOP
0x401007	68 00 21 40 00	   PUSH    402100	; String reference ->
							; "this is a lame information text"
0x40100b	6A 00		   PUSH	        0
0x40100d	E8 0C 30 40 00     CALL    User32!MessageBoxA	

The program loads it - but a DLL is already present at 0x401000 so the operating
system displaces it (relocates it) to 0x801000h - updating the code according
to the table of relocation items which we havn't touched results in:

Mem Address	Hex	 	   Code
0x401000	6A 00	 	   PUSH         0		
0x401003	90 		   NOP
0x401004        90 		   NOP
0x401005        90                 NOP
0x401006        D0 90 68 21 80 00  RCL     Byte Ptr [eax+802168],1
0x40100b	6A 00		   PUSH	        0
0x40100d	E8 0C 30 40 00     CALL    User32!MessageBoxA	

Obviously you managed to fuck up the program - sometimes it might work. 
Sometimes it might not. It all depends if the operating system can put the
file where it was compiled to be loaded or not. Worth noting is:
IT IS NOT BECAUSE I NOPPED. IT'S BECAUSE I CHANGED THE CODE THAT THE OPERATING 
SYSTEM MAY CHANGE AGAIN. INC EAX, DEC EAX WOULD'VE FAILED TOO!!!

Obviously such displacements can also explain that the code you see in softice
is not entirely identical to the code you search for in the exe file. Most 
likely you have noticed this if you patched a lot of dll's.


Stone's Relocaction Nopper
Now in all my kindness I made a program that can traverse the tables in a DLL
or a EXE file to see if any given address is touched by a relocation item and
thus dangerous to patch. And even more if the address is touched by a relocation
item - the program can remove it! It's not really a program that is very needed 
because the trained eye can spot relocations items from just looking at the code 
and can in 99% of the cases without any further adue patch another equivalent 
combination of instructions. However for the beginner it might be a handy 
utillity.

Anyways the way it works is:
Feed it the filename. Then write the *file-offset* where you applied the patch.
Then write how many bytes you patched at this offset. Now the program can do
2 things: 
1) Test if the address in question is touched by a relocation item - this is
done by pressing "TEST".

2) "NOP" out the relocation item so that the operating system will not add
any displacement at this address.



Notice however:
It's a simple program - you need to run it over multiple times if you patch
more than one byte in the file you might need to patch out more than one
relocation item. Press "Test"  to make sure... change the fileoffset a byte
forward etc.. 

It's a simple program - more advanced types of relocation items exists. Only
the so called "type 3" is dealt with by this program. It's out of the ordinary
to see other types - but they do exist... (especially in winnt kernel mode 
drivers and systems files)

It's a buggy program - don't count too heavily on it.



Written by Stone
2nd&mi

You may use the provided sourcecode & program as you wish in accordance with 
copyright regulation on the target. I take no responsibility for any damage
caused by the program - blah blah blah. You may modify & use the sourcecodes
to your liking provided you never rip out the "2nd&mi" tag and you MUST buy me
a beer provided we ever meet in real life. Sourcecodes partially written by
NetWalker - so greet him too!

Contact info:
stone@one.se
http://www.cracking.net

