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


true, I'll have a look around :P
th


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.


Hmmk, I just think that MASM is kind of weird, since it doesn't support DOSSEG for instance... and API calls are also odd with params directly after it, I am used it pushing them (it still works like that too, I know). And all the includes... in TASM you just don't use includes, just define the APIs

oh well, I guess it's just a matter of getting used to.

- Fahr
Posted on 2003-03-21 09:11:48 by Fahr
Iczillions tutorial focuses on retrieving information about a PE file, which is definately a good place to start. You'll have to get all the sections loaded at the right offsets. On my website I have some code that handles relocations and imports, so you don't have to code that from scratch if you can understand my code. It's not that complicated, but it has some oddities because it's designed to be contained inside the exe being loaded. Anyway, just see if it's useable for your purpose.

(In case you didn't already know - you can go to my website by clicking the little www button below this post)
Posted on 2003-03-21 09:14:41 by Qweerdy
Cool, I'll have a look and thanks a lot :)

As stated before, I don't know ASM too well, so I may have some questions. If you're willing to answer them, I'd be most grateful :)

(mag ook in het nederlands ;))

Thanks,
- Fahr
Posted on 2003-03-21 09:19:48 by Fahr
upx is not a pe-loader, that's what i meant. it's nort hard to write
something like this... the hardest part is the compression not the
pe-stuff. ah, links... that's not as easy as you may think on this board,
because most of that links would point to some vx-ralated stuff.
for a good start look at this thread.

just go to the base url of the link i posted there (my tripod website)
and you'll find some examples... for some good pe-related stuff check
out the zip i'll attach to this post. that's really all you need.
Posted on 2003-03-21 09:25:00 by mob
Thanks a lot :)

I'll have a look, the zip looks promising, loads of infos :)

- Fahr
Posted on 2003-03-21 11:36:32 by Fahr
check out y0das inconex

the description is

This program tries to load a target PE image into some memory in its own memory context and execute it there.

full source code.

http://yodas.*******************.info/snippets/InConEx10.zip

prs

Edit, Sorry, cannot allow that subject material here. hutch--
Posted on 2003-03-21 11:37:22 by prs
Well, that is most certainly cool :)

tho I doubt that it can be done using only C, I don't see any ASM files in the zip... is it inline?

I'll check it out :)

Thanks,
- Fahr
Posted on 2003-03-21 11:40:03 by Fahr
My code actually does the opposite of what the code mob posted does: it moves itself into another process and re-executes itself in there, preserving all global variables. I use it for testing API hooking and other stuff that requires easy access to a process' memory area.

And of course I'll be happy to answer any questions. Just send me a PM (in het Nederlands als dat makkelijker is) and I'll answer when I can.
Posted on 2003-03-21 11:51:19 by Qweerdy
Hmm, browsing through some samples and stuff I get the idea there's a distinct difference between the following 2;

1. loading a PE file into memory and executing it
2. wrapping/crypting/packing/whatever a PE file and adding a header to it that then un-whatever-s it and executes it.

It seems like number 2 is a lot easier. Since this yoda guy was able to write a crypter that works on about everything, but he could not write a number 1 type program that works on everything. The link provided above works on maybe 50% of PE files, while the packer works on 99%...

What is the real difference here? I don't get it...

- Fahr
Posted on 2003-03-21 14:27:54 by Fahr
Someone on this board was making PE loader (handled relocations, import section, etc). Check search.
Posted on 2003-03-21 17:49:05 by comrade
Hmm

