Verdieping in encryptie - gebruik van verborgen containers

[High-Voltage2]

Hey all


Omdat er nog een groot gat in mijn kennis over encryptie zat, ben ik me daar nu wat in aan het verdiepen. Eén van de bronnen die ik hiervoor gebruik is de website van TrueCrypt. Gezien het open-source karakter lijkt me dit een betrouwbare bron.

Op dit moment ben ik bezig met het stukje over verborgen containers/volumes, meer bepaald over de manier waarop je ze kan ontdekken en hoe je ze dus verborgen moet houden. Er zijn een aantal punten die me niet geheel duidelijk zijn, graag zou ik wat duiding bij volgende punten hebben. Is er iemand die me dit nader (iets uitgebreider) wil/kan toelichten? Of zijn er over die punten misschien artikels te vinden?
Het gaat telkens over een encryptie container (file based) met daarin een verborgen encryptie container.

The file system in which you store a file-hosted TrueCrypt container has been defragmented and a copy of the TrueCrypt container (or of its fragment) remains in the free space on the host volume (in the defragmented file system).

De (omhullende) container moet niet per definitie aaneengesloten op de schijf staan (het kan dus gefragmenteerd zijn). Na een defragmentatie is het de bedoeling dat die container aaneengesloten is. Hierdoor is het echter mogelijk dat bepaalde delen van de container nog op de oude locatie staan. Deze oude locatie is nu gemarkeerd als "free space".
Ik begrijp niet helemaal hoe dit kan onthullen dat er in je omhullende container nog een verborgen container zit?

A file-hosted TrueCrypt container is stored in a journaling file system (such as NTFS). A copy of the TrueCrypt container (or of its fragment) may remain on the host volume.

Hierbij begrijp ik niet echt waarom het uitmaakt of het FS nu journaled is of niet... Worden die logboeken ergens opgeslagen? Ik meen dat die automatisch weg waren na het succesvol uitvoeren van de disk transacties?

A TrueCrypt volume resides on a device (or in a filesystem) that utilizes a wear-leveling mechanism (e.g. some USB flash drives). A copy of (a fragment of) the TrueCrypt volume may remain on the device.

Opnieuw ontstaat hier het probleem dat er ergens een oude versie is blijven rondslingeren, ditmaal door wearleveling.


Het valt mij op dat bij alle genoemde "problemen" er telkens een oude versie rondslingert (of een deel ervan). Als je deze versies vergelijkt kan je nagaan welke delen gewijzigd zijn. Als nu blijkt dat de omhullende container geen wijzigingen heeft ondergaan moet er dus wel een verborgen container zijn.
De vraag die hierbij dan naar boven komt: als je enkele wijzigen aanbrengt in de omhullende container kan je dan nog zien dat de wijzigingen die gebeurd zijn, niet van de betreffende bestanden zijn? Dus maw dat ondanks het wijzigen van de omhullende container toch nog aangetoond kan worden dat er een hidden container moet zijn?


Ik ben benieuwd naar jullie antwoord.
Alvast bedankt voor de antwoorden/uitleg/doorverwijzingen.


Mvg

H-V2

[jan99999]

Ik weet alleen dat alles wat je op de pc doet, dat er veel dingen achter blijven.

In het swap (in windows kun je bij afsluiten pc de swap laten verwijderen en bij booten opnieuw laten maken, dan zijn alle geevensj pas weg uit het swap), daarna zou je de hd moeten gaan wissen op de lege plekken. En dan nog is misschien nog niet alles weg.
Cleaner programma's gebruiken.
Ntfs gebruikt journaal op de file system, hier is dus ook veel mee terug te halen.

In linux kun je swap, geheugen, en harddisk ook wissen.

Enigste mogelijkheid is de hd volledig te encrypten, dan is de pc veilig indien hij uit staat, en niet op internet gaan. En een lang wachtwoord gebruiken.

En dan nog virussen en spyware die alles bij houden wat je doet.

Ik zou veel gaan lezen over dit, er zijn veel uitzonderingen, en fouten die later gevonden worden, waardoor het niet meer veilig is op de oude manier.

[Verwijderd]

...

[ Voor 100% gewijzigd door Verwijderd op 23-05-2018 15:43 ]

[High-Voltage2]

Verwijderd schreef op zaterdag 09 januari 2010 @ 00:05:
Voor wie wil je je data beschermen?

Virussen, huisgenoten, overheid ( forensische onderzoekers)?

