Hello,

I am new to ASM and I use it mostly inline in Delphi and VC++.

What I am trying to achieve is running a file from memory without dumping it on a harddrive first. I know it is possible, exepackers do it, too. However, I can't figure out how.

The following Delphi code results in endless Access Violations;


var
FS: TFileStream;
Mem: TMemoryStream;
Addr: Pointer;
begin
FS := TFileStream.Create('c:\myexe.exe', fmRead);
Mem := TMemoryStream.Create;

Mem.CopyFrom(FS, FS.Size);
Addr := Mem.Memory;

asm
JMP Addr
end;
end;


The Addr is a valid pointer to the memory containing the executable. Recently someone tipped me that the executable part of a PE file is not at the beginning and I should jump elsewhere. I have no idea how to figure out where it really starts and I think just a JMP is not going to do what I want.

Can anybody help me?
Thanks a lot,
- Fahr
Posted on 2003-03-20 13:29:25 by Fahr
Afternoon, Fahr.

Would you like to inform us as to why you wish to execute a pe32 file from memory?

Cheers,
Scronty
Posted on 2003-03-20 15:50:23 by Scronty
Well, first of all, cuz it is possible and intreguing.
Second, I am looking to rewrite an eZine engine I did for DeBUG Inc. a while back (www.debuginc.com), it works all fine, but it dumps temp files on harddisk when running, cuz it needs a separate DLL to operate and more of that crap. I am investigating methods to load the exefile from resource into mem and start it from there.

no scriptkiddie intentions if that's what you mean. I am a professional programmer, I program for a living and my kiddie days are far over.

- Fahr
Posted on 2003-03-20 16:08:35 by Fahr
Afternoon, Fahr.

Thanks for the clarification:alright: .

From a quick search of the board, it seems to do what you wish means that you've got to basically create your own PE loader.
For doing that, the best examples I've found are on Iczelions' site:
http://win32asm.cjb.net
under "PE Tutorials"

The only other (easy) way, would be to write the executable to H/D and delete it when the application closes.

Cheers,
Scronty
Posted on 2003-03-20 17:09:09 by Scronty
Well, the writing on HD and deleting is what I do now.

I think I'll take a look at that PE loader thing. Thanks a lot :)

Hope it helps me tho. It seems like the tuts cover the PE structure, but not loading... well, I didn't read it completely yet... guess I'll go over it completely first :)

- Fahr
Posted on 2003-03-21 02:49:08 by Fahr
Two observations.

1. When running an PE exe file, what ends up in memory is not what is in the file. The loader drops the header, resolves runtime addresses etc. The is no simple offset into a file that contains executable code - only old DOS .COM files can be executed in this fashion.

2. Memory needs to be allocated with the PAGE_EXECUTE flag if you actually want to execute code within the page - see documentation for API VirtualAlloc. Borland's memory manager does not set this flag so using TMemoryStream is out.


James Thorpe
Posted on 2003-03-21 04:01:19 by James Thorpe
Which leads me to the next bunch of questions;

- How would I go about running a COM file then? I mean; I gotta start somewhere...
- If I can't use a TMemoryStream then what shoul I use? How should I get the testfile into the memory with the correct allocs?

Thanks,
- Fahr
Posted on 2003-03-21 04:06:50 by Fahr
Use the Window API VirtualAlloc to allocate the memory
Then use TFileStream.Read to read data into the allocation.

The only problem is that this will still not work since you still need to deal with the PE format. This format is well documented - do a google search.

Why don't you back up a bit and outline why you are trying to do this. There is probably a much easier way.

James Thorpe
Posted on 2003-03-21 05:00:51 by James Thorpe
I know for sure there are much easier ways to do this. I already used most of them.

The main idea behind this project is the knowledge I will have afterwards. It's foremost intended to be fun and educational rather than practical.

So, what about COM files then?

