ESTRUTURA E FUNCIONAMENTO DE UM EXECUTVEL Por: Fernando Birck ( Fergo )

INTRODUO Neste guia vamos falar um pouco sobre a estrutura e o funcionamento de um arquivo executvel para o Microsoft Windows, mais conhecido pela sua extenso: EXE. Creio que todo o usurio de Windows j ouviu alguma vez esse nome, e sabe que o arquivo principal de qualquer aplicativo, contendo o cdigo do programa compilado. Os executveis ( ou binrios ), tambm recebem a denominao de PE. Essa sigla vem de Portable Executable, que em portugus significaria Executvel Portvel. Essa denominao vem de um padro estabelecido pela Microsoft nos primrdios do Windows, onde decidiram criar um formato de binrio capaz de rodar em qualquer outra verso do Windows. Teoricamente eles conseguiram, pois o formato do arquivo permaneceu inalterado desde o Windows 95. Os arquivos PE no se restringem apenas aos EXE. O mesmo formato utilizado para as bibliotecas de linkagem ( DLL ), componentes ActiveX ( OCX ), entre diversos outros. Isso significa que o padro de todos esses arquivos semelhante, variando apenas algumas funes. Vamos dar uma ateno maior aos arquivos EXE, pois alm de serem os mais famosos, so os que levam o formato PE da forma mais abrangente possvel. Para tal, criei um pequeno aplicativo, contendo uma janela e um boto, que ser o programa de testes, onde faremos as anlises. Apesar de simples, o suficiente para termos um executvel completo e puro ( programado em Assembly ).

FERRAMENTAS Para o nosso estudo, vamos precisar de somente algumas ferramentas. Executvel de testes o Esse o programa que vamos utilizar para realizar nossos experimentos. Pequeno, sem funcionalidade nenhuma. Porm, puro e completo. o www.fergonez.net/download.php?file=tut_teste.zip WinHex o Um editor Hexadecimal. Fundamental para qualquer anlise de binrios compilados. nele que vemos identificar as estruturas do nosso executvel PE. o http://www.winhex.com/winhex/ LordPE o Um timo aplicativo para desmembrar executveis e DLLs. Atravs dele possvel explorar com facilidade o formato complexo dos arquivos PE. o http://scifi.pages.at/yoda9k/LordPE/info.htm

ESTRUTURA E FUNCIONAMENTO Um executvel no formato PE possui uma estrutura um tanto quanto complexa, mas ao mesmo tempo muito organizada e verstil. O arquivo organizado basicamente desta maneira: Cabealho DOS Cabealho Windows Tabela de Sees Seo 1 Seo 2 Seo N...

O cabealho DOS no tem utilidade prtica dentro do sistema Windows, ele serve apenas para apresentar uma mensagem avisando o usurio que o aplicativo em questo no pode ser utilizado em modo texto. J o cabealho do Windows de extrema importncia. nele que esto todas as informaes bsicas necessrias para que o aplicativo funcione, como o nmero de sees, tamanho de cada seo e incio das mesmas, onde iniciar a execuo do cdigo, dentro dezenas de outras configuraes. Veremos isso mais adiante. O EXE divido em sees, que variam de acordo com o compilador utilizado ou que so modificadas pelo usurio. Cada seo fica responsvel por uma caracterstica no PE. As informaes referentes a cada uma das sees ficam armazenadas na Tabela de Sees. Abaixo esto listadas as sees mais comuns ( e oficiais ) de um binrio para Win32. Seo de cdigo - Code Section ( .text ou .code ) Seo de recursos Resource Section ( .rsrc ) Seo de dados Data Section ( .data ) Seo de exportao Export data section ( .edata ) Seo de importao - Import data section ( .idata ) Informaes de debug - Debug information ( .debug )

Veremos o que cada uma dessas sees comporta mais adiante, onde entraremos em detalhes mais tcnicos. Uma caracterstica interessante sobre os arquivos PE que eles so armazenados na memria mantendo a estrutura semelhante ao do arquivo no disco. Quando o usurio requisita a execuo de um aplicativo, o Windows Loader ( parte do Kernel do Windows responsvel por iniciar e organizar o binrio na memria ) analisa o cabealho do PE. Feito isso, ele possui as informaes necessrias para poder copiar o executvel do disco rgido para a RAM. No entanto, ele no jogado para a RAM exatamente da mesma forma que ele se encontra no Windows. O Loader precisa fazer alguns ajustes.

