In brief
The WAL journal as a source of "deleted" data: the main database shows only the final state, while the journal — all the intermediate ones, including deleted records and drafts. Then three cases from a single region where loans were taken out in the victims' names: the APKs themselves were no longer on the phones, but from the log of Sber's antivirus, the system logs of budget Android devices, the Google Play Protect database and the Telegram database the examiner assembled a timeline — from the file being received in a chat to the app being deleted. An important caveat from the speaker: the journals get overwritten, there is no point looking there for "all the deleted stuff", and the point is to capture the journal before the checkpoint. The cases are not his own — they were handed over by a working examiner, which is why some of the questions from the audience had no answer, including two regulatory ones.
Key points
- Why SQLite: more than 20 years old, the most widespread DBMS of mobile and desktop operating systems, no server and no configuration, data in ordinary files, fast and compact.
- A modern device holds "dozens, sometimes hundreds" of databases: messages, location data, browser history, banking apps. What is of interest is not only the database but also its journals.
- A model example: a message was written, edited, deleted. database.db will keep the final state or nothing; the journal is able to preserve all three states.
- The mechanism: before SQLite 3.7 everything was written to the main file; from 3.7 on, changes go into the WAL journal and are transferred into the database after the checkpoint (the control point).
- The practical conclusion: with a physical image or a full file system you have to analyze the pair database.db + database.wal (plus a service file with no user data) — only triaging all the files together gives the picture.
- What can be in the journal: new records not yet transferred into the database; deleted ones; previous and temporary states, drafts; uncompleted transactions after an abrupt power-off.
- The limitation is stated outright: the journals get overwritten, "don't get your hopes up" — and the task is to capture the journal "before it collapses", before the data is transferred into the main database.
- The cases — from a single region, the materials were handed over by a working examiner (he is not in the hall). The victims filed complaints about loans taken out in their names; before that they had followed links and installed something.
- The devices were seized and sent to the regional forensic center (EKC); the extraction — with MKO's product: Unisoc/Spreadtrum Android and Samsung, the FFS method (full file system), "vulnerability 31317". A scan with the "Malicious Objects" section returned nothing — the files were no longer on the devices, so they looked for traces of activity.
- Case 1 ("Search by Full Name bp"). The starting point — threats.db-wal of the Sber app: the built-in antivirus module recorded base.apk as a trojan; the file itself is gone, but the package identifier survived.
- The Android system log of installed apps is empty, but the service log of budget Tecno, Infinix and itel devices preserved the event of the app being registered in the system on 12 November 2025 at 4:39.
- In gass.db (Google Play Protect) the hash of the file was found by its identifier — with it you can already go to the databases of specialized services and match it against episodes with similar offense types.
- In AndroidManifest.xml — the permissions granted: receiving and sending SMS, network access. The caveat: the presence of permissions does not prove they were used, "but still the very fact of these permissions says a lot".
- Another service file of the same budget devices gave the app's visible name — "Search by Full Name bp".
- The source of delivery — Telegram: the messages_v2 table is effectively empty (the message was deleted), but the chats table preserved the name of the chat in which the APK was received: "Missing in Action in the SVO". The speaker's conclusion: scammers pick socially significant topics.
- Case 2 ("Photo Archive 20"). The same Sber journal with base.apk (package com.example.application); the Samsung Messages log recorded that com.example had been set as the default app for receiving and sending SMS; a separate file confirmed the removal of the app on 31 January 2025; the hash — again in gass.db; the name "Photo Archive 20" was preserved by Kaspersky antivirus; delivery — again via Telegram.
- Case 3. The Sber app is not on the device, but the built-in antivirus preserved a record and flagged the object as potentially malicious, with a warning about the risk of confidential data leakage and fraudulent debiting of funds. Two logs gave the installation and the removal three days later, the hash — in gass.db, delivery — Telegram.
- The upshot: the SQLite journals together with the system artifacts made it possible to build a timeline from the file getting onto the device to the source of the APK and to link it to the dates of the fraudulent actions.
Tools, artifacts, technologies
- SQLite, the WAL mechanism (since version 3.7), the checkpoint; the triad of files database.db + database.wal + a service file.
- threats.db-wal — the journal of Sber's antivirus module; gass.db — the Google Play Protect database (hashes); AndroidManifest.xml — permissions; the Android system log of installed apps; the service logs of Tecno / Infinix / itel; Samsung Messages logs; the Telegram database (tables messages_v2, chats).
- Mobile Criminalist — FFS extraction (full file system) for Unisoc/Spreadtrum and Samsung, "vulnerability 31317"; the "Malicious Objects" section — the integration with Kaspersky.
- FQLite Carving Tool — the third-party WAL viewer the examiner used (mentioned in a question from the audience).
- Malicious apps under the names "Search by Full Name bp", "Photo Archive 20", package com.example.application.
Legal and organizational context
The most substantial legal part of the day — in the questions. Mentioned were Federal Law No. 210 ("Anti-Fraud 2", already in force), the "Anti-Fraud 3" now in preparation and the doctrine for developing a system to counter ICT crime, as well as the demands of the regulators — the Bank of Russia and FSTEC — that the expert result not be "automatic", that is, that the conclusions be drawn by a human. Hence two requirements for tools: certification as trusted software for departmental systems and a technical (not textual) record that the objects passed an antivirus scan — because in court defense lawyers ask the expert how he made sure that he did not corrupt anything himself. The procedural outcome of the cases: the information formed the basis of the expert report and was admitted as evidence in court. The seizure and the forensic examination went through the regional EKC.
Questions from the audience
- 1 (Evgenia): was the WAL analyzed with the free FQLite Carving Tool? And why does Mobile Criminalist take the service journals into account when parsing an app, but through the file browser shows the database "as it is"? Does it flag such records separately, as deleted, and is that in the plans? → The analysis was done not by MKO but by the examiner, with a third-party viewer; the choice of viewer — "a matter of taste"; a separate flag — "of course, this task will be on the agenda", but "when exactly, I can't say".
- 2 (Eleonora): because both the database and the WAL are parsed, WhatsApp and Telegram chats come out in MK with doubled and tripled messages, and investigators ask why "the crook sent the victim messages three times", although on the device it is a single message. → "we have received such reports… we'll work on it".
- 3 (name not given, a question about regulation): will at least selected versions of the product be certified as trusted software under the requirements of FSTEC and other regulators — for use in departmental expert systems? And will the tool itself write into the technical logs that the objects passed an antivirus scan and with which tools? → On certification: "that's more a question for a lawyer… I can't say". On the second: "honestly, I'm not sure"; at present there is a malicious objects section built on the Kaspersky integration, and the data is available in the customer portal.
- 4 (name not given): in all the cases the support is antivirus data — how easy is it to tell real malware apart, are there many false positives from built-in and banking antivirus? And how reliable is such evidence: can you confirm that the detection happened and that the logs were not tampered with? → "in general, data can be tampered with, you're right", but the artifacts were examined as a whole, and the conclusions were admitted as evidence in court. On false positives there is no answer: "we weren't the ones who did that examination… we worked with clean data", he promises to check with the examiner.
The speaker's position
The speaker consistently separates what is his from what is not: the cases were handed over by the examiner, the third-party tool — his choice, "we worked with clean data". This is honest, but the price is this: half of the questions from the audience have nothing to answer them with. The limits of the technology are stated outright (the journals get overwritten, permissions do not equal actions, data can be tampered with), and the product is sold softly — through method, not through promises. To the regulatory questions the answer is a frank "I don't know", with no attempt to talk his way out of it.
Quotes
- "…the lawyers might think right now that we can find and view all the deleted stuff, that it'll definitely be there. No. All these journals get overwritten".
- "Of course, nobody is saying that all these permissions, if granted, were actually exercised, but still the very fact of these permissions says a lot".
- "…they pick socially significant topics that are in demand in society right now".
- "Honestly, I'm not sure".
- "Well, in general, data can be tampered with, you're right. But here the artifacts were examined as a whole".