Het is op dit moment louter een theoretische verdieping... Mijn Windows wachtwoordje is zat goed voor huisgenoten. Zij gaan toch geen Linux Live CD booten of de schijf in een andere PC hangen (wat overigens niet zo simpel is door de RAID opstelling).
Ik wil gewoon mijn kennis verbreden. De kans dat je ooit hidden containers nodig hebt is uiteraard klein, maar ik hou het graag compleet.

@jan99999: Veronderstel dat je een encryptie container op stick hebt met daarin een hidden container, dan zou het mogelijk zijn dat de hidden container ontdekt kan worden door bv de stick te defragmenteren (geen idee waarom je zoiets zou doen) of door het NTFS bestandssysteem of door het wear-leveling gedoe. De vraag is dus ook welke specifieke punten ervoor zorgen dat dat mogelijk is? Het enige gemeenschappelijke punt dat ik kan vaststellen is dat er telkens een oude of een stuk van een oude versie achter blijft. Hierdoor zie je dat er bitjes gewijzigd zijn terwijl de omhullende container eigenlijk geen wijzigingen bevat. Bijkomende vraag is dan ook: heb je dit probleem ook als je de buitenste container wijzigt waardoor de wijziging van de binnenste container kunnen toegeschreven worden aan wijziginen van de buitenste container.


Als je overigens hidden containers gebruikt, raad men aan om deze enkel maar te benaderen met een hidden OS. Om dit klaar te krijgen moet je eerst de hele file naar het hidden OS verplaatsen, aangezien je geen schrijfrechten hebt op lokale non-hidden containers. De vraag die hierbij komt is dan: waarom zou je überhaupt nog alles in een dubbel volume steken? Dan kan je de bestanden toch net zo goed "los" in het verborgen OS steken? Hoe krijg je anders ooit de data terug van je verborgen OS naar je gewone OS zonder dat er ineens bestandjes opduiken waar niets van terug te vinden is in de logs? Tenzij natuurlijk je hidden containers op stick staan die je dan benadert vanuit het verborgen OS.
Best complexe materie om zoiets "wachterdicht" te krijgen...

[MisterE]

ik weet niet of zon hidden container altijd helemaal achteraan staat? In theorie zou je dus het totale bestand kunnen monitoren op veranderingen. Ze zullen dan alleen vooraan en achteraan veranderen.

Volgens mij weet truecrypt zelf ook niet of er een tweede container is. Hij probeert iets te decoderen met je wachtwoord en kijkt of er wat zinnigs uitkomt.
Als je trouwens je eerste container opent en volschrijft dan schrijf je vrolijk over je tweede container heen.

Volgens mij heb ik toen op de site van truecrypt wel dingen zien staan over veranderingen monitoren in de FAQ.

[High-Voltage2]

MisterE schreef op maandag 11 januari 2010 @ 01:04:
Volgens mij weet truecrypt zelf ook niet of er een tweede container is. Hij probeert iets te decoderen met je wachtwoord en kijkt of er wat zinnigs uitkomt.

Klopt.

Als je trouwens je eerste container opent en volschrijft dan schrijf je vrolijk over je tweede container heen.

Gelukkig bestaan er opties om dat te voorkomen (maar dan kan je natuurlijk je hele container niet meer volschrijven).

Volgens mij heb ik toen op de site van truecrypt wel dingen zien staan over veranderingen monitoren in de FAQ.

Dan zal ik nog wat verder lezen, heb toch nog het een en ander te lezen. Ik was gewoon op die onduidelijkheden gestoten.

[GemengdeDrop]

High-Voltage2 schreef op woensdag 06 januari 2010 @ 13:29:
Ik begrijp niet helemaal hoe dit kan onthullen dat er in je omhullende container nog een verborgen container zit?

Wel, als je de verborgen container gebruikt kan het dus zijn dat van een klein stukje van die container er twee versies op je HD staan, eentje voor de defragmentatie en eentje na. Als kan aangetoond worden dat dat gedeelte dat 'niet ingebruik' behoord te zijn wél is veranderd (ookal weet men niet wat die verandering is) dan kan men het gebruik van een verborgen volume aantonen en heb je dus geen plausible deniability meer.

Hierbij begrijp ik niet echt waarom het uitmaakt of het FS nu journaled is of niet... Worden die logboeken ergens opgeslagen? Ik meen dat die automatisch weg waren na het succesvol uitvoeren van de disk transacties?

