This is from a tutorial by gabri3l (ARTeam) and may (or not) relate to your problem
Quote:
The problem is that we cannot save the file in that state. This DLL includes Fixups for those calls.
Fixups are the same as relocations. From the PE format reference by goppit:
When the linker creates an EXE file (OR DLL), it makes an assumption about where the file will be mapped into memory. Based on this, the linker puts the real addresses of code and data items into the executable file. If for whatever reason the executable ends up being loaded somewhere else in the virtual address space, the addresses the linker plugged into the image are wrong. The information stored in the .reloc section allows the PE loader to fix these addresses in the loaded image so that they're correct again.
Basically the hex values of the dll are modified to make sure that the CALL corelib.?AsLong@DCString@@QBEJXZ goes to the right place. If we save the program as is when we run it our hex values will be modified too.
In other words it wont be
CODE
002329FD 33C0 XOR EAX,EAX
002329FF 33C9 XOR ECX,ECX
00232A01 48 DEC EAX
00232A02 49 DEC ECX
But rather some of the hex values will change. this will make the program behave erraticaly.
There is hope though. We can view and edit the .reloc section by using LordPE
Open the dll with LordPE and click "Sections"
Now choose .reloc and Right-Click
Choose "Hex Edit Section"
You will now be looking at the relocation table for the executable.
Each table is seperate for each section of the executable.
if you look closely you will see them seperated by something like the following: 0000002000004001000009
-=snip=-
|
http://intechhosting.com/~access/forums/index.php?act=Search&nav=lv&CODE=show&searchid=069b8e1b05f79333ef7438da71e38c17&search_in=topics&result_type=topics&hl=&st=25