A copied message database can look unreadable while a neighbouring file still holds useful information. That is why an assessment of encrypted storage cannot end with opening one file and finding no recognisable conversation.
Imagine an authorised test using two phones and a synthetic message: a meeting time followed by a unique reference number. The examiner copies the application’s storage after receiving it, after restarting the app and after deleting it. Those are three observations of the same conversation, but they need not produce identical files. The question is whether every retained representation receives the protection the product promises.
The database has a lifecycle
SQLite is a storage engine, not a statement of confidentiality. Its write-ahead logging documentation describes a mode in which changes can remain in a separate WAL file before a checkpoint transfers them into the main database. The presence of that file is normal database behaviour. Whether its contents are encrypted depends on the application’s encryption design and integration.
The alternative is not necessarily a single unchanging file either. SQLite’s account of atomic commits explains rollback journals used to recover interrupted transactions. Reliability and confidentiality solve different problems. A successful recovery mechanism does not, by itself, say which information an unauthorised examiner can read.
A review therefore needs a boundary broader than a filename. Start with the protected information, then identify where the application writes it. A message body, an attachment thumbnail and a diagnostic entry may be created by different code paths. Protecting the message record cannot establish the behaviour of those other paths.
A useful test needs a recognisable input
Use invented content that is distinctive enough to identify reliably. Record its exact bytes and the actions that created it. Preserve the original storage capture before searching a working copy. This makes a positive result traceable and a negative result less ambiguous.
Finding no match for a sentence is not equivalent to proving that the information is absent. Encoding, compression, fragmentation or a different representation can defeat a simple string search. An examiner should combine that search with inspection of the relevant formats and the application’s documented storage paths. The report needs to say which methods were actually used.
Repeat the capture across ordinary transitions: receiving a message, viewing an attachment, backgrounding, locking and terminating the process. These are proposed test conditions, not a claim that we have run them against today’s UseCrypt release. A reproducible assessment records the build, platform, configuration and privileges of the examiner.
Where UseCrypt’s documentation fits
The UseCrypt Messenger storage explanation develops a product document supplied in March 2025. It identifies SQLite, encrypted records and a separate application-passcode layer. It also identifies questions about journals, attachments and backups that require implementation evidence. The source does not establish SQLCipher, a specific AES mode or whole-page encryption, so none of those properties should be inferred here.
AVLab’s November 2020 account of a Messenger assessment is a different kind of evidence. It discusses iOS version 2.34 and the tested passcode configuration. Its historical scope matters. It is neither a finding of a current storage leak nor a blanket assurance about every subsequent application build.
What should the result actually say?
“The copied database was unreadable” is a narrow observation. A stronger report identifies the captured files, the protected records examined, the relevant application states and the conditions under which access failed. It also records exclusions. A test that never captured a backup cannot reach a conclusion about that backup.
OWASP’s secure-storage requirement provides an external reference for protecting sensitive stored data. It does not certify an application merely because an article links to it. The practical standard is coverage backed by evidence: follow the information through its lifecycle, rather than treating an encrypted-looking file as the end of the investigation.