- Fahr
Posted on 2003-03-21 05:03:37 by Fahr
Use the Window API VirtualAlloc to allocate the memory
Then use TFileStream.Read to read data into the allocation.

The only problem is that this will still not work since you still need to deal with the PE format. This format is well documented - do a google search.

Why don't you back up a bit and outline why you are trying to do this. There is probably a much easier way.

James Thorpe
Posted on 2003-03-21 05:17:21 by James Thorpe
Hmm, I read that COM files start at 100h. Then you can maybe tell me why this gives an Access Violation on the JMP?


var
FS: TFileStream;
Addr: Pointer;
begin
FS := TFileStream.Create('C:\WINNT\system32\edit.com', fmOpenRead or fmShareDenyWrite);

Addr := VirtualAlloc(nil, FS.Size, MEM_COMMIT, PAGE_EXECUTE_READWRITE);

FS.Read(Addr, FS.Size);

asm
JMP Addr + 0
end;


seems ok to me, for a COM file at least...

Thanks,
- Fahr
Posted on 2003-03-21 05:34:43 by Fahr
@Fahr: Why not just start with Iczelion's PE Tutorial, pointed out above? I'm sure it
will answer most of your basic questions, so don't hesitate and read it...

Remember that COM-files are designed for the real-mode of MS-DOS, so Windows has to
emulate this OS in order to make those applications run properly. To load a COM-file, all
you have to do is read the file directly to offset 0100h of any segment, set up some registers
and jump to that offset.
Here's a basic example for such a loader:

http://www.experts-exchange.com/Programming/Programming_Languages/C/Q_10293337.html

However, that won't help much if you're going to write code for Windows, since the PE format is for
protected-mode and built up in a much more complex way. PE files start with some DOS-code that will
display the infamous "This program cannot be run in DOS mode" and exit itself, when started in
real-mode. From that point on, the PE file format contains information for the loader like:

? Type of CPU required for the code
? Linker version, optional checksum, timestamp, and other minor stuff
? Base address, entry point
? Amount of sections, where to load them into memory, properties/attributes of them

After this header, the actual data and code (which is basically also 'data') sections are following.

Now go read Iczelions PE Tut !! If you have further questions after working through it, we
will of course help you. :cool:


aweX <-
Posted on 2003-03-21 05:44:40 by aweX
You have a different problem now.

COM files also have requirements. Firstly the first $100 bytes are used to set the appropriate environment - command line params etc. This has not been done.

Secondly. a COM file is 16 bit application which cannot simply be loaded into a 32 bit address space and executed. For a start EDIT will most likely attempt to change the segment registers - totally stuffing the virtual environment in which it is running. COM also files have specific requirements about the size of the code and data spaces, and the contents of the CS, DS, and SS registers.

The long and the short of it is that you need to create an appropriate 16 bit virtual environment to execute a COM file like this. And surprise, suprise this is the job of the loader.

Which brings me back to my last question. Why are you trying to do this?

James Thorpe.
Posted on 2003-03-21 05:45:08 by James Thorpe
Again, I answer the 'why' with 'knowledge'. I would just like to be able to do this, mainly for fun and the educational value. I have always been interested in this process, ever since I got my hands on some exe packer, about 6 years ago :P

The difference between then and now is that now I can program and have the time and basic knowledge to make this work, with some help and tuts of course, since I'm quite new to ASM and this seems the be one of the most complicated things one can do :P

I thought a COM would be easier with a default offset and all, but it seems like it's not easier than PE. I guess I'll just go through the tutorial then and see what I can do with that :)

I'll ask my questions after I ploughed through the tutorials. Thanks for the help so far :)

- Fahr
Posted on 2003-03-21 06:00:47 by Fahr
Fahr,

i don't have the reference material on this machine but from the start, you will need to learn a fair bit about the 32 bit Windows PE format to have some chance of making this work.

