anyone here have experience of adding new sections to a pe file?

i find that some apps have lots of space for extra sections headers whereas others with only 2 sections are full up.

for instance notepad.exe puts its import table directly after last section header
whereas apps i compile have nice space of zeros after the last section header
giving me room to add my own extra section header.

is there a general reasoning behind this or do some compilers try to minimise code size by making use of any zero holes?

assuming that I cannot rely on space for an extra section header, can anyone see a problem with making a data section executable?

i am basically writing a packer and want to add my stub code to the end of the file. i was going to add my own section, but this is looking unreliable due to above. So instead i am thinking of increasing the size of the last section, adding my stub in there somewhere and making that section executable.

ZeroAdd and LordPE automatize this. It's the easiest way to do it. ZeroAdd is a small and handy program that creates a new section with the size and name you want. But when the header size isn't enough, it doesn't increase the size. That's where LordPE comes in the game. It can increase header size with just one click, it can be max. 4 KB (1000 in hex). I don't think you'll miss these tools when you google for them.
When doing it manually, you do the following: You add the section header, increase Image size, if necessary, increase the header size and length, and set flags. But I never became successful with manual section adding.

You will find 'cavities' in PE files because sections are usually in sizes of 200h. They will always be in multiples of this value or they can change to maybe 20h or 100h - it just depends but most usually you will find they come in 200h. The sections size can be changed, you will need tools such as PEid and PE explorer, they are very useful for analysing PE files and understanding every last detail to a PE file.
To manually add a code cavity into a PE file use XVI32.

thanks for the comments. In the end i opted to extend the last section and amend that section's header to reflect it's increased size and set it to executable (you also have to amend codesize and imagesize).

I have got a working stub that becomes the entry point for the modified exe now, all that remains to do, is perform some kind of encryption on the code section and then decrypt it in my stub - this is almost finished...

This is all coded in c / asm blocks, and I'll release it in GSO in due course.

Essentially it will allow you to pack/crypt a file against all current AV's, much in the manner IDESpinner described in his video tutorial.

By changing the encryption algortihm (which can be as simple as adding 1 to each byte), you will beat all AV's recognising the initally released version.

I suspect AV will need to step up to the game, by detecting unusual entry points or executable resource sections etc. Although this would probably make most programs that incorporate PE protection detected as viruses.

Currently, AV do not scan memory processes after creation for virus signitures, and perhaps this is the main weakness. But it would not be practical for them to do so...

The game continues...

you can make a new region, even with no room left on the .text.
you just need to shift all the remaining regions (such as .idata for imports) farther over.

true, but i would also need to recalculate all the rva's for the section headers and a bunch of other stuff.

i'll just extend the last section until the need arises.