Esses ajustes so necessrios devido forma com que o S.O. da Microsoft gerencia a memria, utilizando uma memria virtual paginada. Quando as sees so carregadas para a memria, o Windows alinha cada uma delas para caber em pginas de 4KB. como se ele dividisse a RAM em diversos pedaos de 4KB e criasse um ndice de cada trecho. Exemplo: Supondo que voc tem um trecho de dados com um tamanho de 5KB, e o Windows precisa alocar esses 5KB na memria. Inicialmente ele verifica no ndice se existem pginas livres onde esses dados possam ser armazenados. Caso existam, ele vai colocar os primeiros 4KB em uma pgina, e os outros 1KB restantes na pgina seguinte. Nesta ltima, vo sobrar 3KB livres, que acabam sendo desperdiados. A figura abaixo demonstra melhor a situao:

O conceito por trs da memria virtual que ao invs de deixar o software controlar diretamente a memria, o programa chama o gerenciamento do Windows, que por sua vez vai consultar e analisar as leituras e gravaes na RAM. As vantagens por trs disso a possibilidade de criar diversos espaos de endereamento, que consiste em restringir o acesso a determinado trecho de memria somente ao aplicativo que originou a criao do mesmo, evitando que um aplicativo corrompa a memria utilizada por outra aplicao ( como ocorria com os Win 9x ).

Alm do alinhamento na memria, ele tambm possui um alinhamento em disco. O alinhamento em disco segue a mesma teoria, mas as pginas no so divididas em 4KB, pois isso ocasionaria em um desperdcio muito grande de espao. No arquivo elas so dividas em trechos de 512 bytes ( normalmente ), o que explica o fato de qualquer executvel padro possui um tamanho mltiplo de 512. Vamos ento nos focar melhor em cada trecho do executvel, comeando pelo cabealho DOS.

ESPECIFICAO TCNICA Cabealho DOS O arquivo PE comea com um cabealho DOS que ocupa os primeiros 64 bytes do arquivo. A funo deste cabealho verificar se o executvel ou no um arquivo executvel vlido, assim como identificar se o programa pode ser rodado via MS-DOS ou necessita do Windows. Para o caso de aplicativos programados para o Windows, a nica funo do cabealho DOS exibir esta mensagem ( caso seja rodado a partir do MS-DOS ): This program must be run under Microsoft Windows Este texto fica armazenado logo aps o cabealho DOS, numa rea chamada DOS Stub. Essa rea tem como funo armazenar dados que possam ser utilizados na execuo do arquivo. no DOS Stub que fica armazenada a instruo para imprimir o texto destacado acima. Abaixo vou adicionar a estrutura oficial desse cabealho, que utilizada pelos programadores. No h a necessidade de entender o significado de cada item, mas vou ressaltar os dois mais importantes.
IMAGE_DOS_HEADER STRUCT e_magic WORD ? e_cblp WORD ? e_cp WORD ? e_crlc WORD ? e_cparhdr WORD ? e_minalloc WORD ? e_maxalloc WORD ? e_ss WORD ? e_sp WORD ? e_csum WORD ? e_ip WORD ? e_cs WORD ? e_lfarlc WORD ? e_ovno WORD ? e_res WORD 4 dup(?) e_oemid WORD ? e_oeminfo WORD ? e_res2 WORD 10 dup(?) e_lfanew DWORD ? IMAGE_DOS_HEADER ENDS

Como pode ver, temos diversos itens com tamanhos WORD e DWORD, que se forem somados, fecham os 64 bytes iniciais do cabealho. De todos esses nomes, vou destacar os 2 mais importantes. e_magic - um valor de 2 bytes ( WORD ) que identifica um executvel do DOS. Nesses 2 bytes ficam armazenados a sigla MZ ( Mark Zbikowsky, um dos idealizadores do MS-DOS ). Essa sigla um dos dados que o Windows Loader

verifica na hora de rodar um aplicativo, e se ela no existir, ele deixa de reconhecer o arquivo como executvel. e_lfanew - Armazena o offset ( posio ) no arquivo onde est localizado o cabealho WIN ( falaremos dele logo em seguida ).

Veja a imagem abaixo, que representa a estrutura do cabealho DOS, dentro do aplicativo de testes ( utilize o WinHex para visualizar, caso queira )

