Een kort voorwoord
Steganografie verbergt, als iemand het zich niet herinnert, informatie in sommige containers. Bijvoorbeeld op foto's (besproken и ). Je kunt ook gegevens verbergen in servicetabellen van het bestandssysteem (hierover is geschreven ), en zelfs . Helaas hebben al deze methoden één nadeel: om onmerkbaar informatie in een container te 'invoegen', heb je sluwe algoritmen nodig die rekening houden met de eigenaardigheden van de interne structuur van de container. En er ontstaan problemen met de weerstand van de container tegen manipulatie: als je bijvoorbeeld de afbeelding lichtjes bewerkt, gaat verborgen informatie verloren.
Is het mogelijk om op de een of andere manier te doen zonder sluwe algoritmen en subtiele manipulaties met gegevens, en toch de functionaliteit van de container en een acceptabel beveiligingsniveau van verborgen gegevens te garanderen? Vooruitkijkend zeg ik: ja, dat kan! Ik bied zelfs een hulpprogramma aan.
Bloedige details van de methode
Het basisidee is zo simpel als een klap op het voorhoofd: er zijn gebieden op de schijf waar het besturingssysteem nooit naar schrijft (of in zeldzame gevallen schrijft). Om te voorkomen dat we naar deze gebieden moeten zoeken met behulp van sluwe algoritmen, zullen we redundantie gebruiken - dat wil zeggen dat we onze verborgen informatie vele, vele malen zullen dupliceren over alle sectoren van de schijf. Vervolgens kun je, bovenop al deze pracht, de benodigde partities maken, bestandssystemen formatteren, bestanden schrijven en besturingssystemen installeren - toch zal een deel van de geheime gegevens worden opgeslagen en kunnen worden opgehaald, en herhaaldelijk dupliceren zal ons helpen uit de stukken het originele geheel samenstellen.
Het voordeel van deze methode ligt voor de hand: we zijn niet afhankelijk van het bestandsformaat, en zelfs niet van het gebruikte type bestandssysteem.
De nadelen liggen volgens mij ook voor de hand:
- Geheime gegevens kunnen alleen worden gewijzigd door de hele schijf volledig te herschrijven, gevolgd door het opnieuw creëren van de inhoud die zichtbaar is voor de gebruiker. U kunt echter geen software gebruiken die de schijf opnieuw maakt op basis van een afbeelding: deze zal ook de eerdere geheime gegevens opnieuw aanmaken.
- Hoe groter het volume aan geheime gegevens, hoe groter de kans dat bepaalde informatie verloren gaat.
- Het ophalen van gegevens van schijf kan lang duren. Van enkele minuten tot meerdere dagen (moderne schijven zijn groot).
Laten we nu verder gaan met de details.
Het is duidelijk dat als je eenvoudigweg geheime gegevens over de hele schijf verspreidt, deze alleen voor het blote oog verborgen zullen zijn. Als u uw blik uitrust met bijvoorbeeld een schijfeditor, verschijnen de gegevens in al hun glorie. Daarom zou het een goed idee zijn om de gegevens te coderen, zodat deze niet verschijnen. We zullen eenvoudig maar smaakvol coderen: met behulp van het aes256-cbc-algoritme. We vragen de gebruiker om de encryptiesleutel en laten hem een goed wachtwoord bedenken.
De volgende vraag is hoe we ‘goede’ data van slechte data kunnen onderscheiden. Hier zal een controlesom ons helpen, maar geen eenvoudige, maar SHA1. En wat? Het is goed genoeg voor git, dus het past ook bij ons. Besloten: we voorzien elk opgeslagen stukje informatie van een controlesom, en als deze na de ontsleuteling overeenkomt, betekent dit dat de ontsleuteling succesvol was.
Daarnaast heeft u het fragmentnummer en de totale lengte van de geheime gegevens nodig. Het fragmentnummer is om bij te houden welke stukken we al hebben ontcijferd en welke nog over zijn. De totale lengte zal voor ons nuttig zijn bij het verwerken van het laatste fragment, om geen onnodige gegevens te schrijven (dat wil zeggen opvulling). Omdat we nog steeds een header hebben, voegen we daar de naam van het geheime bestand toe. Het zal nuttig zijn na decodering, om niet te raden hoe u het moet openen.
Het testen van de methode in de praktijk
Laten we om dit te controleren het meest gebruikelijke medium nemen: een flashdrive. Ik heb een oude gevonden met een capaciteit van 1 GB, die redelijk geschikt is voor experimenten. Als je, net als ik, op het idee kwam om je niet bezig te houden met fysieke media, maar het te testen op een bestand - een schijfkopie, dan zeg ik meteen: het zal niet werken. Bij het formatteren van zo’n “schijf” maakt Linux het bestand opnieuw aan, en alle ongebruikte sectoren zullen gevuld worden met nullen.
Als machine met Linux moest ik helaas een weerstation gebruiken op de op het balkon liggende Raspberry Pi 3. Daar is niet veel geheugen, dus we zullen geen grote bestanden verbergen. Wij beperken ons tot een maximale grootte van 10 megabyte. Het heeft ook geen zin om te kleine bestanden te verbergen: het hulpprogramma schrijft gegevens naar schijf in clusters van 4 KB. Daarom beperken we ons hieronder tot een bestand van 3 kb - het past in zo'n cluster.
We zullen de flashdrive in fasen bespotten en na elke fase controleren of de verborgen informatie leesbaar is:
- Snelle formattering in FAT16-formaat met een clustergrootte van 16 KB. Dit is wat Windows 7 te bieden heeft met een flashdrive die geen bestandssysteem heeft.
- De flashdrive vullen met allerlei soorten afval met 50%.
- De flashdrive vullen met allerlei soorten afval met 100%.
- “Lange” formattering in FAT16-formaat (alles overschrijven).
De eerste twee tests eindigden, zoals verwacht, in een volledige overwinning: het hulpprogramma kon met succes 10 megabytes aan geheime gegevens uit de flashdrive extraheren. Maar nadat de flashdrive volledig gevuld was met bestanden, deed zich een fout voor:
Total clusters read: 250752, decrypted: 158
ERROR: cannot write incomplete secretFile
Zoals u kunt zien, zijn slechts 158 clusters met succes gedecodeerd (632 kilobytes aan onbewerkte gegevens, wat 636424 bytes aan payload oplevert). Het is duidelijk dat er geen manier is om hier 10 megabytes te krijgen, en toch zijn er onder deze clusters duidelijk duplicaten. Je kunt op deze manier niet eens 1 megabyte herstellen. Maar we kunnen garanderen dat we 3 kilobytes aan geheime gegevens van een flashdrive zullen herstellen, zelfs nadat deze is geformatteerd en naar de maximale capaciteit is geschreven. Uit experimenten blijkt echter dat het heel goed mogelijk is om een bestand van 120 kilobytes lang uit zo'n flashdrive te halen.
Uit de laatste test bleek helaas dat de hele flashdrive was overschreven:
$ sudo ./steganodisk -p password /dev/sda
Device size: 250752 clusters
250700 99%
Total clusters read: 250752, decrypted: 0
ERROR: cannot write incomplete secretFile
Geen enkele cluster heeft het overleefd... Triest, maar niet tragisch! Laten we, voordat we gaan formatteren, proberen een partitie op de flashdrive te maken, en daarin al een bestandssysteem. Trouwens, het kwam uit de fabriek met precies deze opmaak, dus we doen niets verdachts.
Er wordt verwacht dat de beschikbare ruimte op de flashdrive iets is afgenomen.
Er wordt ook verwacht dat 10 megabytes niet verborgen kunnen worden op een volledig volle schijf. Maar nu is het aantal succesvol gedecodeerde clusters meer dan verdubbeld!
Total clusters read: 250752, decrypted: 405
Helaas is het onmogelijk om één megabyte uit stukjes samen te stellen, maar tweehonderd kilobyte is makkelijk.
Welnu, het nieuws over de laatste, 4e controle is deze keer vreugdevol: het volledig formatteren van zo'n flashdrive leidde niet tot de vernietiging van alle informatie! 120 kilobytes aan geheime gegevens passen perfect in ongebruikte ruimte.
Testoverzichtstabel:
Een beetje theorievorming: over vrije ruimte en ongebruikte sectoren
Als u uw harde schijf ooit in partities heeft verdeeld, is het u misschien opgevallen dat het niet altijd mogelijk is om alle vrije ruimte op de schijf toe te wijzen. Het eerste gedeelte begint altijd met een inspringing (meestal 1 megabyte of 2048 sectoren). Achter het laatste gedeelte komt het ook voor dat er een kleine “staart” van ongebruikte sectoren overblijft. En soms zijn er gaten tussen secties, hoewel zelden.
Met andere woorden: er zijn sectoren op de schijf die niet toegankelijk zijn tijdens normaal werk met de schijf, maar er kunnen wel gegevens naar deze sectoren worden geschreven! En dat betekent dat je het ook moet lezen. Aangepast voor het feit dat er ook een partitietabel en bootloadercode is, die zich in het lege gebied aan het begin van de schijf bevinden.
Laten we even een pauze nemen van de secties en de schijf als het ware vanuit vogelperspectief bekijken. Hier hebben we een lege partitie op de schijf. Laten we er een bestandssysteem in maken. Kunnen we zeggen dat sommige sectoren op de schijf niet worden gewist?
E-e-e - tromgeroffel! Het antwoord zal bijna altijd ja zijn! In de meeste gevallen komt het creëren van een bestandssysteem neer op het schrijven van slechts een paar blokken met service-informatie naar de schijf, en anders verandert de inhoud van de partitie niet.
En ook - puur empirisch - kunnen we aannemen dat het bestandssysteem niet altijd alle ruimte kan innemen die eraan is toegewezen, tot aan de laatste sector. Een FAT16-bestandssysteem met een clustergrootte van 64 kilobytes kan bijvoorbeeld uiteraard niet volledig een partitie in beslag nemen met een grootte die niet een veelvoud is van 64 kilobytes. Aan het einde van zo'n sectie zal er een "staart" moeten zijn van verschillende sectoren, ontoegankelijk voor het opslaan van gebruikersgegevens. Deze veronderstelling kon echter experimenteel niet worden bevestigd.
Om de beschikbare ruimte voor het steganogram te maximaliseren, moet u dus een bestandssysteem met een grotere clustergrootte gebruiken. Je kunt ook een partitie aanmaken, ook als dit niet nodig is (bijvoorbeeld op een flashdrive). Het is niet nodig om lege secties te creëren of niet-toegewezen gebieden achter te laten - dit zal de aandacht trekken van geïnteresseerde burgers.
Hulpprogramma voor experimenten
U kunt de broncode van het hulpprogramma aanraken
Om te bouwen heeft u Qt versie 5.0 of hoger en OpenSSL nodig. Als iets niet werkt, moet u mogelijk het bestand steganodisk.pro bewerken.
U kunt de clustergrootte wijzigen van 4 KB naar bijvoorbeeld 512 bytes (in secretfile.h). Tegelijkertijd zullen de kosten van service-informatie stijgen: de header en de checksum bezetten een vaste 68 bytes.
U moet het hulpprogramma uiteraard uitvoeren met rootgebruikersrechten en met de nodige voorzichtigheid. Er worden geen vragen gesteld voordat het opgegeven bestand of apparaat wordt overschreven!
Genieten.
Bron: www.habr.com