RS File Name Obfuscator

This project was developed in 2006, when I was 13 years old, in order to create a "faster" alternative to TrueCrypt, as for my purpose it was enough to just hide the files. It is now deprecated, as it was only an experiment, you shouldn't rely on security through obscurity, and current generation processors support AES instructions, making the use of encrypted volumes more feasible. This page only exists for archival purposes.

Project summary

This project was a quick experiment to develop a console application which would encrypt or decrypt the name of all files and directories recursively starting from the specified path.

It had three versions, addressing various issues I came across.

File name encryption v0.1

The very first version encrypted the file names with AES and then stored it with Base64 encoding. While theoretically it fulfilled its purpose, if you randomly found the folder, you would've known something's up when you're greeted with a bunch of garbage file names:

.                                  .
├───documents                      ├───eWVhaCwgc3VyZQ
│   ├───taxes_2006.pdf     -->     │   ├───d2hlbiBpIHdhcyAxMw
│   └───taxes_2007.pdf             │   └───aSB3YXMgaGlkaW5n
└───something else                 └───bXkgdGF4ZXMsIGZvciBzdXJlIQ

Wordlist usage v0.2

In order to combat this, I've decided to go down on another route, and use wordlists to generate the file names. While the algorithm wasn't as efficient as it could be looking at the code now, it was able to take the file name, use modulo arithmetic to convert the base 26 name to base size of wordlist, it then arranged it into various predefined patterns.

For example .vimrc would turn into data_something_from_wordlist_0215.bin, which looked less shady. This, however, had the issue of overinflating the file names in some cases, hitting the upper limit of 255 characters per file name.

Header obfuscation v0.3

After I was done with the renaming, even though I encrypted the extension as well, I found that most applications would still open the files. While it was clear from the beginning that I'm only concentrating on the file names, avoiding encrypting the whole content, as it would be a time-consuming implementation for the use-case when you quickly need to access randomly hidden files.

With some research, I was able to find out it was enough to overwrite the first few bytes in some of the formats. For example, the starting ‰PNG for .png files, %PDF for .pdf files, and so on. Destroying this magic number in the header would stop some readers of some formats from ever opening the files, thus resulting in success for me, as long as the files are not held up to much scrutiny.

The last version of the application, besides renaming the files, it opened them up, and applied byte⊕keybyte \oplus key against their first four bytes.