Steganography past files: hiding data right in the sectors

Small preface

Steganography, if anyone does not remember, is hiding information in any containers. For example, in pictures (discussed here and here ). You can also hide data in the service tables of the file system (this was written here ), and even in the service packets of the TCP protocol . Unfortunately, all these methods have one drawback: to quietly “interstate” information into a container, we need clever algorithms that take into account the peculiarities of the container’s internal structure. Yes, and with the stability of the container to manipulate problems: for example, if a little edit the picture, the hidden information is lost.

Is it possible to somehow manage without tricky algorithms and subtle manipulations of data, while still ensuring the operability of the container and an acceptable level of security of hidden data? Looking ahead to say - yes, you can! And even offer a utility.

Bloody details of the method

The basic idea is simple, like a blow to the forehead with a cudgel: there are areas on the disk to which the operating system never writes (or writes in rare cases). In order not to look for these areas with clever algorithms, we will use redundancy - that is, many times we will duplicate our hidden information across all sectors of the disk. Then, right on top of all this splendor, you can create the necessary partitions, format file systems, write files and install OSes - anyway, some of the secret data is saved and retrieved, and multiple duplication helps us to make up the original whole of the pieces.

The advantage of this method is obvious: we are not dependent on the file format, or even on the type of file system used.
')
The disadvantages, too, I think, are obvious:

• The secret data can only be changed by completely overwriting the entire disk, and then recreating the content visible to the user. In this case, you can not use the software that recreates the disk from the image: it will recreate the previous secret data.
• The greater the amount of secret data, the greater the likelihood of loss of information.
• Extracting data from a disk can take a long time. From several minutes to several days (modern discs are large).

We now turn to the particulars.

It is clear that if you just blur the secret data on the entire disk, then they will be hidden only from the naked eye. If we arm our eyes with, say, a disk editor, then the data will appear in all its glory. Therefore, the data would be nice to encrypt, so as not to shine. We will encrypt simply, but with taste: according to the algorithm aes256-cbc. Encryption key ask the user, let him come up with a good password.

The next question is how do we distinguish the “correct” data from the corrupted ones. Here the checksum will help us, but not simple, but SHA1. Why? For git, it is good enough, which means it will do for us. It was decided: we supply each saved piece of information with a checksum, and if, after decryption, it coincided, then the decryption was successful.

You will also need the fragment number and the total length of the secret data. Fragment number - to keep track of which pieces we have already deciphered, and which remained. The total length is useful to us when processing the last fragment, in order not to write extra data (that is, padding). Well, since we still have a header, then add the name of the secret file. It will come in handy after decryption, so as not to guess what to open it with.

We check the method in practice

For verification, take the most common media - a flash drive. I found an old 1 GB, which is quite suitable for experiments. If you, like me, had the idea not to bathe with physical media, but to test on a file - a disk image, then I will immediately say: it will not work. When formatting such a “disk”, Linux creates the file again, and all unused sectors will be filled with zeros.

As a Linux machine, unfortunately, I had to use the weather station on the balcony on the Raspberry Pi 3. There is little memory there, so we will not hide large files. We confine ourselves to a maximum size of 10 megabytes. Too small files also make no sense: the utility writes data to the disk in clusters of 4 KB each. Therefore, from below, we restrict ourselves to a 3 kb file — it fits into one such cluster.

We will mock the flash drive in stages, checking after each stage whether the hidden information is read:

1. Fast formatting in FAT16 format with a cluster size of 16 kb. This is what Windows 7 offers to do with a flash drive, on which the file system is missing.
2. Filling a flash drive with rubbish of 50%.
3. Filling a flash drive with 100% garbage.
4. "Long" formatting in FAT16 format (with overwriting everything).

The first two tests quite expectedly ended in complete victory: the utility was able to successfully extract 10 megabytes of secret data from the flash drive. But after the flash drive scored files to the eyeballs, a failure occurred:

Total clusters read: 250752, decrypted: 158
ERROR: cannot write incomplete secretFile

As you can see, only 158 clusters were successfully decrypted (632 kilobytes of raw data, which gives 636424 bytes of payload). It is clear that 10 megabytes cannot be found here, and there are obviously duplicates among these clusters. Even 1 megabyte cannot be restored this way. But you can guarantee that we will restore the 3 kilobytes of secret data from the flash drive even after it is formatted and recorded to the string. However, experiments show that it is quite possible to extract a file with a length of 120 kilobytes from such a flash drive.

The last test, unfortunately, showed that the flash drive was overwritten all:

$ sudo ./steganodisk -p password /dev/sda
Device size: 250752 clusters
250700 99%
Total clusters read: 250752, decrypted: 0
ERROR: cannot write incomplete secretFile


Not a single cluster has been preserved ... Sad but not tragic! Let's try to create a partition on the flash drive before formatting, and already in it - a file system. By the way, she came from the factory with this formatting, so we do not do anything suspicious.
It is expected that the available space on the flash drive has slightly decreased.

It is also expected that 10 megabytes still could not be hidden on a fully clogged drive. But now the number of successfully decoded clusters has more than doubled!

Total clusters read: 250752, decrypted: 405

A megabyte, unfortunately, cannot be assembled from pieces, but two hundred kilobytes is easy.

Well, the news of the last, 4th test, this time joyful: the full formatting of such a flash drive did not lead to the destruction of all the information! 120 kilobytes of secret data perfectly fit into the unused space.

Testing Summary:

A bit of theorizing: on free space and unused sectors

If you once divided your hard disk into partitions, you might notice that it is not always possible to allocate all free space on the disk. The first section always begins with some indentation (usually 1 megabyte, or 2048 sectors). Behind the last section, too, sometimes, there remains a small “tail” of unused sectors. Yes, and sometimes between the sections remain gaps, although rarely.

In other words, there are sectors on the disk that cannot be accessed during normal work with the disk, but you can write data to these sectors! So, read it too. Adjusted for the fact that there is also a partition table and loader code, which are located in an empty area at the beginning of the disk.

Let us distract for a while from the sections and look at the disk from a height, so to speak, a bird's flight. Here we have an empty partition on the disk. Create a file system in it. Is it possible to say that some sectors on the disk were left unclogged?

And-and-and - drum roll! The answer will almost always be - yes! Indeed, in most cases, the creation of a file system is reduced to the fact that only a few blocks of service information are written to the disk, and the rest of the contents of the section does not change.

And also - purely empirically - it can be assumed that the file system may not always take up all the space allocated to it to the last sector. For example, a FAT16 file system with a cluster size of 64 kilobytes obviously cannot fully occupy a partition with a size that is not a multiple of 64 kilobytes. At the end of this section, there will have to be a “tail” in several sectors, unavailable for storing user data. However, experimentally this assumption could not be confirmed.

So, to maximize the space available under the steganogram, you need to use a file system with a larger cluster size. You can still create a partition, even if it is optional (on a flash drive, for example). There is no need to create empty sections or leave unallocated areas - this will attract the attention of interested citizens.

Experiment Utility

The utility sources can be found here.

The build will require Qt version 5.0 and above and OpenSSL. If something is not going to - you may have to correct the file steganodisk.pro.

You can change the cluster size from 4 KB to, say, 512 bytes (in secretfile.h). At the same time, the overhead of service information will increase: the header and checksum occupy a fixed 68 bytes.

You need to run the utility, of course, with root user privileges, and with caution. There will be no questions before overwriting the specified file or device!

Enjoy.