I had this idea one year ago.    I was thinking of how you can supply code for
applications.  For that, Windows uses DLLs. Obviously, you know what they are,
and you know that they supply of code by export of functions.  A DLL is loaded
into  the  application  memory and Windows  resolves  the imports, so that the
application can use the code in the DLL by calling the function.

The are two ways in which an application can import functions using the import
table, one would be to import the functions by name, the second would be using
the ordinals.  When Windows successfully finds the name or ordinal in the DLL,
it gets  the  function  address  from the export address table, the address is
copied  into  the import address table in the application and so it continues.
Here is where I had the strange idea.   Windows doesn't check that the address
in the export address table are actually valid.  :)  I mean, the address could
be FFFFFFFF and Windows would anyway add to it the base address of the DLL and
so it will be copied to the import address table.


Waiter, there's code in my IAT!
There are  viruses  that hook the export address table by changing an entry to
make it point to the virus code.  But that is not the idea here.   If an entry
can be invalid, we can put whatever  thing we want, and if we can do that then
we can put a virus code there.  And would be the result?  Yes!  You can import
code instead.


Tricky Exports
We  have  an  export address  table  that is actually the virus code.  We must
import every DWORD value in the host.     To each value will be added the base
address of the DLL in memory, so  we  achieve a level of encryption there when
the virus gets into the import address table of the host.  So, we need to also
set some code to decrypt (substract) the base address from every DWORD.   Here
is a little problem.  We can't guess the base address in the decryptor for the
DLL.  So, we must solve that first.     We could parse the PEB to find the DLL
but that  would  require  a  lot  of  code  and I wanted it to be small, maybe
so small that it could be  easy for an oligomorphic engine to create.  So, the
solution was to export an address  00000001, then we only need to decrement it
in the import address table and we have the DLL base address.  :)

This is how the decryptor should look like:

        mov     esi, offset iat
        lodsd                                ;load DLL base address
        dec     eax                          ;fix it
        xchg    edx, eax
        push    esi
        push    count                        ;number of imported entries
        pop     ecx

decrypt:
        sub     dword ptr [esi], edx
        lodsd
        loop    decrypt
        pop     esi
        jmp     esi                          ;jump to virus code


EntryPoint Obscuring
Yes, what about it?   A DLL file can export functions from itself, indeed.  It
is something you don't see everyday.   Adding a new import table to host file,
of which  import  address  table points whithin the import  address table of a
previous import table.  You can overwrite that value.   You can infect EXEs in
this way, too.    However, for that you would require to have a DLL with virus
code.
hh86