Nesta imagem podemos notar claramente aqueles dois dados mencionados anteriormente. Os dois primeiros bytes ( 4D 5A ) compe o e_magic, contendo a sigla MZ ( valores ASCII para 4D e 5A ). J no final do cabealho DOS ( offset 0000003Ch ) nos temos os e_lfanew, que indica o local no arquivo onde est localizado o cabealho PE ( veja a seta indicativa ). Cabealho Windows O cabealho Windows, ou cabealho PE, contm as informaes fundamentais para o aplicativo. nele que esto indicadas todas as caractersticas do arquivo. Ele composto por um conjunto de estruturas, que variam de tamanho conforme a complexidade do aplicativo e/ou o nmero de sees que nele esto armazenados. A primeira dessas estruturas o cabealho do NT
IMAGE_NT_HEADERS STRUCT Signature DWORD ? FileHeader IMAGE_FILE_HEADER <> OptionalHeader IMAGE_OPTIONAL_HEADER32 <> IMAGE_NT_HEADERS ENDS

Como podemos notar, ele composto por 3 itens. O primeiro ( Signature ) possui a mesma funo do e_magic. Ele apenas identifica o cabealho NT, e deve ser composto pela sigla PE, seguido de dois bytes nulos, fechando os 4 bytes da DWORD

Em seguida temos o FileHeader, ocupando os prximos 20 bytes do cabealho NT, contendo informaes sobre a estrutura fsica do arquivo executvel. Veja a estrutura do FileHeader abaixo:
IMAGE_FILE_HEADER STRUCT Machine WORD NumberOfSections WORD TimeDateStamp DWORD PointerToSymbolTable DWORD NumberOfSymbols DWORD SizeOfOptionalHeader WORD Characteristics WORD IMAGE_FILE_HEADER ENDS ? ? ? ? ? ? ?

Dessa estrutura, os dados mais importantes so: NumberOfSections Indica o nmero de sees contida no aplicativo ( reveja a introduo, caso necessrio. Characteristics Informa se o arquivo em questo se trata de um EXE, DLL ou OCX.

Voltando ao cabealho NT, temos por ltimo uma outra estrutura, chamada de OptionalHeader. Apesar do nome, ela deve SEMPRE existir. Essa estrutura possui um tamanho de 224 bytes, sendo que os ltimos 128 so reservados para o diretrio de dados, que veremos adiante. certamente a maior estrutura, contendo o maior nmero de valores.
IMAGE_OPTIONAL_HEADER32 STRUCT Magic MajorLinkerVersion MinorLinkerVersion SizeOfCode SizeOfInitializedData SizeOfUninitializedData AddressOfEntryPoint BaseOfCode BaseOfData ImageBase SectionAlignment FileAlignment MajorOperatingSystemVersion MinorOperatingSystemVersion MajorImageVersion MinorImageVersion MajorSubsystemVersion MinorSubsystemVersion Win32VersionValue SizeOfImage SizeOfHeaders CheckSum Subsystem DllCharacteristics SizeOfStackReserve WORD BYTE BYTE DWORD DWORD DWORD DWORD DWORD DWORD DWORD DWORD DWORD WORD WORD WORD WORD WORD WORD DWORD DWORD DWORD DWORD WORD WORD DWORD ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

SizeOfStackCommit SizeOfHeapReserve SizeOfHeapCommit LoaderFlags NumberOfRvaAndSizes DataDirectory IMAGE_OPTIONAL_HEADER32 ENDS

DWORD ? DWORD ? DWORD ? DWORD ? DWORD ? IMAGE_DATA_DIRECTORY

Bastante coisa no? Os nomes das variveis na maioria dos casos explicam o seu propsito, mas como fiz anteriormente, colocarei aqui uma explicao mais profunda sobre algum desses valores. AddressOfEntryPoint Indica o endereo relativo ( RVA Relative Virtual Address ) da primeira instruo a ser executada pelo aplicativo, assim que carregado na memria. Para maiores informaes sobre endereos relativos, veja ao apndice no final do guia. ImageBase E a posio no espao relativo da memria ( restrita ao aplicativo ) que o Windows carregar o aplicativo. Na maioria dos casos, utilizado o VA ( Virtual Address, endereo relativo ) 400000h. SectionAligment o alinhamento de cada uma das sees do executvel na memria. Ns falamos um pouco sobre isso na introduo deste guia, e l foi mencionado que normalmente se utiliza um tamanho de 4096 bytes ( 4KB ), logo, o valor do SectionAligment costuma ser 1000h ( 1000 em hexadecimal representa o valor 4096 no sistema decimal. FileAligment Semelhante ao SectionAligment, mas representa o alinhamento das sees no arquivo em disco, e no na memria. Normalmente as sees ficam alinhadas em trechos de 512 bytes, o que nos daria o valor 200h em hexadecimal. SizeOfImage Tamanho total do arquivo PE aps carregado na memria, incluindo os espaos vazios deixados pelo SectionAlignment. DataDirectory 16 estruturas do tipo IMAGE_DATA_DIRECTORY. Essas estruturas ( mais precisamente, diretrios ) contm informaes referentes s sees dentro do executvel, como a tabela de Imports/Export, Code, Data, etc. Analisaremos ela detalhadamente mais a diante.

Veja a imagem abaixo, que ilustra o cabealho WIN ( PE Header ) dentro do editor Hexadecimal:

Uma outra forma de visualizar o cabealho do arquivo PE utilizando algum programa especfico para isso, como o caso do PEiD, LordPE ou at mesmo um debugger com a opo de desmembrar o cabealho ( como o caso do OllyDbg ). Para finalizar o cabealho Windows, precisamos falar sobre o IMAGE_DATA_DIRECTORY. Como mencionado logo acima, ele compe os ltimos 128 bytes do PE Header sendo uma estrutura importante, contendo o endereo ( RVA ) e tamanho dos diretrios do executvel. Segue abaixo a estrutura do IMAGE_DATA_DIRECTORY:
IMAGE_DATA_DIRECTORY STRUCT DWORD VirtualAddress ISize DWORD IMAGE_DATA_DIRECTORY ENDS ? ?

Um tanto quanto simples. Podem ver que se trata apenas de dois valores DWORD ( cada um com 4 bytes, totalizando 8 por estrutura ). Essa estrutura utilizada pelos 16 diretrios de dados, que so listados a seguir:
IMAGE_DIRECTORY_ENTRY_EXPORT IMAGE_DIRECTORY_ENTRY_IMPORT IMAGE_DIRECTORY_ENTRY_RESOURCE IMAGE_DIRECTORY_ENTRY_EXCEPTION IMAGE_DIRECTORY_ENTRY_SECURITY IMAGE_DIRECTORY_ENTRY_BASERELOC IMAGE_DIRECTORY_ENTRY_DEBUG IMAGE_DIRECTORY_ENTRY_COPYRIGHT IMAGE_DIRECTORY_ENTRY_GLOBALPTR IMAGE_DIRECTORY_ENTRY_TLS IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT IMAGE_DIRECTORY_ENTRY_IAT equ 0 equ 1 equ 2 equ 3 equ 4 equ 5 equ 6 equ 7 equ 8 equ 9 equ 10 equ 11 equ 12

Para cada uma dessas entradas h uma estrutura do tipo IMAGE_DATA_DIRECTORY. Temos 16 entradas de diretrios, e cada uma delas possui oito bytes, totalizando os 128 bytes finais do cabealho WIN. Veja a marcao em amarelo na imagem da pgina anterior ( pode verificar que h 128 bytes marcados em amarelo ). Podemos agora sair do cabealho WIN e partir para a tabela de sees Tabela de Sees A tabela de sees funciona de forma semelhante ao IMAGE_DATA_DIRECTORY. Nessa tabela esto contidas diversas informaes referentes a cada uma das sees presente no executvel ( como o tamanho, endereo e caractersticas ). A quantidade de itens na tabela de vai variar dependendo do nmero de sees contidos no aplicativo ( pode ser obtida na entrada NumberOfSections do cabealho WIN ).
IMAGE_SECTION_HEADER STRUCT Name1 union Misc PhysicalAddress VirtualSize ends VirtualAddress SizeOfRawData PointerToRawData PointerToRelocations PointerToLinenumbers NumberOfRelocations NumberOfLinenumbers Characteristics IMAGE_SECTION_HEADER ENDS IMAGE_SIZEOF_SHORT_NAME BYTE IMAGE_SIZEOF_SHORT_NAME dup(?) DWORD DWORD DWORD DWORD DWORD DWORD DWORD WORD WORD DWORD ? ? ? ? ? ? ? ? ? ?

equ 8

Name1 Nome da seo, apenas para diferenciar as sees. No tem efeito real sobre o aplicativo. No mximo 8 caracteres. VirtualAddress RVA do incio da sesso. O valor aqui contido somado com o ImageBase do cabealho WIN para ter o endereo real da seo. SizeOfRawData Tamanho total da seo em disco, levando em considerao o alinhamento utilizado na compilao ( 512 bytes, para o nosso caso ). PointerToRawData Posio da seo dentro do arquivo ( no na memria ). Esse valor nos d diretamente a posio da seo dentro do arquivo, podendo ser facilmente encontrada em um editor hexadecimal. Characteristics So as caractersticas propriamente ditas da seo. Se ela de somente leitura/escrita, possui dados no inicializados, etc.

Na introduo do tutorial vimos que existem diversas sees dentro de um arquivo PE, sendo algumas delas oficiais. O nosso aplicativo de teste composto por apenas 4 sees: CODE ( .text ) - Contm as instrues e o cdigo do programa. RDATA ( .rdata ) Dados gerais ( incluindo tabela de sees ). DATA ( .data ) Variveis inicializadas. RSRC ( .rsrc ) Resources ( textos e disposio de itens na janela ).

Podemos ento analisar a tabela dessas 4 sees dentro do WinHex:

As sees Como foi dito anteriormente, o arquivo PE pode conter infinitas sees, sendo que algumas delas so oficiais e esto presentes na maioria dos executveis. Abaixo vamos descrever qual a funo de cada uma Seo de cdigo ( CODE/TEXT ) Dentro desta seo fica armazenado o cdigo compilado do aplicativo, contendo todas as instrues em assembly para o funcionamento do programa. Qualquer alterao feita no cdigo de um aplicativo vai resultar numa mudana dos dados presentes dentro deste trecho do arquivo. Seo de dados ( DATA ) Essa seo pode ser subdivida em 3 outras sees, sendo elas: o BSS Contm todas as variveis no inicializadas ( sem um valor definido ) do aplicativo. o RDATA Dados de somente leitura. Podem ser strings, constantes ou at mesmo dados da Import Table.

o DATA Todas as outras variveis que no se encaixam em nenhuma das duas outras sees Seo de recursos ( RSRC ) Esse trecho utilizado para armazenar qualquer outro tipo de dado dentro de um executvel. Nela ficam armazenados os cones, imagens, disposio dos itens na janela, menus, etc. Ela um pouco diferente das outras sees, pois possui uma outra subdiviso interna, separando cada recurso. Um bom modo de ver essas subdivises e os dados nela contidos utilizar um Resource Editor, facilmente encontrado na internet. Recomendo o ResHack, que gratuito e poderoso. Seo de exportao ( EDATA ) Armazena o diretrio de exportao, contendo informaes sobre os nomes e endereos das funes contidas em uma DLL. Os arquivos DLL podem ser definidos por 2 tipos de funes: as internas e externas. As externas podem ser chamadas por qualquer outro mdulo. J as funes internas ficam restritas ao mdulo dono da mesma. As DLLs nos do a possibilidade de modularizar aplicativos, contendo funes genricas que podem ser utilizadas por qualquer programa. Um bom exemplo disso o prprio Kernel do Windows, que subdividido em diversas DLLs que controlam o sistema ( kernel.dll, user32.dll, gdi32.dll, entre outras ). Seo de importao ( IDATA ) Esta seo funciona de forma semelhante a anterior. Ao invs de ser voltada para os arquivos DLL ( como a de exportao ), a seo de importao tem a finalidade de montar um bando de dados de todas as funes utilizadas por um executvel, assim como o endereo e as caractersticas de cada rotina importada. Seria como dizer que a seo de exportao fornece funes para o uso e a de importao busca essas funes exportadas. Poderamos explorar melhor a seo de importao, mas ela um tanto quanto complexa, e ficaria um pouco fora do intuito deste guia. Caso queira maiores informaes, verifique no site da Microsoft pelo formato e funcionamento da API do Windows. Seo de debug ( DEBUG ) Presente normalmente nas compilaes de aplicativos em estgio de desenvolvimento, essa seo contm dados teis para o programador, que podem o auxiliar no tratamento de erros.

APNDICE ENDEREAMENTO VIRTUAL Entendendo o endereamento virtual O Windows trabalha com uma forma de endereamento virtual de memria. Isso quer dizer basicamente que os aplicativos no trabalham com endereos absolutos baseados no arquivo, mas sim na memria. Podemos citar trs formas de endereamento: Offset, VA e RVA. Offset - RawOffset Indica o posicionamento bruto de algo dentro de um arquivo. Por exemplo: PointerToRawData na tabela de sees trabalha com offsets, pois indica em qual byte ( e no endereo de memria ) no arquivo executvel se encontra determinada seo. VA Virtual Address Endereo virtual absoluto na memria. Coloquei entre aspas, pois ele absoluto apenas quando trabalhamos com o espao de endereamento criado para o aplicativo, e no para a toda a memria presente no computador. O VA comea no valor determinado pelo ImageBase, no cabealho PE RVA Relative Virtual Address o endereo relativo a partir do incio do endereamento de memria destinado ao aplicativo em questo. Tendo essas diferenciaes, podemos formar pequenas equaes que talvez esclaream um pouco as coisas: RVA = VA ImageBase VA = RVA + ImageBase Vamos para um exemplo. Suponha que um aplicativo qualquer possua um ImageBase com valor 400000h. O VA relativo ao incio do espao de memria destinado ao aplicativo passa a ser 400000h. Suponho agora que o aplicativo inicie sua execuo no RVA 1000h. Pela formula acima, podemos descobrir que o VA do incio da execuo do programa est no endereo 401000h ( RVA + ImageBase = 400000h + 1000h ). No to complicado quanto parece, s preciso cautela para no confundir as nomenclaturas.

Converso entre Offset e VA Para fazer a converso de um Offset ( posio de determinado byte no arquivo executvel ) para um VA, necessrio conhecer alguns dados do aplicativo. Primeiramente devemos saber em qual seo o nosso offset est localizado. Para isso basta comparar o offset que voc possui com o PointerToRawData e o SizeOfRawData de cada uma das sees. Fica mais fcil de entender atravs de um exemplo ( vou utilizar o nosso aplicativo de testes ). Digamos que eu queira descobrir o VA do offset 00000900h. Abaixo est uma tabela com o RawOffset e o RawSize de cada seo ( retirado da tabela de sees ) Seo .TEXT .RDATA .DATA .RSRC RawOffset 00000400h 00000600h 00000000h 00000800h RawSize 00000200h 00000200h 00000000h 00000200h VirtualOffset 00001000h 00002000h 00003000h 00004000h

Est bem claro que o nosso offset est contido dentro da seo de recursos, pois ela vai de 00000800h at 0000A00h ( 800h + 200h ) e o nosso offset est bem no meio dela ( 00000900h ). Sabemos ento que o nosso offset est 100h bytes a frente do incio da seo de recursos. Como vimos que as sees so copiadas para a memria da mesma forma que elas esto no arquivo em disco, o VA que queremos descobrir tambm est 100h bytes a frente do VirtualOffset da seo de recursos. Ento basta somar o 100h ao VirtualOffset da seo e incluir o ImageBase. VA = RawOffset RawOffset da seo + VirtualOffset da seo + ImageBase No nosso exemplo, tendo a ImageBase como 00400000h, esses clculos seriam: VA = 00000900h 00000800h + 00004000h + 00400000h VA = 00404100h Analiticamente, tambm possvel descobrir o Offset atravs de um VA: RawOffset = VA VirtualOffset da seo ImageBase + RawOffset da seo Fazendo o processo inverso para o nosso exemplo, tendo o VA 00404100h e querendo saber o RawOffset: RawOffset = 00404100h 00004000h 00400000h + 00000800h RawOfsset = 00000900h

CONCLUSO isso a. Espero que esse tutorial tenha atingido o seu objetivo, que era de dar uma viso geral sobre o formato dos executveis, assim como colocar informaes teis para programadores que pretendem se aventurar nesse mundo. Deixei de lado algumas informaes, como a seo de relocao, pois raro de aparecer. Fiquei satisfeito com o resultado e devo dizer que ao mesmo tempo em que escrevia este artigo, aprendi algumas coisas novas sobre o formato, que passaram despercebidas quando eu comecei a me interessar pelo assunto. A vantagem de entender e dominar esse tipo de arquivo que voc passa a ter a possibilidade de customizar o executvel, seja para modificar ou proteger seu software, alterando um pouco a disposio e os endereos padres estabelecidos. Para quem um dia pensa em fazer um compilador, editor de recursos ou simplesmente um visualizador de arquivos PE, creio que este tutorial possa ajudar. Gostaria de deixar um agradecimento especial ao frum Guia do Hardware, por ceder um espao onde eu possa publicar estes artigos, assim como receber crticas e sugestes do mesmo. Obrigado e at a prxima! Artigo escrito por Fernando Birck - 2007 Website: www.fergonez.net

REFERNCIAS The Portable Executable Format o http://www.nikse.dk/petxt.html Iczelion Win32 Assembly o http://win32assembly.online.fr Win32 Programming Reference o ftp://ftp.cs.virginia.edu/pub/lcc-win32/win32hlp.exe Windows EXE File Structure Microsoft o http://www.wotsit.org/download.asp?f=exe-win&sc=233430147