My first post ought to be about a subject I spent years working on. Little did I know what I expected to be a straightforward forensic examination of a wiped LG phone would result in so much — becoming a pivotal piece of evidence that contradicted the suspect’s alibi, my first real foray into reverse engineering Android APKs, the subject of several presentations, and even getting published in a technical op-ed in the INTERPOL Digital Forensics e-Newsletter.

In recent times, location tracking data from iOS has come to the forefront with the work of people like Sarah Edwards (@iamevltwin), Phill Moore (@phillmoore) and Alexis Brignoni (@alexisbrignoni). Turns out, LG’s tracking us too – except they’re trying to be sneaky by obfuscating the data that’s tracked with numeric column and table names. In reality, I think it’s likely that all the mobile vendors are doing this ‘diagnostic’ tracking and it’s just a matter of time (and forensic examinations) before that data gets uncovered. LG does give an explicit warning that this is going to happen regardless, but most people decline to actually read this stuff.

Like many other forensic examiners, I get so focused on completing each examination that it often feels insurmountable to then go on to share my findings with the community, or that the work I did for a file today may be useful in countless other files out there. But with enough years of doing this, and enough opportunities to network with other seasoned forensicators across the globe, it has become clear that we are often trapped in a perpetual state of unnecessary wheel re-invention.

Enter the Magnet Artifact Exchange, a ridiculously needed sharing piece in the digital forensics community, which I only came to know about in the last couple of months. Since learning about it, I’ve had a strong desire to start developing custom artifacts for it, and so today I officially submitted my first of them.

So let’s get down to business. What is LG MPT? It’s a background service that is mostly invisible to the user that runs on LG-Android devices since atleast Android 4.4.2, and as recent as Android 8. It resides on it’s own partition (cleverly named ‘mpt’) and is enabled by default and difficult to disable. On the tiny island of a partition there’s a database or two, the biggest being ‘LDB_MainData.db’, with a LOT of tables with unhelpful names like ‘t301’ and so on. As you can see from the screenshot below, the columns aren’t much better, each one starting with ‘f001’, ‘f002’, and so on.

If you start browsing the data you come across some extremely data-packed tables such as t312:

So where do we go next? Sure, f002 looks like a timestamp. Sure, f006 and f007 looks like MCC/MNC, but are we willing to get up on the stand and point the finger based on what we THINK data might be? Of course, we need to flesh this out much further. One of the easiest things to do here is a trick Paul Sanderson (@sandersonforens) taught me and that is check for TRIGGERS in our database. Sure enough – descriptive words – hooray!

Keep in mind, the word ‘limit’ on the end of each of these is describing the trigger whose purpose is to hard-cap the amount of rows in each table. But the former pertains to the table as well. You can’t see t312 in the above list, but it’s gsm_cell_info. Even with size limits, these are obviously data intensive logs. This trigger ensures that it automatically purges content once it hits a certain size. But let’s be honest, it still tracks A LOT. And does not get wiped when you wipe your phone. Makes you think twice about selling an old LG phone doesn’t it?

To determine the purpose of each field, one must do some reverse engineering work. You can use the tool of your choice, and this post isn’t going to go so in depth as to explain the entire spectrum of APK decompilers, but I will say this from experience — don’t think that APKTOOL / learning SMALI (think of it as an Android equivalent of ASM) is the only way to do this. There are some incredible APK -> Java tools out there that make it so much easier that I wish I had known about way back when.

Instead, I am going to link my research paper which details the process I went through to discover the purpose of each table. Keep in mind, my research was for MPT as it existed back in Android 4.4.2. It’s changed since then — mostly in the sense of adding more tables. A LOT more tables in fact. But the premise is the same if you’re looking to prove what certain data is.

One golden rule when dealing with MPT is that F001 is always ROWID, and F002 is always a Unix MS timestamp, no matter what. After that, things diverge for each table. Some of them are very self explanatory (like the ones that show the current Android version and fingerprint, etc) while others are as subtle as saying a single number which is representative of an enum that you can generally lookup on the Android Developer Documentation.

Anyhow, here is the research paper, I hope you find it useful. The most helpful information is in the first few pages, after that I get into a table-by-table look at what each means. I’ve submitted one artifact for t312 (mappable cell tower data), to Magnet Artifact Exchange as of today, and I’ll be adding more as time permits.

Finally, a sneak peek at the result — reviewing MPT logs directly in-app with Magnet AXIOM. Coming to an app near you!