Ha valaha megnyitottál egy Windowsos futtatható állományt (EXE) hexeditorral vagy akár csak a strings parancs kimenetét böngészted, szinte biztosan belefutottál az első két byte-ba: 0x4D 0x5A. ASCII-ben ez a két karakter az "MZ". Ez a jelölés nem Marc Zuckerbergre, hanem Mark Zbikowskira utal, aki a Microsoft egyik korai, kulcsfontosságú mérnöke volt, és akinek a munkája alapvetően meghatározta a DOS és a korai Windows futtatható formátumait.

A Linux Mint és általában a Linux-felhasználók gyakran találkoznak Windowsos binárisokkal – legyen szó Wine alatti futtatásról, cross-compilálásról vagy fordított mérnöki elemzésről. Érdemes ezért megérteni, mi is az az MZ fejléc, hogyan épül fel, és miért szerepel még ma is a modern PE (Portable Executable) állományok elején.

Ki volt Mark Zbikowski, és mi köze az "MZ"-hez?

Mark Zbikowski a Microsoft egyik korai fejlesztője volt, aki kulcsszerepet játszott a MS-DOS és a futtatható állományformátumok kialakításában. A DOS-os EXE formátum fejlesztésekor szokás volt a fájlformátumok elejére egy úgynevezett magic number-t tenni, amely azonosítja a fájl típusát. Az MZ fejléc esetében ez a magic number egyszerűen a fejlesztő monogramja lett: MZ = Mark Zbikowski.

Ez a gyakorlat nem volt egyedi: más rendszerekben is gyakran használtak emberi nevekhez, monogramokhoz vagy szavakhoz köthető azonosítókat. Az MZ azonban különösen tartósnak bizonyult, mert nemcsak a DOS-os EXE-kben, hanem a későbbi Windows PE formátumban is megmaradt, visszafelé kompatibilitási okokból.

Az MZ fejléc technikai felépítése

A klasszikus DOS EXE fájlok az MZ fejléc (más néven MS-DOS header) segítségével írják le a program betöltéséhez szükséges alapinformációkat. A fejléc első két byte-ja a már említett 0x4D 0x5A, ezt követik a különböző mezők, amelyek mind little-endian sorrendben tárolt 16 bites értékek (kivéve néhány későbbi kiterjesztést).

A legfontosabb mezők közül néhány (a teljesség igénye nélkül):

• e_magic (0x00–0x01): a magic number, értéke 0x5A4D (little-endianben 4D 5A, azaz "MZ").
• e_cblp (0x02–0x03): a fájl utolsó lapjának (512 byte-os blokk) mérete byte-ban.
• e_cp (0x04–0x05): a fájl teljes mérete 512 byte-os lapokban mérve.
• e_crlc (0x06–0x07): a relokációs bejegyzések száma.
• e_cparhdr (0x08–0x09): a fejléc mérete 16 byte-os paragrafusokban.
• e_minalloc / e_maxalloc (0x0A–0x0D): a program számára lefoglalható minimális és maximális extra memória paragrafusokban.
• e_ss / e_sp (0x0E–0x11): kezdeti stack szegmens és stack pointer.
• e_ip / e_cs (0x14–0x17): belépési pont (instruction pointer) és kódszegmens.
• e_lfarlc (0x18–0x19): a relokációs tábla offsetje a fájlon belül.
• e_lfanew (0x3C–0x3F): offset a további fejlécformátumokhoz (pl. PE header) – ez a mező kulcsfontosságú a Windows PE fájloknál.

Az MZ fejléc eredetileg a valódi módú (real-mode) DOS programokhoz készült, ahol a memória 16 bites szegmens:offset címzéssel volt elérhető. A fejléc mezői ennek megfelelően a szegmens-regiszterek és offsetek inicializálásához szükséges adatokat tartalmazták.

Miért van MZ fejléc a modern Windows PE fájlokban is?

A Windows NT-vonal (NT, 2000, XP, Vista, 7, 10, 11 stb.) futtatható állományformátuma a PE (Portable Executable). Ezek a fájlok is MZ-vel kezdődnek, de a DOS fejléc után egy másik, komplexebb struktúra következik. A PE formátum egyik kulcseleme, hogy a DOS fejléc e_lfanew mezője mutat a PE fejléc elejére, ahol a "PE\0\0" szignatúra található.

A PE fájlok elején lévő MZ fejlécnek két fő szerepe van:

• Visszafelé kompatibilitás: ha egy PE fájlt DOS alatt próbálnak futtatni, a DOS loader csak az MZ fejlécet érti. Ilyenkor a fájlban egy rövid, DOS-os stub program található (tipikusan: „This program cannot be run in DOS mode”), amelyet a DOS végrehajt, majd kilép.
• Formátum-azonosítás: a Windows loader is ellenőrzi az MZ-t, majd az e_lfanew mező alapján ugrik a PE fejléc kezdetére. Ha az MZ hiányzik vagy hibás, a fájl nem tekinthető érvényes PE-nek.

Ezért látjuk azt, hogy szinte minden Windowsos .exe és .dll fájl MZ-vel kezdődik, még akkor is, ha valójában soha nem fut DOS alatt. A Linuxos eszközök (pl. file, objdump, readelf – utóbbi inkább ELF-re specializált) is gyakran az MZ jelenlétét használják első lépésben a fájl típusának felismeréséhez, majd a PE-specifikus struktúrákat vizsgálják tovább.