Het gevaar hierin is eigenlijk hetzelfde als bij defragmentatie. Er kan ergens op je hd een kopie van een stukje van de container achterblijven.

Als nu blijkt dat de omhullende container geen wijzigingen heeft ondergaan moet er dus wel een verborgen container zijn.

Wel, niet 100% correct omdat het niet letterlijk te bewijzen is, maar het is inderdaad niet erg aannemelijk dat je een ~100 gig container hebt waar je niks mee doet. Dus voor plausible deniability moet je gewoon regelmatig in je outer container werken, uiteraard dan ook het wachtwoord ingeven voor het binnenste container zodat die beschermd is. IMHO is dat opzichzelf al een probleem voor de deniability, maargoed.

De vraag die hierbij dan naar boven komt: als je enkele wijzigen aanbrengt in de omhullende container kan je dan nog zien dat de wijzigingen die gebeurd zijn, niet van de betreffende bestanden zijn? Dus maw dat ondanks het wijzigen van de omhullende container toch nog aangetoond kan worden dat er een hidden container moet zijn?

Edit: bovenstaande quote verkeerd gelezen. Wat jij bedoelt is als je naar je inner volume schrijft en dan ziet men dat het outer niet veranderd is? Dat betekend dus dat (1): ze jouw ruwe containers op veschillende tijdstippen hebben kunnen bekijken (en dit is altijd foute boel-->geen deniability). en (2): je laat ze het outer volume lezen. Je hebt ALLEEN plausible deniability tot aan het moment dat de aanvaller je schijf leest (gecodeerd of ongecodeerd). Alle handelingen die je daarna doet kunnen je plausible deniability om zeep helpen. Dus daarna mag je nooit meer naar het volume schrijven.
En daarnaast, soms kan het ook door te kijken naar wat je je outer volume schrijft. In het geval dat je het hidden volume beschermd tegen beschadiging door je password daarvoor in te voeren, kan in sommige gevallen aannemelijk gemaakt worden dat er een hidden volume is. Indien bijvoorbeeld normaal gesproken het filesystem van de outer container iets weg zou schrijven naar dat gedeelte van de schijf waar het hidden volume zit, maar dit niet lukt, kan wellicht aannemelijk gemaakt worden dat daar een hidden volume zit. Maar dat is nogal afhankelijk van het gekozen filesystem. Met FAT32 ben je redelijk safe tot het moment dat je outer volume zo vol begint te raken dat het filesystem er voor kiest om bestands fragmenten van het outer volume over je inner volume heen te schrijven. Hoe het voor NTFS zit weet ik niet precies. Die heeft ingewikkelder soorten tabellen.

Nog even een persoonlijke noot hier, het goed volhouden van plausible deniability kan knap lastig zijn. Je moet je ook echt afvragen of je dat wel nodig hebt. Want ALS je denkt dat je het nodig hebt dan moet je het ook goed doen. Er is geen tussenweg. En je moet bedenken dat het gebruik van truecrypt je ook in de problemen kan brengen. Je kan namelijk ook niet aantonen dat je GEEN hidden volume hebt. Nu denk ik niet dat de NL wet toelaat dat je daarvoor gepakt wordt, maar voordat je dat traject doorbent zit je aardig in de problemen.
Dat plausible deniability spul is eigenlijk vooral bedoeld voor mensen die hun leven niet zeker zijn. En dan nog is het de vraag of het lukt. Het is zo verschrikkelijk moeilijk om geen data te lekken, vooral onder windows. Wat op de fora van truecrypt ook steeds aangeraden word is dat je een inventarisatie moet maken van mogelijke bedreigingen en aan de hand daarvan bepalen hoeveel pijn en moeite het je waard is om een bepaalde soort crypto toe te passen.

IMHO is plausible deniability absoluut overkill voor een paar illegale mp3'tjes om maar eens wat te noemen.

Crypto zelf is niet zo moeilijk. Maar om crypto op een goede manier te gebruiken zonder stiekem toch iets te lekken, dat is wel moeilijk. Succes!

[ Voor 7% gewijzigd door GemengdeDrop op 11-01-2010 10:16 ]

[High-Voltage2]

GemengdeDrop schreef op maandag 11 januari 2010 @ 10:11:
Als kan aangetoond worden dat dat gedeelte dat 'niet ingebruik' behoord te zijn wél is veranderd (ookal weet men niet wat die verandering is) dan kan men het gebruik van een verborgen volume aantonen en heb je dus geen plausible deniability meer.

Wat bedoel je juist met "dat gedeelte dat niet in gebruik behoord te zijn"? Als dat een oude versie is die is blijven staan door de defrag dan zal daar niets meer aan wijzigen. Op zich klinkt het allemaal logisch, maar het zijn gewoon die detail puntjes waar ik telkens over struikel. Je zou eventueel kunnen aantonen dat een bepaald bitpatroon voor en na de defrag overeenkomt. Maw dat het bestand verplaatst is. Als je dit geldig kan aantonen, dan kun je eventuele wijzigingen in het bitpatroon toeschrijven aan een verborgen volume als er geen wijzigingen zijn gebeurd aan de buitenste container. Dit kan enkel maar op voorwaarde dat je twee bitpatronen kan matchen. Bv doordat ze 90% gelijk zijn en die overige 10% is dan toe te schrijven aan de wijziging. Maar volgens mij is dit simpel op te lossen door gewoon een wijziging in je buitenste container aan te brengen. Hierdoor kan je de wijziging van het bitpatroon toeschrijven aan de gebeurde wijziging van de outer container.

Dus voor plausible deniability moet je gewoon regelmatig in je outer container werken, uiteraard dan ook het wachtwoord ingeven voor het binnenste container zodat die beschermd is.

Lijkt me zeer logisch ja. Op die manier kan je alle wijzigingen aan het bitpatroon toeschrijven aan wijzigingen in het buitenste volume.

IMHO is dat opzichzelf al een probleem voor de deniability, maargoed.

Is inderdaad een gevaar met keyloggers etc...

Edit: bovenstaande quote verkeerd gelezen. Wat jij bedoelt is als je naar je inner volume schrijft en dan ziet men dat het outer niet veranderd is? Dat betekend dus dat (1): ze jouw ruwe containers op veschillende tijdstippen hebben kunnen bekijken (en dit is altijd foute boel-->geen deniability). en (2): je laat ze het outer volume lezen. Je hebt ALLEEN plausible deniability tot aan het moment dat de aanvaller je schijf leest (gecodeerd of ongecodeerd). Alle handelingen die je daarna doet kunnen je plausible deniability om zeep helpen. Dus daarna mag je nooit meer naar het volume schrijven.

Uiteraard, want als één keer een mapping gemaakt is tussen je bestanden en het bitpatroon kan een verandering in het bitpatroon verraden dat er een hidden container bestaat. Doch vraag ik mij dan af of je dit niet kan oplossen door ook nog een verandering aan te brengen in je buitenste container. Uiteraard zullen die veranderingen dan in relatie moeten zijn. Twintig MB wijzigen in het hidden volume en maar vijf bytes in het outer volume is moeilijk goed te praten.
Het grote gevaar zit dus eigenlijk in het feit dat men op verschillende ogenblikken een mapping doet van de zichtbare bestanden en het bitpatroon. Het begint me duidelijk te worden

En daarnaast, soms kan het ook door te kijken naar wat je je outer volume schrijft. In het geval dat je het hidden volume beschermd tegen beschadiging door je password daarvoor in te voeren, kan in sommige gevallen aannemelijk gemaakt worden dat er een hidden volume is.

Als er iemand meekijkt terwijl je volume gemount is, is nooit goed. Het is natuurlijk niet de bedoeling dat je je hidden volume gaat beschermen tegen overschrijven op het moment dat je "aangevallen" wordt. Op die momenten moet je gewoon niet schrijven... En als je dan toch gaat schrijven (om wat reden ook), tja dan zal het beter zijn dat je volume overschreven wordt dan dat het bekend wordt. Anders zou je immers geen hidden volume nodig hebben.

Nog even een persoonlijke noot hier, het goed volhouden van plausible deniability kan knap lastig zijn. Je moet je ook echt afvragen of je dat wel nodig hebt. Want ALS je denkt dat je het nodig hebt dan moet je het ook goed doen. Er is geen tussenweg. En je moet bedenken dat het gebruik van truecrypt je ook in de problemen kan brengen. Je kan namelijk ook niet aantonen dat je GEEN hidden volume hebt. Nu denk ik niet dat de NL wet toelaat dat je daarvoor gepakt wordt, maar voordat je dat traject doorbent zit je aardig in de problemen.
Dat plausible deniability spul is eigenlijk vooral bedoeld voor mensen die hun leven niet zeker zijn. En dan nog is het de vraag of het lukt. Het is zo verschrikkelijk moeilijk om geen data te lekken, vooral onder windows. Wat op de fora van truecrypt ook steeds aangeraden word is dat je een inventarisatie moet maken van mogelijke bedreigingen en aan de hand daarvan bepalen hoeveel pijn en moeite het je waard is om een bepaalde soort crypto toe te passen.

IMHO is plausible deniability absoluut overkill voor een paar illegale mp3'tjes om maar eens wat te noemen.

Crypto zelf is niet zo moeilijk. Maar om crypto op een goede manier te gebruiken zonder stiekem toch iets te lekken, dat is wel moeilijk. Succes!

True, je hebt het puur technische encrypten, maar daarnaast (en dat is waarschijnlijk veel belangrijker) het psychologische aspect. Je moet goed opletten wat je zegt, hoe je handelt etc etc... Technisch gezien zal het waarschijnlijk wel waterdicht zijn, maar je bent zelf de zwakke schakel dan.

Thanks voor je antwoorden

[GemengdeDrop]

High-Voltage2 schreef op maandag 11 januari 2010 @ 12:57:
[...]

Wat bedoel je juist met "dat gedeelte dat niet in gebruik behoord te zijn"? Als dat een oude versie is die is blijven staan door de defrag dan zal daar niets meer aan wijzigen.

Het is zo dat het hidden volume ergens verborgen wordt in de vrije ruimte van het outer volume. De vrije ruimte van het outer volume veranderd normaal gesproken nooit, tenzij er echt een bestand in het outer volume naar toe geschreven wordt. Veranderd het dan toch terwijl het op dat moment vrije ruimte is, dan kan worden aangetoond (of liever: aannemelijk worden gemaakt) dat daar in die vrije ruimte een hidden volume verborgen zit. Een manier om dat te doen is dus het verkrijgen van twee snapshots van jouw container, eentje voor en eentje na defragmentatie/wear levelling, you name it. Het punt met PD is dat men er vanuit gaat dat je het outer password MOET vrijgeven en dat het outer volume dus toegankelijk is. Dat is juist hoe PD ontstaat, je kan die hele hoop random zooi 'verklaren' doordat truecrypt standaard random data schrijft in de vrije ruimte van je outer volume. Daarom is niet te zeggen of daar nog een hidden volume in zit. Maar als men kan zien dat op een plek van de container die niet in gebruik hoort te zijn (omdat het filesystem van het outer volume zegt dat daar geen bestanden staan) er wel iets veranderd ben je de sjaak.
Vanaf het moment dat iemand je data heeft kunnen bekijken moet je het volume laten voor wat het is. Krijgen ze het na die tijd voor elkaar om het nog een keer te zien (waarschijnlijk wel) dan ben je je mogelijkheid tot PD kwijt. De enige manier om dan nog verder te gaan is een compleet nieuw volume aan te maken, terwijl je je oude volume op een (veilige!) computer mount als readonly en dan de data kopieert van je oude naar je nieuwe volume. Gebruik ik geen geval je oude volume om daar nog veranderingen in aan te brengen. Zelfs het mounten kan al tricky zijn omdat filesystems van alles en nog wat loggen. De lastaccess attributen bijvoorbeeld kan je bijna niet van voorkomen dat ze veranderen. Met NTFS is dat heel erg, zelfs met FAT32 is het nauwelijks te doen.

Het punt dat ik wil maken, truecrypt helpt je totaan de huiszoeking/diefstal/inbraak. Daarna moet je overnieuw beginnen. Ook als iemand physieke toegang heeft tot je computer is het einde verhaal.

Lijkt me zeer logisch ja. Op die manier kan je alle wijzigingen aan het bitpatroon toeschrijven aan wijzigingen in het buitenste volume.

Je vergeet dat die wijzigingen dan ook nog op de juiste sectors van dat volume moeten plaatsvinden. Als ze vinden dat er geen enkel bestand zit in het outer volume op de plek waar de wijzing zit dan is het ook einde verhaal. In de praktijk kan je dit dus gewoon niet voorkomen. Daarom zeg ik: het werkt totaan de eerste keer dat ze enige data (gecrypt of niet gecrypt) lezen. Daarna niet meer. PD is gewoon heel erg moeilijk

Is inderdaad een gevaar met keyloggers etc...

Ik doelde meer op het feit dat het niet normaal is voor filesystems om spontaan niet naar een bepaald gebied aan het einde van de schijf te schrijven als de schijf bijna vol is. Normaal horen daar dan wel wat fragmenten staan, maar als je hidden volumes gebruikt kan dat dus niet. --> alweer geen PD

