Přestože níže uvedené detailní informace o aktuálním formátu RPM souboru byly přesné v době psaní tohoto článku, měli byste mít na paměti tyto tři body:

1. Formát souboru podléhá změně.
2. Jestliže byl RPM soubor nějak pozmněněn, je nutné použít vhodné rpmlib příkazy k zpřístupnění souborů z balíčku. Proč? Podívejte se zpět k bodu 1!
3. Tento článek popisuje nejnovější verzi formátu RPM souboru: verze 3. Pro zjištění verze balíčku RPM může být použita utilita file.
S těmi výhradami čtěte následující text.

Každý RPM soubor může být rozdělený do čtyři odlišných sekcí:

* Lead. (Úvod)
* Signature. (Podpis)
* Header. (Hlavička)
* Archive. (Archív)

Soubory RPM jsou zapisovány v systému bajtových slov. Je-li to vyžadováno, RPM je automaticky převedeno na major bajty, jakmile je začne číst sada programů.

The Lead je první část RPM balíčku. V předchozích verzích RPM byl využíván pro uložení informací využívaných interně samotným RPM. Dnes je ale jediným účelem The Lead snadné rozpoznání souboru RPM. The Lead využívá například utilita file. Všechny informace obsažené v The Lead byly přesunuty nebo nahrazeny informací, které obsahuje Header.

RPM definuje C rutinu, která popisuje The Lead:

struct rpmlead {
unsigned char magic[4];
unsigned char major, minor;
short type;
short archnum;
char name[66];
short osnum;
short signature_type;
char reserved[16];
} ;

Co obsahuje The Lead? V následující display, číslice vlevo od dvojtečky je byte offset nulovy, v šestnáctkové (hexadecimální) soustavě, začínající soubor. Osm skupin po čtyřech znacích zobrazují byty v hex — dva byty ve skupině čtyř znaků. Dálší znaky vpravo zobrazují ASCII hodnoty uvedených dat. (Běžný způsob zobrazených binárních dat v hexaeditorech). Pokud nemají data obsažená v příslušném byte protiklad v ASCII tisknutelném znaku, zobrazí se místo něho tečka (“.“) Zde je prvních třicet-dva bytů RPM soubor — v tomto případě jde o balíček rpm-2.2.1-1.i386.rpm:

00000000: edab eedb 0300 0000 0001 7270 6d2d 322e ……….rpm-2.
00000010: 322e 312d 3100 0000 0000 0000 0000 0000 2.1-1………..

První čtyři byty (edab eedb) jsou tzv. magické číslo, které říka, že jde o soubor typu balíček RPM.
Jak program file, tak systém RPM využívá toto magic numbers k určení, zda soubor je pravý RPM nebo ne.

Další dva byty (0300) obsahuje verzi RPM souboru. V našem příkladu je hlavní číslo (tzv. major numbers) číslem verze, tedy verze 3, a druhé (minor) číslo podverze je 0. Verze RPM novější než 2.1 vytváří balíčkové soubory ve verzi 3.0.

Další bytová dvojice (0000) určí jaký datový typ RPM soubor je. V současnosti jsou definovány dva datové typy:

* Binární soubor (datový typ = 0000)
* Zdrojový soubor (datový typ = 0001)

V našem příkladu je balíček binární soubor.

Další dvojice bytů (0001) je používán pro uložení architektury, pro který byl balík vytvořen. V našem příkladu číslice 1 reprezentuje architekturu i386. Pokud by byl balíček zdrojový RPM, tyto dva byty by měly být ignorovány, protože zdrojové balíčky nejsou vytvořeny pro žádnou konkrétní architekturu.

Následujících šedesátšest bytů (začíná 7270 6d2d) obsahuje jméno balíku. Jméno musí končit nulovým bytem, uzavírajícím šedesátpět bytů vyhrazených pro normální jméno-verze-release(vydání)-styl jména balíčku. V našem případě, můžeme číst jméno z pravé strany výstupu:

rpm-2.2.1-1

Jestliže je jméno rpm-2.2.1-1 kratší než šedesát-pět bytů vymezených pro jméno, pak je zbytek bytů vyplněno nulou.

Přeskočíme za alokovaný prostor pro jméno a uvidíme dva byty (0001):

00000040: 0000 0000 0000 0000 0000 0000 0001 0005 …………….
00000050: 0400 0000 24e1 ffbf 6bb3 0008 00e6 ffbf ….$…k…….

Tyto slabiky reprezentují operační systém, pro nějž byl balíku vytvořen. V našem příkladu je 1, což se rovná LINUX. Kterou architekturu a který operační systém znamenají příslušné číselné kódy, naleznete v souboru /usr/lib/rpmrc.

Další dva byty (0005) určují typ podpisu použitého v souboru. Typ 5 znamená podpis nové verze RPM číslo 3. Podpis se objeví znovu v sekci Signature, proto je nutné vysvětlit další detail před zkoumáním podpisu.

Při pohledu na C rutinu definující The Lead odpovídající bytům ve skutečném balíčkovém RPM souboru se jeví snadné získat data z The Lead. Z programátorského hlediska je jednoduché manipulovat s daty v The Lead — to je jednoduše záležitost použití prvku jména z rutiny. Ale je zde problém. A právě proto již není The Lead používaný samotným RPM.

Proč již není The Lead používaný RPM? Jednoduše proto, že je to nepružné. Technika definující C rutiny k zpřístupnění dat v souboru není moc flexibilní. Pojďme dívat se na příklad.

Nalistujte si znovu C rutinu pro Leads v části The Lead. Řekněme, že nějaký software má velmi dlouhé jméno. Tak dlouhé, že 66 bytů vyhrazených ve struktuře The Lead pro zápis jména nestačí.

Řešením je standardizovat metodu, kterou se informace souboru získávají. Toto je zajištěno vytvořením přesně stanovené struktury dat, která obsahuje snadno dohledatelnou informaci, a pak praktické dolování dat této struktury.

Když jsou požadovaná data, jsou nalezena s využití snadno prohledávatelné datové struktury a bodů odkazujícím na ně. Výhody jsou v tom, že data mohou být umístěn kdekoli v souboru, a že samotný formát dat se může měnit.

Header Structure je řešení problému jak snadno zacházet s informacemi s využitím standardních prostředků. Jediným účelem existence Header Structure je obsahovat žádná nebo více kusů dat. Soubor může mít víc jak jednu strukturu záhlaví v Header Structure. Ve skutečnosti má RPM sada programů dvojí podpis a header. Odtud také pochází jméno této struktury.

V každé Header Structure jsou tři sekce. První část je známá jako the header structure header (což raději nepřekládám). Header structure header je užívána pro rozpoznání začátku header structure, jeho velikost, a počet datových položek které obsahuje.

Za header structure header je oblast nazvaná index. Index obsahuje jeden nebo více indexových položek. Každá indexová položka obsahuje informaci o položce, a ukazatel (pointer) k ní a určující datovou položko.

Po indexu přichází store (paměť?). Právě zde jsou uloženy datové položky. Data v store jsou maximálně komprimována. Pořadí uložení dat není důležité — velmi odlišné od C rutiny užívané v The Lead.

Podívejme se na současný formát struktury Header, začneme strukturou Header Structure:

The Header Structure Header vždy začíná tři-bytovou magickou číslicí: 8e ad e8. Následuje jednobytový záznam čísla verze. Dále jsou čtyři byty, které jsou připraveny pro budoucí rozšíření. Po rezervovaných bytech jsou další čtyři bytové číslice, které uvádějí, kolik položek indexu je obsaženo v této header structure.

Index header structure je tvořená žádnou nebo více indexovými položkami. Každá položka je šestnáct bytů dlouhá. První čtyři byty obsahují značku (tag) — číselnou hodnotu, která identifikuje na jaký typ dat je položka ukazuje. Hodnota tagu se mění podle pozice header structure v RPM souboru. Seznam dostupných tag hodnot, a co znamenají, je obsažen v příloze.

Následující tag je čtyř bytový datový typ, obsahuje číselnou hodnotu, která vyjadřuje formát dat, na něž položka ukazuje. Typy a jejich hodnoty se nemění od header structure k header structure. (The types and their values do not change from header structure to header structure.) Zde je současný seznam:

* NULL = 0
* CHAR = 1
* INT8 = 2
* INT16 = 3
* INT32 = 4
* INT64 = 5
* STRING = 6
* BIN = 7
* STRING_ARRAY = 8

Pár slov k některým datovým typům: datový typ STRING je jednoduše nulový ukončovací řetězec, zatímco STRING_ARRAY je sada řetězců. Nakonec BIN typ je sada binárních dat. Toto jsou normálně používaná identifikovatelná data delší než INT, ale ne tisknutelný STRING.

Dále následují čtyř bytový offset který obsahuje pozici dat, relativně od začátku store.

Poslední čtyři byty obsahují počet datových položek obsažených v index entry. Několik komplikací (wrinkles) ve významu počtu; datový typ STRING je zastoupen vždy 1, zatímco STRING_ARRAY počtem shodným s počtem řetězců obsažených v store.

The Store je místo, kde jsou uložena data obsažená v header structure. V závislosti na typu dat, které tam bývají uloženy, je dobré pamatovat na následující:

* Pro STRING data: každý řetězec je ukončen nulovým bytem.
* Pro INT data, každý datový celek je uložený v přirozeném rozsahu pro svůj datový typ. 64-bit INT je uložený v osmi bytových (1 byte = 8 bit, 8×8=64)) slovech, 16-bitový INT je uložený ve dvou bytových (2×8=16) slovech, a tak dále.
* Všechny data jsou v síťovém bytovém posloupnosti. ( All data is in network byte order. )

Nyní se tedy můžeme s porozuměním podívat do The Signature.

Sekce TS pokračují dále do nitra souboru RPM balíčku. Obsahuje informace, kterou mohou být využity k ověření neporušenosti, a (volitelně), pravost většiny souborů s balíčky. The Signature je podobný Header Structure.

Pravděpodobně si všimněte výrzu „majority“ uvedeného dále. Informace v podpisu header structure je založený jen na obsahu balíčku záhlaví souboru a archive. Data v The Lead a podpisu header structure nejsou obsažena, když je informace o podpisu vytvořena, ani není součástí jakýchkoli následujících kontrol založených na této informaci.

Zatímco to opomenutí by se mohlo jevit slabou stránku v návrhu RPM, ve skutčnosti to tak není. The Lead je využívaný jen pro snadnou identifikaci souboru balíčku, jakékoliv změny provedené v části souboru by, v nejhorším případě, zanechaly soubor ve stavu, že by ho RPM neidentifikovalo jako platný balíčkový soubor. Obdobně jakékoli změny v the signature header structure by znemožňovaly ověření souborové integrity, došlo-li by po vytvoření informace o podpisu ke změně původních hodnot.

V podpisu rpm-2.2.1-1.i386.rpm nalézáme:

00000060: 8ead e801 0000 0000 0000 0003 0000 00ac …………….

První tři bajty (8ead e8) obsahuje magickou číslici označující začátek header structure. Další byt (01) je verze header structure.

Jak je uvedeno dříve, další čtyři bajty (0000 0000) jsou rezervované. Čtyři bajty následující po nich (0000 0003) uvádějí počet položek v rejstříku v signature section, v tomto případě tři. Další čtyři bajty (0000 00ac) ukazují, kolik bajtů dat je uloženo v podpisu /signature). Převedeme-li číslo do desítkové soustavy, zjistíme, že jde o záznam dlouhý 172.

Dále následuje první 16 bytový index. Každá ze tří indexových položek v této headers structure se skládá ze čtyř 32 bitových celých čísel, v následujícím pořadí:

* Tag
* Type
* Offset
* Count

Podívejme se do první položky rejstříku:

00000070: 0000 03e8 0000 0004 0000 0000 0000 0001 …………….

Tag je uložen v prvních čtyřech bytech (0000 03e8), zde jde o číslo 1000 (přeloženo z hex). Po nahlédnutí do zdrojového adresáře RPM do souboru lib/signature.h, najdeme následující tag definice:

#define SIGTAG_SIZE 1000
#define SIGTAG_MD5 1001
#define SIGTAG_PGP 1002

Takže tag, který jsme probírali, uvádí velikost podpisu. Půjdeme dále.

Další čtyři byty (0000 0004) obsahuje datový typ (type). Jak my jsme viděli dříve, typ dat 4 znamená, že data uložená v této rejstříkové položce jsou 32 bitová celá čísla. Zmíníme se ještě o dalších čtyřech bytech (0000 0001), uvádí počet 32 bitových celých čísel, ne něž poukazuje tato rejstříková položka.

Nyní se vrátíme k předcházejícím čtyřem bytům (0000 0000). Tato číslice je offset, v jeho bytech je uložena velikost podpisu. Zde má hodnotu nuly, z čeho vychází? Offset je vypočítán od začátku paměti (store). Takže nejprve musíme najít místo, kde store začíná, a pak můžeme provést jednoduchý výpočet.

Vraťme se k začátku sekce podpisu (signature section):

00000060: 8ead e801 0000 0000 0000 0003 0000 00ac …………….

Po magickém čísle, verzi a čtyřech rezervovaných bytech, následuje počet rejstříkových položek (0000 0003). Díky tomu víme, že každá rejstříková položka je dlouhá šestnáct bytů (čtyři pro tag, čtyři pro datový typ, čtyři pro offset, a čtyři pro počet), můžeme proto násobit počet záznamů (3) počtem bytů v každé položce (16) a výsledkem je celková velikost indexu, což je 48 v desítkové soustavě, nebo 30 v hexadecimální. Od první indexové položky začíná v hex offset 70, takže můžeme jednoduše sčítat hex 30 + 70, a dostaneme offset A0, takže se tam podíváme:

000000a0: 0004 4c4f b025 b097 1597 0132 df35 d169 ..LO.%…..2.5.i

Jestli my jsme počítali správně, první čtyři byty (0004 4c4f) by měly znamenat velikost tohoto souboru. Převedeno na desítkovou soustavu je to 281,679. Pojďme podívat se ve velikosti skutečného souboru:

# ls -al rpm-2.2.1-1.i386.rpm -rw-rw-r– 1
#ed ed 282015 Jul 21 16:05 rpm-2.2.1-1.i386.rpm

Je to dobře? Nebo ne? Vypadá to, jako nám chybělo 336 bytů, nebo v hex, 150. V hex jde o poněkud zakulacenou hodnotu? Pokračujme dál ostatními indexovými položkami, abychom viděli, zda se nám 150 hex objeví někde jinde.

Dále je uvedena další položka indexu. Má tag (dekadicky) 1001, což je MD5 kontrolní součet. Datový typ je 7, což je BIN, 16 bytů dlouhý, a začíná čtyři byty od začátku paměti:

00000080: 0000 03e9 0000 0007 0000 0004 0000 0010 …………….

A následují data. Začínají číslem b025 (po offsetu, který má čtyři byty) a končí číslem 5375. Toto je 128-bitový MD5 kontrolní součet sady souborů balíčku záhlaví a archivní sekce.

000000a0: 0004 4c4f b025 b097 1597 0132 df35 d169 ..LO.%…..2.5.i
000000b0: 329c 5375 8900 9503 0500 31ed 6390 a520 2.Su……1.c..

Vše je v pořádku, vrátíme se zpět na poslední indexovou položku:

00000090: 0000 03ea 0000 0007 0000 0014 0000 0098 …………..

Zde má tag hodnotu 03ea (1002 dekadicky — blok PGP podpisu) a je zároveň binární datový typ. Data začínají 20 desítek bytů od začátku datové oblasti, v souboru je uveden v offset b4 (v hex). Má 152 bytů délky! Tady jsou data, pojčínaje 8900:

000000b0: 329c 5375 8900 9503 0500 31ed 6390 a520 2.Su……1.c..
000000c0: e8f1 cba2 9bf9 0101 437b 0400 9c8e 0ad4 ……..C{….. ….
000000d0: 3790 364e dfb0 9a8a 22b5 b0b3 dc30 4c6f 7.6N….“….0Lo
000000e0: 91b8 c150 704e 2c64 d88a 8fca 18ab 5b6f …PpN,d……[o
000000f0: f041 ebc8 d18a 01c9 3601 66f0 9ddd e956 .A……6.f….V
00000100: 3142 61b3 b1da 8494 6bef 9c19 4574 c49f 1Ba…..k…Et..
00000110: ee17 35e1 d105 fb68 0ce6 715a 60f1 c660 ..5….h..qZ'..'
00000120: 279f 0306 28ed 0ba0 0855 9e82 2b1c 2ede' …(… ….U..+…
00000130: e8e3 5090 6260 0b3c ba04 69a9 2573 1bbb ..P.b'.<..i.%s..
00000140: 5b65 4de1 b1d2 c07f 8afa 4a9b 0000 0000 [eM…….J…..

Celé to ukončuje byt 4a9b. Je to blok 1216-bitového PGP podpisu. Je to zároveň konec sekce podpisu. Čtyři nulové byty následující za poslední datovou položkou za účelem zarovnání velikosti tak, aby se skončilo na celobytové hranici. Toto znamená , že offset další části začíná v offsetu 150, v hex. Připomínáme, že rozdíl velikost ve velikosti podpis a výpočtu byl 150 hex. Ano, velikost uváděná v podpisu je velikost souboru — bez velikosti the lead a sekce podpisu.

Sekce The header obsahují všechny dostupné informaci o balíku. Záznamy jako package's name (jméno balíčku), version (verze), a file list (seznam souborů), je obsažen Hlavičce. Podobně jako sekce Signature (podpis) má header stejný formát dat. Na rozdíl od podpisu (signature), jenž má jen tři možné tag typy, má the header více než šedesát různých tagů. Seznam v současnosti definovaných tagů bude uveden dále v dodatku v části nazvané Header Tag Listing. Tento seznam se může často měnit – konečný seznam se dá najít v RPM zdrojích v lib/rpmlib.h.

Nejjednodušší způsob, jak najít začátek hlavičky je podívat se za druhou strukturu headers structure na její magckou číslici (8ead e8). Šestnáct bytů, počínaje magickým číslem, jsou záhlaví struktury headers. Opakuje se stejný formát jako u záhlaví struktury signature:

00000150: 8ead e801 0000 0000 0000 0021 0000 09D3 ………..!….

Jako předtím, byt následující magickou číslici identifikuje tuto struktura záhlaví jako verzi formátu 1. Následují čtyři rezervované byty, dále najdeme počet záznamů uložených v záhlaví stránky (0000 0021). Převedeno na desítkovou soustavu vidíme, že je zde 33 záznamů. Další čtyři byty (0000 09d3) převedeno na dekadické číslo nám řekne, že v paměti je 2,515 bytů.

Dále je struktura úplně stejná jako u podpisu, takže již víme, že další 16 bytů je první indexová položka:

00000160: 0000 03e8 0000 0006 0000 0000 0000 0001 …………….

První čtyři byty (0000 03e8) jsou tag pro jméno balíčku. Další čtyři byty uvádějí datový typ 6, nebo nulový ukončovací řetězec. Je tu offset čtyř nulových bytů, znamenající, že data tohoto tagu jsouv paměti uloženy jako první. Poslední čtyři byty (0000 0001) zobrazují, že součet dat je 1, který je jedinou legální hodnotou pro datový typ STRING (řetězec).

Pro nalezení dat potřebujeme vzít offset ze začátku první indexové položky v header (160), a propočítat počet indexových položek (21) násobený velikostí vstupu v rejstříku (10). Při výpočtu by měly být použity všechny hodnoty v hex!. Výsledkem je offset k paměti, hex 370. Protože offset pro tuto zvláštní indexovou položku je nula, data by měla začít v offsetu 370:

00000370: 7270 6d00 322E 322E 3100 3100 5265 6420 rpm.2.2.1.1.Red

Protože datový typ této položky je nulový/neplatný, řetězec ukončuje. Protože na začátku datového typu pro tuto položku je nulový ukončovací řetězec, potřebujeme si zapamatovat přečtený byt do té doby, než my bytu jehož číselná hodnota je nula. Najdeme byt 72, 70, 6d, a 00 — nulový. Při pohledu do ASCII zobrazeném vpravo zjistíme, že byt tvoří řetězec RPM, což je jméno tohoto balíčku.

Nyní poněkud komplikovanější příklad. Pojďme dívat se na následující rejstříkovou položku:

00000250: 0000 0403 0000 0008 0000 0199 0000 0018 …………….

Tag 403 znamená, že tato položka je seznam jmen souborů. Datový typ 8, neboli STRING_ARRAY, s ním souvisí. Z předchozího příkladu jsme zjistili, že datová oblast header začala na offsetu 370. Přičteme-li offset k prvnímu jménu souboru (199), výsledek je 509. Po přičtení posledního čísla 18 (hex) vypoví, že jméno souboru by mělo být ukončeno 24 nulovým ukončovacím řetězcem:

00000500: 696e 6974 6462 0a0a 002f 6269 6e2f 7270 initdb…/bin/rp
00000510: 6d00 2f65 7463 2f72 706d 7263 002f 7573 m./etc/rpmrc./us

Byt v offsetu 509 je 2f — a “/“. Čtením až do prvního nulového bytu zjistíme, že první jméno souboru je /bin/RPM, naásledované /atd/rpmrc. Stejně to pokračuje pro dalších 22 jména souborů.

Je tam daleko více tagů, který bychom mohli dekódovat, ale všechny jsou vytvořené stejným způsobem.

Následující seznam ukazuje dostupné tagy, společně s definujícími hodnotami, pro použití v headers. Tento seznam je ze současné verze 2.3 RPM. Ve většině novějších verzích se podívejte do souboru lib/rpmlib.h v.

#define RPMTAG_NAME 1000
#define RPMTAG_VERSION 1001
#define RPMTAG_RELEASE 1002
#define RPMTAG_SERIAL 1003
#define RPMTAG_SUMMARY 1004
#define RPMTAG_DESCRIPTION 1005
#define RPMTAG_BUILDTIME 1006
#define RPMTAG_BUILDHOST 1007
#define RPMTAG_INSTALLTIME 1008
#define RPMTAG_SIZE 1009
#define RPMTAG_DISTRIBUTION 1010
#define RPMTAG_VENDOR 1011
#define RPMTAG_GIF 1012
#define RPMTAG_XPM 1013
#define RPMTAG_COPYRIGHT 1014
#define RPMTAG_PACKAGER 1015
#define RPMTAG_GROUP 1016
#define RPMTAG_CHANGELOG 1017
#define RPMTAG_SOURCE 1018
#define RPMTAG_PATCH 1019
#define RPMTAG_URL 1020
#define RPMTAG_OS 1021
#define RPMTAG_ARCH 1022
#define RPMTAG_PREIN 1023
#define RPMTAG_POSTIN 1024
#define RPMTAG_PREUN 1025
#define RPMTAG_POSTUN 1026
#define RPMTAG_FILENAMES 1027
#define RPMTAG_FILESIZES 1028
#define RPMTAG_FILESTATES 1029
#define RPMTAG_FILEMODES 1030
#define RPMTAG_FILEUIDS 1031
#define RPMTAG_FILEGIDS 1032
#define RPMTAG_FILERDEVS 1033
#define RPMTAG_FILEMTIMES 1034
#define RPMTAG_FILEMD5S 1035
#define RPMTAG_FILELINKTOS 1036
#define RPMTAG_FILEFLAGS 1037
#define RPMTAG_ROOT 1038
#define RPMTAG_FILEUSERNAME 1039
#define RPMTAG_FILEGROUPNAME 1040
#define RPMTAG_EXCLUDE 1041 /* not used */
#define RPMTAG_EXCLUSIVE 1042 /* not used */
#define RPMTAG_ICON 1043
#define RPMTAG_SOURCERPM 1044
#define RPMTAG_FILEVERIFYFLAGS 1045
#define RPMTAG_ARCHIVESIZE 1046
#define RPMTAG_PROVIDES 1047
#define RPMTAG_REQUIREFLAGS 1048
#define RPMTAG_REQUIRENAME 1049
#define RPMTAG_REQUIREVERSION 1050
#define RPMTAG_NOSOURCE 1051
#define RPMTAG_NOPATCH 1052
#define RPMTAG_CONFLICTFLAGS 1053
#define RPMTAG_CONFLICTNAME 1054
#define RPMTAG_CONFLICTVERSION 1055
#define RPMTAG_DEFAULTPREFIX 1056
#define RPMTAG_BUILDROOT 1057
#define RPMTAG_INSTALLPREFIX 1058
#define RPMTAG_EXCLUDEARCH 1059
#define RPMTAG_EXCLUDEOS 1060
#define RPMTAG_EXCLUSIVEARCH 1061
#define RPMTAG_EXCLUSIVEOS 1062
#define RPMTAG_AUTOREQPROV 1063 /* used internally by build */
#define RPMTAG_RPMVERSION 1064
#define RPMTAG_TRIGGERSCRIPTS 1065
#define RPMTAG_TRIGGERNAME 1066
#define RPMTAG_TRIGGERVERSION 1067
#define RPMTAG_TRIGGERFLAGS 1068
#define RPMTAG_TRIGGERINDEX 1069
#define RPMTAG_VERIFYSCRIPT 1079

Následující sekcí v header archiv. Archiv obsahuje skutečné soubory, které tvoří balíček. Archiv je komprimován pomocí GNU zip. Můžeme si to ověřit, jestliže se podíváme do začátku archivu:

00000d40: 0000 001f 8b08 0000 0000 0002 03ec fd7b ……………{
00000d50: 7c13 d516 388e 4e92 691b 4a20 010a 1428 |…8.N.i.J …(

V našem příkladu začíná archív v offset d43. Podle obsahu /usr/lib/magie první dva byty souboru komprimovaného programem gzip b měly být 1f8b, což jsou, jak vidíme. Následující byt (08) je flag používaný GNU zip který má ukázat, že soubor byl komprimován pomocí „deflační“ metody gzipu. Osmý byt má hodnotu 02 a znamená, že archiv byl komprimován maximálním kompresním poměrem. Následující byt udává operační systém, pod kterým byl archiv komprimován. 03 v tomto bytu signalizuje, že komprimace proběhla pod OS UNIX.

Zbytek balíčku RPM je komprimovaný archiv. Po dekompresi (rozbalení) archivu jde o obyčejný cpio archiv v SVR4 formátu s CRC kontrolním součtem.