Gewiste data terugvinden
Gegevens verwijderen en weer terugvinden
Ik wilde de oude wijsheden over het wissen van gegevens niet zomaar accepteren. Dus ben ik zelf maar eens op zoek gegaan naar verwijderde gegevens. Je gelooft nooit, wat ik toen vond.
Deze twee artikelen over het op de juiste manier verwijderen van gegevens komen voort uit een persoonlijke behoefte. Ik was verantwoordelijk voor een Windows-pc waarop onversleutelde iPhone-back-ups werden gemaakt. Die moesten daar weg en de computer moest verder voor andere dingen gebruikt worden. Toen ik de back-ups had verwijderd in iTunes, bedacht ik me ineens iets. De gegevens zelf waren waarschijnlijk helemaal niet verdwenen. Wat nu? Alle geraadpleegde deskundigen waren unaniem: "Alles helemaal wissen is de enige manier om van die gegevens af te komen."
Dat kwam echter om verschillende redenen niet in aanmerking. Ik wilde ook niet zomaar genoegen nemen met die onduidelijke situatie. Er moest een tussenweg zijn. Dus ging ik testen. Na de eerste, enigszins verwarrende resultaten bracht ik meer en meer methodiek in de tests aan om beter te begrijpen wat ik eigenlijk zag. Hier is het resultaat.
Wat de test betreft: ik testte naast elkaar een stokoud notebook met Windows Vista en een conventionele harde schijf en een modern Windows 10-systeem met een ssd. Het verloop was steeds hetzelfde. Ik heb met een paar snel in elkaar geknutselde PowerShell-scripts veel bestanden van verschillende grootte aangemaakt in een maphiërarchie. Alle bestanden bevatten de teststring 'cttest123' in verschillende varianten, die aangaven hoe groot het bestand oorspronkelijk was en waar de tekst in het bestand stond. De rest van het bestand was willekeurige rommel of zelfs leeg.
Vervolgens voerde ik de verwijderopdracht uit die ik wilde testen en sloot Windows af, want bij de tests mocht het besturingssysteem me zo min mogelijk voor de voeten lopen. Voor de zekerheid voerde ik voor de herstart nog een 'sync' uit, dat eventuele nog niet weggeschreven blokken naar de schijf zou schrijven (Mark Russinovich heeft die handige tool voor Unix geschikt gemaakt voor Windows). Soms rommelde ik zelf nog een beetje rond op het systeem of liet het 's nachts draaien, om Windows een beetje tijd te geven voor het opruimen. Daarna startte ik mijn analysesysteem vanaf een usb-stick. Daarvoor kun je eigenlijk bijna elke willekeurige liveLinux gebruiken. Gangbare Linux-systemen bevatten alle benodigde hulpmiddelen.
Sommige systemen bevatten ook de datarecovery-tool photorec, die vaak verbazingwekkend presteert bij het terughalen van verwijderde bestanden. Maar daar ging het mij niet om. Wat ik wilde weten was iets fundamentelers. Duikt mijn teststring nog op, en zo ja, waar dan? Voor mij een duidelijk geval voor de universele tool grep, die ik direct aan de slag zette op de testpartitie /dev/sda2. De parameter -a instrueerde grep om dit block-device als een tekstbestand te doorzoeken op 'cttest123', -b zorgde voor de byte-offsets van de treffers. Toen kwam het eerste probleem: grep stopte er telkens mee met geheugenfouten.
Een beetje googelen gaf de reden en een oplossing: grep werkt per regel. Sommige bestanden bevatten zulke lange gegevensblokken, zonder regeleinden, dat grep te weinig geheugen had. De oplossing kwam van twee kleine Linux-tools:
cat /dev/sda2 | tr '\0' '\n' | grep
-ba 'cttest123'
Dit verving alle null-tekens door de regeleinden die grep nodig heeft. Zoeken met grep in deze wirwar leverde soms verbazingwekkend lange lijsten met cttest123hits op. Ik controleerde de vondsten steekproefsgewijs met een hex-dumper:
xxd -s <offset> /dev/sda2 | less
en in alle gevallen stond daar inderdaad de gezochte tekenreeks.
Om te bepalen in welke context ze daar stonden, wiste ik systematisch verschillende delen van het NTFS-bestandssysteem met de Linux-tool ntfswipe en keek dan nog een keer. Ntfswipe is een bijproduct van het NTFS-stuurprogramma voor Linux, waarmee het te verwijderen gebied kan worden geselecteerd. Je kunt kiezen uit MFT, Pagefile, Tails, Directory, Logfile, Undeletable en Unused.
Het programmaatje maakte overigens een heel positieve indruk in mijn tests en was zeer grondig. Na een run met --all vond de volgende controlerun over de hele partitie inderdaad geen teststrings meer, op één uitzondering na, waarop ik nog terugkom. Daarbij werden in totaal honderden verwijderacties gecombineerd, die geen problemen veroorzaakten. Bovendien liet ntfswipe precies zien waar het verwijderproces gefaald had. Maar ik loop op de zaken vooruit.
Missers bij het wissen
Bij de eerste stap documenteerde ik een gewone verwijdering en wat daarna nog op de schijf te zien was. Daarbij heb ik verschillende verwijdermethoden getest, zoals het legen van de prullenbak, verwijderen met ingedrukte Shift-toets in Verkenner en het verwijderen vanaf de opdrachtregel, zonder daarbij verschillen te vinden.
Zoals verwacht werden bijna alle verwijderde bestanden grotendeels intact teruggevonden op de harde schijf. Op de ssd waren de gegevens echter grotendeels verdwenen. En dat bijna meteen. Zoals te verwachten, zorgde de TRIM-opdracht ervoor dat de ssd de geheugengebieden van de verwijderde bestanden als vrij markeerde. Hij retourneerde alleen nullen voor de volgende leesacties. Tenminste, bij bijna alle bestanden.
Kleine bestanden, die een plaats vonden in de MFT zelf, ontsnapten regelmatig aan deze bewerking. Niet alle en ook niet altijd evenveel, maar grep kwam steeds met een aantal van die kleine cttest123bestanden aanzetten. Met ntfswipe -m werden de gegevens echter op een betrouwbare manier uit de MFT verwijderd. In sommige gevallen bevonden zich ook delen van grotere bestanden in het logboek van het Windows-bestandssysteem. Vreemd genoeg overleefden ze daar zelfs verschillende Windows-herstarts.
Dit laatste herhaalde zich tijdens het veilig verwijderen, dus het overschrijven met de SysInternals-tool SDelete. Zowel op de ssd als op de harde schijf bevatte het logbestand van het NTFS-bestandssysteem delen van het begin van grote bestanden. Deze resterende gegevens geven echter relatief weinig problemen. Ze verdwijnen waarschijnlijk na een korte tijd vanzelf.
Ook bij het wissen van vrije geheugengebieden met de Windows-toepassingen Cipher en SDelete bleven resten achter. Sommige kleine testbestanden vonden weer beschutting in de MFT, en dat zowel op de ssd als de harde schijf. Dat is wel een probleem. De ingangen in de MFT kunnen slechts een zeer kleine hoeveelheid gegevens bevatten, maar voor een wachtwoordbestand of een geheime sleutel kunnen de typische 512 bytes net genoeg zijn. En als verwijderende gebruiker heb ik geen idee welke bestanden in de MFT staan.
Ik kan niet echt verklaren waarom deze gegevens zowel het wissen van vrije ruimte als de TRIM ontlopen. Ik vermoed dat Windows op de een of andere manier beslag legt op de MFT-ingangen en ze beschermt tegen overschrijven door nieuw aangemaakte bestanden. Ntfswipe hoeft daar omdat het vanuit Linux opereert geen rekening mee te houden en kan gewoon de gegevens van alle MFT-ingangen verwijderen die als vrij gemarkeerd zijn.
Verraderlijke zoektocht
Bij toeval stuitte ik op iets interessants. Toen ik op een ochtend niet meer zeker wist of ik de dag ervoor al nieuwe testbestanden had gemaakt, zocht ik een beetje slaperig in Verkenner naar de teststring 'cttest123'. Geen bestanden. De volgende testruns onthulden echter twee hardnekkige cttest123-treffers die zelfs ntfswipe niet kon elimineren. Al snel drong het tot me door dat ik mezelf in de nesten had gewerkt. Windows had mijn zoekopdrachten opgeslagen in de zoekgeschiedenis, die zich natuurlijk op de harde schijf bevond. Om precies te zijn, vond ik de tekenreeks in het bestand NTUSER.DAT. Dat is de gebruikerstak van het register.
Naïef als ik was, wiste ik de zoekgeschiedenis met de betreffende optie in Verkenner en dacht van het probleem af te zijn. Tot mijn verbazing doken deze treffers bij de volgende keer zoeken nog steeds op. En dat niet alleen in het automatisch aangemaakte bestand ntuser.dat.LOG1, maar ook in het origineel. Toen volgde een urenlange Odyssee met als doel dat verdraaide 'cttest123' uit het Windows-systeem te verwijderen, zodat ik door kon gaan met de verwijdertests. Uiteindelijk greep ik in wanhoop naar de botte bijl in de vorm van een hex-editor. Daarmee veranderde ik de tekens 'ct' in 'ab', met voorbijgaan aan het bestandssysteem, rechtstreeks op de juiste plek op de harde schijf. Deze Harakiriactie lukte en had geen verdere gevolgen, maar probeer dat maar liever niet thuis! Ik documenteer dit alleen om te laten zien hoe hardnekkig gegevens in een Windowssysteem kunnen vastzitten.
Na mijn tests begrijp ik beter hoe het verwijderen werkt en kan ik de risico's dat verwijderde gegevens weer opduiken beter inschatten. Het volgende is mijn persoonlijke conclusie, die je alleen met de nodige voorzichtigheid op je eigen situatie mag toepassen. Het grootste gevaar zit hem in de kopieën van de gegevens, die opduiken op plaatsen waar je ze niet verwacht en die dus ook niet verwijderd worden, zoals na een zoekactie in Verkenner. Afgezien daarvan voldoet bij ssd's met een werkende TRIM de gewone verwijdering aan mijn behoeften. Het restrisico van in theorie uitleesbaar flashgeheugen neem ik op de koop toe.
Als je veilig moet verwijderen, is een combinatie van overschrijven en wissen van de vrije ruimte het beste. Zorgwekkend zijn de kleine bestanden die in de MFT terechtkomen. Daarbij helpt ntfswipe, vanaf een snel gestarte Linux-live-cd. De Windows-installatie met de iPhone-back-ups kreeg in elk geval een tweede leven na een grondige ntfswipe.