Formato De Archivos Pe

Formato de archivos PE

Cuando se enfrenta al listado "en vivo" (en un depurador) o "muerto" (desensambl ado por ejemplo mediante W32DASM) de un programa target, el reverser es como un cirujano para quien los más intrincados detalles de la anatomía y fisiología del pacie nte deber ser conocidos para tener mayores chances de éxito. Lo que sigue es un eq uivalente a un estudio anatómico, un sumario del formato y header de archivos ejec utables PE de Win32 con tres ejemplos de código fuente: un primer programa escrito en C++, después un rudimentario programa Windows escrito en lenguaje Assembly y f inalmente un listado desensamblado generado por W32DASM del programa C++. Espero que la revisión y comparación de estos permita al reverser familiarizarse con las e structuras fundamentales y "órganos" de su target y asi estar preparado para patch ear con éxito cualquier programa que le llegue. FORMATO DE ARCHIVOS PE "En un comienzo", había sólo dos tipos de archivos ejecutables: los .COM (ejecutable s de un sólo segmento) y .EXE (ejecutables de varios segmentos). Debido a que los archivos .COM ocupan un sólo segmento, no tenían necesidad de header y por lo tanto se cargaban en el primer segmento de memoria disponible. En cambio, los .EXE nec esitaban frecuentemente usar varios segmentos y fue preciso dotarlos con un head er (el encabezamiento del archivo) de 64 bytes para informarle al SO cuántos segme ntos serían necesarios y cómo debían ser allocados. El SO Windows fue desarrollado con la idea que los archivos ejecutables debían usa r una colección de funciones provistas por el núcleo del SO, llamadas API. Como el p rograma no debía ya manejar cosas tales como entrada desde teclado, seguimiento de l mouse y salida a pantalla, y como se esperaba que un programa comparta la memo ria con varios otros programas corriendo en forma simultánea, fue preciso suminist rarle al SO mayor cantidad de información para que la comunicación entre SO y progra ma sea eficiente y completa (en contrapartida con los programas DOS que frecuent emente ignoraban por completo al sistema operativo). Fue asi que se crearon los tipos de archivos ejecutable NE, LZ y PE (y sus headers): el formato de archivo impone una estructura al archivo ejecutable y el header del archvo diagrama esa estructura. Mediante el conocimiento del formato y header de archivos PE, se pue den hacer un sorprendente número de cambios en el archivo PE contando solamente co n un editor hexa (mejor si es uno que interpreta el header de los archivos PE co mo el Hiew 5.66) El header de un PE comienza con el header del DOS (MZ) MZ Header WORD e_magic número mágico WORD e_cblp

Bytes en la última página del archivo WORD e_cp Cantidad de páginas del archivo WORD e_crlc Relocaciones WORD e_cparhdr Longitud del header en parágrafos WORD e_minalloc Minimo de parágrafos extra necesarios WORD e_maxalloc Maximo de parágrafos extra necesarios WORD e_ss Valor inicial (relativo) de SS WORD e_sp Valor inicial de SP WORD

e_csum Checksum WORD e_ip Valor inicial de IP WORD e_cs Valor inicial (relativo) de CS WORD e_lfarlc Dirección de la tabla de relocación WORD e_ovno Número de overlays WORD e_res[4] Palabras reservadas WORD e_oemid Identificador de OEM (e_oeminfo) WORD e_oeminfo

Información de OEM (e_oemid) WORD e_res2[10] Reservadas DWORD e_lfanew Dirección del nuevo header exe Esto es seguido por un programa "stub" (tal como winstub.exe) que es ejecutado s i el programa PE es corrido fuera del ambiente Windows; usualmente esto escribe en la pantalla el mensaje: "este programa requiere MS-Windows para correr", pero puede ser modificado por el programador para que diga cualquier otra cosa, o ev entualmente hacer correr una segunda versión (DOS) del programa como para hacerlo más portable (parece gracioso, pero nadie parece haberse tomado el tiempo como par a hacerlo hasta ahora). Después del stub, viene la firma 00004550 ("PE",0,0), y lu ego el header PE: Estos ejemplos de header de archivo PE son del Notepad.exe) WORD Tipo_ de_ Máquina 014C WORD Número_ de_ Secciones 0006 DWORD Time/Date_ Stamp 2FF3548D DWORD Puntero_ a_ la_ Symbol_ Table