Have a look at memory mapping for the space to write the EXE file to memory and from memory, there is a flag in the allocation of the memory mapped file that is designed to load executable files. Your next problem is that PE EXE files are loaded at 400000h arbitrarily so this will have to be taken into account and you will have to modify the PE header in memory to fix it. A DLL has a relocation table as they are usually determined at runtime.

A PE exe file is usually smaller on disk that when loaded in memory, the sections are aligned differently in memory so usually the memory image is larger.

You have a complicate task in front of you but I think a few members have done stuff like this in the past so you may get some help here. If Iczelion has done a tutorial on this, make a point of having a look at it as his technical work is very good.

Regards,

hutch@movsd.com

PS : If you know how to get a complete memory dump of a running PE file, that will handle the correct layout of the file but yoy will still have to fix up the load address.
Posted on 2003-03-21 06:16:00 by hutch--
I know it will be a lot of work, but I'm patient.

I also set this as sort of a final goal in my total learning process of ASM, one step at a time.

On another note, which debugger would I use to get a complete memdump of a running exe? Or rather; which debugger is capable of giving me a browse in the memory of running processes?

Thanks,
- Fahr
Posted on 2003-03-21 07:14:28 by Fahr
Also; checking out different tutorials, it seems like most assemblers are not very compatible with eachother. Which would be the best assembler to start messing with? I like the way TASM code looks, while MASM seems a bit too much like VB with the direct parameter calling etc.

Any ideas on this one? Or should I just stick with inline?

Thanks,
- Fahr
Posted on 2003-03-21 07:46:51 by Fahr
i don't want to steal your motivation but you can drop that idea. there
are thousands of things that you have to fix before you get a valid pointer
to your executable code. back then i tried the same and i even got some
working results but i gave up because it's just too hard and compilcated.
i never saw full-working code like this. memory calculation and allocation,
relocation, alignment, import and exports, resources, etc ... just forget it.
there are better ways, belive me. why don't you study the pe-header and
learn some more asm... then you would be able to to write your own dos-com
like programs, the keyword is relocatable code... if you know what a delta-
offset is and how to get the kernel-base, you could study the export directory
and you're done... then you could write code that is able to use all the
windows api's without a loader. it just doesn't matter where the code is stored,
a pointer is all you need then. you'll also find a hand-full of working examples
on this board. i could also provide you with links if you want to go in that
direction---
Posted on 2003-03-21 08:07:21 by mob
On another note, which debugger would I use to get a complete memdump of a running exe? Or rather; which debugger is capable of giving me a browse in the memory of running processes?

If some program called debugger isn't able to do it - it is certainly not a debugger, imho.

Which would be the best assembler to start messing with?

It depends. If you intend to work with big projects, consider masm. Seems like every other x86 asm is no more than home grown tool, imho, of course.
Posted on 2003-03-21 08:20:12 by masquer

i don't want to steal your motivation but you can drop that idea. there
are thousands of things that you have to fix before you get a valid pointer
to your executable code. back then i tried the same and i even got some
working results but i gave up because it's just too hard and compilcated.
i never saw full-working code like this. memory calculation and allocation,
relocation, alignment, import and exports, resources, etc ... just forget it.
there are better ways, belive me. why don't you study the pe-header and
learn some more asm... then you would be able to to write your own dos-com
like programs, the keyword is relocatable code... if you know what a delta-
offset is and how to get the kernel-base, you could study the export directory
and you're done... then you could write code that is able to use all the
windows api's without a loader. it just doesn't matter where the code is stored,
a pointer is all you need then. you'll also find a hand-full of working examples
on this board. i could also provide you with links if you want to go in that
direction---


well, DO provide me with links, it sounds very interesting, too :)

also, there are people who managed to do this. Look at UPX for instance, it's even opensource. That guy managed to wrap his PE Loader with a decompressor. Too bad I don't understand one bit of it, otherwise I could use it. But his PE decompressor / loader is opensource...

- Fahr
Posted on 2003-03-21 09:05:13 by Fahr