If you wanna make the world a better place, take a look at ...

typical packer entry-points
It can be useful to have a reminder of the most usual packers' entry point - especially the light ones, which are likely to be hacked or used as an inner layer.

Quand mes 'elles' se froissent et mes 'ils' se noient

pages on anti-debuggers and PE oddities

I created 2 new pages: one is about anti-debuggers (nothing new, just a compact and a printable form), and the other about PE oddities.

Life's a piece of sh.t, when you look at it

Overview of one-byte opcodes

I made a simple one-page overview of one-byte opcodes:

Aurais-je été meilleur ou pire que ces gens, si j'avais été...

packers' categories and features
Following my graph of the packers' landscape, I made a graph showing the different categories of packers, and what kind of features they have.
Then, to go deeper in details, I made a more detailed list of the various features for each of these kinds.

You can't hide nowhere, with the torchlight on

a emptier TinyPE
TinyPE is an impressive project, that explains step-by-step how to make an incredible 97 bytes functional PE. It also shows that a PE can't be any smaller, otherwise IMAGE_OPTIONAL_HEADER32.Subsystem, which is a critical field, wouldn't be defined - it's even already shortened from a word to a byte.

However, the original TinyPE still defines a section and SizeOfOptionalHeader, which are not necessary.
Removing them makes such a PE not only Tiny, but also very small in amount of information - yet it works, naturally, and there's quite some room for code (relatively).
In the end, here are the only defined fields, across all PE headers fields:

Si c'est ton corps qui bouge, c'est ton coeur qui fait tout

Getting the current EIP
While standard code starts at a fixed address, there are several cases when your code needs to know its current IP:

• after a vulnerability has been triggered, shellcodes can't know in advance where they are executing exactly
• packers often allocates a buffer and decompress their next layer of code, which will likely need to locate itself at some point
• relocating code is a good way to avoid breakpoints: same code, somewhere else

Thus, I'll enumerate ways to get your current EIP, in a file, on which you can test your emulator or debugger.

no, I'm your father

misc news
Opcodes 'complete'

my file listing all known 32 bits opcodes is almost done: everything documented should be in (including AVX, XOP, Padlock, LWP), and 99% of undocumented stuff I can think of is in (to be blogged later)
Source

Packers graph now printable