Pole Vaulting Over the Gallery Vault

Over the past few years, I’ve become more and more aware of these poorly written File Encryption utilities showing up on the Google Play Store. While I typically try and steer clear of these applications, I thought it’d be fun to try and bypass whatever “security features” they had implemented.

Why Gallery Vault?

I chose Gallery Vault as my target for a couple reasons. The app has over 10 million downloads, so it’s reasonable to believe that there are at least a few people out there relying on it’s security. Also, the price of their In-app Products leads me to believe that their main focus is making as much money as they can, as quickly as they can. After taking a look at their website, I was dumbfounded by the idea that the same developers who have the most typo and broken link ridden website I have ever seen could manage to cobble together anything remotely secure. I tried to glean more information from the Play Store listing, but all I could find was the typical, “just trust us, we know what we’re doing.” All the Gallery Vault listing has to say is,

With GalleryVault, your privacy is well protected.

The hidden files are all encrypted


Android File Storage: Internal vs. External

With Android, Google has tried explicitly hard to provide a fail-safe environment for the security-challenged developer. One of the most powerful of these safeguards is the incorporation of the least-privilege model combined with strictly enforced application sand-boxing. The Android OS provides a secure storage location, also referred to as Internal Storage, for every application installed on the device. This is usually a folder located in /data/data/ with very strict permissions enforced by the operating system. Only the application to which that folder was assigned can read from, or write to, that directory. Not even the owner of the device can access this folder without intrusive modifications to the operating system. This makes sense, applications tend to store rather sensitive information, and you don’t want to have to worry about the Facebook app rifling through the data contained within your tracking app, or any other inter-application subterfuge. This is incredibly easy for developers to implement, by design. Google has designed and morphed the Android API in such a way that it’s easier to use the secure, Internal Storage, than it is to use it’s cousin, the External Storage.

Sometimes, you have data that you want to make public to other applications and to the end user, such as music and pictures. The External Storage is just another name for the device’s SD Card, mounted at /sdcard/. Most newer phones do not have SD Cards, instead, they create their own virtual SD Card typically mounted at /storage/emulated/0 (which, for compatibility purposes, tends to also be a symbolic link to /sdcard/). The main difference between Internal and External Storage, is that with External Storage, any application and read and write to any folder on the partition. This is why you never want to store any sensitive information in External Storage, for an evil application would be given unhindered access. Just like with Internal Storage, the OS will create a special folder designated for that application on the External Storage. Except the OS won’t be able to defend against prying eyes, so the External Storage data folder is typically used for caching larger files, such as music in a streaming media player.

Involuntary Backups, Courtesy of Gallery Vault

After first installing Gallery Vault, I opened the file explorer on my phone, and began to look for any files it may have saved. Remember, since my file explorer isn’t Gallery Vault, we can’t look inside the Internal Storage, where all the goods would be held. The first place I looked was inside it’s data folder on the External Storage and you’ll never guess what I found…


It’s a log file! If we look closely we see the test jpg that I uploaded from my DCIM folder, but then we see something else. Oh Gallery Vault team, you poor, simple, fools. They’ve had the brilliant idea of “backing up” the folder that only they could access to the External Storage. Not just to the External Storage, but to the root of it. They then realized they had a problem, they couldn’t just announce their (uninvited) presence to the user or other apps like this. So they asked themselves, What Would Bruce Schneier Do? They then came up with the most impenetrable method for securing folders, making them hidden. I don’t really understand what they’re idea was behind this, except for maybe just tricking the end user, because as we know, hidden folders aren’t really hidden at all. Once we navigate to /sdcard/.galleryvault_DoNotDelete, we are presented with an involuntary backup of what appears to be everything that would’ve been inside the InternalStorage folder.

The logs folder contains only a debug log for one of the many advertising networks linked into Gallery Vault. This one being from Baidu, a Chinese company that I don’t know much about. Speaking of Chinese companies, Gallery Vault also includes some libraries from Alibaba. While this isn’t exactly surprising, it makes me feel uncomfortable about the huge amount of control Alibaba has over China. But I digress. events just contains an event log similar to the one we saw earlier. files is where all of the pictures, documents, etc. that you’ve encrypted with the app are stored. backup is where I’m drawn to, given my goal isn’t to slurp files, but to see if I can find the encryption key or the pin protect the contents of the application. I copied over both gv_db.dat and setting.backup to my McBook, and started typing away.

Aunt Steggy

Using file and binwalk we can see that this isn’t anything like the SQLite database that I was imagining. Renaming the file to a PNG yielded a 300×300 picture of Gallery Vault’s icon. Now, this is a 130kb file, but with hardly any pixels. What gives?

Poking further, we see that additional data has been appended to the png file. I did manage to reverse engineer the format of the data, but I feel like that deserves an article of its own. Basically, the data contains the actual file, and some encrypted metadata such as the filename, creation time, email address of the owner, etc.

When I ran file on the settings database however, there was no picture or custom file formats to wrestle with. It was simply a text file, containing a hex representation of some data.

Deep in the Heart of DEXes

After decompiling the APK, I was able to get a better understanding of how the application worked. After searching, I found the function responsible for generating the json destined to become setting.backup.


At last, I finally have a specific target, “LockPin.” If I can manage to decode the file, I could write an Android app to automatically open the database (remember, it’s in a shared storage space), then simply give me the pin for the lock screen. Sounds simple enough, but first we need to find out how the file is encoded. Following the chain of execution, I finally discover the revolutionary encryption algorithm powering Gallery Vault..

DES, also known as the Data Encryption Standard, has been around for 45 years and was proven broken many, many, years ago. They aren’t even using TripleDES, the slightly stronger variant, or any of the stronger modes of DES. Gallery Vault uses DES-ECB to protect it’s users data, and still claims to be secure. But wait! There’s more. The key that’s used to encrypt the settings database is hardcoded into the application. In fact, all of the files that it encrypts use hardcoded keys. Oh, did I mention they also have a cloud service?

Let’s recap real quick, this is a program marketed towards hiding and securing sensitive documents, so nobody else can see. The user is then nagged into paying to have their sensitive documents “backed up” to a Chinese cloud server. The user is led to believe that their files are properly encrypted, and that Gallery Vault isn’t even able to decrypt them. Whereas in actuality, Gallery Vault already knows the key, because everyone’s is the same.

private static final String f16975c = C4757c.m13851d("EFD2F212FDDD754C30E41AB4849249A440E7846035AF71D4");

That is the encrypted version of the key for the settings database (there are many other keys just like this, scattered around the codebase for other files), which is stored right at the top of the class file for convenience. The m13851d function, decrypts that string of hex using what I like to call The Root Key. The Root Key is used do decrypt pretty much all of the file-specific keys, and some other stuff. The Root Key is defined as

private static final String f13704b = new String(hexToByte("676F6F645F6776"));

When we decode The Root Key, we get the PRNG generated key, good_gv. Then when we use The Root Key to decrypt the settings database key, we get the incredibly complex gallery_vault_key. Oh and remember that custom file format I was talking about earlier? That’s used for pretty much every file it encrypts, not just databases. That file format has got it’s own special key for encrypting the metadata, tianxiawuzei.

Alright, so we’ve decrypted the settings database, now what? Well, turns out the LockPin variable isn’t actually in plaintext like I had hoped, they hashed it. Not with one hash, but with two. Oh they nested one hash inside of the other? Nope.


Someone had the brilliant thought of, instead of hashing the pin with SHA, we’ll append the MD5 hash to make it longer and look scary! Literally the only purpose this serves is for security theater. Since strings are, well, strings, and MD5 hashes are 32 characters long, we can just get rid of everything except for the last 32 characters. Now we can just crack the MD5 and not worry having to deal with that pesky SHA hash.

The final result is a Proof-of-Concept Android application that is able to automatically detect Gallery Vault, read and decrypt the settings database, and crack the pin, all within seconds.

Key Takeaways:

  • Don’t save sensitive information to External Storage
  • Don’t use hidden folders to hide sensitive data in public storage locations
  • Don’t use steganography as part of your security model
  • Don’t use antiquated encryption algorithms
  • Don’t hardcode keys, generate them for each user
  • Don’t rely on Security by Obscurity
  • Don’t favor money over security
  • Don’t combine two hashing algorithms to create one mega hash
  • Don’t automatically “backup” files without the users consent