How to check whether a vault app is lying to you
2026-09-10
You can verify this yourself in about fifteen minutes, on any vault app, without trusting a review — including this one.
Independent teardowns in early 2026 found something uncomfortable about this
category: a lot of popular "photo hider" apps do not encrypt anything. They
move your pictures to a folder the gallery does not scan, put a PIN screen in
front of the app, and call it a vault. Pull the storage into a computer and
the photos are sitting there, readable, still named
IMG_4471.jpg.
The reason this works commercially is that almost nobody checks. Checking is not actually hard.
The idea
A vault makes one promise: without the password, the data on disk is useless. So the test is to become an attacker who has the disk but not the password, and see what you can read.
You need three things, and no security expertise:
- An Android phone with USB debugging turned on
adb, from Google's platform-tools- A test file with a phrase in it you can search for
The test
1. Put a marked file in the vault
Make a text file containing something unmistakable, like
watermelon-sunrise-7741, and a photo you can recognise. Add both
to the vault. Close the app.
2. Pull the app's storage off the phone
adb shell "run-as com.example.thevault tar cf - ." > vault.tar tar xf vault.tar
If the app is not debuggable — most published apps are not — use a full backup instead, or test on an emulator where you have root. On an emulator:
adb root adb shell "tar cf - /data/data/com.example.thevault" > vault.tar
3. Search it
grep -r "watermelon-sunrise-7741" . find . -name "*.jpg" -o -name "*.png" | head
Now read the result honestly:
| What you find | What it means |
|---|---|
| Your phrase appears in plain text | Nothing is encrypted. This is a folder with a password on the door. |
| Image files open normally in a viewer | Same. Renaming a file is not encryption. |
Files are unreadable, but names like holiday.jpg survive in a database | Contents encrypted, metadata not. Better, but the file list is still a map of your private life. |
| Everything is random bytes, names included | This is what a vault is supposed to look like. |
The second test, which almost nobody runs
Encryption alone is not enough if the app also stores something that lets an attacker check a password guess cheaply. Look through the database for anything shaped like a password hash or a "verifier" — a stored value the app compares your typed password against.
If one exists, an attacker with your phone can try millions of guesses per second offline, and a six-character password falls in minutes. A vault built properly has nothing to check a guess against: the only way to test a password is to run the full key derivation and attempt to decrypt, which is deliberately slow.
How this app does
We ran exactly this against SealKeep, on the real on-device storage. The encrypted file begins with a format header and then random bytes:
00000000: 4c4d 4656 4155 4c54 0101 0000 0000 1000 LMFVAULT........ 00000010: 2300 0000 0000 0000 b0cf 480e 65f9 5274 #.........H.e.Rt 00000020: 9279 8102 c605 493c 4c7a f21f c891 faee .y....I<Lz......
Searching every stored byte — database, write-ahead log and the encrypted blob — for the test phrase, the file name, and the password returned nothing. The file name is not stored anywhere in the clear; it lives inside its own encrypted blob.
There is no password verifier. The only way to test a guess is to run Argon2id at 64 MiB of memory and attempt to unwrap a key, which takes about a second per attempt on a phone.
One thing is stored in the clear, and pretending otherwise would make this whole article worthless: the vault's name. It has to be, so the app can list your vaults on the lock screen before anything is unlocked. Call a vault "Documents", not something you would not want read aloud.
Run it on us
If you run this test on SealKeep and find something we have not disclosed here, we want to know: hello@sealkeep.app. A claim that cannot be checked is just advertising.