MZ vs. más futtatható formátumok (ELF, Mach-O)

Linuxon a legelterjedtebb futtatható formátum az ELF (Executable and Linkable Format). Az ELF fájlok elején a magic number 0x7F 'E' 'L' 'F', amely egyértelműen azonosítja a formátumot. Az ELF és a PE között több fontos különbség van:

• Magic number: MZ (0x4D 0x5A) vs. 0x7F 45 4C 46 (ELF).
• Fejléc-struktúra: az MZ egy történelmi DOS-fejléc, amelyre ráépül a PE; az ELF-nél a fejléc eleve a modern, 32/64 bites architektúrákra lett tervezve.
• Platform-fókusz: PE elsősorban Windows (NT-vonal), ELF elsősorban Unix-szerű rendszerek (Linux, *BSD, Solaris, stb.).

macOS-en a Mach-O formátum használatos, amely szintén saját magic numberrel rendelkezik (pl. 0xFEEDFACE, 0xFEEDFACF, 0xCAFEBABE különböző variánsoknál). Ezekhez képest az MZ kifejezetten a DOS/Windows-világ öröksége, de a PE-n keresztül máig jelen van.

Gyakorlati szempontok Linuxon: Wine, cross-compilálás, reverse engineering

Linux Mint alatt több tipikus helyzetben találkozhatunk MZ/PE fájlokkal:

• Wine alatt futtatott Windows programok: a Wine loader a PE fejlécet olvassa, de az MZ jelenlétét is ellenőrzi. Ha hexeditorral megnézünk egy Wine alatt futó EXE-t, ugyanúgy MZ-vel kezdődik.
• Cross-compilálás MinGW-vel: ha Linuxon MinGW-t használunk Windowsos binárisok fordítására, a keletkező .exe fájlok szintén MZ/PE formátumúak lesznek. A objdump -x vagy a file parancs jól mutatja a PE struktúrát.
• Reverse engineering, malware-analízis: biztonsági szakemberek gyakran vizsgálják Windowsos binárisok felépítését Linuxon. Az MZ fejléc és az e_lfanew mező az első lépés a PE struktúra feltérképezésében.

Egyszerű ellenőrzéshez Linuxon elég egy:

hexdump -C program.exe | head

A kimenet első soraiban jól látható lesz a 4d 5a bytepár, azaz az "MZ".

Érdekességek és kevésbé ismert részletek

• Nem minden MZ = PE: léteznek olyan fájlok, amelyek MZ-vel kezdődnek, de nem PE-k, hanem valódi, régi DOS EXE-k. Ilyenkor az e_lfanew mező vagy nem mutat érvényes PE fejlécet, vagy egyáltalán nincs PE rész.
• DOS stub program: a PE fájlok elején lévő DOS stub gyakran ugyanazt az üzenetet tartalmazza („This program cannot be run in DOS mode.”). Ez a stub egy minimális, valóban futtatható DOS program, amelyet a DOS loader végrehajtana.
• Magic number ellenőrzés: sok egyszerű eszköz (pl. primitív vírusirtók, fájltípus-azonosítók) csak az MZ jelenlétét ellenőrizték, ami miatt könnyen meg lehetett téveszteni őket egy hamis MZ-vel kezdődő fájllal. A komolyabb eszközök természetesen a teljes PE struktúrát is elemzik.

Miért maradt velünk az MZ ennyi ideig?

Az MZ fejléc túlélése jó példája annak, hogyan hat a visszafelé kompatibilitás a szoftveriparra. A DOS-os örökség miatt a Windows fejlesztői úgy döntöttek, hogy a PE formátumot az MZ fejléc mögé „rejtik”, így a régi rendszerek legalább egy értelmes hibaüzenetet tudnak adni, a modern rendszerek pedig a PE struktúrát használják.

Ez a döntés azt eredményezte, hogy egy több évtizedes formátumdarab – az MZ – ma is minden Windowsos futtatható állomány elején ott van. A Linux-világban ez leginkább akkor érdekes, amikor Windowsos binárisokat kell elemezni, futtatni vagy generálni, de jól mutatja, hogy a történelmi döntések milyen mélyen beépülnek a mai rendszerekbe.

Összegzés: egy kétbetűs aláírás, ami rendszerek milliárdjain él tovább

Az, hogy minden .exe fájl elején ott az "MZ", nem véletlen, és nem is egy véletlenszerű bytepár. Ez egy konkrét mérnök, Mark Zbikowski monogramja, amely a DOS-os idők óta jelzi a futtatható állományokat. A Linux Mint felhasználók számára ez a tudás akkor válik igazán hasznossá, amikor Windowsos binárisokkal dolgoznak – legyen az Wine, cross-compilálás vagy reverse engineering.

Az MZ fejléc megértése segít jobban átlátni a PE formátumot, és általában azt, hogyan épülnek fel a futtatható állományok különböző operációs rendszereken. Egy apró, kétbyte-os „aláírás”, amely mögött komoly történet, mérnöki munka és kompatibilitási megfontolások egész sora áll.