Short introduction
Steganography, if anyone does not remember, is the hiding of information in any containers. For example, in pictures (discussed и ). You can also hide data in the service tables of the file system (it was written about this ), and even . Unfortunately, all these methods have one drawback: in order to imperceptibly "insert" information into the container, tricky algorithms are needed that take into account the peculiarities of the container's internal structure. Yes, and with the resistance of the container to manipulation, there are problems: for example, if you slightly edit the picture, the hidden information is lost.
Is it possible to somehow do without cunning algorithms and subtle manipulations with data, and at the same time still ensure the container's performance and an acceptable level of security of hidden data? Looking ahead, I will say - yes, you can! And I will even offer a utility.
Bloody Method Details
The basic idea is as simple as a blow to the forehead with a club: there are areas on the disk that the operating system never writes to (or writes to on rare occasions). In order not to have to search for these areas with cunning algorithms, we will use redundancy - that is, we will duplicate our hidden information many, many times over 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, part of the secret data will be preserved and can be extracted, and multiple duplication will help us compose the original whole from the pieces.
The advantage of this method is obvious: we do not depend on the file format, or even on the type of file system used.
The disadvantages are also obvious:
- Secret data can only be changed by completely overwriting the entire disk, with the subsequent re-creation of the content visible to the user. In this case, you cannot use software that recreates a disk from an image: it will also recreate the previous secret data.
- The larger the amount of secret data, the greater the likelihood of losing some of the information.
- Retrieving data from disk can take a long time. From several minutes to several days (modern disks are large).
Now let's move on to particulars.
It is clear that if you simply smear secret data all over the disk, then they will be hidden only from the naked eye. If you arm your eyes with, say, a disk editor, then the data will appear in all its glory. Therefore, it would be nice to encrypt the data so that it does not shine. We will encrypt simply, but with taste: according to the aes256-cbc algorithm. We will ask the user for the encryption key, let him come up with a good password.
The next question is how do we distinguish “correct” data from corrupted ones. Here the checksum will help us, but not simple, but SHA1. And what? It's good enough for git, so it's good enough for us. Resolved: we supply each saved piece of information with a checksum, and if after decryption it matches, 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 are left. The total length will be useful to us when processing the last fragment, so as not to write extra data (that is, padding). Well, since we still have a header pecking, then add the name of the secret file there. It will come in handy after decryption, so as not to guess how to open it.
Checking the method in practice
To check, let's take the most common media - a flash drive. I found an old one for 1 GB, which is quite suitable for experiments. If you, like me, came up with the idea not to bathe with physical media, but to test it on a file - a disk image, then I’ll say right away: it won’t work. When formatting such a "disk", Linux creates the file again, and all unused sectors will be filled with zeros.
As a machine with Linux, unfortunately, I had to use the weather station lying on the balcony on the Raspberry Pi 3. There is not a lot of memory there, so we will not hide large files. We will limit ourselves to a maximum size of 10 megabytes. Too small files also make no sense to hide: the utility writes data to disk in clusters of 4 KB. Therefore, from below we will limit ourselves to a file of 3 kb - it fits into one such cluster.
We will mock the flash drive in stages, checking after each stage whether the hidden information is read:
- Fast formatting in FAT16 format with a cluster size of 16 KB. This is what Windows 7 suggests doing with a flash drive that lacks a file system.
- Filling the flash drive with all sorts of garbage by 50%.
- Filling the flash drive with all sorts of garbage by 100%.
- "Long" formatting in FAT16 format (overwriting everything).
The first two tests, as expected, ended in complete victory: the utility was able to successfully extract 10 megabytes of secret data from a flash drive. But after the flash drive was filled with 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 is not enough here, and there are obviously duplicates among these clusters. Even 1 megabyte cannot be restored in this way. But on the other hand, we can guarantee that we will recover 3 kilobytes of secret data from a flash drive even after it is formatted and written to capacity. However, experiments show that it is quite possible to extract a 120 kilobyte file from such a flash drive.
The last test, unfortunately, showed that the entire flash drive was overwritten:
$ 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 - the file system. By the way, it came from the factory with exactly this formatting, so we don’t do anything suspicious.
It is quite expected that the available space on the flash drive has decreased slightly.
It is also quite expected that 10 megabytes still could not be hidden on a completely clogged disk. But now the number of successfully decrypted 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 about the last, 4th check, this time is joyful: the complete formatting of such a flash drive did not lead to the destruction of all information! 120 kilobytes of secret data perfectly fit into unused space.
Summary table for testing:
A little theorizing: about free space and unused sectors
If you have ever partitioned a hard disk, you may have noticed that it is not always possible to allocate all the free space on the disk. The first section always starts with some indentation (usually 1 megabyte, or 2048 sectors). Behind the last section, too, it happens that there is a small “tail” of unused sectors. And sometimes there are gaps between sections, although rarely.
In other words, there are sectors on the disk that cannot be accessed during normal work with the disk, but data can be written to these sectors! And that means reading it too. Adjusted for the fact that there is also a partition table and bootloader code, which are located in the empty area at the beginning of the disk.
Let's digress for a while from the sections and look at the disk from a height, so to speak, of a bird's eye view. Here we have an empty partition on the disk. Let's create a file system in it. Is it possible to say that some sectors on the disk remained intact?
And-and-and - drumroll! The answer will almost always be yes! Indeed, in most cases, the creation of a file system comes down to the fact that only a few blocks of service information are written to the disk, and otherwise the contents of the partition do not change.
And also - purely empirically - it can be assumed that the file system cannot always take up all the space allotted to it until the last sector. For example, a FAT16 file system with a cluster size of 64 kilobytes obviously cannot completely occupy a partition with a size that is not a multiple of 64 kilobytes. At the end of such a section, there will have to be a “tail” of several sectors, inaccessible for storing user data. However, this assumption could not be experimentally confirmed.
So, to maximize the space available for the steganogram, you need to use a file system with a larger cluster size. You can still create a partition, even if it is not necessary (on a flash drive, for example). It is not necessary to create empty sections or leave unallocated areas - this will attract the attention of interested citizens.
Utility for experiments
The source code of the utility can be felt
To build, you need Qt version 5.0 and above and OpenSSL. If something is not going, you may have to correct the steganodisk.pro file.
You can change the cluster size from 4 KB to, say, 512 bytes (in secretfile.h). At the same time, the cost 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 rights, and with caution. There will be no questions before overwriting the specified file or device!
Enjoy.
Source: habr.com