Moderator's introduction
Thank you, everyone. Thank you. And before I introduce our next speaker, let's first picture a situation that's quite familiar to everyone. You open the phone, everything's deleted, no data, of course, no records either, but we all know very well that the digital world works differently. Alexey Moskvichev, our next speaker, will tell how to work with SQLite databases. Please welcome him with applause.
Talk
Good afternoon, dear colleagues. Yes, Dmitry has introduced me.
Right, what about the clicker. Aha, it's working. Yes, today I'd like to talk about SQLite database journals. We'll briefly look at what data they store, how you can view it and find what at first glance seems to be deleted information. And we have three practical cases that practitioners in the field have shared with us. I think it'll be interesting. First of all, why SQLite? Because it's been around for over 20 years and is the most widespread, let's say, database management system for most mobile and desktop operating systems. Essentially, it doesn't require a separate server, needs almost no configuration, stores data in ordinary files, and offers fairly high performance while taking up very little space.
And if you look at it through the eyes of an examiner, it becomes obvious that a modern digital device holds dozens, sometimes hundreds of different databases, which store messages, some location data, browser history, banking app data among other things, and so on. But sometimes what's of interest is not the database itself, but its journals, which can provide equally valuable information.
So, let's imagine a simplified picture, let's call it that. A user opens some app, writes a message, sends it to someone, then edits it, and then decides to delete it. What state will the specialist or examiner see in the main database, database.db? In fact, probably the final state of the system, or no message at all, if it was deleted, but the so-called SQLite journals can preserve all three states of the system.
How WAL works: what it keeps and why to collect the journal first
Well, essentially, let's go through it briefly, I don't think I'm discovering America here, but we have a varied audience here, including lawyers, so that it's clear for them. Overall, from the point of view of the WAL mechanism, let's see how it works. So previously all user data was written to the main database file, but since SQLite 3.7 a so-called change log is kept, and all new or modified messages, including deletions, are written to this so-called WAL journal. After the so-called checkpoint procedure, they are transferred into the main database, database.db.
And that's exactly why, when examining a mobile device, in particular when obtaining a physical image or a full file system, it's advisable to analyze both the database.db file and database.wal. There's one more service file, it holds no user data, but, let's say, triaging these files lets you analyze the app data as a whole. Essentially, I've already said what records the journal may contain. These are new records not yet transferred to the database, deleted ones, some previous states of the system, temporary states, drafts perhaps. Or uncompleted transactions because, say, the device was abruptly powered off, hard-rebooted, and so on.
So that's essentially what transactions may be found there. But don't get your hopes up here. These journals, essentially, get overwritten. 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. And the main goal here is to capture that journal before it collapses and before that data is transferred into the main database. And one more simple example. I text a friend at 6 pm: let's meet at 18:00, then I edit it and delete it. So, essentially, the WAL journal will keep all three states of the system, in short.
Three cases: malicious APKs from Telegram and loans taken out on the victims
Well, enough theory, I think, let's move on to practical cases. In one of the regions there was a series of similar incidents, let's say. The user who gave us this information is watching us right now. We send him a big hello. Unfortunately, he couldn't make it. So the victims filed complaints saying that loans had been taken out in their names illegally; they themselves had taken no steps to apply, nothing at all, but shortly before these incidents they had clicked on some links, and some had installed some apps.
And so, essentially, one theory put forward was that most likely there had been some kind of software on the device. To test this theory, the victims' devices were seized and sent for examination to the regional forensic center. Next, our product was used to extract the devices' file system. The methods are here. Unisoc/Spreadtrum Android and Samsung data was pulled via FFS, full file system, vulnerability 31317.
And then, in our "Malicious Objects" section, we scanned the file structure for malware. Nothing was found. And so the examiner then decided to carry out an in-depth examination of the Android operating system, so as not to look for the files themselves, which would be odd to find there anyway, but to look instead for traces of activity of those executable files.
The first incident is called "Search by Full Name bp", you'll see later. Well, the first find was the threats.db-wal journal of the Sber app, you see. Essentially, a record was found there about a file base.apk, which the built-in Sber antivirus, Sber's antivirus module, had classified as a trojan. The file itself was no longer on the device, right, but its unique identifier had survived. Note that at this stage it was already possible to draw an interim conclusion that there had been some kind of software on the device which the Sber app had detected as potentially malicious.
Next, the Android system log, which most of you are probably well familiar with, which records all information about apps installed at the current moment. There was nothing in it, no apps and no data with that identifier. For simplicity we'll call it "OK". The "OK" identifier. It wasn't there, but here's another system log of budget devices, Tecno, Infinix and itel. Note, it's palm-a, right, it recorded, it actually saved the events of the app being registered in the system on November 12, 2025, at 4:39.
Next, in the system database gass.db, that's a Google database, Google Play Protect, right, that's where information about the hash of this executable file was kept, by its identifier. And after that you could already search the databases of specialized software. They exist, you all probably know them well. Try to match it against additional episodes with similar offense types, which, essentially, is what was done. The next step for the examiner was to answer the question of what capabilities the app had, what it could do on the device. Here, in another file, Android, AndroidManifest.xml, there was information about the permissions granted to this app.
Note: sending and receiving SMS, and network access. 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. Next, the following question that had to be answered was, essentially, how an ordinary user knew it, under what name. And here another system file of these Tecno, Infinix and itel devices let us answer that question. This app with the identifier "OKT" was displayed on the device under the name "Search by Full Name bp".
Essentially, next we needed to figure out how it got onto the device. At the very beginning I told you the victims said in their statements that some of them had followed links, some had installed something. And here the Telegram database, Pavel didn't let us down, had saved information about receiving this file "Search by Full Name bp" in one of the Telegram chats. We've blurred part of the information here. And then we needed to figure out, to find out, ideally, something about this Telegram chat, right.
This messages_v2 table itself was effectively empty, because the message had most likely been deleted, the app was removed, but in the chats table, note, the name of this chat survived, in which this APK was received: "Missing in Action in the SVO". This is probably telling, showing how, let's say, resourcefully, that's the word, scammers approach their criminal activity, they pick socially significant topics that are in demand in society right now. So, essentially, that's how the chain of events unfolded in the first incident, where it all started, remember, with the WAL journal, and then, through the operating system logs, additional information was obtained.
A similar incident is called "Photo Archive 20". In exactly the same way, the Sber app, note, kept a log, kept a record of a little file base.apk, also detected it, com.example.application. Then a log file confirmed the information that this app, com.example, had been set as the default. This is a log for the Samsung Messages app, which recorded the fact that specifically the com.example app had been set as the default app for receiving and sending SMS messages.
Next, we needed to figure out when the app had been removed. Another file confirmed the removal of the app on January 31, 2025. And then the same Google database gass.db, note, the hash was obtained. Then Kaspersky antivirus had saved information about the name of this app, "Photo Archive 20". And then again, Telegram was used as the means of delivering this executable file to the device. And here, too, the information was obtained from its database, in one of the chats.
Incident 3 differs somewhat in that the Sber app was not present on it, but the built-in antivirus also saved, the built-in antivirus log saved information about the record, and also classified it as potentially malicious. And, essentially, in addition, you see, it highlighted that this app is dangerous, there's a risk of confidential data leakage, fraudulent debiting of funds, so we recommend removing it.
And then two log files confirmed the installation of the app, note, and the removal of the app three days later.
And then another hash was confirmed in the gass.db file, note, and Telegram was likewise involved in this incident.
To sum up briefly, it all started, as I said, with the SQLite journal, in fact the SQLite journals combined with the system artifacts of the operating system made it possible to build a full timeline, to trace the chronology of events on the device, starting from the moment it got onto the device all the way to the source of this APK. So in fact it was then possible to link these events to the dates of the fraudulent actions.
Q&A
Overall, my talk is fairly short. That's it, if you have questions, go ahead. Colleagues, questions by raised hand too, if you have any. Valery, oh, Evgenia, please go ahead.
— Alexey, just a few points. One. I see you analyzed the WAL files with FQLite Carving Tool. That's some free program, it's fairly convenient to use. Does it display?
— Yes, we didn't analyze it. I said a working examiner provided us this information. The viewer used here wasn't ours, it was a third-party one. That's right. And from that follows the question of how Mobile Criminalist handles system journals. I've noticed that depending on where you launch it from, roughly speaking, Mobile Criminalist already takes them into account when displaying, say, the Telegram app, it already accounts for these system journals. But if you open it via the file browser, Mobile Criminalist shows the information as it is in the database, ignoring these journal files. Well, yes, here it's first of all a matter of taste.
If Mobile Criminalist already displays something, then of course you should probably use our viewer. If it doesn't display some of the information, then, as here, a third-party product was used. The question is more this. Does Mobile Criminalist not flag this information separately at all? Or put it this way: it doesn't flag it separately at the moment, but are there plans to implement that, so it's shown as deleted information? Actually, since we received this information from the expert, yes, of course, this task will be on the agenda.
— When exactly, I can't say. Thank you. Colleagues, more questions. Eleonora, please.
— Thank you for the talk. As I know, Mobile Criminalist can examine WAL files, not only the databases but the WAL files too, and parse them. So the problem is that when we get a copy of the data, well, like a file system copy, Mobile Criminalist examines the database, say WhatsApp or Telegram, at the default paths, but also the WAL files, and sometimes the chats end up with doubled or tripled messages. Can this problem be solved somehow going forward, so investigators don't ask why the crook sent the victim messages three times, sent some files three times in the chat? That didn't happen in reality. On the device we see it once, but in the Mobile Criminalist parse we see doubled, tripled data.
Yes, we have received such reports, yes, and our development team has them, so I think we'll work on it, yes.
— May I ask a question? Sorry, while the colleague is getting ready. The thing is, right now, besides the Anti-Fraud 3 package of bills, we have Anti-Fraud 2 already in force, Federal Law No. 210. Now a doctrine is being prepared for a system to counter ICT crime. And one of the important issues you covered in your talk is exactly countering banking fraud carried out with malware. Well, generally, yes.
And the thing is, this area now overlaps much more strongly with information security, with computer attacks in the form of malware. So there's been pushback from regulators, from the Bank of Russia, FSTEC and others, that when we turn forensic tools into a forensic system, especially under a number of departmental regulations, we need to make sure, first, that the result isn't automatic. You just showed a human analyst extracting this information, correlating it and delivering it as the result of the examination.
Are there plans to build in compliance, first of all, probably, with FSTEC, to certify some versions, maybe selectively, so they can be used in departmental systems, not as standalone tools taken out to the scene, but specifically in expert systems, and have the corresponding status: trusted software or a technical hardware-software complex. First question. And the second question relates to banking requirements and the like; one of the requirements there is that any system, whether a banking app or an analysis system, where you have to present evidence, must carry information about the absence of malware.
That is, not just get some version, say, that this is trusted software, but that the expert, doing the analysis, used, besides the forensic extraction and analysis tool, antivirus tools as well, and which ones. That is, showing that he himself didn't and couldn't have introduced any changes. Unfortunately, the current legal requirement applies directly to banking apps, but during analysis many experts get such questions in court, especially from defense lawyers, when cross-examined. How did you make sure that during your examination you yourself, or some software examining, possibly malware from that same phone, didn't corrupt your examination results?
So, two questions related to ensuring reliability. Thank you. On the first one. Did I understand correctly that as regards our product specifically, it can be accepted as evidence in court? What did you mean? Can our product be used at crime scenes?
I'll repeat it in plain Russian. First question. Will at least some versions of the product be certified as trusted software under the current infosec rules? Because the field of fighting ICT crime is overlapping more and more with general information security, banking in particular. First question. Second question. Will there be any tool-level integration with an antivirus, and will the operation logs, including the technical ones, record that the objects examined by the tool passed an antivirus scan, say, with this, this and this? Not just us writing in our report, well, nobody writes in LaTeX, in Word, we insert into the expert opinion, that we found, say, malware of such-and-such type.
But specifically a technical record that, well, is entered practically automatically or in an automated mode, so the expert doesn't need to add any extra explanatory notes, because that's already a legal requirement. Understood. Two questions. On certification, I think that's more a question for a lawyer, it's hard for me to answer, I can't say. On the second question, here I also find it hard to answer how to simplify this information, this work, for the user.
Honestly, I'm not sure. From our product's standpoint, as I said, we have a separate malicious objects section, purely the Kaspersky integration. That information is in the customer portal and in the add-ons in the customer portal that you'll be installing. What else needs to be shown or highlighted? I don't know how else to simplify it. What's here?
Colleagues, let's keep going. We have time for one more question. The young man over there has had his hand up for a while. Please, over on that side. Eleonora. Please give the mic to the young man on that side. Raise your hand higher, please, so she can see you. She's seen you, yes. Eleonora, the young man.
— Thanks for passing me the floor. Good afternoon again. My question is this: in all three cases, antivirus data came up. And it's a bit of a tangential question, just about antivirus on mobile devices. I'm curious whether it was really that easy to determine which software ultimately turned out to be malicious. Are there many false positives from built-in antivirus, and from it in the banking environment? And the second question, maybe you know, unfortunately I'm not quite an expert in this field, how strong is evidence that comes in a database format or in text form, where the antivirus logs are written, is it really reliable?
That is, can you somehow confirm such a detection really happened? Or, for instance, the antivirus logs were tampered with, and the attacker could, say, cover his tracks.
— Well, in general, data can be tampered with, you're right. But here the artifacts were examined as a whole. And so, yes, of course, this information formed the basis of the expert opinion. They were admitted as evidence in court. As for the first question about antivirus. How easy or hard it was to find all this among all that cluttered data. But here we weren't the ones who did that examination, so effectively we worked with clean data the expert provided to us. So let's check that information with him, I'll get back to you, and we'll discuss it more fully. Great, thank you.
Alexey, thank you very much. Thank you. Let's give Alexey a round of applause. And I'd like to remind everyone that right at the back of the hall is the exhibition area, and there won't be a roast today. So now we have a fairly long break until 12 o'clock, and then we'll continue. See you back in the hall.
[A break (11:55–12:30 in the program) is cut from the recording here — about 39 minutes in two pieces: before the moderator's line “And we are back…” and right after it.]