Err.. Nee, als het MBR weer hersteld wordt kun je gewoon bij de data. De data is heus niet ineens spontaan verdwenen omdat het MBR (en de partitietabel) weg is. Dat het voor de gemiddelde computer n00b weg is is een tweede maar de data staat wel degelijk nog steeds op de schijf.

Er wordt dus wel degelijk data vernietigd. En er zijn wel forensische methodes om dit op magnetische HDs te recoveren, maar goedkoop zijn deze niet.

Precies MBR is geen probleem maar met name deze is lastig:

"Door Redactie:
Vervolgens zal de malware alle bestanden op de harde schijven enumereren om daarna bestanden met een specifieke extensie met nullen te overschrijven"

Als de 1 pass zero methode gebruikt wordt en het daarbij blijft is er nog redding. Als er echter ook combinaties van andere methoden worden gebruikt (Gutmann's algorithm,German VSITR, One-pass zeros method, One-pass random characters method, User defined method (user’s pattern and specified number of passes), User-defined number of passes (up to 99) wordt het wel heel moeilijk zo niet onmogelijk bij Gutmann's algoritme.

Dat klopt maar dat is niet wat Wicherski zegt:

Dit hoor ik vaker, maar kan iemand dit ook bewijzen? Is daar ergens een paper over? Ik heb wel eens gepraat met iemand die dit recoveren voor zijn werk doet, en hij gaf aan dat zo gauw een schijf is overschreven (al is het maar één pass met plain data) het eigenlijk al niet meer te doen is om daar nog data vanaf te halen. Dit schijnt te gelden voor de moderne HDDs.

Hahaha. Als iemand van McAfee dat zegt, dan is de kans groot dat het om een zg. 'false positive' gaat!

Met nullen overschrijven doet vaak niet wat je denkt. Dit komt omdat veel bestandssystemen deze nullen eigenlijk helemaal niet opslaan. Het is daarom beter om een bestand te overschrijven met willekeurige data i.p.v. nullen.

http://en.wikipedia.org/wiki/Sparse_file

Als je onder Windows Vista of 7 een Format doet is de disk toch echt overschreven met nullen.
Vertel mij maar eens welke file recovery tool daar nog data uit weet te halen.
Data overschrijven met nullen, al is het maar 1 keer, is echt wissen.
De MBR overschrijven is inderdaad onvoldoende om de rest van de data onbruikbaar te maken.

Er is een groot verschil tussen een bestand overschrijven en een schijf overschrijven.

He vriend, van kiet af aan heb je gelijk hier, een MBR is natuurlijk te herstellen.
Maar wat bedoel je hiermee ?

Natuurlijk is er een verschil maar wat bedoel je technisch dan.
Als je een file overschrijft dan wordt alles inhoudelijk een 0
Als je de hele schijf overschrijft dan worden alle files inhoudelijk een 0
Wat is het verschil dan (buiten de info van de partitie tabel en zo om)

Zie mijn opmerking over sparse files. Een schijf overschrijven gaat buiten het filesystem om.

@14:37
In OSX kun je de vrije ruimte wissen met nullen terwijl het filesystem én gemount blijft, én tegelijk gebruikt kan worden.

Ik dacht dat je op een Windows workstation zelden sparse files zou vinden.
Heb het dan ook even snel gecontroleerd op een Windows XP PC: geen enkel systeembestand is een sparse file, zelfs de swap file niet.

NTFS ondersteunt wel degelijk sparse files.

Hoe heb je dit gecontroleerd? Bedenk dat sparse files compleet transparant zijn t.o.v. de gebruiker. Als je een bestand leest dat bestaat uit 1000 nul bytes dan lees je ook 1000 keer een nul. De bestandsgroote zal ook netjes 1000 bytes aangeven. Fysiek op de schijf wordt er echter minder opgeslagen. Dan ben je met een paar bytes klaar, alleen wat metadata.

http://www.flexhex.com/docs/articles/sparse-files.phtml

V.w.b. de swapfile kan ik me voorstellen dat ze geen sparse file daarvoor gebruiken. Dit zou de performance niet echt goed doen (en die is toch al niet zo best als je swap file aangesproken wordt).

Ik gebruik NTFS op mijn system, geen FAT, anders zou ik geen sparse files kunnen aanmaken.

De inhoud van een file analyseren om te bepalen of het een sparse file is, is als methode totaal ongeschikt. Je moet het OS ondervragen.

Programmatorisch doe je dit door GetFileInformationByHandle aan te roepen met een open handle voor de bewuste file, en dan kijk je of de file attributen de vlag FILE_ATTRIBUTE_SPARSE_FILE hebben.
Let er wel op dat je dus een handle moet kunnen openen, voor systeem bestanden zoals de swapfile die exclusief geopend worden, moet je ervoor zorgen dat het OS het bestand niet gebruikt (wat ik ook gedaan heb).

Manueel doe je dit met de fsutil opdracht. Hier geldt dezelfde opmerking betreffende toegang tot de files.

Nee, wanneer je een file verwijderd, dan worden de gebruikte sectoren gemarkeerd als 'ongebruikt' en kan je die sectoren dus weer overschrijven met een nieuw te maken file of een bestaande file die groter wordt.
Echter je weet niet wanneer welke niet gebruikte sector aan de beurt is, dus de data van de oude file kan nog heel lang op je schijf blijven staan.
Wanneer je een sector gaat toevoegen aan een file, dan zal je OS over het algemeen de sector pas overschrijven met 0-en op het deel van de sector waar verder geen informatie van de file in komt.
Bijvoorbeeld een textbestand met "hoi" erin zal minimaal 1 sector in beslag nemen en in de praktijk zelfs iets meer, maar dat is afhankelijk van je filesysteem. Die file is dan zo'n 3 bytes lang (exclusief enige header-informatie) en de rest zijn 0-en.
Uiteraard zijn hier ook nog weer uitzonderingen op, waaronder de al genoemde sparse-files, maar ook gecombineerde files (ben ff de naam kwijt), wat sommige filesystemen ondersteunen met heel veel kleine files die vrijwel nooit aangepast worden.

Met het formatteren wordt er nog veel minder weggeschreven dan met het wissen van een schijf.
Heel simpel 'bewijs' is dat wanneer je een 1 TB schijf echt zou willen overschrijven met 0-en tijdens het formatteren, dan ben je bijna 3 uur bezig (10'000 sec) met ruim 100 MB/s. En dat formatteren duurt echt maar een paar seconden tot een minuut hooguit.
Kortom, met de juiste tools kun je een (net) geformatteerde schijf vrijwel geheel nog weer lezen en ook alle directories en filenamen die erop stonden. Pas als er nieuwe files op geschreven worden kun je die delen niet meer teruglezen.

SSD's hebben nog een andere vorm van verwijderen van files. Wanneer je een sector vrijgeeft, dan komt die achter aan in het rijtje van te gebruiken sectoren te staan. Dus die zal pas als allerlaatste weer gebruikt gaan worden bij het maken van een nieuwe file. (wear-levelling) Echter het schrijven van een SSD gaat ook iets anders.
Je kunt alleen een 1 in een 0 omzetten. Dus bij het aanpassen van een file, moet je de sector lezen, in het geheugen aanpassen, sector wissen (alles op 1 zetten) en de hele sector weer schrijven. In de praktijk is dat ook een andere sector.
Dit is traag, dus hebben ze het TRIM commando uitgevonden. Wanneer een sector vrijgegeven is en je OS heeft even niets te doen, dan gaat 'ie alle vrijgegeven sectoren alvast wissen, dus op 1 zetten. Dan hoef je bij het schrijven niet meer te wissen en dat is sneller.


En dan nu het recoveren van data die overschreven is.
Vroegah, toen de lucht nog schoon was en de sex.... nou ja toen werd een bit dus opgeslagen door een "1" of een "0" te schrijven op een stukje op de platter.
Echter dat neemt best wel veel ruimte in, zelfs met de staande (perpendicular) bitjes van Hitachi. Dus tegenwoordig wordt er een encoding toegepast waarbij er effectief meer dan 1 bitje staat op een fysieke plek.
Waar je dus vroeger een "1" naar een "0" veranderde, stond daar dus eigenlijk analoog het signaal "0.25" oid. (en van 0 naar 1 is dan dus ergens rond de 0.75)
Bij het opslaan van "00" op de plek waar "01" stond, op de huidige schijven, zal er dus niet "0, 0.25" staan, maar een waarde die bijna niet meer van "01" te onderscheiden is.
Je moet dan al erg veel redundantie in je file hebben zitten wil je er nog iets van kunnen maken. Maar tegenwoordig heeft vrijwel elk bestandsformaat (op .txt en .bmp na zeg maar) wel enige vorm van compressie in zich en dus is de redundantie er vrijwel uit.
De afbeelding in een .bmp file kun je als mens nog vrij makkelijk interpreteren, ookal is 90% van de data vernield, maar een Jpeg met 1% omgegooide bitjes is al vrijwel niet meer te reconstrueren. (met die 1% op de meest beroerde plekken en verspreid over de file)

Over sparse-files en het niet overschrijven wat je wel zou verwachten:
Als jij een file volschrijft met data, dan hoeft die file nog helemaal niet op de harde schijf te staan. Je OS zal de boel ook redelijk proberen te cachen, Best kans dat wanneer je die file dan weggooit, dat de cache dan geflusht wordt zonder ooit op een schijf te belanden.
En met sparse-files is het volgens mij nog wel zo dat je dat vrij expliciet moet aangeven bij het maken van de file, dat het een sparse-file betreft. Maar dat weet ik niet helemaal zeker.
In elk geval is het wel iets om rekening mee te houden.

Hoe dan ook, ik vind het flink ziek om dit soort malware te maken. Wat heb je er aan om dit soort troep te ontwikkelen om schade aan te brengen aan andermans zijn data? Ziekelijk gedrag gewoon.

Hoe meer data je vernield, hoe minder kans dat sporen naar de maker wijzen.

Gewoon formatteren duurt nog steeds lang maar dat komt (zover ik weet) alleen maar door de mede uitgevoerde schijfcontrole, je moet wel de quick-format gebruiken.

@ TD-er

Uiteraard maar SirDice had het over OVERSCHRIJVEN, dan denk ik aan willekeurige informatie plaatsen op de plaats van een ander file.
Dus zie ik het verschil niet tussen een file met nullen of enen overschrijven of een hele schijf maar het zal wel in die nullen zitten. Ik zie die nullen voorbeeld (kan voor mij ook 1 en zijn) maar het gaat juist om die nullen als ik SD zijn verhaal lees.

Het deleten van een file is niet gelijk aan overschrijven van de ruimte die dat file inneemt. Ik reageerde op dat overschrijf verhaal.

Correct, het gaat vooral om het met nullen overschrijven van een bestand. Stel dat je een bestand hebt van 1000 bytes (we gaan er even vanuit dat daar geen blok met nullen in zit). Die 1000 bytes staan netjes achter elkaar op schijf. Als je die gaat overschrijven met 1000 nullen zou je denken dat alles weg is. Maar omdat er niet 1000 nullen op schijf worden gezet maar alleen wat metadata (een paar bytes) overschrijf je dus maar een klein deel van het originele bestand. De rest van dat origineel staat dus nog op de schijf en zou terug te halen zijn.

Even voor de duidelijkheid, ik zeg niet dat Windows altijd sparse files gebruikt, ik zeg dat NTFS het ondersteunt. En dat je door een filesystem dat sparse files gebruikt niet altijd zeker bent dat je alles overschrijft als je een bestand met nullen overschrijft.

Om dat dus helemaal uit te sluiten kun je dus beter met willekeurige data overschrijven ipv met nullen.

Een minuut om een 1 TB schijf te formatteren?!
Heb je het mogelijk over snel-formatteren in plaats van volledig formatteren?

En, zoals eerder al vaker is aangegeven, formatteren onder XP en eerder is niet hetzelfde als onder Vista en later.
Zie bijvoorbeeld dit:
http://www.consumentenbond.nl/test/elektronica-communicatie/computers/laptops/extra/harde-schijf-wissen-stappenplan/
en Bitwipers bijdragen in deze thread:
http://www.security.nl/artikel/34402/1/%22Veel_priv%C3%A9gegevens_op_afgedankte_computers%22.html