flat assembler
Message board for the users of flat assembler.

Index > Windows > Loading .exe into memory and manually executing it?

Author
Thread Post new topic Reply to topic
keyoke



Joined: 18 Jun 2003
Posts: 56
Location: London
keyoke
I'm looking to embed another .exe file within one of my own as a stream of bytes. is it feasible to write these bytes to some area of memory and execute them? if so I also need to supply commandline parameters.
Help would be appreciated
cheers
Post 08 Oct 2009, 12:11
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17492
Location: In your JS exploiting you and your system
revolution
In general an exe file cannot be easily included within another exe. You have to properly load all the sections into memory, possibly also relocate the code, resolve all the imports, and a bunch of other stuff that the normal Windows loader will do.

Perhaps a better idea is to write the binary exe file (from the data section of your exe) to disk as a new exe file and then load it as a child process within your app.
Post 08 Oct 2009, 12:21
View user's profile Send private message Visit poster's website Reply with quote
keyoke



Joined: 18 Jun 2003
Posts: 56
Location: London
keyoke
Thanks, this was my initial thought but was hoping to have a "cleaner"(the whole thing is not very clean I know), not having to have write permissions to a temp folder etc....
Post 08 Oct 2009, 13:03
View user's profile Send private message Visit poster's website Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
If you have the source code for the "OTHER" EXE then there's no need to embed it into your EXE just turn the functionality you need into a SUB ROUTINE / PROCEDURE or a separate DLL file.

If you don't have the source for the "OTHER" EXE then you should distribute it AS IS with your own EXE; if your true goal is for a "CLEAN" program.

For your specific question, UPX does what you want. It unpacks an EXE in memory and runs it. http://upx.sourceforge.net/
Post 08 Oct 2009, 14:29
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
Defsanguje



Joined: 07 Aug 2006
Posts: 7
Location: Finland
Defsanguje
The problem itself is very interesting. Z0mbie and yoda has done some work related to the subject:

InConEx - executing PE files in the own process memory context - Binaries & SRC
Post 08 Oct 2009, 20:59
View user's profile Send private message MSN Messenger Reply with quote
pal



Joined: 26 Aug 2008
Posts: 227
pal
I know exactly what you are talking about, but I cannot find a link to it. This guy has a website which has a POC for it. It is like Win32 fork(). Damn I cant find it, it is annoying. He his some Asian guy who's name is like Tan/Tang something something.

If I find it I will post it. Under VB it goes by the name of RunPE, but the original POC was done in C. It will execute a PE file loaded in your programs memory. It is not that hard to do to be honest.

Interesting links Defsanguje.
Post 08 Oct 2009, 22:27
View user's profile Send private message Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
You can do it, but...

1) your exe file needs relocations (or has to be written to use position-independent code)
2) you need to fix up imports
3) you need to hook various API functions for the memory-exe... the most complicated is getting resources to work.
Post 21 Oct 2009, 07:38
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.