2

Suppose, I have 1 disk partition (previously filled with random data) and create some file system on it (NTFS, FAT, EXT2, etc). I am going to keep some files here (i.e. visible files).

Then i create a few loobpack devices with different offsets and make some file systems on them.

The question is: can an observer determine that these hidden containers exist by the presence of the metafiles/system info of the original file system?

I've read:

  • FAT keeps system data in the begining and the end of partition,
  • NTFS keeps system data in the begining and MFT mirror in the middle of the partition.
  • EXT2 keeps superblocks in each block group, and there is a lot of them on the disk.

When i fill hidden loopback devices with some data this outer file system's metadata may be erased, right? Like in the case of NTFS MFT mirror in the middle of the partition may be erased. In the case of EXT2 superblocks may be eraised. And this will look suspicious.

How can we avoid it?

onetuser
  • 281
  • 2
  • 6
  • 1
    This sounds like a questionable approach. Why not just use hidden TrueCrypt volumes that have a provable security model? – Polynomial May 13 '13 at 11:44
  • I do not like that it has no more than one hidden container, and it is used mostly because of it. I asked it here http://security.stackexchange.com/questions/34684/truly-deniable-encryption – onetuser May 13 '13 at 11:55

1 Answers1

4

Data on hard disk has structure. That's a problem for you:

  • If your hidden containers don't use encryption, then inspecting the partition contents directly will show your hidden files. Such inspection is customary in forensics analysis, if only to recover parts of old files which have been deleted.

  • If your hidden containers use encryption, then the corresponding sectors will look random, and this will be suspicious, because "normal" filesystems don't store random data in unused sectors. The partition contents inspection expects finding some old file parts with detectable structure, and your container will show up as a statistical anomaly.

The "hidden volumes" of TrueCrypt solve that problem by being applied on a volume which is explicitly using TrueCrypt, which applies encryption on the whole partition. This allows the hidden volume to disappear into the randomish background.

As for your specific question, this is an allocation issue. If you never modify the outer filesystem, then you could do the following:

  1. Create a sequence of 512 random bytes.

  2. Fill the target partition with copies of that sequence.

  3. Create the "visible" filesystem on it and put your few dummy files.

  4. Unmount the visible filesystem, and scan again the partition: every 512-byte sector which still contains your random sequence is "untouched". You can use these sectors for your hidden container. All you need to do is to find the longest contiguous sequences of untouched sectors and mount them as loopback.

Of course, since the outer filesystem is completely unaware of your devious loopback usage, any modification to that outer filesystem may use some of your sectors: from your point of view, these sectors are for your hidden container, but from the point of view of the outer filesystem, they are free -- and that's by design. Your hidden containers are "hidden" only because nothing in the outer filesystem is aware of them.

(But this still does not solve the issues with statistical analysis, as explained above.)

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • Yes, I said "previously filled with random data", so encrypted hidden containers wont be detectable. In your example with 512 random bytes repeated on the partition, it will be strange if attacker discovers bytes that do not match this pattern and do not relate to the visible fs. So you cannot mask hidden containers in this case. It's more reliable to fill whole partition with random & learn fs's structure to find wich gap can be used for hidden containers. So, the question is if i miss smth, and what fs is better for this purpose. FAT32 seems good but it is old and hence suspicious choice. – onetuser May 14 '13 at 09:22
  • Maybe it is possible to loopback devices "inside" of outer fs, so only free space from the point of view of the original fs will be used, and fs's system data wont be touched? How this can be done? – onetuser May 14 '13 at 09:30