Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

run_pe method not working for executables without .reloc table #63

Open
harunkocacaliskan opened this issue Feb 26, 2025 · 2 comments
Open

Comments

@harunkocacaliskan
Copy link

Hello,

I have an old executable which doesnt have any .reloc section, it was build with FIXED base address. When i tried to run it it says, Could not relocate the module.

I build Hello World Console App with FIXED address for testing.

Image

runpe output.

Image

Do we need to make some modifications for executables which doesnt have .reloc table, or we need to use alternative techniques?

@hasherezade
Copy link
Owner

Hello!
The problem with executables with a fixed base is, well, they can be loaded only at one, defined address. If it was impossible to allocate that memory at that precise address, they can't be run at all. There is no way to relocate the used addresses within it into a new base. This is why I don't support them by default.

It is possible to load them using RunPE method, but if and only if, we can manage to allocate within the target the exact base that is required by the payload. Sometimes, there is already something loaded at this address, so it is not free. If the previous main executable occupies it, we can free this space by unmapping the EXE (as it is done in a classic variant of RunPE).

In my current implementation of RunPE, I don't unmap the original EXE, but load the payload alongside, and then update the base address in the PEB. This is a bit stealthier variant of RunPE. But it won't support your case.
I may do some refactoring that support it, but I am not sure if it is really worth it, since most of the modern PEs use dynamic base.
Try using a different variant of RunPE that does the unmapping of the original module, it should help.

@harunkocacaliskan
Copy link
Author

Hello! The problem with executables with a fixed base is, well, they can be loaded only at one, defined address. If it was impossible to allocate that memory at that precise address, they can't be run at all. There is no way to relocate the used addresses within it into a new base. This is why I don't support them by default.

It is possible to load them using RunPE method, but if and only if, we can manage to allocate within the target the exact base that is required by the payload. Sometimes, there is already something loaded at this address, so it is not free. If the previous main executable occupies it, we can free this space by unmapping the EXE (as it is done in a classic variant of RunPE).

In my current implementation of RunPE, I don't unmap the original EXE, but load the payload alongside, and then update the base address in the PEB. This is a bit stealthier variant of RunPE. But it won't support your case. I may do some refactoring that support it, but I am not sure if it is really worth it, since most of the modern PEs use dynamic base. Try using a different variant of RunPE that does the unmapping of the original module, it should help.

Hello,

Yes i tried unmapping method it works for operating systems up to windows 11 24h2, as we discussed other issue, windows 11 24h2 throws an error 0xC0000141 STATUS_INVALID_ADDRESS. And patching of ntdll not working for fixed base executables. So thats not an issue for libpe. Thanks for your help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants