Cracking the Vault: Exposing the weaknesses of encrypted apps

With millions of applications available on the smartphone market today, and many claiming to offer encryption or secure storage, it can be difficult for users to determine which applications truly protect their data. The reality is not all of them provide the robust security they promise. At times, applications marketed as encrypted storage solutions suffer from poor implementation, making them easily decryptable. Some of them don't encrypt the data at all; instead, opting to simply mask file extensions or store files in unsuspecting locations that are not immediately recognisable as containing sensitive data.

The digital forensics team at S-RM frequently handle bespoke cases involving applications they have never encountered before and may not encounter again. Some of these cases include mobile applications that do not provide functionality to download the account’s data, presenting unique challenges in identifying and recovering the data within them. In this article, our expert Jordan Hare illustrates how encrypted applications may not always be as secure as they appear and demonstrates methods that other experts can utilise to gain access to the application’s data.

Case study: Gallery Vault

In late December 2024, S-RM were engaged to support a client in investigating an encrypted application, Gallery Vault. This application was not supported by leading mobile forensic software. Gallery Vault is a notable privacy application, for Android devices designed “to easily hide and encrypt your photos, videos, and any other files that you do not wish others to see”. While its primary aim is to secure users' media, it also offers additional features such as web browsing and the ability to change the application’s icon to conceal its identity. Some of these features are part of a premium package.

In this particular case, the version in use was 4.4.26. However, initial testing of earlier versions revealed that the processes and artefacts described below remain consistent and applicable across versions.

The objectives in this case were to:

1. Recover, as far as possible, all files stored within the application
2. Evaluate what other information the application may contain, which could be pertinent to our client’s investigation
   1. Identify how to access the application – PIN code / Pattern
   2. Identify original file details, name, location, dates and times

Unlocking the vaults secrets

Data locations

There are two key locations of which to be mindful when dealing with application data on Android devices. It is standard practice for data to be stored both in the app-specific user data section of the device and on the physical or emulated SD card:

• /data/data/com.thinkyeah.galleryvault
• /sdcard/.galleryvault_DoNotDelete_XXXXXXXXXX

The folder name on the SD card will vary, as the string at the end of the name is a Unix epoch timestamp indicating when the folder was created. During testing, this folder was only generated when the user took specific actions within the application. For instance, simply setting up the application with a passcode, without further interaction such as adding files to the vault, does not trigger the creation of this folder.

Additionally, outside of these key locations, it is possible to create a backup of all data from within the application. This backup can be saved either to the cloud or locally on the device/SD card and is typically named “gv_backup.dat.”

Figure 1

This file is an encrypted version of the database usually stored within /data/data/com.thinkyeah.galleryvault/databases/galleryvault.db. This file contains many interesting artefacts. An excerpt of the table names has been listed below:

Figure 2

In particular, the table ‘file_v1’, reflects the details available from within the application about user files. As shown below, when selecting individual files in the application, it provides information such as the ‘Added Time’ and the ‘Original Path’.

Figure 3

Accessing the application

For many applications, whether they are chat applications or otherwise, the simplest way to review the data stored within them is often through the application's interface. However, accessing this data typically requires entering the passcode. If encryption is in use, the PIN code can form an integral part of the encryption and decryption process. This means that the PIN code must be known to access the encrypted files both inside and outside the application. In the case of Gallery Vault, the application is secured by default with a 4-digit PIN code.

Figure 4

For users with the premium version, the application offers an option to randomise the order of the numbers each time they open it to enter the PIN, a useful feature to protect against shoulder surfing. If the application opens with a scrambled layout, it indicates that the premium version is active, which comes with additional functionality to be aware of.

Although the default setting is a 4-digit PIN, premium users can opt for a pattern lock as an alternative security solution. This can also help guard against shoulder surfing, and users can choose whether or not to make the pattern visible. By default, the “Make Pattern Visible” option is enabled.

It is also worth noting that fingerprint unlocking can be activated for the application. However, regardless of whether this is setup a backup PIN or pattern is still required, ensuring that fingerprint authentication is never the sole method of accessing the data.

Decoding the PIN code

Similar to many Android applications of this nature, a general and repeatable approach can often be used to identify the PIN code. The first place to check is:

• /data/data/<application name>/shared_prefs

These files often contain a wealth of information, and more commonly, this is where details such as the PIN code, either in plain text or encoded, are stored.

For Gallery Vault, the file in question is kidd.xml (/data/data/com.thinkyeah.galleryvault/shared_prefs/kidd.xml). Even in the very early versions of this application, the details related to the PIN code have been stored in this file. This is an XML file, and the XML tag identifying the PIN is 'LockPin'.

Figure 5

Breaking down this string (figure 5), there are two hashes present, both derived from the plaintext PIN: SHA1 followed by MD5. In this instance, the PIN code “1234” is represented by the following hashes:

Since the PIN code options available to the user for this application are quite limited, and the algorithm used to generate them is not computationally intensive, using a rainbow table – a precomputed table designed to reverse hash functions by mapping hashes back to possible plaintext values – can make identifying the PIN code relatively easy. In this case, an MD5 hash can be quickly searched online, often returning the correct PIN from an existing list.

Decoding the pattern lock

Similarly for the pattern lock, the details are stored within the ‘kidd.xml’ file, also stored as two hash values: SHA1 followed by MD5.

Figure 8

However, with patterns it is important to understand how the numbers are perceived in order to generate the hash values. For Gallery Vault, the layout runs from 0 to 8:

Figure 8

Meaning, the pattern for the letter ‘L’, in this case, would be 03678.

Figure 9

While interacting directly with the application may not be considered the most forensically sound, determining the PIN or pattern allows for manual review of the application’s contents, including details of each image, video, note, etc. However, unless the data is then exported from the application, further comparisons or investigations of the media are not possible. This is why S-RM took additional steps to assess and decrypt the data associated with the application.

Files and encryption

Earlier versions of this application have been reported not to encrypt data, instead opting to obfuscate it in some way. However, in the version S-RM tested, there is some encryption in place which would otherwise prevent an examiner from making an exact comparison of images or similarly prevent them identifying critical metadata.

Data storage

Media files, thumbnails, backup files, etc. are all stored on the SD card at /sdcard/.galleryvault_DoNotDelete_XXXXXXXXXX/*. A snapshot of the underlying folder structure has been provided below, along with the forensic artefacts that it contains:

‘settings.backup’ is DES ECB encrypted using a hard coded key 0x67616c6c6572795f which, in ASCII, is ‘gallery_[1]’. This file, once decrypted, also contains the PIN code, information about the authorisation email, and other interesting information related to the applications use:

Figure 10

Of particular note is the ‘files’ folder which contains several subfolders denoted with two alphanumeric characters. These subfolders hold the full file and, if present, its thumbnail:

Figure 11

If the SD card were to be misplaced and someone opened these files from within this folder, they would be presented with the following image each time:

Figure 12

By examining the hexadecimal data of the encrypted file, analysis shows a small thumbnail is embedded at the beginning of the file during encryption, giving it the appearance of a standard image and thereby obfuscating the file’s contents. In large-scale operations where time is critical, an examiner might overlook this image. However, the file's hexadecimal (hex) content tells a very different story.

Each file begins with 2803 bytes, which correspond to the image we observe above. If an examiner were to scroll through the hex or search for key indicators, such as a JPEG file footer (0xFF, 0xD9 for original JPEG files), they might find positive results would emerge throughout the file. Carving for images within the data, could result in a thumbnail of the original image file.

Further analysis by S-RM revealed that Gallery Vault uses a mechanism known as the ‘tail’. The tail, which is variable in length, is stored between two key markers: >>tyfs>>, indicating the start, and <<tyfs<<, indicating the end. One might logically assume that reading the data from >>tyfs>> to <<tyfs<< would be correct; however, the tail must be read from the end marker to the start marker. Below is a diagram illustrating the structure of the tail, which varies in length depending on the size of the encrypted data.

Figure 13

There are several important points to note here. Firstly, two forms of encryption are used: DES ECB, applied to the first block of data (from bottom to top, shown in green) and XOR (shown in purple). The data highlighted in green is encrypted with a hardcoded key from the application, 0x7469616e78696177, which decodes to 'tianxiaw' in ASCII. Once decrypted, this data reveals information about the file:

Figure 14

The second portion of encrypted data is protected by an encrypted XOR key, also encrypted using DES ECB with the same hardcoded key, the result once encrypted is a 4-byte XOR key. This XOR key is then used to decrypt the second block of encrypted data. However, an adjustment to the key is necessary. If the XOR key is used in its raw form without any adjustment, it is likely that only the first byte will be decrypted correctly while the remainder will not. The XOR key shifts (or rotates) as each byte of data is processed. The specific byte used for XORing is determined by the position in the sequence, ensuring a repeating but shifting pattern.

An example of how this key adjustment is applied is included below:

The size of the decrypted XOR data typically matches that of 2803. However, in certain files, the encrypted data may exceed what is stored in the tail. When this happens, the encrypted data continues beyond the tail, following directly from the end of the embedded PNG file. This primarily affects larger files, such as backups and encrypted document files. The ‘Check Byte’ referenced in figure 13 above indicates whether the encrypted data, in purple, extends outside the tail and into the main section of the file. If this byte is 0x00 then the encrypted data is fully contained within the tail, if it is 0x01 then then encrypted data continues directly after the Gallery Vault thumbnail at the start of the file for the length dictated within the tail, as show in Figure 13.

As an overview, the following diagram demonstrates the structure of an encrypted file:

Figure 15

Conclusion

As demonstrated, not all secure applications are necessarily as secure as they may initially appear. More importantly, with the growing number of applications available on both the Apple App Store and Google Play Store, it is not feasible for forensic tools to support every single application or even every version of an application.

Practically, manually decrypting and analysing a single encrypted file is achievable; however, attempting to do so for a high volume of files quickly becomes unmanageable. S-RM has developed a script to decrypt files associated with Gallery Vault, including their metadata, and present them in a client-ready format which will be shared publicly via S-RM's GitHub. Please contact S-RM if you encounter any unsupported applications related to encryption or chat applications and require assistance.

[1] Hardcoded encryption keys within this application can be truncated. In this instance, the hardcoded key is ‘gallery_0’ but is shortened to comply with the hex length requirements for AES DES encryption.