Hiding Between Partitions

One of the challenges of digital forensics is the number of places that someone who knows what they are doing could hide data they didn’t want to be found. Fortunately, the vast majority of cases don’t fall into that category. Most of the time, this will be a case of files sitting in the Documents folder where they belong or maybe in the Recycle Bin or Trash, depending on the system you are looking at. This requires some experience with the different operating systems to know where to look for documents.
Of course, if someone wanted to be a little sneaky, they may create a folder somewhere else on the drive and hide their illicit documents, like their collection of Justin Beiber MP3s, in that folder. This would, of course, be outside of the standard document repositories for users. You might, for example, stuff a folder into the Windows directory structure. This would require administrative rights to the drive but on most personal desktop systems, the user would have those rights. However, you are not restricted to the filesystem itself. If you know what you are doing a little bit, you can make use of the entire drive to store data.
Let’s say that you were to create a little slack space on your drive where you didn’t have a partition defined. Remember that a partition is a collection of consecutive blocks or sectors on a drive. A partition can then be formatted with a filesystem so it can then be used by the operating system to store files on. If you have a blank space before a partition or after a partition, that’s space that the operating system can’t use within a filesystem. That makes it fair game to stuff data into. You can see in the figure below, a drive that has two partitions defined on it with a large gap between the two partitions.

The end sector for the first partition is 1000000 but the beginning of the next sector is 1500000. This leaves 500000 sectors unused. Each sector is 512 bytes. That gives us something around 250M to store information into. This is a small drive and that value is close to a quarter of the drive. On larger drives, it may be a lot easier to carve a decent chunk out of the middle or the end of the drive and not have it be noticed.
The problem with this space is that it’s unorganized. I can’t just copy files to it and expect those files to be placed nicely so they can be retrieved easily. If I have a few files that I
want to put up there, I could manually place them one at a time and keep track of where I positioned them within that space. That requires figuring out how many blocks the files take up and remembering where they are. Instead, another way to do it is to simply concatenate the files together. There are a number of utilities you can use to do that. Under Linux, which is where I did this work, you can just use the cat utility. Perhaps one thing you want to do is to put a separator file between the files you want to store. That will allow you to extract the original files later on.
Once we have the concatenated file with all of the data we want to store in it, we can just dump it up to the slack space on the drive. In the figure below, you can see that I took my file as my input to the dd (disk dump) command and then wrote out to a sector in the slack space between the two partitions.

 

You will notice that when I was writing out to the slack space, I used the seek parameter. That’s because I needed to seek into the output file. If I want to go to a particular location in the input file, I would use skip, as you can see in the next invocation of dd where I extract the data. You will also notice in the output, I get 56+1 when I write the data out. That’s because I am writing 56 complete blocks plus 1 partial block. I didn’t file the last 512 byte sector when I wrote the file out. When I read in, then, I need to read in all 57 blocks to get the complete file.
Since I have the original file as well as the recovered file, I can compare one against the other. diff shows an insignificant difference regarding a newline at the end of the file. When I check the line count, I get the same line count between the two. These two comparisons tell me that the file I retrieved is substantially the same as the file that I put up into the disk.
Of course, I could also check to see if there is a specific piece of content in the entire file system using grep but on large disks, that can take a while. There are other tools that can be used to ferret out such things, especially if you can afford the commercial forensics tools.
While this is all very manual, this could be performed programmatically as well. Perhaps another time.