Rövid bevezető
A steganográfia, ha valaki nem emlékezne, információk elrejtését jelenti különböző tárolókban. Például képekben (erről már volt szó és ). Az adatokat el lehet rejteni a fájlrendszer szolgáltatási tábláiban is (erről írtunk már ), sőt akár . Sajnos, ezeknek a módszereknek van egy közös hátrányuk: ahhoz, hogy észrevétlenül "beletussoljunk" információt a tárolóba, ügyes algoritmusokra van szükség, amelyek figyelembe veszik a tároló belső működésének sajátosságait. Emellett a tároló manipulációkkal szembeni ellenállóképességével is problémák adódhatnak: például ha kicsit átírjuk a képet, az elrejtett információ elveszik.
Van-e mód arra, hogy elkerüljük a bonyolult algoritmusokat és a finom adatmanipulációkat, és közben mégis biztosítsuk a tároló működőképességét és a titkos adatok megfelelő szintű megőrzését? Előre elmondom - igen, lehetséges! És még egy kis segédprogramot is ajánlok.
A módszer véres részletei
Az alapgondolat egyszerű, mint egy kalapács ütése a fejünkre: a lemezen vannak olyan területek, ahova az operációs rendszer soha nem ír (vagy csak ritkán). Ahhoz, hogy ne kelljen ravasz algoritmusokkal keresgélni ezeket a területeket, a redundanciát fogjuk kihasználni - tehát az elrejtett információnkat sok-sok példányban meg fogjuk duplázni a lemez összes szektorában. Ezután közvetlenül a mindenféle szépség fölé lehet létrehozni a szükséges partíciókat, formázni a fájlrendszereket, fájlokat írni és operációs rendszereket telepíteni - a titkos adatok egy része meg fog maradni, és ki lehet őket nyerni, míg a többszöri duplikálás segít nekünk az eredeti egész összerakásában.
Ennek a módszernek az előnye nyilvánvaló: nem függünk a fájlformátumtól, sőt, még a használt fájlrendszer típusától sem.
A hátrányok is nyilvánvalóak, gondolom:
- A titkos adatokat csak a teljes lemez újraírásával lehet megváltoztatni, az azt követő felhasználó számára látható tartalom újbóli létrehozásával. Közben nem szabad olyan szoftvert használni, amely az elegy képből állítja vissza a lemezt: az visszaállítja az előző titkos adatokat is.
- Minél nagyobb a titkos adatok mennyisége, annál nagyobb a valószínűsége annak, hogy az információ egy része elveszik.
- Az adatok kinyerése a lemezről sok időt is igénybe vehet. Pár perctől akár néhány napig is eltarthat (a modern lemezek nagyok).
Most térjünk át a részletekre.
Nyilvánvaló, hogy ha egyszerűen szétkenjük a titkos adatokat a lemezen, csak a fegyvertelen szem elől rejtjük el őket. Ha fegyverezünk, mondjuk, egy lemezszerkesztőt, akkor az adatok teljes pompájukban fognak feltárulni. Ezért az adatokat érdemes lenne titkosítani, hogy ne tűnjenek fel. Egyszerű, de ízléses titkosítást alkalmazunk: az aes256-cbc algoritmus szerint. A titkosítási kulcsot a felhasználótól kérjük el, hadd találjon ki egy jó jelszót.
A következő kérdés: hogyan különböztessük meg a "helyes" adatokat a sérült adatoktól? Ebben segít nekünk a checksum, de nem akármilyen, hanem SHA1. Miért ne? A git számára elég jó, tehát nekünk is megfelel. Döntöttünk: minden elmentett információs részt ellátunk egy checksum-mal, és ha a visszafejtés után egyezik, akkor a visszafejtés sikerült.
Szükségünk lesz a fragmentum számára és a titkos adatok teljes hosszára. A fragmentum száma segít nyomon követni, hogy melyik darabot már fejtettük vissza, és melyik maradt hátra. A teljes hossz fontos lesz az utolsó fragmentum feldolgozásakor, hogy ne írjunk fölösleges adatokat (azaz padding). Mivel már így is fejlécet készítünk, hozzáadjuk a titkos fájl nevét is. Ez hasznos lesz a visszafejtés után, hogy ne találgassuk, mivel nyissuk meg.
Praktikusan ellenőrizzük a módszert
A teszteléshez a legelterjedtebb adathordozót, egy flash meghajtót választunk. Találtam egy régi 1 GB-osat, ami tökéletesen alkalmas a kísérletezésre. Ha Önnek, akárcsak nekem, az a gondolata támadt, hogy ne fájdalmaskodjon a fizikai adathordozókkal, hanem fájlképzéssel teszteljen, azonnal mondom: ez nem fog menni. Amikor egy ilyen „lemezt” formázunk, a Linux új fájlt hoz létre, és az összes nemhasználható szektort nullákkal töltik ki.
Linux gépként sajnos egy Raspberry Pi 3 meteorológiai állomást kellett használnom, ami a balkonon hevert. A memória nem bőséges, ezért nagy fájlokat nem fogunk elrejteni. Megkoronázzuk a maximális méret 10 megabájtban. Túl kicsi fájlokat sem érdemes rejtegetni: az eszköz 4 KB-os blokkokban írja az adatokat a lemezre. Ezért lefelé limitálva egy 3 kB-os fájlra korlátozódunk – ez elfér egy ilyen blokkban.
A flash meghajtóval lépésről lépésre fogunk játszadozni, és minden lépés után ellenőrizzük, olvasható-e a rejtett információ:
- Gyors formázás FAT16 formátumban 16 kB méretű klaszterrel. Ezt kínálja a Windows 7 egy fájlrendszer nélküli flash meghajtón.
- A flash meghajtó 50%-os kitöltése különféle szeméttel.
- A flash meghajtó 100%-os kitöltése különféle szeméttel.
- Hosszú formázás FAT16 formátumban (minden felülírásával).
Az első két teszt várhatóan teljes győzelemmel végződött: az eszköz sikeresen kinyerte a flash meghajtóról 10 megabájtnyi titkos adatot. Azonban miután a meghajtót teljesen feltöltöttük fájlokkal, hiba történt:
Összes beolvasott klaszter: 250752, dekripált: 158
HIBA: nem lehet írni a hiányos secretFile fájlba
Ahogy látjuk, csak 158 klasztert sikerült sikeresen dekódolni (632 kB nyers adatot, ami 636424 bájt hasznos adatot jelent). Nyilvánvaló, hogy itt 10 megabájt nem gyűjthető össze, és ezek között nyilván vannak duplikátumok. Még 1 megabájt is így már nem állítható helyre. De garantálható, hogy 3 kB titkos adatot vissza tudunk nyerni a flash meghajtóról, még azután is, hogy formázták és teljesen feltöltötték. Azonban a kísérletek azt mutatják, hogy ilyen flash meghajtóról egy 120 kB hosszúságú fájl is kinyerhető.
Sajnos az utolsó teszt azt mutatta, hogy a flash meghajtó teljesen felülírásra került:
$ sudo .\/steganodisk -p jelszó \/dev\/sda
Eszköz mérete: 250752 klaszter
250700 99%
Összesen olvasott klaszter: 250752, dekódolt: 0
HIBA: nem lehet írni a hiányos secretFile fájlba
Egyetlen klaszter sem maradt meg... Szomorú, de nem tragikus! Próbálkozunk azzal, hogy formázás előtt létrehozunk egy partíciót a flash meghajtón, majd abban - fájlrendszert. Egyébként gyárilag ilyen formázással érkezett, tehát semmi gyanúsat nem csinálunk.
Teljesen várható, hogy a flash meghajtón lévő szabad hely kissé csökkent.
Ugyancsak teljesen várható, hogy 10 megabájtot nem sikerült elrejteni egy teljesen megtöltött lemezen. De most már a sikeresen dekódolt klaszterek száma több mint a duplájára nőtt!
Olvasott klaszterek összesen: 250752, dekódolt: 405
Sajnos megabájtot nem lehet darabokból összerakni, de 200 kilobájtot könnyedén.
A legutolsó, negyedik ellenőrzésről is jó hír érkezett: a flash meghajtó teljes formázása nem vezetett az összes információ megsemmisítéséhez! 120 kilobajt titkos adat tökéletesen elfért a nem használt térben.
Összefoglaló táblázat a tesztelésről:
Kicsit elméleti: a szabad helyről és a nem használt szektorokról
Ha valaha is megosztottad a merevlemezedet partíciókra, észrevehetted, hogy nem mindig sikerül az összes szabad területet a lemezen felhasználni. Az első partíció mindig némi eltolással kezdődik (általában ez 1 megabájt vagy 2048 szektor). A legutolsó partíció mögött is néha marad egy kis „farok” felhasználatlan szektorokból. Ráadásul a partíciók között is néha maradnak rések, bár ez ritkán fordul elő.
Más szavakkal, a lemezen vannak olyan szektorok, amelyekhez nincs hozzáférés a lemez szokásos használata során, de az adatokba ezekre a szektorokra is le lehet írni! Tehát olvasni is lehet ezeket. Azt figyelembe véve, hogy van még partíciós tábla és betöltő kód, amelyek pontosan a lemez elején található üres területen helyezkednek el.
Térjünk el egy időre a partícióktól, és nézzük meg a lemezt madártávlatból. Van egy üres partíciónk a lemezen. Hozzunk létre benne egy fájlrendszert. Mondhatjuk, hogy néhány szektor a lemezen érintetlen maradt?
És-és-és — dobpergés! A válasz szinte mindig az lesz — igen! Mert a legtöbb esetben a fájlrendszer létrehozása annyira leegyszerűsödik, hogy a lemezre csak néhány rendszerinformációs blokk kerül írásra, míg a partíció többi tartalma változatlan marad.
Emellett — empirikusan — feltételezhetjük, hogy a fájlrendszer nem mindig tudja teljesen elfoglalni az összes neki kijelölt teret az utolsó szektorig. Például a 64 kilobájtos klaszterméretű FAT16 fájlrendszer nyilvánvalóan nem tudja teljesen elfoglalni azt a partíciót, amelynek mérete nem osztható 64 kilobájttal. Egy ilyen partíció végén maradnia kell egy „faroknak” néhány szektorban, amely nem elérhető felhasználói adatok tárolására. Mindazonáltal ezt kísérletileg nem tudtuk megerősíteni.
Így, hogy maximalizáljuk a steganogram számára elérhető helyet, olyan fájlrendszert kell használni, amelynek klasztermérete nagyobb. Létrehozhatunk még egy partíciót, még ha ez nem is szükséges (például egy pendrive-on). Nem szükséges üres partíciókat létrehozni vagy nem kiosztott területeket hagyni — ez fel fogja kelteni az érdeklődők figyelmét.
Kísérleti alkalmazás
Az alkalmazás forrásai megtekinthetők
A fordításhoz Qt 5.0-s verzióra és újabbra, valamint OpenSSL-re van szükség. Ha valami nem fordul — lehet, hogy módosítanod kell a steganodisk.pro fájlt.
A klaszter méretét 4 Kb-ról, például 512 bájtra változtathatjuk (a secretfile.h fájlban). Ezzel együtt a vezérlőinformáció költségei is nőni fognak: a fejléc és a ellenőrző összeg fixen 68 bájtot foglal el.
A segédprogramot természetesen root felhasználói jogokkal kell futtatni, és óvatosan. Nincsenek kérdések a megadott fájl vagy eszköz felülírása előtt!
Élvezze.
Forrás: habr.com
