Flag: Tornado!
Hurricane!
|
|
Topic created on: September 6, 2005 23:30 CDT by dzzie  .
anyone see any hidden bombshells in this experiments future?
http://sandsprite.com/CodeStuff/Using_an_exe_as_a_dll.html
|
A lot of EXEs have stripped relocations and won't load on a different imagebase. Though I guess it should be possible to link the host EXE with a different imagebase...
|
Yea...base relocations are your only real difficulty. EXE's and dll's are actually identical in structure. EXE's can export functions as well...they just don't often do so. It'd be very easy to build an export table in memory for that exe...but yea...it'd have to be loaded at it's requested base address.
I've written some code that manually maps a dll into memory(for dll injection), and executes it, which may be of some interest to you:
www.darawk.com/Code/ManualMap.cpp
and also I wrote my own version of GetProcAddress to work with these modules(as the real GetProcAddress verifies that the module handle is valid...on a ManualMap'd dll, that would not be the case), if you're interested in parsing/building export tables.
www.darawk.com/Code/GetProcAddress2.cpp
|
doesnt editbin /rebase relocate the exe if needed ??
without having relocation table ??
i havent tried relocating exes but i have relocated
some dlls to have differnet imagebase rather than the default 0x10000000 address
actually it was a petite packed dll that was erring with some unknown reasons to load
i managed to find that my avgs dll was already loaded at that address and that was creating the problem
so i manually did
editbin /rebase blah.dll 0x15000000 (used the equivalent editbin from masm32 package that actually
formats the argv to have link -e /rebase
and uses the ms linker to relocate the dll
|
I just skimmed the linked article, but I don't get the problem...
You just LoadLibrary the file, the handle you get back is the base address, and you just call a fixed offset to the function you want, right? I did this for TSGrinder...
What am I missing?
|
"Calling a fixed offset" won't work if the exe is not loaded at its imagebasde and the called code is not position-independent.
anonymouse: rebase works only if relocations are present, which are almost always present in DLLs. EXEs have them often stripped.
|
Yes, calling a fixed offset (fixed from the base of the .EXE got loaded at, which LoadLibrary returns to you) will work. I've done it.
But I'm making the assumption that the functions can't move independently of the offset. I.e. if you use IDA Pro to determine that the function is at 0x4012C0, then you can always call $base + 0x12C0. I could see that being a bad assumption, has anyone observed something to the contrary? I'm under the impression that the offset fixup process is a pretty simple one...
|
No.
You cannot relocate an exe safely, unless it's a 'test' one.
- you cannot know if a given value is an addr ref. or a constant.
- you cannot know if it's obfuscated code/part of opcodes.
Therefore, you cannot safely do such relocation. You risk to alter code and data. And you would surely end up doing it in complex or obfuscated applications. And what about apps that use 'non-traditional' calling systems? They would always bang.
|
thanks for the thoughts guys
in the very simple test app, it continues to work even if i zero out the relocations fields, overwrite relocations table itself. In these cases it is also loading at 410000 instead of its expected base of 400000 because of an nls file coming in at 400000. I also tried packing the post modified file (added dllmain ret 1) with upx and still working.
with that said, I am now testing with a more complex md5 executable. In both tests my loader is based at 800000, in the md5 example I am now trying to UnMapViewofFile(0x400000) to get the exe at its target load address. Right now all of its internal functions are hitting in the right places, although it is still blowingup inside a HeapAlloc although i may have had it skip some initalization code.
mapping out the limits of this is still a good exercise i think as it could be a nice quick solution for some things.
|
|
oops i was zeroed out the wrong reloc field, should have done the stripped relocation charateristic flag to 0 in which case it fails if something else is at its preferred address, thanks guys will add that to the doc
|
Can somebody describe me: if EXE does export many functions - I can see this via depends.exe, how can I use these exports? I tell about postgres.exe from binary Windows distributable from http://www.postgresql.org/.
I can LoadLibrary("postgres.exe"). I can GetProcAddress() for any export I see via depends.exe. But call of this function by obtained address results in exception. I see that postgres.exe is loaded to something like 0x00420000. While DLL gets loaded in 0x774d0000 or near.
So EXE gets loaded in another location then DLL.
Moreover - there is import library in this distribution - postgres.lib. It allows to link to postgres.exe. But when linked app calls something from postgres.exe - it crashes.
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,320 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}