Doch vraag ik mij dan af of je dit niet kan oplossen door ook nog een verandering aan te brengen in je buitenste container.

Het helpt een beetje, maar het is absoluut niet afdoende. Zie het hele verhaal hierboven.

Het grote gevaar zit dus eigenlijk in het feit dat men op verschillende ogenblikken een mapping doet van de zichtbare bestanden en het bitpatroon. Het begint me duidelijk te worden

Sterker nog, de bestanden hoeven niet eens echt zichtbaar te zijn. Het gaat immers om de aanemelijke ontkenning, dat kan je alleen maar doen door ze in elke situatie het wachtwoord van het outer volume te geven. Dus die bestanden gaan zowieso zichtbaar zijn. Waarom anders PD gebruiken als je het toch niet van plan bent echt uit te spelen? Hoewel dit meer een issue is in rechtsgebieden waarin je verplicht bent je wachtwoord af te staan. In NL kan je je in theorie beroepen op zwijgerecht, Maar soms kan je maar beter gewoon je PD uitspelen, dat gaat sneller. Hoop je althans. En dan moet het ook nog goed werken (doet het niet)

Als er iemand meekijkt terwijl je volume gemount is, is nooit goed. Het is natuurlijk niet de bedoeling dat je je hidden volume gaat beschermen tegen overschrijven op het moment dat je "aangevallen" wordt. Op die momenten moet je gewoon niet schrijven... En als je dan toch gaat schrijven (om wat reden ook), tja dan zal het beter zijn dat je volume overschreven wordt dan dat het bekend wordt. Anders zou je immers geen hidden volume nodig hebben.

Niet alleen op het moment DAT je aangevallen wordt, maar daarna nooit weer. Je kan opzich een geheel nieuwe container aanmaken, maar als je PD echt nodig bent mag je er ook wel vanuit gaan dat na de eerste 'aanval' of ondervraging/whatever je computersysteem niet meer veilig is. En overschrijven moet je nooit doen nadat je ondervraagd bent. Dan loop je het risico gepakt te worden op het vernietigen van bewijslast. Het risico, want ze moeten dan wel eerst bewijzen dat het er in de eerste plaats een volume geweest was, maar als je wilt overschrijven heb je eigenlijk je PD aan de kant gezet. PD kan je maar op één manier doen: heel nauwkeurig uitspelen.

True, je hebt het puur technische encrypten, maar daarnaast (en dat is waarschijnlijk veel belangrijker) het psychologische aspect. Je moet goed opletten wat je zegt, hoe je handelt etc etc... Technisch gezien zal het waarschijnlijk wel waterdicht zijn, maar je bent zelf de zwakke schakel dan.

Ja, dat, maar het is ook technisch gewoon niet in orde. Het enige moment waarop PD gaat werken is volgensmij:

* niemand heeft ooit iets van je (ruwe) data gezien
* niemand heeft ooit aan je apparatuur gezeten
* je gebruikt system encryption met een hidden operating system
(anders lek je toch informatie naar alle kanten)
* je gebruikt geen internet of externe media in je hidden operating system
* In het outer volume staat iets dat het volume zelf verklaart (quasi vertrouwelijke informatie, die af en toe veranderd)
* het outer volume is slechts voor een klein deel gevuld.

typisch FAIL scenario:
je gebruikt MSN in je hidden os. Packet sniffers op de lijn zeggen dat je een schermafbeelding ontvangen hebt. Die schermafbeelding is niet terug te vinden in je outer volume ---> je hebt een hidden volume.

ik noem maar wat. PD is echt niet te doen in de praktijk. Dan moet je echt een superduper 007 spy zijn die gek genoeg door de vijand op vrije voeten wordt gesteld als hij zijn PD gebruikt. Nog een reden waarom ik denk dat PD niet werkt. De mensen die PD echt nodig hebben kunnen ze wel overtuigen met 'andere middelen' . XKCD verbeeld dit mooi trouwens: http://xkcd.com/538/

[High-Voltage2]

@GemengdeDrop: Hartelijk dank voor je uitleg
Ik zag twee keer over het hoofd dat je je bestanden via het FS kan mappen aan het bitpatroon. Als inderdaad blijkt dat bepaalde delen -die volgens het FS niet in gebruik zijn- toch regelmatig wijzigen, dan heb je natuurlijk een probleem.