Loading a PE file into memory?

Ok so I understand that the role of the "DOS Stub" in a PE file is to: firstly check if the file is being run in DOS mode, if it is then it displays the error "This file cannot be run in DOS mode".
If not, then it maps each of the files sections then loads it into memory, and then executes it.

Does anyone know of an open-source DOS Stub / loader that is equivelant to the windows one, or know how I would go about writing one?

WINE probably has something.

Quote:

---

Originally Posted by jsithy

Ok so I understand that the role of the "DOS Stub" in a PE file is to: firstly check if the file is being run in DOS mode, if it is then it displays the error "This file cannot be run in DOS mode".
If not, then it maps each of the files sections then loads it into memory, and then executes it.

Does anyone know of an open-source DOS Stub / loader that is equivelant to the windows one, or know how I would go about writing one?

---

I'm fairly sure that the DOS stub is there for backwards compatibility only - the OS itself loads the file into memory. The stub only solves the problem where the file is being run in pure DOS and of course can not be run in that mode (because DOS doesn't know that there may be other OS's with different executable formats - it's a typical "backwards compatibility feature").

There are implementations that provide a DOS extender or some such in the stub, such as DJGPP's EMX that works with OS/2 [at least did some 15 years ago]. Some info on that here: http://www.delorie.com/djgpp/faq/wha...comparison.txt


--
Mats

Analyzing a worm a few days ago, I happened to come across just this subject. And I happened to find this file extremely enlightening:
http://www.wotsit.org/download.asp?f=pe1&sc=283672831

True, it could have been written a bit more structured (so it's easier to find out which info is at which address), but that file contains everything you'll need to know.

Quote:

---

Originally Posted by matsp

I'm fairly sure that the DOS stub is there for backwards compatibility only - the OS itself loads the file into memory. The stub only solves the problem where the file is being run in pure DOS and of course can not be run in that mode (because DOS doesn't know that there may be other OS's with different executable formats - it's a typical "backwards compatibility feature").

There are implementations that provide a DOS extender or some such in the stub, such as DJGPP's EMX that works with OS/2 [at least did some 15 years ago]. Some info on that here: http://www.delorie.com/djgpp/faq/wha...comparison.txt


--
Mats

---

I'll check it out.

Quote:

---

Originally Posted by EVOEx

Analyzing a worm a few days ago, I happened to come across just this subject. And I happened to find this file extremely enlightening:
http://www.wotsit.org/download.asp?f=pe1&sc=283672831

True, it could have been written a bit more structured (so it's easier to find out which info is at which address), but that file contains everything you'll need to know.

---

Download link doesn't work.


But, my ultimate goal is to parse a valid PE file from disk, and execute it in the same memory space as the calling process.

Quote:

---

Originally Posted by jsithy

But, my ultimate goal is to parse a valid PE file from disk, and execute it in the same memory space as the calling process.

---

That sounds pretty dodgy to me. What is the purpose of that?

And how will you avoid overwriting the code that loads the executable file when loading the new file - since most of the time [and particularly if the intention is to load into the same space as the current process] the address of the executable is fixed, and the file being loaded will by necessity have similar address to the one being overwritten [or you can't load it into the same space].

--
Mats