I came across some interesting things, like dumping PE images from memory to a disk image. If I get it correctly, those images can be run directly without a loader (which raises the question; why doesn't Windows store files like that?).

Is this assumption correct? And how would I go about doing something like that then? This is probably the idea the exepackers use, right?

I thought that making a PE loader would be more or less the same as all this. But from what I read now, it's not a PE loader I want to make (what's the use? I'm not writing an OS...), but something with those images... It's not the same, is it?

Thanks,
- Fahr
Posted on 2003-03-22 05:48:49 by Fahr
The problem of a straight image is that you need to absolutely guarantee that it is loaded at the same memory location within your virtual address space each time.

What is worse that you need to guarentee that ALL the dll entry points (ie API calls) are in exactly the same address each time you load. Unless you write code your code to dynamically resolve the address of each API call before you call it.

This can actually be done but is a bloody nuisance. The beauty of the loader is that is resolve each and every external API address at load time for you - and then "fixes" up the application to that each call gets to the right address.

If you wish to handle address resolution yourself look at LoadLibrary and other related API calls (of course you need to resolve the address of LoadLibrary and GetProcAddress before you call them - catch 22)

Can I suggest you try an easier learning project - such as finding a simple solution to Fermat's Last Theorem

Actually if you want a really good project for learning a programming language - I suggest implementing a Forth Interpreter. That was one of my first learning projects 20 years ago, and I do it again regularly with new languages. A project like that has the tendency to really highlight the strengths and weaknesses of any tool really quickly.

James Thorpe.
Posted on 2003-03-22 06:13:21 by James Thorpe
Well, all those reallocations are done by exepackers like UPX, right?

I mean, how does it work? It doesn't have a PE loader, so it somehow preprocesses the PE file into a format readable for its own loader and then still reallocates all of the stuff at runtime... Or not?

And what is this with Forth? Somehow Forth has crossed my path a lot lately, it seems to be bound to ASM somehow, everyone seems to write his/her own interpretors and one guy even wrote a forth interpretor in pure Bash... Odd...

Anyways, I have some other interesting learning project goals - like a bootloader - but I don't see how this image/loader thing can be so difficult... yoda did it, the UPX guy did it... and it all works!

Tho they probably have a lot more experience than I have :P

- Fahr
Posted on 2003-03-22 06:46:55 by Fahr
Yeah and the guys at Micro$oft wrote Windows ... and it all works! :eek: :eek: :eek: :eek: :eek:
Posted on 2003-03-22 08:15:32 by aweX
Very funny...
Posted on 2003-03-22 08:19:33 by Fahr
Leave Forth out of this man, it a totally different stuff and while it is very interesting to study and use it will not help yu here IMHO. Also i do not know if you have the expertise required to understand its inner workings...please excuse.

FORT is a OS by itself somehow and YES it is used as a bootloader and language at boot time by FreeBSD, inside Postscript printers as a gfx language and in many embeded and astronomicaly systems...

As i told you it is self contained and does all interpretor, compiler, OOP, etc in his own very different and indeed funny ways... it will not help you for the task of loading and running a PE Windows executable into memory.

You must understand how Windows does this and not FORTH. The fact that Yoda and UPX did it doesnt make it easy :P

A program must be able to run at diferent adresses in the memory space of an OS, so all absolute Jumps and Calls must be patched by the loader. Also the references to the API (usually from DLL memory space) must be "fixed" also before such calls can be made.

Please, please read and try to understand the Icz tutorials about PE files structure.
Posted on 2003-03-22 11:39:26 by BogdanOntanu
Yes, I'm doing just that (the tutorials), but I still have the same basic question;

do yoda and UPX first 'pre-process' the PE file into a different image format? Or do they keep the PE format and load that somehow?

Also; still looking for a debugger which allowes me to browse and dump from mem... can't really find one except soft-ice (too lowlevel for my taste).

- Fahr
Posted on 2003-03-22 12:41:38 by Fahr
Fahr, what I wrote above should make you reconize that you cannot
start with the most complex things first. As Mister Ontanu wrote: just
because someone did it, doesn't mean you can do or even understand
it right now.

So please put your current question into the archive for later, because
you might be able to understand it if you know all of the background.

In case you still want to know NOW what UPX does, why not look at the
source-code of it? ( http://upx.sourceforge.net )

Have fun....
Posted on 2003-03-22 23:51:12 by aweX
Yeah, I know you're right...

But what I am asking is IF there is a difference between PE from mem and the stuff UPX does, cuz then I know where to set my goals.

I'm reading tuts now and I have a feeling this will work, some day. Still need that debugger, tho :S

- Fahr
Posted on 2003-03-23 06:55:01 by Fahr
One reason not to dump the entire file from memory is that the uninitialized sections will be stored as well. Depending on the program, these can add a lot of size to the file.
Posted on 2003-03-23 09:22:56 by Qweerdy