Heather Mahalik: Hello, everyone. Welcome to Preparing for Court Testimony. This is a product that we worked on at Cellebrite; and Paul, Ian, and myself are here to share some hints and tips and best practices with you on what happens when you press a button on one of our products.
When you find yourself in a jam, and I love this little graphic here, because it’s literally, we’ve all been there: you’re in a pile of work and suddenly you realize you need help. This could be because possibly you have replaced someone who did the initial investigation or examination, and you have to testify to it.
It could be because you work on a team of people. I have experience where we had people remotely do all the acquisitions and then send us the data, but we would have to speak to how the data was acquired. So there are lots of moving parts in digital forensics, especially mobile.
So we want to guide you with this documentation on what happens when you press that button; whether it’s UFED, Physical Analyzer, Reader, Pathfinder, Digital Collector, Inspector. These are the products that you really want to be aware of if you say you’re going to perhaps get a full file system extraction.
What does it do? What does that mean? What traces are left behind? What if you conduct covert operations? What if you are required to leave the trace behind, but there’s a setting that will automatically remove it?
So documentation is key, best practices are clearly going to be in place, and even though we are providing you guidance on what happens when you press that button, clearly your SOPs and your departments and your organizations matter. So you want to make sure that people are aware of this document.
I would recommend, and I don’t know if Paul and Ian disagree, but printing it and having it with you so that if you find that you’re testifying to something or you’re in a deposition and someone says, “Well, what happens if a boot loader is installed on? What does that mean?” You would have a definition or something in front of you that you could actually explain that.
The details. Now, this is a direct quote from the intro of our paper that we put here. “It is your responsibility to testify to the integrity of these tools.” So what that means: when an update comes out, when something changes, it is up to you in your organization to understand one: what was updated? If bugs were fixed, what does that mean? Do you have test data that you can actually validate it against?
And all of you should have test data. We at Cellebrite release CTF public images, Josh Hickman releases public images, Magnet has public images. There are so many out there that you can use that you should be able to test, trust, and validate. If you’re unsure of what the CTF data included, look at the walkthrough blogs we also released.
So there’s a lot of public information. Josh Hickman’s extractions come with a PDF file saying, “This is what I did and this is when.” So again, validating the extraction as well as the parsing is really important. There are simple things that will make your results vary.
For example, when we talk about some of the decoding, if you don’t have a checkbox for deep-carving SQLite, your results may look different in-version. So you have to control the settings of your tools, as well. Our goal is to provide you terminology, methods, and just essentially try to make you a little bit smarter on knowing what happens when you press the button.
Final thoughts for me here, and then I’m going to pass it on to Paul, but key points for you: again, adhere to best practices for any of the UFED extraction tools. So no matter what you’re doing; if you’re extracting cloud, if you’re extracting an iPhone or an Android, you need to understand best practices for these devices.
You also have to understand what happens if you have a mobile device and you don’t isolate it from the network. So all the things that could go wrong, you know, at some point they will go wrong. Make sure you understand all the things like a wipe that could be waiting on that device.
But then you also understand that there are some third party applications that require a network connection. So you may have to do more than one extraction. You may have to, for Instagram, for example, if you need messages, you may have to extract the device not connected to the network and then risk it or do it in a safe way or pull cloud data to get the rest of that data set.
Ensure that your data is securely collected. Make sure you’re not working from only one copy, ever. You’ll read everywhere the gold copy. You want to have additional copies of your evidence that you’re working from.
And the write block thing. You cannot write block a phone. I’ve had many people reach out and say, “Well, my phone isn’t seen by the UFED.” or, “My phone isn’t seen by the computer.” And that’s because you cannot write block it. You could write block an SD card or a micro SD card or any kind of storage like that from an Android device, but you cannot connect this through a write blocker.
So changes are always going to be made to mobile devices. And it’s your job to document what occurred. As far as documentation on this, and this is in bold and it’s very important; what we are telling you today, what we wrote in the document, what we’re sharing with you, is relevant for these versions on these dates. And obviously technology changes, our software changes, everything evolves very quickly. So please, please, please test and validate.
Paul Lorentz: Thanks, Heather. Great introduction summary. Of course everything that starts, it always starts in extraction. That’s where all of the data starts. Before your examinations, investigations probably start, there has to be an extraction.
Today, nowadays there is, we call it alphabet soup, that there are various different terminologies, acronyms being used, whether it’s a hot / cold, AFU / BFU device, understanding what those are is going to help you understand kind what you can and can’t do. Understanding what those acronyms actually mean.
For example, AFU, a hot device; a device that’s been powered on, that the password, even if it’s locked, it’s been unlocked at least once, it’s a less secure device than a device that’s been powered off and then you finally turn it on. Let’s say if it’s been sitting, the battery’s been completely drained and it’s a BFU device as soon as you power it back on if you don’t enter the passcode.
If you want to do a little simple test yourself, if you have a phone that you leave not plugged in overnight, you wake up in the morning, the power’s off. If actually someone calls you after it’s first turned on without actually unlocked, their contact information is not going to actually come up there. That information is stored in a different part of the phone. That’s actually more secure as part of encryption.
So again, so these terms are used to describe the way that the device state is in. Different types of state of devices give you different access to those. So again, there’ll be a few devices, the device right before — as soon as it boots up without the password being entered — the data’s not decrypted, there’s still some data available to your device to function, but it’s not going to have sort of the usually the goodies, all the stuff that you’re coming after.
A device that’s hot or in an AFU state it’s, even if it’s been locked, it’s a device that the password’s been entered at least once, encryption keys start to get loaded and data is decrypted. Even though the data’s been decrypted, parts of the data are encrypted.
So again, understanding what state the device is in is important because it’s going to determine what you can and can’t do when it comes to that.
Which kind of spins off into this: understanding the different types of extractions. There’s lots of information that we have available — not as part of this, in the document we do have share information about extractions — but understanding that there are different types of extractions; whether it’s a partial extraction, which can include an advanced logical, a backup, a file system; potentially an AFU extraction, cold or BFU extraction; selective extractions, understanding that those aren’t generally full types of extractions.
And then on the spin-off of that, full extractions, like your physical extraction, your full file system extraction and your physical are using a boot loader. This is done by JTAG or ISP or chip off. Again, these methods are less and less relevant when it comes to new technology with encryption coming in. But again, they’re still possible.
Just as you can see in the little graphics here, your advanced logical uses API posts. So it sends a command, you know, through an application to the phone saying, “Hey, give your messages. Sure, here they are. Oh, can you give me your emails as well? Well, sorry. No, you can’t, you don’t have access to that.”
So understanding that the different type of extraction you are going to try to intend on a device is going to give you different types of data that results from that, which is good to understand ahead of time because if know you your investigation’s going down a certain path, you know which type of extraction you should be trying to get from the data you’re trying to go after.
And again, understanding the differences between the way that iOS and Android behave is different, as well. That advanced logical extractions in iOS leverage the iTunes backup protocols. And then if you want to try to get the richest type of extraction, which is going to be your full file system extraction, whether it’s through advanced unlocking solutions or through Checkm8, which isn’t directly available, or other jailbroken devices.
But again, understanding, and knowing what to do with those extractions, how to get to that to kind of squeeze every single or every little byte of data that you can possibly have is going to help you determine kind of the type of access that you can get, the type of data that you get, which spins right into encryption.
Encryption is not going away. It’s something that we as a society broadly we’re going to be living with every day. As examiners, it’s going to make life a lot more difficult.
When it comes to decryption data of device information, there’s always going to be a device key and the user key, which is generally the password or password PIN pattern, often numeric, whichever type of password it is. Those put together actually become the decryption key. You add that with the encrypted data that’s on the device, gives you the decrypted data once it’s done.
Again, the industry’s pretty much shifted away from full disc encryption where there’d be one encryption key for the entire memory range where now with file base, every single file has its own encryption keys. So data recovery becomes much more difficult.
Understanding that, you know, what happens when a device picture gets deleted? Well, it still stays active in unallocated space, but realistically, trying to get access to the decryption key for that one specific file when a phone has hundreds of thousands of files on it could be definitely difficult.
So knowing your device, knowing the type of extraction you get and knowing how the encryption actually will affect your extraction and also the decoding, which Ian’s going to be speaking about next.
Ian Whiffin: Okay, so thank you, Paul. As he just mentioned, it is possible sometimes to recover deleted content. Typically it is going to depend on the type of extraction that you have. So a logical extraction where we’ve done API calls for messages or for photographs aren’t going to give you the opportunity to to recover any deleted content, but a full file system or a physical extraction probably will get you some kind of deleted content.
But it really depends on whether the content is completely deleted or whether it’s marked for deletion. So if you just sent something to the recycle bin, for example, or deleted a photograph, you may still be able to get it back for, you know, 30 days or so.
Or, as we’ve said here, if you have a NAND level physical extraction, we can actually look and pull the data and reconstruct the data at the very, very base level. Although pretty rare that that’s now going to be possible because of encryption.
One of the other things we wanted to really highlight in this paper is the difference between decoding and parsing. So decoding is the process of taking the data from the device in its pretty raw state and making some kind of sense of it. So that could be taking a plist and showing that data in a way that kind of makes sense in a node-based tree, taking a file and showing it as a database view that you can then search through and filter, or even decrypting files.
So once the data is taken from the device, it may still be encrypted. Documents like Snapchat photographs, for example, have their own method of encryption, additional to what the phone has itself. So all that comes under the decoding and decryption section of the process of using a tool like PA.
Moving on from there is the actual parse, and that’s where it takes the decoded data. And based on research that’s being conducted by humans they work out okay, how do we want to view this data in a way that really will make sense and benefit the investigator?
So we start running SQL queries, we start bringing in data from other sources. You might want to, for example, take the SMS database and the contacts database and see how they work together to create a view like you can see on the right there, where you have a conversation thread.
Although, because this is data that is researched by researchers and developers, when an app changes, it can completely break the tool’s ability to parse the data, and that’s going to require further research, further coding, and then time for it to be pumped out to all the users.
So in those cases where a change has occurred, PA or whichever tool no longer parses that data, or it’s an artifact that we don’t support in the first place. PA includes additional tools in the form of file viewers in SQL Wizard, the Carvers, and the App Genie, things like that. So you can go in and look at the data manually, try to make sense of it and include that data in your report, even if the tool itself doesn’t support it.
It is also worth bearing in mind that some of the data presented in these tools doesn’t come from the device itself. BSSID enrichment, cell tower enrichment, reverse geolocating. So take a GPS coordinate and change into a physical address. These are all features that typically come from external sources similar as it mentions here, languages and media classifications.
So if you were to take an extraction and run it in one of our tools and run it in a separate tool, some of that data may appear different. And that is because of the external enrichments that can be applied to that data. So it’s really important to understand; if you have an artifact, is that from the device or does it include data brought in from elsewhere?
Heather: That was an excellent point, Ian. So how do you know what you can do? Verification. And there is a paper that the three of us actually worked on, ironically. It’s called The Six Simple Steps to Mobile Validation. It’s hosted on the SANS website and it’s free for everyone and it just talks about ways to conduct verification from everything, from acquisition through analysis. So literally the beginning to the end of a mobile device investigation.
There are some simple things you can do: hashing. So, hashing, you can get a hash value to see if a file is the same. When I work malware investigations, hashing is a huge part of that.
Now, with a lot of media files, or if we think of pictures, videos, with all the trimming and sharing and stripping that different applications do to these graphics, that may not be as easy or relevant. So you may be forced to compare the data. Maybe this is in two tools, maybe this is in two commercial tools, a free tool in Physical Analyzer, if you export the file and look at it natively.
So there are many things you could do. If you think back to Ian’s slide, where he had the parse data and the raw data, don’t be afraid to compare the data to the hex or the database or the native plist. You don’t always have to leave your tool. And that’s something that’s very important that is discussed in that paper.
Timestamps are confusing and we’ve done Ctrl+Alt+Delete on timestamps, we have done Tip Tuesdays on timestamps. There’s lots of documentation on it, but you have to understand how the tool could possibly be giving you a timestamp that causes confusion.
A good example: 1/1/1970. If you see that as the day I sent Ian a message, you’re like, “That doesn’t make sense. Heather didn’t have an Android or an iPhone on 1/1/1970.” It’s because if you look at the actual database, if you go and click on the source and follow it to that database, you would see that it has a zero in that field. Meaning zero seconds from 1/1/1970, which is 1/1/1970.
So a lot of people will see that and say, “What is this? My tool is broken. It’s not working.” It is working, it’s just, you need to take that time to go and validate the timestamp.
When iOS 11 came out, Apple introduced 18-digit timestamps, instead of just nine. The tools lost their minds. It was chaos because imagine one column and the decoding aspect of that didn’t work, right? It wasn’t able to be parsed. So all those steps that Ian discussed with you were broken, and that could happen. We know that Apple and Android, things change quickly on these devices.
Now, the final one is something I’ve always said since before I joined Cellebrite, like, for years, if you’ve ever seen a presentation: trust but validate. Do not trust us, do not trust the tool, do not just 100% rely on any documentation. Trust it, have faith in it, but prove it to yourself by just making sure that something that is going to make or break your case is actually correct. And it belongs on that device and it got there for a reason, you can put someone or something behind it.
Paul: Thank you, Heather. As we know, using a tool doesn’t make you an expert witness. If your position and title makes you provide testimony in court, the title of expert witness, which is often called upon, it varies between jurisdictions of kind of what the bar has set.
Oftentimes it’s someone that has a much more advanced knowledge of a certain topic or a specific expertise. Some of that expertise, you’re not going to get just by doing just your own testing. You do need training, you do need certification. There are different courses that are available through Cellebrite, through other mediums to be able to go through this. Again, to be able to understand and demonstrate your ability to test, to validate, to understand the artifacts. You’re never going to be able to speak to every single artifact of, how does this happen?
You can test in certain similar situations. As you’re doing that, take documentation, write that stuff down. You have to keep an up-to-date résumé, your CV has to stay up to date. So when you do get called to court, or if your position does call that you go to court, it’s important that you are showing that you’re not presenting training or certifications that are no longer valid or relevant. This stuff has to stay up to date. And again, it’s not the tool that makes the examiner, it’s the examiner that makes you the expert.
Ian: Yeah, thank you. And part of that process to convince the court that you’re qualified to speak as an expert in these matters, they’ll be asking questions about your CV, about the tools that you use, about the experience that you have. Some of the simple questions that you really should be able to answer are, what is Cellebrite UFED? What training or certifications do you have? You know, what information can you get? What did you get? And did you validate and test your findings?
Bear in mind, the people in court; the judge, the jury, they don’t understand digital forensics. They may understand using a device, they know what it looks like from a user point of view, but they don’t understand all the work that goes into the back-end to prove, you know, why that data is there and what it means for the case. And it is your job to really convey your experience and knowledge to everybody in that courtroom.
And that’s pretty much it. The paper itself contains much more detail about each of the topics we’ve touched on today. And we recommend you go to this address at the bottom, cellebrite.com/en/resources and take a full read for yourself, and we’ll hopefully answer a lot of questions or give you ideas of what you need to look into prior to testifying at court and give you an idea what will be asked and what’s expected from you.
