A standard methodology for examining information stored on mobile devices and their components

Moderator's introduction

We're moving on to the second part of today's event. Once again, I invite everyone to come back into the hall. You can do that with your coffee and sandwiches. Personally, I don't see any problem with that. As we've already gathered, broadly, from our previous session, the phone, even the one in my hands right now, really is a genuine black box, since it stores everything you searched for, who you called, what you browsed at night, and so on. And overall, even once we've unlocked this phone, we need to understand what's in its contents. Olga Vladislavovna Tushkanova will now kindly tell us about the standard methodology for examining precisely this kind of evidence that arises in these cases. Let's give her a round of applause.

Olga Vladislavovna, the mic is yours. I'll bring the clicker over now.

Talk and Q&A

Good afternoon. Oh, well then, yes, thank you very much. Right, where's the... the up arrow, that's that way. We'll sort it out now. Why did this topic come up? Actually, all of us, as forensic experts, are, generally speaking, obliged to cite some literature, some sources that we rely on when conducting a forensic examination. This is an integral part of the expert's report, where it must be stated. One, two, three.

No.

So, I'll now take two sources of this information, where an expert can draw from, and what he can refer to, take information from for his work. In fact, there are scientific publications, where all sorts of things get written, and non-scientific publications, various recommendations that developers produce, and all the help files and the rest — it all exists. But the main thing experts use is either methodologies, or methodological guidelines.

A methodology is a formalized algorithm of the expert's actions, ensuring the reproducibility and reliability of the results. It includes the stages of preparation, execution, and evaluation of results, as well as requirements for the tools and the conditions of the examination. So that's what we call a methodology, and it's the main thing an expert should rely on. Two years ago I talked, more or less, about which tasks absolutely require methodologies, which tasks they're optional for, and which tasks are, well, where a person just writes: it's a search task, I can search this way or that, here's what I found, there you go, or didn't find it, so be it — like a crime scene examination: whatever you found goes into the criminal investigation pool; what you didn't find, you didn't find.

Methodological guidelines are advisory documents that explain and help apply forensic methodologies and equipment. If a methodology is one, two, three, five, mandatory, then methodological guidelines as a rule, explain how to apply that methodology. For example, our standard methodology for examining computer information, already written and improved several times. And under this methodology for examining computer information, we've now started writing methodological guidelines. One of them: methodological guidelines on examining information in Astra Linux. Astra Linux: it details the trace picture; the methodological guidelines tell you where to look, what to look with, and how to look, more specifically for Linux. Now we're writing the same for macOS.

But unlike that, we started creating methodologies, I suppose, more by object, so the methodological guidelines on examining computer information, they mostly concern information that resides on regular computers, in the form of file systems. It's a different matter when it comes to methodological guidelines and methodologies for examining mobile phones. Let's start with a bit of historical background. Why the three dots?

I can't claim to know everything that's been written on this subject since mobile phones first appeared — who wrote what and how. Including developers of certain software — they also described some things. Do this, do this, do this. The first more or less reliable source is the methodological guidelines on the forensic examination of cellular mobile phones in the bodies for control over the trafficking of narcotic drugs and psychotropic substances. I had the 2011 version; the FSKN — the drug control service — developed it, and these methodological guidelines were marked "for official use only". So they reached some people and didn't reach others. The drug control service used it itself. As far as I understand, one of the authors of that document is actually here today.

The next thing we got — guidelines, guidelines, we needed a standard methodology for examining information. And in 2014, the EKC MVD of Russia more or less wrote such a methodology. But it was written to the level of the objects that existed back then, and many of the things that have since appeared in mobile phones, this methodology really couldn't take into account, because it was hard to imagine what else would show up. The next thing, done in 2023: the EKC MVD of Russia improved this methodology a little, but it doesn't, let's say, differ much from the last one. And this year we wrote a standard methodology, developed it, for the forensic examination of information contained in mobile devices and their components.

I won't list for you one, two, three items and lay out how it's written. I'll just tell you about the innovations that were made, and from that it'll become clear why, generally speaking, we took this on. Why did we have to write a methodology for this kind of examination?

What's new? First. Previously it was just mobile phones. We've moved to mobile devices. So we've broadened the range of objects of examination a bit, because the principles and approaches are the same. What else did we include? Keypad mobile phones, obviously, smartphones, tablet computers and smartwatches, smart bands. So we've broadened the range of what falls under this methodology, right here. We reworked the section dedicated to the objects of examination, that is, their description. A standard methodology necessarily consists of several mandatory sections, including a brief description of the object of examination, the standard questions, the expert task, approaches to the equipment you use. The methodology itself — do one, two, three, four, five — but without being tied to specific equipment, just recommendations, so you don't forget to check here, check there, and check over there.

And the conclusions and so on. We've also added a section there on describing the objects of examination, describing technical data encryption. Among other things — much is new there.

But the requirements for the equipment used to conduct the examination have been clarified. So, let's say, the problem of what we should record in the methodology for examining computer information specifically, how much detail we should give about the equipment. If we go down that road — say, today I'm examining a computer or a mobile phone, and I need, preferably, this specific bench equipment, these specific hardware tools. Preferably, I should have something from ACE Lab, from MKO Systems, from someone else. Plus such-and-such software by name — then that's a road to nowhere, because in six months the names of the software products will change, something new will appear that I want, and the thing I wanted will disappear, but, unfortunately, they've simply gone off the market and aren't sold anymore. So the requirements in methodologies are written as functional ones. And what they'll be implemented with at any given moment, what you'll order and put into the technical specifications for procurement, into the contract, that will be something that meets these requirements.

But it will take on a concrete form and a concrete name of software and hardware. Equipment requirements: the expert's hardware and software workstation. Look: have various interface and technology connectors, specialized devices — well, a Bluetooth adapter, a Wi-Fi adapter, some other equipment — interface cables for connecting mobile devices, SIM cards, memory cards. What exactly, under which name right now — I have no idea, but it has to be able to do this. Have equipment for working with information on digital storage media. Have the ability to block the registration of mobile devices on cellular networks.

Have the ability to provide electrical power to batteries and directly to the mobile devices themselves. For example, a universal power supply unit. For example — go look, maybe something else will come along. Have the ability to remove memory chips from mobile devices. Why, how, which product? I won't say. The capability has to be there. Have the ability to read information from the memory chips of mobile devices. Next. Have the ability to read SIM cards and to write SIM card memory identifiers. Have the ability to decode the user partitions of mobile device memory. Have SIM cards that are not registered by a cellular operator.

Have an ultrasonic bath and drying equipment. It says "optional" here, meaning there are cases when a phone has to be properly washed and dried. Have the ability to search and interpret information obtained from the memory of mobile devices, memory cards and SIM cards. Again, here they tell you what they interpret it with, how they crack passwords, doesn't matter. The expert has to have that capability. Have the ability to video-record actions performed by the expert during the examination. That's sometimes needed, and among other things it must illustrate certain points. And have the ability to document the examination results and to prepare report files. Nowadays practically the majority of software products we have for examining information on mobile phones generate report files. So, well, let that capability be there.

The next of what's new for us. Well, let's say the examination procedure has been made more specific and expanded. Among other things — this isn't all of it, there's actually a lot, no point listing it, it's not interesting — we've added measures ensuring the preservation and integrity of information contained in the memory of the mobile device and its components. That is, they're divided into software measures, hardware ones, and for powered-on devices and for powered-off ones. It spells out which methods are used to do this. Recommendations are given on diagnosing faults in a mobile device and restoring it to working order. Actually, in our very first methodology there was also a tiny little table devoted to faults like these. Now it's a serious appendix in which all faults are broken down into five types. The device doesn't power on; the image on the display is partially or completely absent.

The device doesn't respond, or responds incorrectly, to the control buttons. No response from the device to touchscreen input. And no communication with the device through the connection port. Including when the device fails to initialize in the operating system of the bench equipment. For each of these items we've laid out the possible causes of these faults. The table's second column, and the third — what to do in each case when such a cause has been identified. Sometimes, of course, it turns out that's it, the device — nothing more can be done, a brick — so write it's a brick. But that's only one or two items. So this part has been added and nicely, interestingly expanded.

Next. What should we do as far as establishing the passcode on the device, the PIN or PUK code, or the SIM card password? In the two previous talks we were cracking the password. This way, that way, that other way. But what if that doesn't work? What's needed in that case? What other options do we have to try? Well, actually, we have the motion. And the investigator can question the person from whom this phone was seized. Various methods — actually, the operational way of obtaining password information hasn't gone anywhere, and operational combinations do exist. So, among other things, this methodology, besides cracking the password by various means, establishes the types of motions: for provision of the password value for access to the mobile device's memory, for provision of the PIN or PUK code values for access to the SIM card memory. And the coolest one — for the device's user to be present at the forensic examination in order to pass biometric identification, because a number of actions with various phones, are sometimes impossible without that.

So these are provided for, and templates are given for how to do it. If they don't provide it, they don't — the expert often can't wriggle out of it, but we've provided for these things. Next: the methods and stages of extracting information from mobile device memory — these have also been worked out. What's included here? As for methods, it's low-level extraction, meaning full file system access — that's one. And second, extraction of publicly accessible data. So these methods exist, and sometimes the first works, sometimes, unfortunately, only the second does. And the stages. These aren't stages the expert must necessarily go through — one, two, three. It's what he may encounter with these methods of information extraction.

Well, like, powering the device on and off, photographing, video-recording the screen — that was the very first to appear back then: what do we do when we have to extract information from a mobile device? We had to, generally speaking, take a camera and, swiping the information with a finger, photograph every single screen. So that hasn't gone anywhere; some things still need to be photographed too. Connecting the device via a connecting cable or wireless interfaces to the expert's workstation. It includes establishing and initializing the connection between the mobile device and the expert's hardware and software workstation.

Putting the device into a service mode using test pads or the control buttons. Installing an agent program, downgrading the operating system and software version, bringing the device to a state that allows information to be extracted from it, connecting the SIM card to the expert's workstation using a SIM card reader device. So, let's say, the expert includes and goes through a number of these stages in an examination. The next thing we got again — well, the glossary of key terms and definitions has been significantly expanded compared to the methodologies that existed before. Every methodology has a glossary, but we've expanded it a little. And so on — there's no point listing everything, but quite a lot specifically about how to examine the device has been added; all these procedures are there.

What else is very interesting? Well, let's say, there's a problem we have and have always had. And the standard methodology for examining computer information says that, in principle, the resulting information should be copied to write-once storage media — everyone will have fewer problems. The investigator — how to read it later — and the expert has fewer problems too, but we're coming to the point where data volumes are growing and write-once media are no longer sufficient. So this methodology now includes regulation of exactly how the sought information is written to rewritable storage media. In what form? If the results of the examination are written to a solid-state drive or an external hard disk drive, then the explanatory label and the expert's signature are put on adhesive paper tape attached to a part of the drive that has no identifying features: the serial number, some other number — none of that.

A corresponding entry is made in the research section of the expert report, stating the identifying features of the storage medium — well, like the make, model, serial number and so on — the size of the written information in bytes, the cryptographic hash value of the information written to the storage medium. Then at least it'll be clear how to work with these things and how to write to rewritable storage media from now on. What else is new? And now the most interesting part, because this was a very problematic question, and we even held a meeting with representatives of the EKC MVD of Russia to work out a single common approach. What do we do if, in the objects under examination, we find credentials for authentication on cloud services, cloud storage, passwords for email and so on? I mean, we were literally tearing each other apart: what, we found it, we have the question, and the investigator needs it.

So they got into the email account, downloaded all they needed from there too. Got into the cloud storage and downloaded all they needed from there too. Well, there were, like, several sensible objections that, on the one hand, this is probably already exceeding our authority, because now, now, now — now, there's such a thing; I was against it too, but unfortunately, many think so. And on the other hand, it's also an additional large volume of information that the expert has to process, given that the backlogs there are huge, and working through this too... My mailbox has over 10,000 emails in it, and you wouldn't much enjoy working with it. Go ahead, pull down all the rest — little of it would actually be needed. In any case, what did we decide? First: establishing the presence of data for authentication on cloud services and cloud storage — the so-called tokens — is a stage of the information examination. We've now officially put that into the methodology, and that's important.

And then the following was decided. If the mobile device's memory contains files with authentication data for cloud services — tokens — and actually, I suppose this would also cover, and I'm thinking we might still manage to add, information for accessing cryptocurrency and other things. Although they sometimes ask for that info, and there the keys got listed fine — on internet resources, in social networks, in email — immediately, without waiting for the examination to end, once you've found it, write a notice about it to the investigator, attach that information — well, obviously — and then attach it to the expert report and note the possibility of extracting data from cloud services later on, in the course of investigative actions. So you report at once; the investigator, if he needs it, comes and inspects too. The main thing is he picks out what he needs in the given case.

And a standard template of such a notice on the presence in the examined objects of authentication data for cloud services and storage is provided in our methodological recommendations. Well, let's say, one more problematic issue that actually hasn't been resolved anywhere at all.

Much as we'd like, so far nothing seems to be said about it in Federal Law 73-FZ — yes, nothing at all. So what do we do when the investigator simply writes with mistakes? I'm not even talking about him framing the questions methodologically wrong. We don't go into that; we simply rephrase, saying the question is put incorrectly, that it's a legal question, and so on. That's not what this is about. But lots of our experts do the following. They put the questions in quotes and copy them verbatim, with spelling mistakes, with syntax errors. And why should I have to correct them? But I understand: on one hand, the expert himself may not be very literate either and may add his own mistakes in place of those.

But we resolved it this way. If the questions put to the expert contain semantic, stylistic, lexical, syntactic or spelling errors, then in the introductory part of the expert report the question wording may be edited, indicating the reasons for making the corresponding changes. So they may be — if you don't want to, don't consider yourself literate enough, you'll write it as is — well, that's one more way to show the judge that the investigator isn't very literate, and what are we going to do about that. So in fact that's the option; we decided to put all of this, these provisions, into our standard methodology.

And so, at a meeting of the Scientific and Technical Council of the Investigative Committee of the Russian Federation, this methodology was reviewed and basically recommended for use in the forensic expert units of, first of all, the Investigative Committee, then we'll publish and distribute it — well, distribute it and, in any case, bring it to other forensic expert units. It's their right to use this methodology, to cite it in their expert reports, or not to. But we've already given it a certain direction for its use. Right now I have no printed version of this methodology, because it was sent to the proofreader and then on to the typesetter, and it will be printed. But it's not a quick process. Given that at the end of the first half of the year we held the Scientific and Technical Council, at best — at the very best, it comes out in printed form by the end of the year. But we're already announcing it and drawing attention specifically to which problems and tasks we set ourselves and how we solved them.

Thank you. —

[applause]

— So, colleagues, your questions. Mikhail Mikhailovich, on my way. —

— Olga Vladislavovna, thank you. Well, I can't keep quiet. So, first. A harmless one first — just to clarify video recording of the expert's actions. That's probably connected with particular cases. I remember some of them, but please explain to the audience. —

— No, actually, sometimes there's a need to record what you did, where you went and how it happened. So why not? And not only substitution — there were complaints when they say you swapped something, did it yourselves — that too, probably. No, well, it's for when the need arises — you see, these are all advisory, recommendations in general. We'd like you to have all of this, and when you start working with it, if such a task comes up, that you have the equipment and can record all of it. But as a rule, video recording is still needed more during inspections than during, say, an examination. I'll tell you a real case: a phone comes to me, it says a Samsung phone, I open it — a totally different model. And the courts say, was it video-recorded? So the fraudster brought to court a phone on which he'd committed the fraudulent actions, but swapped the phone itself.

Well, the judge just blindly recorded it — they don't know which phone it is. And that was a real case. No, well, look, I also brought up feature phones, and a number of feature phones — old feature phones — could only be examined by setting up a video camera, a still camera. Now here's another thing: as I understand it, you didn't include smart TVs and smart set-top boxes, since you'll have some smart-home methodology, and they'll be assigned there, or how? No, well, at one point one of our respected developers made us equipment for examining them, but practically no examinations were done with it by connecting to anything. —

— Well, these days I easily go online from my TV, and video and everything else. Right, but those involve other examination methods and methodologies. So that would be some separate methodology? If such a need arises — that we're constantly having phones, I mean TVs, brought in for examination — then we'll have to develop and write such a methodology. No, in fact they hardly ever bring them. Which is why that equipment sits with me — honestly, it's sitting on the desk. But unfortunately, so far I don't see any particular need for such examinations. —

— And one more — okay, I'll end on this, I understand. So, look, regarding data that is personal: the personal data laws, among other things, allow third parties, responsibility for data lies with others, and the expert, under Federal Law 73-FZ, also bears responsibility for disclosure. So I don't understand what the problem is with presenting this data, especially if it's required. Well, as I understand it, you — I mean those tokens, what you were saying. No, there's no problem at all presenting them; it's just that the order of how to do it, and the procedure, we've spelled out. When I raised this question for myself and tried to talk it over with everyone, I even ran a little survey on Tsifropol; some there said, yes, yes, let's examine it right away as part of the examination; some of my experts, whom I still keep in touch with at the MVD, say, well, we too sometimes turn a blind eye and hand all this over in the examination.

But it was the EKC MVD department heads who said, for God's sake, we don't need this, because it'll be too complicated later for every examination. It'll complicate all this work, add to it, and our backlogs will grow again. We just don't need that in such a format. Thank you. —

— So, colleagues, more questions. There, I see a hand. —

— Hello, wonderful talk. I'm always impressed at every conference when you come and tell us about the methodology. I have a question regarding cloud storage. For example, a real-life made-up case: examining a computer running Windows, and it's syncing with OneDrive. The sync covers official documents, including documents and information constituting state secrets. We see that the sync has happened and the information has leaked to the servers of a foreign state. How should the forensic examination be conducted and written up in this case? —

— If only I'd caught all of that. —

— On the question of examining classified information, you know, well... No, the situation is that the computer is syncing with OneDrive. That's standard practice on Windows systems, if it hasn't been turned off. And the sync happened with documents — official ones, for example "for official use only" (FOUO), of various kinds. How do you write up the forensic examination in this situation, if we know that these documents have leaked to the servers of a foreign state, and OneDrive falls under laws like FISA or the CLOUD Act, which... The problem is that such documents shouldn't be on such computers at all. That is, a person's internet — I mean, a computer that goes online must not contain any FOUO or classified information — none whatsoever.

If it leaked, of course, you must report that such information is there, because it's simply a violation in itself that such information exists on such a computer. Second, if you see that it leaked, you absolutely must report that. Here there's not even any disagreement in understanding that, yes, these documents are also sitting, among other places, in cloud storage. But as a rule, still, let's say — inspecting cloud storage clearly has to be part of an investigative inspection. So, as part of an inspection. That inspection procedure exists. With video recording, naturally.

Yes, video recording, absolutely. But actually, our biggest problem isn't that; it's whether our experts are cleared to work with information involving some state secret. —

— Well, let's say they do. However many times we raised this issue back in the day, we were told: well, you must have a specialized hardware-software system that is certified, tested and so on. And we say, wait, wait, that's all fine for working with such documents, everything we have is certified and so on. But when they're set up so that no other documents can get into them — files that aren't meant to be processed on that computer — that's a very serious problem, and we can say that there's a file with such-and-such attributes, such-and-such markings and so on, and nothing more. But unfortunately, we have no other option. "Possibly containing." Always "possibly", right? —

— "Possibly containing." Well, that's how we write, right? No, we don't even say "possibly containing". We say there's a corresponding classification marking. Actually, I know perfectly well that if a person needs to keep everything on a computer — I'm not talking about anything classified, even just an FOUO document — he simply goes and wipes out the relevant numbers, markings and all the rest, and keeps everything else. And you'll never determine whether it's classified or not. Thank you. —

— Right, colleagues, one more question. Nikita, over there, I saw a hand go up. —

— Yes, San Sanych.

Tell me, please, about the Scientific and Technical Council. Is it working on describing and creating a standard mobile forensic laboratory that would bring together all the main tools, like those from MKO, Elcomsoft, ELETEK? And are there any thoughts, let's say, about methodologies? Thank you. —

— So, the Investigative Committee's Scientific and Technical Council — like, in fact, any such body; we have them at the Russian MVD too, and I think at the FSB — everywhere there are certain bodies that review and approve; they don't develop anything. If I, as head of a certain research department, together with the experts who work with us, with the Investigative Committee Forensic Expert Center — we developed this method, we have the right, and we refer it to the scientific and technical councils, which then recommend it. So it's advisory in nature. What you're talking about gets developed, let's say, not within some scientific paradigm; as a rule, it all goes as an annex to a state contract.

And it would take you a very long time — as I say, today we have one vision of this equipment, six months later another; say two companies started cooperating, and now we have a different little label, a different name for the software everyone uses, and then they went and fell out, and now we've got two different labels again, and we need both of them. In general, actually, we always have a problem between what we want — and what we want is for it to be one, two, three, done. Software products partly have the same functions, but this one has one bell and whistle, that one another, and I need both. And it's always very hard when you're allocated a specific sum, no more, for procurement — to fit into it with your bells and whistles and justify that today I want Mobile Criminalist, and tomorrow, somehow — what if Cellebrite comes back, then I'll want Cellebrite.

It will all depend on the market and what's available. What you mentioned, the development of systems — yes, that's basically a separate research effort that's commissioned, and within the MVD it's easier to do: they have a special unit, "Special Equipment and Communications", that handles contracts. I acted as the functional customer. I'd say, I want to develop such-and-such a hardware-software system now. Functionally it must include these things. And our contractor, who enters the tender, develops both the description and the designation, and presents a prototype. We test it. And we say, all good, great, it's adopted into service with the Russian MVD. A year later everything's different — well, not everything, some of it; they come and say, let's refine it now, change this here, change that there, now your system will have this configuration.

Well, let's change it — tests again, all the rest. We say, yes, this suits us, now we'll be procuring equipment with these specifications. That's not science — it goes specifically through development (R&D) work. —

— Olga Vladislavovna, thank you very much. Let's send her off with a round of applause. That was really great.