Roncsoljunk JPEG-et újra

Az inspirációt ez a videó adta, és az alatta meghivatkozott online kis eszköz, ami annyival több egy sima hexEditornál, hogy képes lokalizálni a JPEG-anatómiai részeit, és azt színkódosan jelölni, hogy célzottan tudjuk az egyes részeket támadni. Sőt egyből updateli is a beavatkozást és mutatja a hatást, nem kell menteni, megnyitani mindegyre. Mondjuk érdemes lenne még tovább fejleszteni azzal, hogy kijelölje az egyes támadható byteokat is, amiket elbarmolva nem teszik olvashatatlanná a képet. De ne legyünk telhetetlenek, sőt az a jó, hogy ezt meghagyta a kolléga nekünk, így magunknak kell felfedezni. Lássunk hozzá.

A JPEG-nél markerek vezetik be az egyes szekciókat, ezek két byteból állnak, az első byte értéke pedig FF. Például:

FF D8 - a képfile kezdete, nem érdemes babrálni, mert a kép értelmezhetetlenné válik

FF D9 - a képfile vége, babrálható, de nincs látványos értelme

vagy:

FF E1 - az EXIF kezdete, amit még két byte követ, ami a szegmens hosszát írja le.  Például:

FF E1 13 1B, ami annyit jelent, hogy az EXIF szegmens hossza 13 1B (hexában), vagyis 4891 byte (decimálisan), ebbe mindig beleszámítandó, a két hossz-leíró byte is, vagyis az FF E1 után 4891 bytera fog következni a következő szegmens markere.  Azért nem egyszerűen a következő marker mondja meg, honnan következik a következő szekció, mert magában az adatsorban is lehet markernek kinéző adat. 

A megadott hossz és a következő valid marker közé beszúrhatunk ugyan byteokat, de ennek a glitch szempontjából nincs értéke, esetleg szteganográfiára használható, de változó, hogyan reagálnak rá a képszerkesztő programok, és ha meg is nyitják, újramentésnél valószínűsíthetően nem fogják tovább vinni a számukra irreleváns, szegmensek közötti adatot, amit feltehetően be sem olvasnak.

A ChatGPT mondott egy érdekeset, nem csak a JPEG struktúráját hekkeljük a glitchelés, databending alatt, hanem a képnézegetők hibatűrését is. Sőt, mint ki fog derülni, a képet elmentő program által beépített hibakezelést is.

1. QT

A JPEG struktúrájában az első, vizuális szempontból értelmes, támadási lehetőség a Quantazation table szegmensben van, amiből az első 5 byteot nem érdemes babrálni:

Értelmezzük, az FF DB a szegmens markere, a 00 84, ami decimálisan 132 byte. Hogy is jön ez ki? Ebbe beleszámít a hosszat leíró két byte (00 84) plusz általában van egy Luminance és egy Chrominance táblánk, egyenként 8*8 byteosak. Tehát: 

2 (hossz-byte) + 1 (luminance azonosító) + 64 (tábla mérete) + 1 (chromninance azonosító) + 64 (tábla mérete) = 132

FF DB 00 84 00 - a marker, majd a hossz után a 00 byte határozza meg milyen tábláról van szó, ez a Luminosity tábla, az ötödik byteig tehát nem piszkálható, de az utána következő értékeket már igenis érdemes. Pontosan 64 byte hosszan. 

Mert utána megint egy 01 byte következik, ami a Chrominance táblát vezeti fel, ezt átírva megint kuka a kép. De utána 64 byte hosszan megint baszkurálhatjuk. 

A Luminance és a Chrominance (képzeletbeli 8*8-as) tábla 64 byteja a bal felső saroktól cikk-cakkban halad a jobb alsó sarok felé. Mitől van benne annyi 01, majd 02 és 03? Ez egy Photoshopban, 12-es minőségre mentett kép, egy régebbi posztunkból meghivatkozzuk a DQT tábla képét:

Minél jobban tömörített képről van szó (Level 0), a számok annál nagyobbak. De fentről jobbra és lefele haladva, bántalmazva a byteokat, azt is megfigyelhetjük, hogy előbb hatalmas, nagy felületre kiterjedő, kis frekvenciájú glitchek jelennek meg, de a tábla vége felé már csak az apró, nagy frekvenciás artifactek. A Luminancia táblában még van értelme a 02 byteok átírásának, de a chroma táblában már alig van látható hatása. De hét ennek is tudjuk az okát, a luminancia eltérésekre érzékenyebb az emberi szem, mint a színekre, 

1.1 Luminancia-tábla támadása:

1.2. Krominancia-tábla támadása:

2. Frame Header

Ez elég rövidke:

FF C0 00 11 08 03 E8 01 C2 03 01 11 00 02 11 01 03 11 01

lássuk mi van benne:

FF C0 SOF0 —

00 11   szegmens hossza         17

08     precision                 8 bit

03 E8  magasság                 1000            - ezzel csak kroppoljuk vagy növeljük a magasságot

01 C2  szélesség                  450            - ezzel azonban jól össze lehet kuszálni a képet. 

03     komponensek száma 3                

01     komponens ID         1 = Y

11     sampling          H=1, V=1    - káosz, érdemes (hex)11 és 44 között minden variációt kipróbálni

00     DQT                         #0

02     komponens ID         2 = Cb

11     sampling          H=1, V=1   - káosz, érdemes (hex) 11 és 44 között minden variációt kipróbálni

01     DQT                         #1

03     komponens ID         3 = Cr

11     sampling        H=1, V=1    - káosz, érdemes  (hex) 11 és 44 között minden variációt kipróbálni

01     DQT                         #1

Érdekesség, hogy amikor a HexEditorral rákerestem az FF C0 markerre, totál mást találtam, egy kisfelbontású, szét-szubsamplingezett képre utaló headert, ami nem lehet más, mint a thumbnail. De mint ilyen, az EXIF része, tehát az EXIF APP1 (FF E1 11 45) 4421 bytejában lapul egy teljes, komplett JPEG, kvantálási táblástól, Headerestől, Huffmannostól és adatstreamestől. Persze a fileban hátrább megtaláltam a teljes kép headerjét is, már nem beágyazva az EXIF adatfolyamába. Na ezért fontos, hogy egy marker után (pl EXIF) azt is megadjuk, hogy a szegmens milyen hosszú (4421 byte), mert így tudjuk, hogy a talált kis JPEG összes markere, szőröstől-bőröstől az EXIF része, tehát nem az igazi kép, csak egy thumbnail. 

3. Restart Interval

Célja, hogy a bitstreamben keletkezett hibát lokalizálja, tűzfalként szolgáljon a glitch továbbterjedése ellen. Ez itt csak a fejléc, ami elmondja a szabályokat, de a bitstreamben majd lesznek meghatározott MCU-szám után konkrét két byteos restart markerek is.

FF DD 00 04 00 39 - vagyis a Restart interval marker 4 byte hosszú, és a 00 39 azt jelenti, hogy 57 MCU-nként szinkronizálja a bitstreamet. 

A bitstreamen belül tehát restart markereink vannak, FF D0 - FF D7 között, majd kezdi elölről, összesen 124 ilyen van ezen a konkrét képen. Hogy jön ez ki? A kép 450*1000 pixeles, egy MCU 8*8 pixel, vagyis a képben 7125 MCU van. Ha 57 MCU-nként van egy Restart interval, akkor 7125/57 az 125 interval, az utolsó végére nem tesz markert (ott amúgy is lezárja a teljes JPEG-et FF D9-markerrel), tehát 124 restart marker van az adatfolyamban. A képünk 1000 pixel magas, 125*8 az meg pont 1000.

Azt is megfigyelhetjük, hogy mivel MCU-soronként (57 MCU) alkalmazza a restart intervalt, ha belerondítunk a bitstreambe, a glitch a sor végéig tart. Utána minden helyreáll. Ezért van tűzfal szerepe a hibák ellen, tehát 8 pixel magas képsor tud sérülni csak egy hiba miatt, nem a fél, vagy az egész kép. (ezt néha sikerült kijátszanunk)

Itt most a 00 39 helyett írtunk 00 38-at, ami azt hazudja a dekódernek, hogy a Restart Interval 56 MCU. Ez azt okozza, hogy soronként egy-egy MCU-val tolódik el a kép. 

3.1. Restart Interval marker a bitstreamben. 

Láttuk, hogy ennél a képnél 57 MCU egy intervallum, az adatfolyamban ez után egy Restart interval marker következik, az első MCU-sor után  FF D0, a második MCU-sor után FF D1 és így tovább. 

Mi történik, ha ezt a markert hazudjuk el az első 57 MCU végén? 

Nyilván a dekóder a frame headerből tudja a kép pontos geometriáját, vagyis, hogy 450 pixel, felkerekítve 57MCU széles, de a bitfolyam kiolvasásának pillanatában azt nem tudhatja, hogy az 57 MCU pontosan hány bitnyi adat.  Az MCU bitstream-hossza soronként is eltérő lehet, például homogén kék égből egy erdő aprólékos textúrájára vált, ami nagyságrendekkel hosszabb adatfolyamot eredményez elkódolva. 

Mivel nem kapja meg a restart interval markert, mert  FF D0 -t elhazudtuk 11 D0-nak, azt hiszi ez még mindig a bitstream része és az azelőtti DC és Huffman szabályokkal próbálja értelmezni tovább, amitől szürke MCU-sor keletkezik (nem értjük a pontos okát, de szabályszerűen történik, hogy 128-ra normalizálódik). Majd amikor végigrájra magát a következő sor adatain is, azt feltételezve, hogy az még az első soré, a második sor végén megtalálja az FF D1 markert, restart és helyreáll a rend. 

4. Huffman tábla támadása

FF C4 01 A2, vagyis a tábláink 418 (416) byte hosszúak, és itt lapul az az információ (fa-struktúra), ami alapján értelmezni lehet majd a kép lényegét rejtő bit-streamet. 

Nem nagyon világos, hogy melyik byte pontosan micsoda, gyaníthatóan nem is egyszerű visszafejteni, mivel képi információ-függő. Találomra próbáltunk benne byteokat kicserélni, a legtöbb kinyírta a képet, de volt olyan is, ami nagyon szép artifacteket okozott, de ezekre is jellemző volt, hogy csak kicsit kellett megváltoztatni, egy nagyon nagy adat beírása ezekre a byteokra, szintén megölte a képet. Ha ezt a támadást komolyan akarnánk csinálni, akkor mindenképpen szoftveres segítség kellene, ami feltérképezi az adott fotó Huffman struktúráját, sajnos a bejegyzés elején meghivatkozott online eszköz ennyire nem részletezi. De nézzük ezt a konkrét esetet:

FF C4 01 A2  - Huffman táblák, hossza 418 byte hosszú

00  - Első tábla fejléce  felső 4 bit vagyis a baloldali 0 a típusa (0-DC, 1 AC)

- a baloldali 0 vagy 1 lehet, hanem döglik a kép, de a 0-t 1-re átírva szép glitchet kapunk

     - a jobboldali 0 vagyis alsó 4 bit a tábla azonosítója, ez 0-3 között bármire átírható, de ugyanazt a glitchet kapjuk, mint a baloldali 4 bitnél, nagyobb értékekre döglik  kép

00 00 06 02 03 01 00 00 00 00 00 00 00 00 00 00 - BITS tömb, 16 byte szokott lenni, balról jobbra azt mondja meg, hány darab 1 bit hosszúságú kód van, majd hány darab 2 bit hosszúságú... egészen hány darab 16 bit hosszúságú a fában.

- itt most 6 darab van 3 bitesből, 2 darab a négybitesből és így tovább

- ha összeadjuk a 16 byteot, ennyi byte lesz a HUFFVAL hossza  - most ez 12
Az értékek átírása legtöbbször a kép kinyírását okozza, néha full fehér képet kapunk (túlcsordul), ha a byteokat cserélgetjük random, akkor néha kapunk glitchet is. Nem túl kiszámítható.

07 08 06 05 04 09 03 0A 02 01 00 0B
- HUFVAL - szimbólum értékek. hossza (12 byte) megegyezik a BITS 16 számának összegével

Bármelyik byte átírható 00-tól 0F-ig (0-15 között decimálisan) és glitchet kapunk, 10-FF (16-255 decimálisan) között sem döglik meg a kép, de hófehér lesz, vagyis túlcsordul. Ha kicsi értékkel írjuk felül, ilyesmi az eredmény, itt most  az első 07-et 00-ra cseréltük:

de minél nagyobb értékre cseréljül annál durvább a hatás, itt ha a 07-et 0F-re cseréljük (10 hex-től már csordul):

És így végig a HUFVAL minden byteján, de haladva jobbra egyre gyengébb (nem olyan nagy kiterjedésű) a glitch-hatás. Az utolsó 0B byte bántalmazása meg semmi láthatót nem okoz 00-0F között, afölött meg itt is túlcsordul az egész kép fehérbe..
Ez a csökkenő glitch hatás azért van, mert a 07 a legyakoribb fényerő különbségeket kódolja és így haladunk az egyre ritkábbakig 0B-ig. Nem kizárt, hogy a 0B is okoz valamit, csak éppen észre sem vevődik.

01  - következő tábla (DC-, mert a baloldali 0, a második DC tábla, mert a jobboldali 1)

00 00 06 03 01 01 01 00 00 00 00 00 00 00 00 00 -  BITS tömb, 16 byte, a számok összege 12, tehát

06 05 04 03 07 02 08 01 09 00 0A 0B  - a HUFAL 12 byte lesz

Hasonlóan viselkedik, mint az előbbi. 

10   a baloldali, felső 4 bit 1 a jobboldali pedig 0, tehát ez az első AC tábla, ezt a byteot DC-nek (00, vagy 01) hazudva fehér képet kapunk, tehát csak 11-nek hazudhatjuk, ekkor glitchet kapunk. más, nagyobb értékekkel megnyithatatlan lesz a kép.

00 02 01 03 04 01 03 03 02 03 03 03 02 06 09 75  - összeadva 162, tehát ennyi byte a következő HUFVAL 

01 02 03 04 11 05 12 06 21 07 13 22 00 08 31 14 41 32 23 15 09 51 42 16 61 24 33 17 52 71 81 18 62 91 25 43 A1 B1 F0 26 34 72 0A 19 C1 D1 35 27 E1 53 36 82 F1 92 A2 44 54 73 45 46 37 47 63 28 55 56 57 1A B2 C2 D2 E2 F2 64 83 74 93 84 65 A3 B3 C3 D3 E3 29 38 66 F3 75 2A 39 3A 48 49 4A 58 59 5A 67 68 69 6A 76 77 78 79 7A 85 86 87 88 89 8A 94 95 96 97 98 99 9A A4 A5 A6 A7 A8 A9 AA B4 B5 B6 B7 B8 B9 BA C4 C5 C6 C7 C8 C9 CA D4 D5 D6 D7 D8 D9 DA E4 E5 E6 E7 E8 E9 EA F4 F5 F6 F7 F8 F9 FA 

Ez a tábla sokkal érzékenyebb a BITS tömb értékeinek a cserélgetésére, módosítására, viszont a HUFVAL-t lehet küldeni mindenfélével FF-ig is akár. Az elől levő byteok nagyobb hatást érnek el. Nagyjából a felétől hátrább levőknek nincs látható hatása.

11 - AC következő tábla ez is csak AC táblának hazudható, hanem fehér képet kapunk, vagy megnyithatatlan képet nagyobb értékek esetén

00 02 01 03 02 04 04 03 05 04 04 04 06 06 05 6D  - összeadva szintén 162 byte lesz a következő rész

01 02 03 11 04 21 12 05 31 06 00 22 13 41 51 07 32 61 14 71 08 42 81 23 91 15 52 A1 62 16 33 09 B1 24 C1 D1 43 72 F0 17 E1 82 34 25 92 53 18 63 44 F1 A2 B2 26 35 19 54 36 45 64 27 0A 73 83 93 46 74 C2 D2 E2 F2 55 65 75 56 37 84 85 A3 B3 C3 D3 E3 F3 29 1A 94 A4 B4 C4 D4 E4 F4 95 A5 B5 C5 D5 E5 F5 28 47 57 66 38 76 86 96 A6 B6 C6 D6 E6 F6 67 77 87 97 A7 B7 C7 D7 E7 F7 48 58 68 78 88 98 A8 B8 C8 D8 E8 F8 39 49 59 69 79 89 99 A9 B9 C9 D9 E9 F9 2A 3A 4A 5A 6A 7A 8A 9A AA BA CA DA EA FA

Erre is igaz nagyjából az amit az előbbi táblánál tapasztaltunk. 

5. Scan header támadása

FF DA SOS – Start Of Scan

00 0C SOS hossza = 12 byte

03 komponensek száma = 3

01 00 komponens 1 → Huffman DC=0, AC=0    

02 11 komponens 2 → Huffman DC=1, AC=1

03 11 komponens 3 → Huffman DC=1, AC=1

00 spectral selection start = 0

3F spectral selection end = 63

00 successive approximation = 0

Nincs sok támadható byte, a három komponens második bytejait lehet elhazudni, de csak valid Hufmantábla azonosítóra (00, 01, 10, 11), ilyenkor glitch az eredmény, más értékekre meghal a file. Az utolsó 3 byte meg a progresszívre mentett JPEG-ekre vonatkozik, itt semmi hatása nincs, ha átírjuk őket. 

De azért mentettünk egy Progressive képet is 5-ös scans értékkel. A Successive approximation (utolsó) byte támadása elég érdekes, rég elfeledett CGA grafikus megjelenést idézett.

De számos más különbséget is észrevettünk a normál JPEG-hez képest, ebben nincsenek Restart markerke a bit-streamben, viszont van 14 darab Scan header. Ha például a második Scan header utolsó byteját támadjuk, akkor meg ezt kapjuk:

De sorra magtámadhatjuk a harmadik, negyedik, stb. Scan headert is, bár a glitch egyre vékonyabb, egyre kevésbé karakteres, viszont minden esetben más és más. Azzal is érdemes játszani, hogy az egyes Scan headereket semmisítjük meg, FF DA átírásával. ilyenkor nagyon nem mindegy, hogy az elsőket, vagy az utolsókat nyírjuk ki, teljesen más rétegek érvényesülnek. Rá kellett ébredjek, hogy érdemes lenne az egészet elölről kezdeni ezzel a progresszív képpel is, mert vélhetően az elejétől felsorolt beavatkozások zöme is totál más geometriájú glitcheket eredményezne. 

6. magának az adatfolyamnak a támadása

Itt teljességgel kitalálhatatlan, hogy melyik byte átírása hova fog ütni. Eleve mi byteokat látunk egy hexeditorban, de a valóságban ez egy bitfolyam, amiben az adathosszúságok bárhány bitesek lehetnek. Jellemzően mégis, ha az adatfolyam elejét támadjuk, akkor a glitch a kép felső részét fogja érinteni, míg ha a végét, akkor az alját. Azt hogy a hiba melyik MCU-t fogja érinteni azt szinte lehetetlen eltalálni de próbálgatással azért lehet közelíteni. A sorhossznyi restart intervalos képeknél a glitch a sor végéig tart, de néha előfordult, hogy a kép végéig az összes MCU-sor megnyikkant. Leginkább 8 pixel magas szürke sávként jelentkezik a hiba, de néha sikerül színes találatot is csinálni. Ami viszont nagyon érdekes, hogyha sorban írjuk át a byteokat és keletkezik egy sor glitch, a következő néhány byte átírásánál nagyon gyakran visszaáll a helyes kép. Kifejezetten gyakori és könnyen előidézhető jelenség. Hiba * hiba = jó kép, mindenesetre furcsa, de biztos a dolog matematikája miatt determinisztikus.

Hosszú és kimerítő utazás volt, két MI-t is fárasztottunk a kérdéseinkkel, nélkülük esélyünk se lett volna a byteok értelmezésében, a végére így is mindketten elkezdtek hallucinálni. De nem sikerült mélységében megérteni a dolgot, inkább rengeteg új perspektívát nyitott ki. Ez csak egyetlen típusú JPEG (plusz egy progresszív a végén bónusznak) körüljárása volt, és az is csak lóugrásokban. De JPEGet menteni sokféleképpen lehet és mind eltérően viselkedhetnek. 
És akkor még nem is próbálkoztunk azzal, hogy a támadásokat egymásra halmozzuk. De hátha valaki kedvet kap hozzá és ír egy olyan programot, ami egyesíti a bejegyzés elején meghivatkozott kolléga munkáját az itt felhozott további részletekkel. Mondjuk egy olyat, ami kijelöli a leglátványosabban támadható byteokat és valid támadó értékintervallumot is ajánl ott ahol nem mindegy mit írunk át mire.