Flag: Tornado! Hurricane!

 Forums >>  Brainstorms - General  >>  compiled exes as dlls - Using functions from

Topic created on: September 6, 2005 23:30 CDT by dzzie .

anyone see any hidden bombshells in this experiments future?


  igorsk     September 7, 2005 10:12.06 CDT
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...

  Darawk     September 7, 2005 18:55.38 CDT
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:

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.


  anonymouse     September 8, 2005 05:41.37 CDT
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

  ryanlrussell     September 8, 2005 14:51.46 CDT
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?

  igorsk     September 8, 2005 19:56.40 CDT
"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.

  ryanlrussell     September 8, 2005 21:02.00 CDT
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...

  MaXimuS   September 9, 2005 07:15.39 CDT
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.

  dzzie     September 9, 2005 09:42.12 CDT
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.

  dzzie     September 10, 2005 14:31.08 CDT
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

  ClockworkAlexei     February 21, 2008 14:34.45 CST
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,317 total registered users.

Recently Created Topics
[help] Unpacking VMP...
Reverse Engineering ...
let 'IDAPython' impo...
set 'IDAPython' as t...
GuessType return une...
About retrieving the...
How to find specific...
How to get data depe...
Identify RVA data in...

Recent Forum Posts
Finding the procedur...
Question about debbu...
Identify RVA data in...
let 'IDAPython' impo...
How to find specific...
Problem with ollydbg
How can I write olly...
New LoadMAP plugin v...
Intel pin in loaded ...
OOP_RE tool available?

Recent Blog Entries
Breaking IonCUBE VM

Anatomy of a code tracer

IAT Patcher - new tool for ...

CryptoShark: code tracer ba...

Build a debugger in 5 minutes

More ...

Recent Blog Comments
nieo on:
IAT Patcher - new tool for ...

djnemo on:
Kernel debugger vs user mod...

acel on:
Kernel debugger vs user mod...

pedram on:
frida.github.io: scriptable...

capadleman on:
Using NtCreateThreadEx for ...

More ...

SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit