Steganografi efter filer: döljer data direkt i sektorer

Ett litet förord

Steganografi, om någon inte kommer ihåg, döljer information i vissa behållare. Till exempel i bilder (diskuterat här и här). Du kan också dölja data i filsystemets servicetabeller (detta skrevs om här), och även i TCP-protokollservicepaket. Tyvärr har alla dessa metoder en nackdel: för att omärkligt "infoga" information i en behållare behöver du listiga algoritmer som tar hänsyn till särdragen i behållarens interna struktur. Och problem uppstår med behållarens motståndskraft mot manipulation: till exempel, om du redigerar bilden något, går dold information förlorad.

Är det möjligt att på något sätt klara sig utan listiga algoritmer och subtila manipulationer med data, och ändå säkerställa behållarens funktionalitet och en acceptabel säkerhetsnivå för dolda data? När jag ser framåt, säger jag - ja, det kan du! Jag kommer till och med att erbjuda dig ett verktyg.

Bloda detaljer om metoden

Grundidén är så enkel som ett slag i pannan: det finns områden på disken som operativsystemet aldrig skriver till (eller skriver i sällsynta fall). För att undvika behovet av att söka efter dessa områden med hjälp av listiga algoritmer kommer vi att använda redundans - det vill säga vi kommer att duplicera vår dolda information många, många gånger över alla sektorer på disken. Sedan, ovanpå all denna prakt, kan du skapa de nödvändiga partitionerna, formatera filsystem, skriva filer och installera operativsystem - samtidigt kommer en del av den hemliga informationen att sparas och kan hämtas, och upprepad duplicering kommer att hjälpa oss sätta ihop den ursprungliga helheten från bitarna.

Fördelen med denna metod är uppenbar: vi är inte beroende av filformatet, eller ens på vilken typ av filsystem som används.

Nackdelarna är också, tror jag, uppenbara:

  • Hemliga data kan endast ändras genom att fullständigt skriva om hela disken, följt av att återskapa innehållet som är synligt för användaren. Du kan dock inte använda programvara som återskapar disken från en bild: den kommer också att återskapa tidigare hemliga data.
  • Ju större volym hemlig data, desto större är sannolikheten för att viss information går förlorad.
  • Att hämta data från disk kan ta lång tid. Från flera minuter till flera dagar (moderna diskar är stora).

Låt oss nu gå vidare till detaljerna.

Det är klart att om du helt enkelt smetar ut hemlig data över hela disken, kommer den bara att döljas för blotta ögat. Om du utrustar din blick med, säg, en diskredigerare, kommer datan att dyka upp i all ära. Därför skulle det vara en bra idé att kryptera data så att den inte dyker upp. Vi kommer att kryptera enkelt, men smakfullt: med aes256-cbc-algoritmen. Vi ber användaren om krypteringsnyckeln och låter honom komma med ett bra lösenord.

Nästa fråga är hur vi kan skilja "bra" data från dåliga data. Här kommer en kontrollsumma att hjälpa oss, men inte en enkel sådan, utan SHA1. Och vad? Det är tillräckligt bra för git, så det kommer att passa oss också. Beslutat: vi förser varje lagrad information med en kontrollsumma, och om den matchar efter dekrypteringen betyder det att dekrypteringen lyckades.

Du behöver också fragmentnumret och den totala längden på de hemliga uppgifterna. Fragmentnumret är till för att hålla reda på vilka bitar vi redan har dechiffrerat och vilka som finns kvar. Den totala längden kommer att vara användbar för oss när vi bearbetar det sista fragmentet, för att inte skriva onödiga data (det vill säga utfyllnad). Tja, eftersom vi fortfarande har en rubrik lägger vi till namnet på den hemliga filen där. Det kommer att vara användbart efter dekryptering, för att inte gissa hur man öppnar det.

Testa metoden i praktiken

För att kontrollera, låt oss ta det vanligaste mediet - en flash-enhet. Jag hittade en gammal med 1 GB kapacitet, som är ganska lämplig för experiment. Om du, som jag, kom på idén att inte bry dig om fysiska medier, utan att testa det på en fil - en diskavbildning, då säger jag direkt: det kommer inte att fungera. När du formaterar en sådan "disk" skapar Linux filen igen, och alla oanvända sektorer kommer att fyllas med nollor.

Som en maskin med Linux var jag tyvärr tvungen att använda en väderstation på Raspberry Pi 3 som låg på balkongen. Det finns inte mycket minne där, så vi kommer inte att gömma stora filer. Vi begränsar oss till en maximal storlek på 10 megabyte. Det är heller ingen idé att dölja filer som är för små: verktyget skriver data till disken i 4 KB-kluster. Därför kommer vi nedan att begränsa oss till en 3 kb fil - den passar in i ett sådant kluster.

Vi kommer att håna flashenheten i etapper och kontrollera efter varje steg om den dolda informationen är läsbar:

  1. Snabbformatering i FAT16-format med en klusterstorlek på 16 KB. Detta är vad Windows 7 erbjuder att göra med en flashenhet som inte har ett filsystem.
  2. Fyller flash-enheten med alla typer av skräp med 50%.
  3. Fyller flash-enheten med alla typer av skräp med 100%.
  4. "Lång" formatering i FAT16-format (skriver över allt).

De två första testerna slutade, som väntat, i fullständig seger: verktyget kunde framgångsrikt extrahera 10 megabyte hemlig data från flashenheten. Men efter att flashenheten var fylld till kapaciteten med filer, inträffade ett fel:

Total clusters read: 250752, decrypted: 158
ERROR: cannot write incomplete secretFile

Som du kan se dekrypterades endast 158 ​​kluster framgångsrikt (632 kilobyte rådata, vilket ger 636424 10 byte nyttolast). Det är tydligt att det inte finns något sätt att få 1 megabyte här, och ändå finns det tydliga dubbletter bland dessa kluster. Du kan inte ens återställa 3 megabyte på detta sätt. Men vi kan garantera att vi kommer att återställa 120 kilobyte hemlig data från en flash-enhet även efter att den har formaterats och skrivits till kapacitet. Experiment visar dock att det är fullt möjligt att extrahera en fil som är XNUMX kilobyte lång från en sådan flashenhet.

Det senaste testet visade tyvärr att hela flashenheten skrevs över:

$ sudo ./steganodisk -p password /dev/sda
Device size: 250752 clusters
250700 99%
Total clusters read: 250752, decrypted: 0
ERROR: cannot write incomplete secretFile

Inte ett enda kluster har överlevt... Sorgligt, men inte tragiskt! Innan vi formaterar, låt oss försöka skapa en partition på flashenheten och redan i det ett filsystem. Den kom förresten från fabriken med exakt denna formatering, så vi gör inget misstänkt.
Det är ganska förväntat att det tillgängliga utrymmet på flashenheten har minskat något.

Det är också ganska väntat att 10 megabyte inte kunde döljas på en helt full disk. Men nu har antalet framgångsrikt dekrypterade kluster mer än fördubblats!

Total clusters read: 250752, decrypted: 405

Tyvärr är det omöjligt att sätta ihop en megabyte från bitar, men tvåhundra kilobyte är lätt.

Nåväl, nyheterna om den sista, fjärde kontrollen, den här gången är glädjande: att fullständigt formatera en sådan flashenhet ledde inte till att all information förstördes! 4 kilobyte hemlig data passar perfekt in i oanvänt utrymme.

Testsammanfattningstabell:

Steganografi efter filer: döljer data direkt i sektorer

Lite teoretisering: om ledigt utrymme och oanvända sektorer

Om du någon gång har delat upp din hårddisk i partitioner har du kanske märkt att det inte alltid är möjligt att allokera allt ledigt utrymme på disken. Det första avsnittet börjar alltid med någon indragning (vanligtvis 1 megabyte, eller 2048 sektorer). Bakom det sista avsnittet händer det också att det finns kvar en liten "svans" av oanvända sektorer. Och ibland finns det luckor mellan avsnitten, även om det är sällan.

Det finns med andra ord sektorer på disken som inte går att komma åt under normalt arbete med disken, men data kan skrivas till dessa sektorer! Och det betyder att läsa den också. Justerat för det faktum att det även finns en partitionstabell och startladdarkod, som finns i det tomma området i början av disken.

Låt oss ta en paus från avsnitten en stund och titta på skivan från fågelperspektiv så att säga. Här har vi en tom partition på disken. Låt oss skapa ett filsystem i den. Kan vi säga att vissa sektorer på disken förblir oraderade?

E-e-e - trumrulle! Svaret kommer nästan alltid att vara ja! Faktum är att i de flesta fall, att skapa ett filsystem beror på det faktum att endast ett fåtal block av tjänstinformation skrivs till disken, och annars ändras inte partitionens innehåll.

Och även - rent empiriskt - kan vi anta att filsystemet inte alltid kan uppta allt utrymme som tilldelats det fram till den sista sektorn. Till exempel kan ett FAT16-filsystem med en klusterstorlek på 64 kilobyte uppenbarligen inte helt uppta en partition med en storlek som inte är en multipel av 64 kilobyte. I slutet av ett sådant avsnitt måste det finnas en "svans" av flera sektorer som är otillgängliga för att lagra användardata. Detta antagande kunde dock inte bekräftas experimentellt.

Så för att maximera det tillgängliga utrymmet för steganogrammet måste du använda ett filsystem med en större klusterstorlek. Du kan också skapa en partition, även om detta inte är nödvändigt (på en flash-enhet, till exempel). Det finns inget behov av att skapa tomma sektioner eller lämna otilldelade områden - detta kommer att locka intresserade medborgares uppmärksamhet.

Verktyg för experiment

Du kan trycka på källkoden för verktyget här

För att bygga behöver du Qt version 5.0 eller högre och OpenSSL. Om något inte fungerar kan du behöva redigera filen steganodisk.pro.

Du kan ändra klusterstorleken från 4 KB till, säg, 512 byte (i secretfile.h). Samtidigt kommer kostnaden för serviceinformation att öka: rubriken och kontrollsumman upptar en fast 68 byte.

Du måste naturligtvis köra verktyget med root-användarrättigheter och med försiktighet. Det kommer inte att ställas några frågor innan du skriver över den angivna filen eller enheten!

Njut av det.

Källa: will.com

Lägg en kommentar