00000000 DWORD Número_ de_ Símbolos 00000000 WORD Longitud_ del_ Optional_ Header 00E0 WORD Características 010E PE Optional Header WORD Magic 010B BYTE MajorLinkerVersion 02 BYTE MinorLinkerVersion 32 DWORD SizeOfCode 00003A00

DWORD SizeOfInitializedData 00004800 DWORD SizeOfUninitializedData 00000600 DWORD AddressOfEntryPoint 00001000 DWORD BaseOfCode 00001000 DWORD BaseOfData 00005000 ----Campos opcionales para NT (sólo para Windows NT)---DWORD ImageBase; DWORD SectionAlignment; DWORD FileAlignment; WORD

MajorOperatingSystemVersion; WORD MinorOperatingSystemVersion; WORD MajorImageVersion; WORD MinorImageVersion; WORD MajorSubsystemVersion; WORD MinorSubsystemVersion; DWORD Reserved1; DWORD SizeOfImage; DWORD SizeOfHeaders; DWORD CheckSum; WORD Subsystem; WORD DllCharacteristics; DWORD

SizeOfStackReserve; DWORD SizeOfStackCommit; DWORD SizeOfHeapReserve; DWORD SizeOfHeapCommit; DWORD LoaderFlags; DWORD NumberOfRvaAndSizes; Inmediatamente después del header del archivo, vienen los Section Headers Section Header BYTE Name[IMAGE_SIZEOF_SHORT_NAME]; DWORD PhysicalAddress; DWORD VirtualSize; DWORD VirtualAddress; DWORD SizeOfRawData; DWORD

PointerToRawData; DWORD PointerToRelocations; DWORD PointerToLinenumbers; WORD NumberOfRelocations; WORD NumberOfLinenumbers; DWORD Characteristics; Adviértase que hay un Header Section por sección; asi, de acuerdo con el PE Header d el Notepad, habrá 6 Section Headers. Cada sección contiene su propio nombre en un st ring ASCII (por ejempo, ".text") y un puntero a su ubicación dentro del archivo; e stos headers son de una longitud de 40 bytes y no están previstos bytes de relleno entre ellos. Las secciones que normalmente están presentes en un ejecutable son: .text (sección de código ejecutable) .data (sección de datos, también puede haber .rdata o .bss) .rsrc (sección de recursos) .edata (sección de datos exportados) .idata (sección de datos importados)

.debug (sección de información sobre depuración) Advierta que no todas estas secciones deben necesariamente estar presentes. Cuan do se busca una sección específica, a veces conviene saltearse el header completo y buscar directamente el nombre ASCII de la sección en el editor hexa. Sección de código ejecutable .TEXT Esta sección contiene el código del programa y la tabla de saltos fixup. Esta sección no tiene un formato específico. Sección de datos: .data, .rdata, .bss Hay tres tipos de secciones de datos: .bss contiene datos sin inicializar (inclu yendo todas las variables declaradas como static); .rdata contiene datos de sólo-l ectura, tales como strings y constantes; .data contiene variables globales para el programa. Tampoco tiene estructura. Sección de recursos: .rsrc Esta sección contiene todos los recursos para la aplicación. Los primeros 16 bytes c ontienen el Resource Directory Header, que se estructura como sigue: Resource Directory DWORD Characteristics; DWORD TimeDateStamp; WORD MajorVersion; WORD MinorVersion; WORD NumberOfNamedEntries; WORD NumberOfIdEntries;

