Encryptation through relocs

Until now relocs section (.reloc) has been very useful (curiously by useless)
for virus coders. Why? Virus coders overwrite it to hide an increase of size
after the infection. Nothing to worry because when Windows loads an
executable it gives a new virtual address space and it will be loaded into
the base address indicated in his header and it's not necessary to apply the
relocs. That's the reason why by default some compilers don't include the
.reloc section except if you tell the contrary. Of course, it doesn't happen
the same with DLLs since it's more common they have their base already
busy (at least it's already loaded the executable and usually there will be
other DLLs) then it will must to be loaded into other base address and
applied new relocs based in the new base.

Let's see what happens when a module is loaded into another different base of
the indicated in the header and it's needed to apply relocs; each entry in
the relocs table point to the addresses of the module that are needed to be
reseted. To the content of each of these addresses is subtracted the indicated
base in the header (since it's already reseted respect to that base) and it's
added the base where it has been loaded really.

Other fact we will use is that if to an executable we put a base where we know
it will not be loaded, Windows by default tries to load it at 0x400000.

Taking care of all these, we are going to get encrypted a virus and the own
Windows will decrypt it, i mean, it will not be needed any decryption routine.

First, we need the host having his base at 0x400000 and we need to null his
relocs (if it has any). Now we change the base to the executable for one we
know Windows will not accept, per example we take 0x12345678. With this we
will get Windows loading the executable at 0x400000 and applying the relocs;
It's due to that we have nulled the relocs of the host since finally it's
being loaded his choosed base.

Now we create a new .reloc section pointing each DWORD from the body of the
virus and we encrypt every DWORD of the virus in the next way:

DWORD virus + 0x12345678 - 0x400000

We do that since when Windows loads the executable at 0x400000 what it will
do will be subtract the header of the base (0x12345678) and add the real base
(0x400000).

This way: (virus + 0x12345678 - 0x400000) - 0x12345678 + 0x400000 = virus;

We've gotten Windows finally decrypting our virus and then it's different
to how it was in disk without execute any instruction (it's only needed
whereupon it has been loaded into a debugger per example :-)

In NT there are limitations to the use of this method since it doesn't want to
load the executable if it finds a strange base (i believe it must to be
multiple of 64KB).

Tcp/29A