The upper picture shows how i want the final memory layout to be (manually edited VSizes, Problem: PE file invalid, unusable). The bottom picture shows the same version rebuilt with LordPE ('validate PE') afterwards. This is necessary to get the pe file valid but it pulls the VSize up to the next section start - notice the last section start offset - guess what happens when you start the target...

The swapfile size raises to 1.8gb (virtually - in taskmanager) and the program crashes somewhere in the game. I don't know if its caused by memory issues or protection yet.

The original target extracts PE files and remaps them to these areas. I'm trying to get them back in place without a loader if possible (i'm a lousy coder).

Any ideas how to get the upper PE layout valid?

http://img157.imageshack.us/img157/6321/sectiongap6qd.png

Unfortunately, it is one of the requirements of the PE format that the sections are contiguous and 0x1000 aligned in memory.

The most common way to work around this problem is to use an inline patch at your EP: Set the VOffsets so the non-contiguous sections sit directly after the preceding sections (so _0157000 would be loaded at 396000, _026E000 at 3B6000 etc.), hence removing the discontinuities. Now your PE will load. All that's left to do is to redirect your EP to a ten-liner that VirtualAlloc's the appropriate blocks and then gets RtlMoveMemory to do the business before jumping to OEP.
It's a little bit tedious to implement, particularly when you have a few sections to do this to (as you do) and it knocks your memory-consumption up a bit, but it's fairly standard and is pretty much guaranteed to work, providing your old and new sections don't overlap.

From looking at the VOffsets and VSizes, this problem looks a lot like the code-splicing trick that Armadillo uses, but the section names don't seem too familiar. Would you mind telling us what packer you're battling with here?

Regards
Admiral

FLEXnet

Thanks for the apis. I'll try inline patching...

Admiral, sections need neither to be contiguous, nor 0x1000 aligned in memory.

A field exists in the PE header to set the alignment you want (which often is 0x1000 nevertheless). Also, you can specify virtual addresses where you'd like sections to be mapped. Anyway, the executable loader has the last word on it.

Peres

I can tell you one reason your PE is not valid, is that you have the Raw size set equal to Virtual size, but the virtual size of not correct. Look at the bottom image. The virtual size of the stxt371 size is huge. But of course the raw size is small (0x3490). This is of course fine, as long as the VA of the next section is aligned correctly. Even with 0x1000 alignement, the sections can be any size you want as long as the next section is aligned on a 0x1000 boundary. SO the problem in the top image is for some reason the Virtual size was set to the raw size when really is should have been the other way around. (The raw size should be set to virtual size instead - the original virtual sizes, and hopefully the file's whole size is correct to all the virtual sizes added up together.) Also do not forget to change the file alignment to match the virtual alignment value - since remember, this file was dumped from memory so everthing will be aligned to the virtual alignment.

In fact if you add up the VA offset's to their sizes, it comes out equal to the next section's va address just fine. So this file probably is 0x1000 aligned but your dump does not have the correct raw sizes.


-nt20

chances are even if you do manage it you will have a LOT more work to do.
from the picture, i can only guess from the section names and other data that you are attempting to crack a safedisc protected application by dumping the exe, and the dlls and trying to incorporate that into one executable, if so, you are definately doing it that hard way.. even if you do manage to get the exe running you then also have to dump the virtualalloc'd tables safedisc makes into your exe, fix ALL imports (exe, and from the dll you dumped into the exe section).. try a different approach .. like perhaps wrapping the exe so it loads your code at the entrypoint, and then setting up hooks.. considerably easier

It's indeed a safedisc derivate and i'm aware its probably the wrong way i'm facing but i never touched this before and i need to gather informations somehow. Still wondering that it runs half way with simple dumping. I didn't fixed any IATs yet. Just dumped some additional Valloc's (01570000+026E0000) and the corresponding dlls (DF+DEAD). Some calls go 'main->valloc->dll->ret(main)'.

I cannot get rid of the antidebug code so i attach at some later point (html trial menu). Possible that some (dynamic) Vallocs are already in place at that time. Code is mangled/confuscating and has several double NOPs here and there. I don't know too much about the protection behaviour/characteristics yet.

I have to see how far i can get with this approach and what will break it. Thx for the help so far. Should bring me back on track...

Yo Peres.

I remember reading somewhere (and affirming my belief when I came to write my own PE protector) that although the PE header has a SectionAlignment field, Windows will refuse to load your file if it isn't set to 0x1000. If you can find a counterexample I'll eat my hat

As for the contiguity constraint, I think I also read this in a text but I may have made it up . By 'contiguous', I mean that

VOffset(i+1) = RoundUp1000(VOffset(i) + VSize(i)), for i = 1,2,...

where
RoundUp1000(x)
| (if x % 0x1000 == 0) = x
| (otherwise) = 0x1000 * ((x \ 0x1000) + 1)

if you'll excuse my formal (and somewhat Frankensteined) notation. I've never managed to break this rule and keep my target working, but if you can provide a counterexample I'd appreciate it.

Regards
Admiral

Edit: If you're going to be anal enough to give a formal definition, you should probably get it right .

Sorry admiral, put some syrup on that hat - .NET executables are usually 0x2000 virtual alignment (a lesson I also learned the hard way)



-nt20

From http://msdn.microsoft.com/msdnmag/issues/02/02/PE/

From my PE reference:

Admiral, I have been dealing with Delphi compiled executables, and they are using file alignment of 0x200.

Cheers

Nacho_dj

Here's one up for thread-hijacking.

Nacho_dj:
I'm sure you're right - I've played about with FileAlignment lots and found 0x200 works fine (although I think that's a lower bound). However, the dispute was over SectionAlignment - the equivalent field for the virtual image.

But it seems I'm fighting a one-man-battle. I think it's time to concede about the SectionAlignment needing to be 0x1000. I guess the actual restriction is (in the general case) that this field needs to be a multiple of 0x1000, which is the architecture page size on every version of Windows I've REd on. By the way, that's a good find, LLXX. I'll have to try out that direct-mapping thing some time.
So I stand corrected. Now where did I put that hat...

As for the contiguity thing, I'm gonna stand fast. ('Cause I'm stubborn like that ).

Regards
Admiral -=- Learning things I thought I'd already learned

It seems you are right to do that. My PE reference: