Niezależnie od tego, czy komputer jest włączony, czy nie, wszystkie dane i programy przechowywane są w długotrwałej (zewnętrznej) pamięci komputera w postaci plików – skąd są ładowane podczas wykonywania lub przetwarzania.

Plik to pewien zestaw kodów wyświetlających pewną ilość informacji związanych z rodzajem lub przeznaczeniem, której przypisano unikalną nazwę i która jest przechowywana w pamięci długotrwałej.

Teksty źródłowe programów, programy gotowe do wykonania, dokumenty, obrazy graficzne i wszelkie inne dane mogą być przechowywane w formie plików. W zależności od rodzaju organizacji i zawartości pliki dzielą się na dwie kategorie - tekstowe i binarne (binarne). Pliki tekstowe zgodnie ze swoim przeznaczeniem przechowują ciągi znaków interpretowane jako teksty. Pliki wykonywalne składają się z kodów programów gotowych do wykonania.

Unikalne nazwy umożliwiają organizowanie plików i udostępnianie ich systemom operacyjnym i innym programom. Nazwa pliku składa się z dwóch części oddzielonych kropką: Właściwie Nazwa plik i rozszerzenie , określając jego typ (program, dane itp.). Nazwę pliku nadaje użytkownik (czasami domyślnie system). Typ pliku jest zwykle ustawiany automatycznie przez program podczas jego tworzenia, co w większości przypadków pozwala zautomatyzować uruchamianie programów. Na przykład, .com, .exe– pliki wykonywalne (programy), .txt, .rtf . doktor– pliki tekstowe, .pierwszeństwo– tekst źródłowy programu napisanego w danym języku Pascal .

Aby uporządkować rozmieszczenie plików na dyskach, ich nazwy są rejestrowane w specjalne pliki– katalogi (we współczesnych systemach operacyjnych pliki te nazywane są lornetka składana) . Katalog Jest to plik tabeli (przechowywany na tym samym dysku co pliki), w którym przechowywane są nazwy plików, informacje o ich rozmiarze, czasie ostatniej aktualizacji, atrybutach (właściwościach) plików itp. Jeśli katalog przechowuje nazwę pliku, często mówi się, że plik „znajduje się” w tym katalogu. W rzeczywistości plik jest lokowany (zapisywany) w jakimś obszarze pamięci na dysku komputera, często w postaci kilku części, fragmentów na różnych ścieżkach i dyskach pakietu (na wolnych obszarach nośnika). Odpowiednie informacje znajdują się w katalogu.

Na każdym dysku może znajdować się wiele katalogów - ich liczba jest ustalana celowo i ograniczona jedynie pojemnością dysku. Dotyczy to również ilości plików w katalogu. Wszystkie nowoczesne dyskowe systemy operacyjne zapewniają utworzenie systemu plików zaprojektowanego do organizowania przechowywania danych i zapewniania do nich dostępu. Zasada organizacji systemu plików jest tabelaryczna. Powierzchnię dysku twardego uważa się za trójwymiarową matrycę, której wymiary to liczba powierzchni, cylindrów i sektorów. Przez cylinder rozumie się zbiór wszystkich torów należących do różnych powierzchni i znajdujących się w jednakowej odległości od osi obrotu. Dane o tym, gdzie na dysku zapisano dany plik, przechowywane są w obszarze systemowym dysku w specjalnych tabelach alokacji plików (tablice FAT).

O kolejności przechowywania plików na dysku decyduje organizacja systemu plików (organizacja katalogów oraz sposób opisu w nich rozmieszczenia i atrybutów plików).

Na dyskach przechowywane są setki tysięcy plików, dlatego dla ułatwienia wyszukiwania pliki są zorganizowane w formie wielopoziomowego systemu plików, którego struktura jest pokazana na rysunku.

Katalog początkowy, główny zawiera podkatalogi pierwszego poziomu, z kolei w każdym z nich znajdują się podkatalogi drugiego poziomu itd. Każdy katalog ma nazwę (bez rozszerzenia) i można go zarejestrować w innym, rodzicielski katalog. Należy zauważyć, że katalogi na wszystkich poziomach mogą przechowywać nie tylko katalogi, ale także pliki.

Chociaż dane o lokalizacji plików są faktycznie przechowywane w formie tabelarycznej, dla wygody użytkownika są one przedstawiane jako drzewo hierarchiczne struktury, a wszystkie niezbędne połączenia zapewnia system operacyjny.

Funkcje konserwacji systemu plików obejmują następujące operacje wykonywane pod kontrolą system operacyjny:

tworzenie i nazywanie plików;

tworzenie i nazywanie katalogów;

zmiana nazw plików i katalogów;

kopiowanie i przenoszenie plików pomiędzy dyskami komputerów oraz pomiędzy katalogami na tym samym dysku;

usuwanie plików i katalogów;

nawigacja po strukturze plików w celu uzyskania dostępu do danego pliku lub katalogu;

zarządzanie atrybutami plików.

Wykład 3. Struktura plików

Literatura

o Nowoczesne systemy operacyjne, E. Tanenbaum, 2002, St. Petersburg, St. Petersburg, 1040 s., (w djvu 10,1 MB) więcej szczegółów>>

o Sieciowe systemy operacyjne N. A. Olifer, V. G. Olifer (archiwum zip 1,1 MB)

o Sieciowe systemy operacyjne N. A. Olifer, V. G. Olifer, 2001, St. Petersburg, Peter, 544 s., (w djvu 6,3 MB) więcej szczegółów>>

Akta

Wymagania dotyczące przechowywania informacji:

o możliwość przechowywania dużych ilości danych

o informacje należy zachować po zakończeniu procesu

o kilka procesów musi mieć jednoczesny dostęp do informacji

2.1.1 Nazywanie plików

Długość nazwy pliku zależy od systemu operacyjnego i może wynosić od 8 (MS-DOS) do 255 (Windows, LINUX).

Systemy operacyjne potrafią rozróżniać wielkie i małe litery. Na przykład WINDOWS i okna dla MS-DOS są takie same, ale dla UNIX są to różne pliki.

W wielu systemach operacyjnych nazwa pliku składa się z dwóch części oddzielonych kropką, np. Windows.exe. Część po kropce nazywa się rozszerzenie pliku. System wykorzystuje to do rozróżnienia typu pliku.

W przypadku MS-DOS rozszerzenie wynosi 3 znaki. Za jego pomocą system rozróżnia typ pliku i to, czy można go uruchomić, czy nie.

W systemie UNIX rozszerzenie jest ograniczone do rozmiaru nazwy pliku wynoszącego 255 znaków, a UNIX może mieć kilka rozszerzeń, ale rozszerzenia są częściej używane przez aplikacje, a nie przez system operacyjny. UNIX nie może określić, czy plik jest wykonywalny, czy nie, na podstawie jego rozszerzenia.

2.1.2 Struktura pliku

Trzy główne struktury plików:

1. Sekwencja bajtów- System operacyjny nie jest zainteresowany zawartością pliku, widzi tylko bajty. Główną zaletą takiego systemu jest elastyczność użytkowania. Używany w systemach Windows i UNIX.

2. Kolejność zapisów- zapisy o stałej długości (np. karta dziurkowana) odczytywane są sekwencyjnie. Nie używany teraz.

3. Drzewo wejściowe- każdy rekord posiada klucz, zapisy odczytywane są za pomocą klucza. Główną zaletą takiego systemu jest szybkość wyszukiwania. Nadal używany na komputerach mainframe.

Trzy typy struktur plików.

2.1.3 Typy plików

Główne typy plików:

o Regularny- zawierają informacje o użytkowniku. Używany w systemach Windows i UNIX.

o Katalogi- pliki systemowe, które zapewniają obsługę struktury systemu plików. Używany w systemach Windows i UNIX.

o Charakter- do modelowania wejścia-wyjścia. Używany tylko w systemie UNIX.

o Blok- do modelowania dysków. Używany tylko w systemie UNIX.

Główne typy zwykłych plików:

o pliki ASCII- składają się z ciągów tekstowych. Każdy wiersz kończy się znakiem powrotu karetki (Windows), znakiem nowego wiersza (UNIX) i obydwoma znakami (MS-DOS). Dlatego jeśli otworzysz plik tekstowy napisany w UNIX, w Windows, wtedy wszystkie linie połączą się w jedną dużą linię, ale w MS-DOS nie zostaną połączone ( jest to dość powszechna sytuacja). Główne zalety plików ASCII:
- mogą być wyświetlane na ekranie i wysyłane do drukarki bez konwersji
- może być edytowany przez prawie każdego redaktora

o Pliki binarne- inne pliki (inne niż ASCII). Z reguły mają strukturę wewnętrzną.

Główne typy plików binarnych:

o Wykonywalny- programy, mogą być przetwarzane przez sam system operacyjny, chociaż są zapisywane jako ciąg bajtów.

o Niewykonywalny- wszyscy inni.

Przykłady plików wykonywalnych i niewykonywalnych

„Magiczna liczba”- identyfikowanie pliku jako wykonywalnego.

2.1.4 Dostęp do plików

Główne typy dostępu do plików:

o Spójny- bajty są odczytywane w kolejności. Używane, gdy istniały taśmy magnetyczne.

2.1.5 Atrybuty plików

Główne atrybuty pliku:

o Ochrona – kto i w jaki sposób może uzyskać dostęp do pliku (użytkownicy, grupy, odczyt/zapis). Używany w systemach Windows i UNIX.

o Hasło - hasło do pliku

o Twórca – kto stworzył plik

o Właściciel - aktualny właściciel pliku

o Flaga tylko do odczytu - 0 - odczyt/zapis, 1 - tylko do odczytu. Używany w systemie Windows.

o Flaga „ukryty” - 0 - widoczny, 1 - niewidoczny na liście plików katalogowych (domyślnie). Używany w systemie Windows.

o Oznacz „system” - 0 - normalny, 1 - systemowy. Używany w systemie Windows.

o Oznacz „archiwum” – gotowe lub nie do archiwizacji (nie mylić z kompresją). Używany w systemie Windows.

o Oznacz "skompresowany" - plik jest skompresowany (podobnie jak archiwa ZIP). Używany w systemie Windows.

o Oznacz „zaszyfrowane” – używany jest algorytm szyfrowania. Jeśli ktoś spróbuje odczytać plik, który nie ma do tego uprawnień, nie będzie mógł go odczytać. Używany w systemie Windows.

o Flaga ASCII/binarna - 0 - ASCII, 1 - binarna

o Flaga dostępu swobodnego - 0 - tylko sekwencyjny, 1 - dostęp losowy

o Flaga „tymczasowa” - 0 - normalna, 1 - aby usunąć plik po zakończeniu procesu

o Flaga blokująca - blokowanie dostępu do pliku. Jeśli jest zajęty edycją.

o Czas utworzenia - data i godzina utworzenia. Używany jest UNIX.

o Czas ostatniego dostępu - data i godzina ostatniego dostępu

Czas ostatnia zmiana- data i godzina ostatniej zmiany. Używany w systemach Windows i UNIX.

o Aktualny rozmiar- rozmiar pliku. Używany w systemach Windows i UNIX.

2.1.6Operacje na plikach

Podstawowe wywołania systemowe do pracy z plikami:

o Utwórz – utworzenie pliku bez danych.

o Usuń - usuń plik.

o Otwórz - otwórz plik.

o Zamknij - zamknięcie pliku.

o Odczyt - odczyt z pliku, z aktualnej pozycji pliku.

o Write - zapis do pliku, do aktualnej pozycji pliku.

o Dołącz - dodanie na końcu pliku.

o Seek – ustawia wskaźnik pliku na określoną pozycję w pliku.

o Pobierz atrybuty - pobieranie atrybutów pliku.

o Ustaw atrybuty - ustaw atrybuty pliku.

o Zmień nazwę – zmień nazwę pliku.

Struktura pliku PE

Ogólny opis pliku PE

Rozwiązywanie szerokiego zakresu zadań programistycznych wymaga wiedzy struktura wewnętrzna pliki wykonywalne i pomysł, w jaki sposób są ładowane do pamięci.

We wszystkich 32-bitowych gałęziach systemu operacyjnego Windows pliki obiektów (.OBJ), bibliotek (.LIB) i plików wykonywalnych (.EXE i .DLL) są przechowywane w jednym formacie COFF (Common Object File Format), który jest używany przez niektóre Systemy Unix i systemy operacyjne VMS.

Format PE (Portable Executable) to specjalizacja COFF do przechowywania modułów wykonywalnych. Został on ustandaryzowany przez Komitet ds. Standardów Interfejsu Narzędzi (Microsoft, Intel, IBM, Borland, Watcom itp.) w 1993 r., a następnie stopniowo aktualizowany (ostatnia aktualizacja, o której wiem, miała miejsce w lutym 1999 r., ale nie obejmuje obsługi metadanych dla .NET, dodany w 2000 r.). Nazwa Portable Executable wzięła się stąd, że tego formatu nie zależy od architektury procesora, dla którego plik wykonywalny jest zbudowany.

Obecnie istnieją dwa formaty plików PE: PE32 i PE32+. Obydwa ograniczają przestrzeń adresową programu do 4 GB (0xFFFFFFFF), ale PE32 używa adresów 32-bitowych (architektura Win32), a PE32+ używa adresów 64-bitowych (architektura Win64).

Większość struktur i stałych opisanych poniżej znajduje się w standardowym pliku nagłówkowym Windows WINNT.H.

Każdy plik PE składa się z kilku nagłówków i kilku (od 1 do 96) sekcji. Nagłówki zawierają oficjalna informacja, opisujący różne właściwości pliku wykonywalnego i jego strukturę. Sekcje zawierają dane, które są przydzielane do przestrzeni adresowej procesu, gdy plik wykonywalny jest ładowany do pamięci.

Pliki PE są względnymi plikami do pobrania, tj. teoretycznie można umieścić w przestrzeni adresowej 0x00000000 - 0xFFFFFFFF z dowolnego adresu, zwanego adresem bazowym. Ponieważ adres bazowy nie jest z góry znany, struktura plików PE opiera się na koncepcji RVA (względny adres wirtualny). RVA to przesunięcie w stosunku do adresu bazowego pliku wykonywalnego podany adres. Innymi słowy, aby uzyskać adres liniowy w pamięci wirtualnej procesu, należy dodać RVA do adresu bazowego.

Należy szczególnie podkreślić, że RVA nie mają nic wspólnego z przesunięciami względem początku pliku. Podczas procesu ładowania pliku każda jego sekcja jest umieszczana w pamięci z własnym RVA i, jeśli to konieczne, dopełniana zerami do określonego rozmiaru. W tym przypadku sekcja RVA i jej rozmiar w pamięci, ogólnie rzecz biorąc, nie są w żaden sposób powiązane z jej lokalizacją i rozmiarem w pliku źródłowym.

Ogólną strukturę pliku PE przedstawiono w tabeli 2.1:

Tabela 2.1 – Struktura pliku Re

Poniżej szczegółowo opisano każdą z tych struktur.

Ogólny opis nagłówka i kodu pośredniczącego DOS

Ponieważ zarówno aplikacje DOS, jak i Windows mają rozszerzenie .EXE, wszystkie są wykonywalne Pliki Windowsa użyj schematu podwójnego rozruchu. Polega ona na tym, że plik zaczyna się od nagłówka DOS, po którym następuje odcinek, czyli tzw. Mały plik EXE w formacie DOS. Kiedy próbujesz załadować plik z DOS-u, wykonywany jest kod pośredniczący, a kiedy ładujesz plik z Windows, moduł ładujący analizuje nagłówek DOS i wyodrębnia z niego przesunięcie w stosunku do prawdziwego nagłówka pliku wykonywalnego.

b Struktura nagłówka DOS nosi nazwę IMAGE_DOS_HEADER. Nie będę w pełni opisywał nagłówka DOS-owego, bo... Interesują nas w nim tylko dwa pola, a mianowicie:

b sygnatura 2-bajtowa (WORD) zlokalizowana w offsetie 0 (e_magic) i równa „MZ” (IMAGE_DOS_SIGNATURE);

b 4-bajtowe (DWORD) przesunięcie od początku pliku do nagłówka PE, zlokalizowane pod offsetem 0x3C (e_lfanew).

Podczas ładowania pliku PE należy najpierw sprawdzić podpis DOS, następnie znaleźć przesunięcie do nagłówka PE, a następnie sprawdzić podpis PE znajdujący się na początku jego nagłówka. Podpis ten składa się z 4 bajtów i jest równy „PE” (oznaczenie IMAGE_NT_SIGNATURE).

Inne pliki (pliki wykonywalne Win16 i OS/2 oraz sterowniki Windows 9x VxD) korzystają z tego samego schematu podwójnego rozruchu, dlatego sprawdzenie poprawności podpisu PE jest obowiązkowe.

Zazwyczaj moduł DOS wyświetli komunikat typu „Ten program wymaga systemu Microsoft Windows” i zakończy działanie. Jednak budując program, możemy określić w wiersz poleceń zbierz dowolny plik DOS EXE jako kod pośredniczący. Pozwala to na tworzenie „podwójnych” programów działających zarówno w systemie DOS, jak i Windows.

Struktura nagłówka DOS

typedef struct _IMAGE_DOS_HEADER ( // Nagłówek DOS.EXE

USHORT e_magia; // Magiczna liczba

USHORT e_cblp; // Liczba bajtów na ostatniej stronie pliku

USHORT e_cp; // Liczba stron w pliku

USHORT e_crlc; // Przeprowadzki

USHORT e_cparhdr; // Rozmiar nagłówka w akapitach

USHORT e_minalloc; // Wymagana minimalna liczba dodatkowych akapitów

USHORT e_maxalloc; // Wymagana maksymalna liczba dodatkowych akapitów

USHORT e_ss; // Wartość początkowa (względna) rejestru SS

USHORT e_sp; // Wartość początkowa zarejestruj się

USHORT e_csum; // Suma kontrolna

USHORT e_ip; // Wartość początkowa rejestru IP

USHORT e_cs; // Wartość początkowa (względna) rejestru CS

USHORT e_lfarlc; // Adres w pliku do tabeli przekazywania

USHORT e_ovno; // Liczba nakładek

USHORT e_res; // Skryty

USHORT e_oemid; // Identyfikator OEM (dla e_oeminfo)

USHORT e_oeminfo; // Informacje OEM; specyficzny dla e_oemid

USHORT e_res2 ; // Skryty

DŁUGI e_lfanew; // Adres w nowym pliku nagłówkowym .exe

) IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

Najważniejszym polem jest tutaj e_lfanew, które zawiera 4-bajtowe przesunięcie od początku pliku do nagłówka PE. Pierwsze pole struktury e_magic zawiera sygnaturę pliku wykonywalnego. Wszystkie pliki wykonywalne kompatybilne z MS-DOS mają podpis 0x54AD, który jest reprezentowany w znakach ASCII przez dwa znaki MZ. Z tego powodu nagłówek DOS jest często nazywany nagłówkiem MZ.

Struktura nagłówka PE

Nagłówek PE (IMAGE_NT_HEADERS) składa się z trzech części (patrz tabela 2.2):

Tabela 2.2 – Struktura nagłówka