Es inmediatamente seguido por el número de Directory Entries especificado en Numbe rOfNamedEntries + NumberOfIdEntries: Resource Directory Entry DWORD Name; DWORD OffsetToData; El campo Name de una Directory Entry determina el tipo del recurso (como se lo d efine en winuser.h), mientras que el offset apunta o bien a otra Directory Entry (la estructura usual es 1 Resource Directory conteniendo el tipo de recurso apu ntando a un Resource Directory (o subdirectory) conteniendo el Resource ID# y un puntero a Resource Data Entry), o bien a un Resource Data Entry. Resource Data Entry DWORD OffsetToData; DWORD Size; DWORD CodePage; DWORD Reserved; Una Resource Data Entry contiene el tamaño y offset del dato de recurso real, el c ual será una lista de strings unicode (para una tabla de strings), una imagen bina ria (para un bitmap), o una lista de valores y strings (para un dialog box). En el documento "Win32 binary resource formats" publicado por Micro$oft se puede en contrar información sobre el formato del contenido de un recurso binario. Sección Export Data: .edata La sección .edata contiene los datos exportados y funciones para una aplicación o li brería (.DLL). La sección comienza con el Export Directory. Export Directory DWORD Characteristics; DWORD TimeDateStamp; WORD MajorVersion; WORD MinorVersion; DWORD Name; DWORD

Base; DWORD NumberOfFunctions; DWORD NumberOfNames; DWORD *AddressOfFunctions; DWORD *AddressOfNames; WORD *AddressOfNameOrdinals; Los últimos tres campos contienen punteros a una lista de puntos de entrada de fun ciones exportadas, una lista que contiene los nombres de las funciones separadas por caracteres NULL, y una lista de valores ordinales de las funciones. Note qu e esos punteros asumen que el programa está cargado; para encontrar las listas den tro del archivo, uno debe restar la dirección virtual del Section Header del campo AddressOf... y luego sumar la dirección del PointerToRawData. Sección datos importados: .idata Esta sección contiene las listas de las funciones importadas por el programa. Comi enza con el Import Directory: Import Directory DWORD dwRVAFunctionNameList; DWORD dwUseless1; DWORD dwUseless2; DWORD

dwRVAModuleName; DWORD dwRVAFunctionAddressList; Los dos últimos campos están repetidos para cada aplicación o librería desde la que impo rta el programa; con un editor hexa se puede ver que el orden es un poco extraño: el nombre de la primera función importada desde un módulo dado, luego el nombre del módulo, luego cualquier otra función importada desde ese módulo. El listado se repite hasta encontrar una entrada null. Sección información de depuración: .debug Esta sección contiene la información de depuración del programa, si es que el compilad or fue instruído para incluirla. Comienza con un Debug Directory: Debug Directory DWORD Characteristics; DWORD TimeDateStamp; WORD MajorVersion; WORD MinorVersion; DWORD Type; DWORD SizeOfData; DWORD AddressOfRawData; DWORD

PointerToRawData; Los diferentes tipos de información de debug están definidos en el archivo winuser.h ; cualquier otra estructura impuesta en cada tipo de información de depuración está ta mbién definida aqui. Modificación de un Header de archivo PE Desde que un header de PE da la dirección de arranque y longitud de cada una de su s secciones (y, como en el caso de la sección .rsrc, la longitud real de los datos ), es bastante simple aunque tedioso modificar el contenido de un header de PE, cambiando su tamaño original mediante el ajuste de los campos offset de cada sección según las modificaciones introducidad. Para agregar código adicional uno debe exten der la sección .text y reparar cada sección posterior. Para agregar o modificar recu rsos, se debe modificar cada subdirectorio de la sección .rsrc y reparar cada secc ión subsiguiente (esta es la manera en que operan BRW y Resource Studio). Puede co nvenir que para cambiar cualquier sección sea mejor mover su dirección virtual al fi nal del archivo PR y extender la sección anterior a esta para cubrir el vacío result ante el cual, por cierto debe llenarcos con bytes 00. Adviértase que esto es algo azaroso especialmente con las secciones .text y .idata y que la longitud del eje cutable se incrementa un poco. No obstante es el método más rápido y fácil en muchos cas os, ya que sólo es necesario reparar dos secciones (la modificada y la anterior a esta). Como alternativa, si la información agregada son datos referenciados direct amente por el programa (y esto puede hacer deseable ubicar el código ejecutable en directorios Data, y referirse a ellos por su offset dentro del programa e inser tarlo dentro del ejecutable), es agregar los datos a la última sección y extender es a sección hasta comprender todos los datos adicionados. Mammon_