That's just zeroed bytes. It doesn't mean the memory it corresponds to is actually executable.
Problem with loading a DLL through a code cave
It needs to go somewhere where you know it will be loaded by the OS into an executable memory page. We can't tell without the EXE itself where that might be, so you'll have to look at how PE loading works as well as understand the structure of the actual binary you're trying to modify.
Or you could just do what was suggested earlier, and launch the process under a debugger to see why it won't run.
Author
But does the fact that the size of the modded exe isn't different from the original size, already tell me that the part I am using for my code cave isn't loaded by the OS?
But does the fact that the size of the modded exe isn't different from the original size, already tell me that the part I am using for my code cave isn't loaded by the OS?
When the program is actually loaded into RAM there will be padding at the end of the code section until the next page size boundary (Typically 4096 bytes for a 32-bit process, which it looks like yours is). The linker can optionally leave that same amount of padding in the EXE file itself, but it is not required to.
If you load the EXE in a hexeditor and see a bunch of zeros after the "end" of the code but before the start of the next section listed in the PE headers, that's padding, and you can add instructions there without editing the PE headers.
If there's no padding, then you'll have to rearrange the EXE or scavenge space from some unimportant existing code (perhaps a logging function if you can find any).
Author
Does anyone here know of any good tutorial which explains the process of fixing an executable with a debugger?
The first thing to do with a debugger is to work out why it's crashing. You can do that with visual studio in the same way you'd debug any other process without symbols.
If this is some sort of commercial product you're trying to adjust I wouldn't be surprised if simply noping out a single harmless instruction would stop it loading. They will generally have some kind of built in anti-cheating and copy protection code that go to a lot of effort to make it difficult to do much.
Perhaps a more useful question is, what are you trying to accomplish in the first place? If all you want is to get your code loaded into another process, there are far simpler and easier ways - look up DLL injection.
Agreed with Apoch. It's easier to just CreateProcess(suspended), VirtualAllocEx, WriteProcessMemory and CreateRemoteThread to load a DLL into another process than it is to find space in the existing EXE and patch it.
Author
Thanks alot for the replies guys, I am aware of dll injection and how it works. But I really need to have this dll loaded when the exe, that I am modifying, starts. Without depending on other executables like dll injectors.
I think code caving is my best option.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