struktura IMAGE_NT_HEADERS (

podpis DWORD;

IMAGE_FILE_HEADER Nagłówek pliku;

IMAGE_OPTIONAL_HEADER Opcjonalny nagłówek;

Nagłówek PE zawsze zaczyna się od 4-bajtowego podpisu „PE” (IMAGE_NT_SIGNATURE). Po nim następują dwa nagłówki: nagłówek pliku (IMAGE_FILE_HEADER) i opcjonalny nagłówek (IMAGE_OPTIONAL_HEADER). Pomimo swojej nazwy, IMAGE_OPTIONAL_HEADER jest zawsze obecny w pliku PE (jest opcjonalny z punktu widzenia ogólnego formatu COFF, ponieważ nie jest używany w plikach obiektowych i bibliotek).

Nagłówek pliku

Nagłówek pliku składa się z 0x14 bajtów (definicja IMAGE_SIZEOF_FILE_HEADER), jest umieszczany bezpośrednio po podpisie i zawiera opis ogólny plik. Składa się z następujących pól:

Tabela 2.3 – Struktura nagłówka pliku

Opis przeznaczenia pól.

Pole maszynowe

16-bitowa liczba określająca architekturę procesora, na którym można uruchomić program.

Pole TimeDateStamp

32-bitowa liczba zawierająca datę i godzinę utworzenia pliku. Format tego pola jest nieudokumentowany, ale kolekcjonerzy firmy Microsoft wprowadzają tutaj czas jako liczbę sekund od północy 01.01.1970 w formacie UTC (to znaczy używają uniksowego formatu czasu zwracanego przez funkcję czasu języka C). Nawiasem mówiąc, oznacza to, że obecny stan formatu PE obowiązuje tylko do 18.01.2038.

Ponieważ format tego pola jest nieudokumentowany, niektórzy zewnętrzni kolekcjonerzy przechowują jego wartość w innych formatach. To może być istotne, bo... To pole jest używane podczas dynamicznego łączenia importów z bibliotek DLL.

Pola PointerToSymbolTable i NumberOfSymbols

Zgodnie ze standardem COFF te 4-bajtowe pola muszą zapewniać dostęp do informacji debugowania w pliku. Jednak wszystkie znane mi kolektory zawierają zera, a do uzyskania dostępu do informacji debugowania używana jest inna metoda (zobacz katalog informacji o debugowaniu).

Pole SizeOfOptionalHeader

16-bitowa liczba określająca rozmiar opcjonalnego nagłówka. Jest to 0xE0 dla plików PE32 (IMAGE_SIZEOF_NT_OPTIONAL32_HEADER) i 0xF0 dla plików PE32+ (IMAGE_SIZEOF_NT_OPTIONAL64_HEADER).

Pole Charakterystyka

16-bitowe pole flag zawierające atrybuty COFF pliku.

Opcjonalny nagłówek

Opcjonalny nagłówek ma dwa różne formaty: dla PE32 i dla PE32+. Odpowiednie struktury noszą nazwy IMAGE_OPTIONAL_HEADER32 i IMAGE_OPTIONAL_HEADER64. Ich pola podsumowano w tabeli 2.4:

Tabela 2.4 – Opcjonalna struktura nagłówka

Offset (sześciokątny, PE32/PE32+)	Rozmiar (PE32/PE32+)	Typ (PE32/PE32+)	Nazwa	Opis
				Podpis nagłówka.
			Wersja MajorLinker	Najbardziej znacząca cyfra numeru wersji asemblera. Nieużywany przez bootloader.
			Wersja MinorLinker	Drobna cyfra numeru wersji asemblera. Nieużywany przez bootloader.
				Suma rozmiarów wszystkich sekcji zawierających kod programu.
			Rozmiar zainicjowanych danych	Suma rozmiarów wszystkich sekcji zawierających zainicjowane dane.
			Rozmiar niezainicjowanych danych	Suma rozmiarów wszystkich sekcji zawierających niezainicjowane dane.
			AdresPunktu Wejścia	RVA punktu uruchomienia programu. W przypadku sterownika jest to adres DriverEntry, w przypadku biblioteki DLL jest to adres DllMain lub zero.
				RVA to początek kodu programu.
				RVA początku danych programu. Pole niezaufane, nieużywane przez moduł ładujący. Niedostępne w wersji PE32+!
				Preferowany adres bazowy programu w pamięci, będący wielokrotnością 64 KB. Wartość domyślna to 0x00400000 dla plików EXE w systemie Windows 9x/NT, 0x00010000 dla plików EXE w systemie Windows CE i 0x10000000 dla bibliotek DLL. Załadowanie programu z tego adresu pozwala obejść się bez ustawiania adresów.
			Wyrównanie sekcji	Wyrównanie bajtów dla sekcji ładowanych do pamięci większe lub równe FileAlignment. Domyślnie jest to rozmiar strony pamięci wirtualnej dla tego procesora.
				Wyrównanie w bajtach sekcji w pliku. Musi to być potęga liczby 2 od 512 do 64 KB włącznie. Wartość domyślna to 512. Jeśli opcja SessionAlignment jest mniejsza niż rozmiar strony pamięci wirtualnej, funkcja FileAlignment musi być do niego dopasowana.
			Główna wersja systemu operacyjnego	Najbardziej znacząca cyfra numeru wersji systemu operacyjnego. Nieużywany przez bootloader.
			Podrzędna wersja systemu operacyjnego	Mała cyfra numeru wersji systemu operacyjnego. Nieużywany przez bootloader.
			Wersja MajorImage	Najbardziej znacząca cyfra numeru wersji tego pliku. Nieużywany przez bootloader.
			Wersja mniejszego obrazu	Drobna cyfra numeru wersji tego pliku. Nieużywany przez bootloader.
			Główna wersja podsystemu	Najbardziej znacząca cyfra numeru wersji podsystemu.
			Wersja podsystemu pomocniczego	Dolna cyfra numeru wersji podsystemu.
			Wartość wersji Win32	Zarezerwowane, zawsze równe 0.
				Rozmiar pliku w pamięci, łącznie ze wszystkimi nagłówkami. Musi być wielokrotnością SessionAlignment.
				Całkowity rozmiar nagłówka i kodu pośredniczącego DOS, nagłówka PE i nagłówków sekcji, wyrównany do granicy FileAlignment. Określa przesunięcie od początku pliku do danych pierwszej sekcji.
				Suma kontrolna pliku.
				Podsystem wykonawczy systemu Windows dla tego pliku.
			Dll Charakterystyka	Dodatkowe atrybuty pliku.
			Rezerwa rozmiaru stosu	Rozmiar stosu wątku początkowego programu w bajtach pamięci wirtualnej. Podczas ładowania do pamięci fizycznej wyświetlany jest później tylko bajt SizeOfStackCommit, wyświetlana jest jedna strona pamięci wirtualnej. Wartość domyślna to 1 MB.
			Rozmiar stosuZatwierdź	Początkowy rozmiar stosu programu w bajtach. Wartość domyślna to 4 KB.
			Rezerwa rozmiaru sterty	Rozmiar sterty programu w bajtach. Podczas ładowania do pamięci fizycznej wyświetlany jest później tylko bajt SizeOfHeapCommit, wyświetlana jest jedna strona pamięci wirtualnej. Wartość domyślna to 1 MB. We wszystkich 32-bitowych wersjach systemu Windows sterta jest ograniczona jedynie rozmiarem pamięci wirtualnej i to pole wydaje się być ignorowane.
			Rozmiar stertyZatwierdź	Początkowy rozmiar sterty programu w bajtach. Wartość domyślna to 4 KB.
				Pole przestarzałe, nieużywane.
			LiczbaRwaIRozmiary	Liczba deskryptorów katalogu danych. NA aktualna chwila zawsze równa się 16.
		IMAGE_DATA_DIRECTORY		Deskryptory katalogów danych.

16-bitowe pole zawierające podpis nagłówka. Może przyjmować wartości (patrz tabela 2.4):

Tabela 2.4 - Prawidłowe wartości Magiczne pola

Pola MajorSubsystemVersion i MinorSubsystemVersion

Liczby 16-bitowe wskazujące oczekiwanie Wersja Windowsa. W przeciwieństwie do wszystkich innych pól numeru wersji, to pole było analizowane po załadowaniu programów do systemów NT 4.0 i 95. Jeśli program był aplikacją graficzną i to pole nie zawierało wersji 4.0, wówczas uznawano, że program został opracowany dla systemu NT 3.51 i symulowano zachowanie tego systemu operacyjnego (w szczególności brak trójwymiarowych stylów dialogów itp.). Obecnie nieużywany i prawie zawsze równy 4,0.

Pole sumy kontrolnej

Suma kontrolna pliku 32-bitowego. Sprawdzane tylko w systemie Windows NT podczas ładowania sterowników jądra i kilku systemowych bibliotek DLL. Algorytm obliczania sumy kontrolnej nie jest udokumentowany, ale do jej obliczenia można użyć funkcji systemowej CheckSumMappedFile z biblioteki IMAGEHLP.DLL.

Pole podsystemu

16-bitowa liczba wskazująca, który sub System Windows Interfejs API musi wykonać ten plik. Jego możliwe wartości przedstawiono w tabeli 2.5:

Tabela 2.5 - Prawidłowe wartości pola Podsystem

Nazwa	Oznaczający	Podsystem
IMAGE_SUBSYSTEM_UNKNOWN		Nieznany podsystem.
IMAGE_SUBSYSTEM_NATIVE		Nie jest wymagany żaden podsystem, używany przez sterowniki i natywne aplikacje NT.
IMAGE_SUBSYSTEM_WINDOWS_GUI		Podsystem graficzny systemu Windows.
IMAGE_SUBSYSTEM_WINDOWS_CUI		Podsystem konsoli Windows.
IMAGE_SUBSYSTEM_OS2_CUI		Podsystem konsoli OS/2.
IMAGE_SUBSYSTEM_POSIX_CUI		Podsystem konsoli POSIX.
IMAGE_SUBSYSTEM_NATIVE_WINDOWS		„Natywny” sterownik dla systemu Windows 9x.
IMAGE_SUBSYSTEM_WINDOWS_CE_GUI		Podsystem graficzny Windows CE.
IMAGE_SUBSYSTEM_EFI_APPLICATION		programu EFI.
IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER		Sterownik EFI zapewniający usługę rozruchu.
IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER		Sterownik EFI środowiska wykonawczego.
IMAGE_SUBSYSTEM_EFI_ROM		Oprogramowanie sprzętowe ROM dla EFI.
IMAGE_SUBSYSTEM_XBOX		Podsystem Xbox.

Pole DLLCharacteristics

16-bitowe pole flagi określające dodatkowe atrybuty pliku. Możliwe wartości flag przedstawiono w tabeli 2.6.

Tabela 2.6 – Możliwe wartości flag pola DLLCharacteristics

Pola NumberOfRvaAndSizes i DataDirectory

Na końcu opcjonalnego nagłówka znajduje się 32-bitowa liczba przechowująca liczbę uchwytów katalogu danych. Po nim następuje tablica samych deskryptorów, z których każdy wygląda następująco:

struktura IMAGE_DATA_DIRECTORY (

Adres wirtualny DWORD;

Obecnie pole NumberOfRvaAndSizes zawsze zawiera liczbę 16 (nazwa symboliczna IMAGE_NUMBEROF_DIRECTORY_ENTRIES). Odpowiednio tablica DataDirectory również składa się z 16 deskryptorów. Każdy deskryptor zawiera RVA i rozmiar jednego katalogu danych. Jeżeli katalogu nie ma w pliku, to oba pola jego deskryptora są równe zero.

Każdy z katalogów danych zawiera określone informacje serwisowe. Typ tej informacji jest określony przez numer katalogu w tablicy deskryptorów. Ponieważ katalogi danych zwykle znajdują się wewnątrz partycji, aby uzyskać dostęp do ich zawartości, musimy najpierw sprawdzić strukturę partycji.

Nagłówki sekcji

Zaraz po nagłówku PE w pliku znajduje się tablica nagłówków sekcji. Jego rozmiar jest określony przez pole NumberOfSections w nagłówku pliku. Każdy nagłówek sekcji składa się z 0x28 bajtów i ma następująca struktura(patrz tabela 2.7):

Tabela 2.7 – Struktura nagłówka sekcji

Przesunięcie (szesnastkowe)			Nazwa	Opis
				Nazwa sekcji.
			Różne Rozmiar wirtualny	Rozmiar sekcji pamięci. Jeśli ta wartość jest większa niż SizeOfRawData, wówczas sekcja jest uzupełniana w pamięci bajtami zerowymi.
				Sekcje RVA w pamięci.
				Rozmiar sekcji w pliku. Zawsze wielokrotność FileAlignment z opcjonalnego nagłówka. Jeśli sekcja zawiera tylko niezainicjowane dane, wówczas wartość tego pola wynosi zero.
			WskaźnikDoRawData	Przesunięcie w pliku na początek tych sekcji. Zawsze wielokrotność FileAlignment z opcjonalnego nagłówka. Jeśli sekcja zawiera tylko niezainicjowane dane, wówczas wartość tego pola wynosi zero.
			WskaźnikDoRelokacji
			WskaźnikDoNumerLini	W plikach wykonywalnych to pole ma zawsze wartość zero.
			LiczbaRelokacji	W plikach wykonywalnych to pole ma zawsze wartość zero.
			NumberOfLinenumbers	W plikach wykonywalnych to pole ma zawsze wartość zero.
			Charakterystyka	Atrybuty sekcji.

Nazwa sekcji

Nazwa sekcji zawiera od 0 do 8 znaków ASCII. Zamiast stałej 8 możesz użyć definicji IMAGE_SIZEOF_SHORT_NAME. Jeśli nazwa ma mniej niż 8 znaków, jest uzupełniana bajtami zerowymi. Jeżeli składa się z dokładnie 8 znaków, to nie ma kończącego bajtu zerowego. Warto zaznaczyć, że nazwa sekcji, ogólnie rzecz biorąc, nie ma żadnego związku z jej treścią. Każdy kompilator ma własną konwencję nazewnictwa sekcji, więc podczas jej analizowania nie można polegać na nazwie sekcji. Jedynym niezawodnym sposobem ustalenia, co zawiera dana sekcja, jest sprawdzenie jej atrybutów i zawartych w niej katalogów danych.

Atrybuty sekcji

Pole Charakterystyka 32-bitowa zawiera zestaw flag opisujących zawartość tej sekcji. Sekcje pliku wykonywalnego mogą mieć następujące atrybuty (patrz tabela 2.8):

Tabela 2.8 – Atrybuty przekroju

Nazwa	Oznaczający	Opis
IMAGE_SCN_CNT_CODE		Sekcja zawiera kod wykonywalny.
IMAGE_SCN_CNT_INITIALIZED_DATA		Sekcja zawiera zainicjowane dane.
IMAGE_SCN_CNT_UNINITIALIZED_DATA		Sekcja zawiera niezainicjowane dane.
IMAGE_SCN_MEM_DISCARDABLE		Sekcję można usunąć z pamięci po utworzeniu procesu.
IMAGE_SCN_MEM_NOT_CACHED		Sekcja nie może być buforowana.
IMAGE_SCN_MEM_NOT_PAGED		Sekcji nie można zamienić na plik wymiany.
IMAGE_SCN_MEM_SHARED		Wszystkie kopie danego pliku mogą mieć jedną wspólną instancję tej sekcji. Najwyraźniej używany tylko w dynamicznych sekcjach danych bibliotecznych.
IMAGE_SCN_MEM_EXECUTE		Sekcję można wykonać jako kod programu.
IMAGE_SCN_MEM_READ
IMAGE_SCN_MEM_WRITE		Możesz napisać do działu.

Same sekcje znajdują się w pliku po nagłówkach wszystkich sekcji. Każda sekcja jest wyrównana do granicy FileAlignment opcjonalnego nagłówka.

Analizując zawartość działów należy wziąć pod uwagę, że treść ta może być niejednorodna. Na przykład jedna sekcja może zawierać zarówno kod wykonywalny, jak i tabelę importu.

Format pliku wykonywalnego systemu operacyjnego w dużej mierze odzwierciedla założenia i zachowania wbudowane w system operacyjny. Dynamiczne łączenie, zachowanie modułu ładującego i zarządzanie pamięcią to tylko trzy przykłady właściwości specyficznych dla systemu operacyjnego, które można zrozumieć podczas studiowania formatu pliku wykonywalnego.

Plik wykonywalny na dysku i moduł otrzymany po załadowaniu są bardzo podobne. Program ładujący po prostu używa mapowanych w pamięci plików Win32 do załadowania odpowiednich części pliku PE do przestrzeni adresowej programu. Ładowanie bibliotek DLL jest równie łatwe. Po załadowaniu modułu EXE lub .DLL system Windows traktuje go tak samo, jak inne pliki mapowane na pamięć.

Natomiast w Win32 pamięć używana na programy, dane, zasoby, tablice wejściowe, tabele wyjściowe i inne elementy to jedna ciągła liniowa tablica przestrzeni adresowej. W tym przypadku wystarczy znać adres, pod którym moduł ładujący zmapował plik wykonywalny do pamięci. Następnie, aby znaleźć dowolny element modułu, wystarczy podążać za wskaźnikami, które są zapisywane w ramach mapowania.

Nagłówek MS-DOS

Nagłówek MS-DOS zajmuje pierwsze 64 bajty pliku PE. Struktura reprezentująca zawartość nagłówka MS-DOS jest następująca:

typedef struct _IMAGE_DOS_HEADER ( //Nagłówek DOS .EXE
USHORT e_magia; //MZ
USHORT e_cblp; //Ostatnie bajty
//strona pliku
USHORT e_cp; //Strony w pliku
USHORT e_crlc; //Ustawienia
USHORT e_cparhdr; //Rozmiar nagłówka w
//akapity
USHORT e_minalloc; //Minimalna przydzielona pamięć
USHORT e_maxalloc; //Maksymalna przydzielona pamięć
USHORT e_ss; //Początkowy (względny)
//Wartość SS
USHORT e_sp; //Początkowa wartość SP
USHORT e_csum; //Suma kontrolna
USHORT e_ip; //Początkowa wartość adresu IP
USHORT e_cs; //Początkowy (względny)
//Wartość CS
USHORT e_lfarlc; //adres pliku tabeli konfiguracyjnej
USHORT e_ovno; //Numer nakładki
USHORT e_res ; //Słowa zastrzeżone
USHORT e_oemid; //Identyfikator OEM (dla
//e_oeminfo)
USHORT e_oeminfo; //Informacje OEM; e_oemid
//specyficzny
USHORT e_res2 ; //Słowa zastrzeżone
DŁUGI e_lfanew; //adres przesunięcia nagłówka PE
) IMAGE_DOS_HEADER, * PIMAGE_DOS_HEADER;

Główny nagłówek pliku PE reprezentuje strukturę typu IMAGE_NT_HEADERS, zdefiniowaną w pliku WINNT.H. Struktura IMAGE_NT_HEADERS znajdująca się w pamięci jest tym, czego system Windows używa jako bazy danych modułów w pamięci. Każdy załadowany plik EXE lub DLL jest reprezentowany w systemie Windows przez strukturę IMAGE_NT_HEADERS. Struktura ta składa się z podwójnego słowa i dwóch podstruktur, jak pokazano poniżej:

podpis DWORD;
IMAGE_FILE_HEADER Nagłówek pliku;
IMAGE_OPTIONAL_HEADER Opcjonalny nagłówek;

Podpis pliku PE

Pole podpisu, reprezentowane jako kod ASCII, to PE\0\0 (dwa bajty zerowe po PE). Jeśli pole e_lfanew w nagłówku DOS-u wskazywało w tym miejscu oznaczenie NE zamiast oznaczenia PE, to pracujesz z plikiem Win16 NE. Podobnie, jeśli w polu Podpis podano oznaczenie LE, wówczas jest to plik VxD (VirtualDeviceDriver). Oznaczenie LX odnosi się do pliku ze starego rywala Windows 95, OS/2.

Nagłówek pliku PE

Po podwójnym słowie – sygnaturze PE – w nagłówku pliku PE następuje struktura typu IMAGE_FILE_HEADER. Pola tej struktury zawierają tylko najwięcej informacje ogólne o pliku.
Poniżej znajdują się pola IMAGE_FILE_HEADER:

typedef struct _IMAGE_FILE_HEADER
{
Maszyna USHORT;
USHORT Liczba sekcji;
ULONG znacznik czasu i daty;
ULONG PointerToSymbolTable;
ULONG LiczbaSymboli;
USHORT SizeOfOptionalNagłówek;
Charakterystyka USHORT;
) IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER

Maszyna– jest to jednostka centralna, dla której przeznaczony jest plik. Zdefiniowano następujące identyfikatory procesorów:

Intel I386 0xl4C
Intel I860 0xl4D
MIPS R3000 0x162
MIPS R4000 0x166
DEC Alpha AXP 0x184
Power PC 0x1F0 (mały endian)
Motorola 68000 0x268
PA RISC 0x290 (architektura precyzyjna)

Liczba sekcji– liczba sekcji w pliku EXE lub OBJ.

CzasDataStempel– czas utworzenia pliku przez linker (lub kompilator, jeśli jest to plik OBJ). To pole wskazuje liczbę sekund, które upłynęły od godziny 16:00 31.12.1969

Wskaźnik do tabeli symboli– przesunięcie pliku tablicy symboli COFF. To pole jest używane tylko w plikach OBJ i PE z informacjami debugera COFF. Pliki PE obsługują różne formaty debugowania, więc debugery muszą odwoływać się do wpisu IMAGE_DIRECTORY_ENTRY_DEBUG w katalogu danych.

LiczbaSymboli– liczba symboli w tabeli symboli COFF.

Rozmiar opcjonalnego nagłówka– rozmiar opcjonalnego nagłówka, który może być zgodny z tą strukturą. W plikach wykonywalnych jest to rozmiar struktury IMAGE_OPTIONAL_HEADER zgodnej z tą strukturą.

Charakterystyka– flagi zawierające informacje o pliku. Opisano tutaj kilka ważnych pól.
0x0001 – plik nie zawiera ruchów
0x0002 – plik reprezentuje mapowanie wykonywalne (tzn. nie jest to plik OBJ ani LIB)
0x2000 – plik jest biblioteką dołączaną dynamicznie (DLL), a nie programem

Opcjonalny nagłówek pliku PE

Trzecim składnikiem nagłówka pliku PE jest struktura typu IMAGE_OPTIONAL_HEADER. W przypadku plików PE ta część jest obowiązkowa. Najważniejszymi polami są pola ImageBase i Subsystem.

Baza obrazów– gdy linker tworzy plik wykonywalny, oczekuje, że plik zostanie wyświetlony w konkretne miejsce w pamięci, to właśnie ten adres jest przechowywany w tym polu.

Podsystem– typ podsystemu, którego ten plik wykonywalny używa w swoim interfejsie użytkownika. WINNT.H definiuje następujące wartości:
NATIVE = 1 – nie jest wymagany żaden podsystem (na przykład dla sterownika urządzenia)
WINDOWS_GUI = 2 – działa w podsystemie Windows GUI
WINDOWS_GUI = 3 – działa w podsystemie znakowym Windows (aplikacja terminalowa)
OS2_GUI = 5 – działa w podsystemie OS/2 (tylko aplikacje OS/2 IJC)
POSIX_GUI = 7 – działa w podsystemie Posix

Tabela sekcji

Zaraz po nagłówku pliku PE w pamięci znajduje się tablica 1MAGE_SECT10N_HEADER. Ten stół. zawiera informacje o każdej sekcji wyświetlacza. Liczba elementów tej tablicy jest podana w nagłówku pliku PE (pole IMAGE_NT_HEADER.FileHeader.NumberOfSections). Sekcje na wyświetlaczu są uporządkowane według adresu początkowego, a nie alfabetycznego.
Każdy IMAGE_SECTION_HEADER reprezentuje kompletną bazę danych jednej sekcji pliku EXE lub OBJ i ma następujący format.

#zdefiniuj IMAGE_SIZEOF_SHORT_NAME 8
wpiszedef struct _IMAGE_SECTION_HEADER
{
Imię i nazwisko;
związek (
Adres fizyczny ULONG;
ULONG wirtualny rozmiar;
) Różne;
Adres wirtualny ULONG;
ULONG RozmiarRawData;
ULONG PointerToRawData;
ULONG wskaźnik do relokacji;
ULONG PointerToLinenumbers;
USHORT Liczba relokacji;
USHORT NumberOfLinenumbers;
Charakterystyka ULONG;
) IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;

Nazwa– 8-bajtowa nazwa ANSI (nie Unicode) stanowiąca nazwę sekcji.

Różne– to pole ma różne cele w zależności od tego, czy występuje w pliku EXE, czy OBJ. W pliku EXE zawiera wirtualny rozmiar sekcji kodu programu lub danych. W przypadku plików OBJ to pole określa adres fizyczny sekcji.

Adres wirtualny– w przypadku plików EXE pole to zawiera RVA, w którym moduł ładujący powinien zmapować sekcję. Narzędzia Microsoft ustawiają domyślną wartość RVA pierwszej sekcji na 0x101. Dla plików obiektowych to pole jest ustawione na 0.

RozmiarSurowych Danych– w plikach EXE pole to zawiera rozmiar przekroju z dokładnością do najbliższej górna granica rozmiar pliku.
PointerToRawData – przesunięcie pliku obszaru, w którym znajdują się dane źródłowe sekcji. Jeśli użytkownik mapuje plik PE lub COFF do pamięci (zamiast ładować go przez system operacyjny), to pole jest ważniejsze niż w VirtualAddress.

WskaźnikDoRelokacji– w plikach obiektowych jest to przesunięcie pliku informacji korekcyjnej następującej po danych źródłowych dla danej sekcji. W plikach EXE to pole jest ustawione na 0.

WskaźnikDoLinenumhers– przesunięcie pliku tabeli numerów wierszy. Tabela numerów linii dopasowuje numery linii pliku źródłowego do adresów, pod którymi można znaleźć kod wygenerowany dla danej linii. Zwykle tylko sekcje kodu (takie jak .text lub CODE) mają numery linii. W plikach EXE numery wierszy są gromadzone na końcu pliku, po danych źródłowych sekcji. W plikach obiektowych tabela numerów wierszy sekcji jest zgodna z danymi źródłowymi sekcji i tabelą relokacji dla tej sekcji.

LiczbaRelokacji– liczba ruchów w tabeli korekcji dla tej sekcji (używana tylko w plikach obiektowych).
NumberOfLinenumbers – liczba numerów linii w tabeli numerów linii dla tej sekcji.
Charakterystyka – zestaw flag wskazujących atrybuty sekcji (program/dane, przeznaczony do odczytu, przeznaczony do zapisu itp.).

Częste sekcje

Tekst sekcji(Lub KOD

Ta sekcja zawiera cały kod programu ogólnego przeznaczenia wygenerowany przez kompilator lub asembler. Linker łączy wszystkie sekcje .text z różnych plików obiektowych w jedną dużą sekcję .text w pliku EXE.

Dane sekcji(Lub DANE, jeśli plik PE został utworzony przez Borland C++)

Zainicjowane dane trafiają do sekcji .data. Zainicjowane dane składają się ze zmiennych globalnych i statycznych, które zostały zainicjowane w czasie kompilacji. Obejmują one także literały łańcuchowe (na przykład ciąg „Hello World” w programie C/C++). Linker łączy wszystkie sekcje .data z różnych plików obiektowych i LIB w jedną sekcję .data w pliku EXE. Zmienne lokalne znajdują się na stosie łańcucha i nie zajmują miejsca w sekcjach .data i .bss.

Sekcja.bss

Sekcja .bss przechowuje niezainicjowane zmienne statyczne i globalne. Linker łączy wszystkie sekcje .bss z różnych plików obiektowych i LIB w jedną sekcję .bss w pliku EXE.

Sekcja.CRT

Kolejna sekcja dotycząca zainicjowanych danych, używana przez biblioteki wykonawcze Programy Microsoftu C/C++. Dane w tej sekcji są używane do celów takich jak wywoływanie konstruktorów klas statycznych C++ przed wywołaniem main lub WinMain.

Sekcja.rsrc

Sekcja .rsrc zawiera zasoby modułu.

Dane sekcji

Sekcja.idata (lub tabela importu) zawiera informacje o funkcjach (i danych), które moduł importuje z innych bibliotek DLL. Tabela importu zaczyna się od tablicy składającej się z IMAGE_IMPORT_DESCRIPTOR. Każdy element (IMAGE_IMPORT_DESCRIPTOR) odpowiada jednej z bibliotek DLL, z którymi plik PE jest niejawnie powiązany. Liczba elementów tablicy nie jest nigdzie brana pod uwagę. Zamiast tego ostatnia struktura tablicy IMAGE_IMPORT_DESCRIPTOR zawiera pola zawierające NULL.
Struktura IMAGE_IMPORT_DESCRIPTOR ma następujący format

typedef struktura _IMAGE_IMPORT_DESCRIPTOR (
związek (
Charakterystyka DWORD;
DWORD OriginalFirstThunk;
};
DWORD znacznik czasu i daty;

Łańcuch przesyłania DWORD;
Nazwa DWORD;
DWORD FirstThunk;
) IMAGE_IMPORT_DESCRIPTOR

Charakterystyka/OryginalnyFirstThunk– To pole zawiera przesunięcie (RVA) tablicy podwójnych słów. Każde z tych podwójnych słów jest w rzeczywistości sumą IMAGE_THUNK_DATA. Każde podwójne słowo IMAGE_THUNK_DATA odpowiada jednej funkcji zaimportowanej przez ten plik EXE lub bibliotekę DLL.

CzasDataStempel– znacznik czasu i daty wskazujący, kiedy plik został utworzony.
ForwarderChain - pole to dotyczy transferu, gdy jedna biblioteka DLL przekazuje łącze do niektórych swoich funkcji do innej biblioteki DLL.
Nazwa to RVA zakończonego zerem ciągu znaków ASCII zawierającego nazwy bibliotek DLL, które mają zostać zaimportowane.

Pierwszy Thunk– Przesunięcie RVA tablicy podwójnych słów IMAGE_THUNK_DATA. W większości przypadków podwójne słowo jest traktowane jako wskaźnik do struktury IMAGE_IMPORT_BY_NAME. Struktura ta wygląda następująco:

typedef struct _IMAGE_IMPORT_BY_NAME (
SŁOWO Podpowiedź;
BAJT Nazwa;
) IMAGE_IMPORT_BY_NAME, *PIMAGE_IMPORT_BY_NAME;

Wskazówka– numer eksportu funkcji importu.
Nazwa– Ciąg znaków ASCIIZ z nazwą importowanej funkcji.

Fragment programu odczytującego z pliku PE listę funkcji systemu operacyjnego zaimportowanych przez program.

Poniższy fragment programu zapisuje listę bibliotek z funkcjami zaimportowanymi przez program do pliku FunctionList.txt.

1. unieważnij ShowImportFunction()

   BAJT *pImage = (BAJT*) GetModuleHandle(NULL) ;

   IMAGE_DOS_HEADER *idh;

   IMAGE_OPTIONAL_HEADER *ioh;

   IMAGE_SECTION_HEADER *ish;

   IMAGE_IMPORT_DESCRIPTOR *iid;

   IMAGE_IMPORT_BY_NAME *ibn;

   IMAGE_THUNK_DATA *thunk;

   int i = 0 ;

   DWORD j = 0 ;

   char lib = „Importowana biblioteka:”;

2. UCHWYT pliku = CreateFile(TEXT("FunctionList.txt") ,GENERIC_READ|GENERIC_WRITE,

   0 ,0 ,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL|FILE_FLAG_RANDOM_ACCESS,0 ) ;

   idh = (IMAGE_DOS_HEADER*) pObraz;

   ioh = (IMAGE_OPTIONAL_HEADER*)

   (pImage + idh->e_lfanew + 4 +

   rozmiar (IMAGE_FILE_HEADER) ) ;

   ish = (IMAGE_SECTION_HEADER*) ((DWORD) ioh + rozmiar (IMAGE_OPTIONAL_HEADER) ) ;

   dla (i = 0 ; tj< 16 ; i++)

pamięci przez moduł ładujący systemu operacyjnego, a następnie wykonywane. W systemie operacyjnym Windows pliki wykonywalne mają zwykle rozszerzenia „.exe” i „.dll”. Rozszerzenie „.exe” odnosi się do programów, które użytkownik może bezpośrednio uruchomić. Rozszerzenie „.dll” zawiera tak zwane biblioteki dołączane dynamicznie. Biblioteki te eksportują funkcje używane przez inne programy.

Aby moduł ładujący systemu operacyjnego mógł poprawnie się załadować plik wykonywalny do pamięci, zawartość tego pliku musi odpowiadać formatowi pliku wykonywalnego akceptowanemu w tym systemie operacyjnym. Wiele różnych formatów istniało i nadal istnieje w różnych systemach operacyjnych w różnym czasie. W tym rozdziale przyjrzymy się formatowi Portable Executable (PE). Format PE jest podstawowym formatem przechowywania plików wykonywalnych w systemie operacyjnym Windows. Zespoły. Pliki NET są również przechowywane w tym formacie.

Dodatkowo do reprezentacji można użyć formatu PE pliki obiektowe. Pliki obiektowe służą do organizowania oddzielnej kompilacji programu. Celem oddzielnej kompilacji jest to, że części programu (moduły) są kompilowane niezależnie do plików obiektowych, które następnie są łączone przez linker w jeden plik wykonywalny.

A teraz - trochę historii. Format PE został stworzony przez twórców systemu Windows NT. Wcześniej system operacyjny Windows korzystał z formatów New Executable (NE) i Linear Executable (LE) do reprezentowania plików wykonywalnych i przechowywania pliki obiektowe Zastosowano format modułu obiektowego (OMF). Format NE był przeznaczony dla 16-bitowych aplikacji Windows, podczas gdy format LE, pierwotnie opracowany dla OS/2, był już 32-bitowy. Powstaje pytanie: dlaczego? Programiści Windowsa NT zdecydowało się porzucić dotychczasowe formaty? Odpowiedź staje się oczywista, jeśli zwrócisz uwagę na fakt, że bardzo zespół, który pracował nad stworzeniem systemu Windows NT, pracował wcześniej w Digital Equipment Corporation. W DEC opracowywali narzędzia dla systemu operacyjnego VAX/VMS i mieli już umiejętności i gotowy kod do pracy z plikami wykonywalnymi reprezentowanymi w formacie Common Object File Format (COFF). W związku z tym format COFF w nieco zmodyfikowanej formie został przeniesiony do systemu Windows NT i otrzymał nazwę PE.

„Słownik .NET Framework” mówi, że PE jest implementacją formatu COFF firmy Microsoft. Jednocześnie stwierdza się, że PE jest formatem pliku wykonywalnego, a COFF jest formatem pliki obiektowe. Generalnie w dokumentacji Microsoftu możemy zaobserwować zamieszanie dotyczące nazwy formatu. W niektórych miejscach nazywają to COFF, a w innych PE. Co prawda, można zauważyć, że w nowych tekstach coraz rzadziej używa się nazwy COFF. Co więcej, format PE stale się rozwija. Na przykład kilka lat temu Microsoft przestał przechowywać informacje debugowania w pliku wykonywalnym i dlatego obecnie wiele pól w strukturach formatu COFF po prostu nie jest używanych. Ponadto format COFF jest 32-bitowy i najnowsze wydanie Format PE (zwany PE32+) może być używany na 64-bitowych platformach sprzętowych. Najwyraźniej sprawy zmierzają w kierunku tego, że nazwa COFF nie będzie już w ogóle używana.

Warto zauważyć, że pliki wykonywalne w starszych formatach NE i LE są nadal obsługiwane przez system Windows. Pliki wykonywalne w formacie NE można uruchomić pod NTVDM (NT Virtual DOS Machine), a format LE jest używany w przypadku sterowników urządzeń wirtualnych (