Burning the new Burner (Part 1 of 2)

Posted on January 12, 2020 by Lee Reiber

In this two part series I take a look at the start of a new investigation hurdle in mobile forensics; a device running KaiOS.  The first part will simply introduce the group to a minuscule amount of KaiOS history and architecture and extraction and the second part to the parsing and decoding.  So, let’s get started!

It was not long ago I was dealing with the burners of old like the Kyocera SE47 and KE413, Sanyo SCP-4920, Motorola T720 and V120x, and Nokia’s 3570, 6370 along with many others I am sure you can resurrect from your memory.  The connection to these devices and the lack of support from the few vendors often left one simply photographing the screen or manually digging through the data (if you were lucky enough to obtain it). If you remember BitPim and traversing the filesystem manually a big high five; and a big bonus if you know what I am talking about when I say BREW and not think of your favorite IPA, pale, or stout.  If you did think of a nice beer, jump online and pick up my book Mobile Forensic Investigations where I talk bout that pesky operating system of old.  Very few devices are still around running this type of OS and most investigations simply deal with Android or iOS so you can give a big sigh of relief, but the burner of today is just as tricky.

Today’s examiners now have to deal with KaiOS and the devices that are running this Boot to Gecko OS (B2G OS). This operating system is open source and a fork of Firefox OS, and as we dive deeper into the data on these devices you will see why this operating system can be referred to as a web-based mobile OS.  KaiOS was originally developed in 2017 to give feature phones (non-touch) a way to give a smartphone look to a feature phone, bringing the smart feature phone to life. Google owns much of the US based company as does Reliance Jio who sells more devices world wide running this OS.  Built with access to the KaiStore, users can download and use apps that are built specifically to run on the operating system.  More and more apps become available daily adding another level to the investigation of these devices as currently most companies in the forensic industry do not support the parsing of third-party apps from this OS.  Investigators should be prepared to deal with these devices as their popularity and low cost drive a new industry around the world with over 30 million phones using KaiOS.

The technical aspects and operating system in a nutshell must be mentioned if not for the fantastic names given to the various levels of the operating system.  At the lowest level lives Gonk where the Linux kernel and associated members thrive and drive the KaiOS stack as the interface between Gecko and hardware. It is Gonk that controls the hardware and is the gatekeeper of this level.  Gecko is the KaiOS runtime and is the engine that renders/controls/operates the HTML to hardware as the interface between the content (web) and the device. It is here that the parsing and rendering of HTML5 is provided and the API are exposed to communicate to the functions of the hardware.  The final or front end of the KaiOS device is what the user interacts with and this is Gaia. Anything that the user sees on the device is the Gaia layer and uses HTML, CSS, and JavaScript. This layer is a basic layer with operation using the mentioned web protocols but also can interact with the device hardware using several available APIs.  For any Greek mythology buffs you might be interested in Gaia and the name origins.

Figure 1. KaiOS architecture (https://developer.kaiostech.com/introduction/architecture)

In simple terms KaiOS is a transactional and active web connection and rendering interface with an extremely small footprint taking up little power and storage.  This gives manufacturers flexibility in the form factor for their produced devices and honestly the ability to produce an internet ready device for an extremely low price bringing in a completely new vertical– customers that either cannot afford a traditional smartphone or want a throw away device (AKA burner). 

Extraction

Often the most difficult for mobile forensic investigators is the collection of the device.  In the case of KaiOS devices it is a mix; the extraction logically is uncharted territory by tool vendors and it has been found to be much easier to simply obtain a physical collection.  Why is this you ask? Let me cover briefly some of the anomalies with devices running this emerging operating system.

  • ADB is available after USB debugging is enabled, and basic information can be obtained with the typical ADB command interface.  
    • However, since this is not an “Android” device tools are unaware of how to query to obtain the most basic of data (e.g., calls, SMS/MMS, contacts) by using an agent.  
  • Binary collection is unencrypted and by enabling download mode on the device running KaiOS a full physical is obtainable.
  • Web based data has storage principles and locations not like a device running Android and tool manufacturers are having to R/D from square-one.

So, if you can easily obtain a physical collection then what is the big deal right?  Well, it comes down to parsing and decoding of the data; most forensic tools in the market are having a difficult time.  The information on parsing and decoding will be covered in part 2 of this document. However, let me cover a general method of obtaining at least the binary image from a KaiOS device.

Debugging

The first addition of the KaiOS devices that hit the market in 2017 and some of the Reliance Jio devices can be put into debugging mode by using the same method as other Android devices.  Navigate to the device information and click on the build version to then show developer options. It has been my experience that the devices sold in North America as “Burners” do not have this option and an engineering passcode has to be used.  The code *#*#33284#*#* (spells DEBUG) entered by dialing will place the device into debugging mode and once connecting the cable the device will be visible in the Device Manager. This has been tested on the most popular smart feature phone Alcatels (MyFlip (405), Go Flip/QuickFlip(4044), SmartFlip (4052).   With all these devices ADB was enabled and I was able to query and communicate to the device via the command window with ADB. (More on this in Part 2)

Extraction

Obtaining a physical is as simple as placing the device in download mode and running your software of choice so long as it supports physical collection of devices with Qualcomm Snapdragon chipsets 210 (MSM8909).  Some software simply allows using a cable, commonly referred to as an EDL cable, but I have found many of these Alcatels have to be forced into download mode then connected.  Make sure before beginning the process to download and install the Qualcomm QDLoader driver if your software of choice has not preinstalled these required drivers. Here is a location of a guide on how to install a setup package and also what should be expected in the Device Manager when the attached device is recognized. 

Figure 2. successful installation of QDLoader drivers

Remember the device will not be recognized until plugged into the examination computer. So, by using a combination of key presses with the Alcatel device and then plugging the device into the computer running your collection software we can obtain a full physical.  With the Alcatel devices follow the following steps:

  • Remove the battery and then re-insert the battery but leave the device off.
  • Press both the + and – volume keys (simply press between them both).
  • Plug the cable into the device and then while plugging into the USB on keep the volume keys depressed.
  • The device will start up and goto the download mode screen on the main LCD.
  • Press the volume up + and the screen will go black.
  • Continue to hold for approximately 10 seconds while drivers will begin to load
  • The device will then be located under the ports section in the Device Manager
Figure 3. Once installed the driver can be found under Ports

Once the device is recognized in the Device Manager, the device can be collected at a physical level.  In this instance I used the Jio Profile in Oxygen Forensic Detective to extract the partitions into a binary file.   The binary file was then processed and decoded in the same solution.

In PART 2 (and the most important) I will walk through the parsing and decoding of the data and where to look for some great artifacts.

Thank you, look for Part 2 soon! Until next time, and never stop learning!

Posted in Information | Tagged , , , , | Leave a comment

I am back from Dagobah

Posted on April 25, 2018 by Lee Reiber

Not that I have neglected anyone, but working on the 2nd Edition of my book, Mobile Forensic Investigations as well as working to help grow Oxygen Forensics, Inc. I have been a bit busy. Furthermore, the travel is part of my world so that also makes it rather difficult to concentrate on getting things out, but I can not contain myself…

As I sit on the plane I started to watch a webinar that had been sent to me a bit ago to watch since it related to SQLite databases. So, since the WiFi is not working and there is no personal entertainment I felt it was time to watch! This particular webinar was about a new feature in a commercial mobile forensic tool that allowed for the building of queries to support applications that are not auto parsed by said application. This is particularly intriguing since I actually wrote a C# tool called SQLQuery Builder a few years back and I happen to really enjoy SQLite. What could go wrong… I found out a lot.

As it started, and I was introduced to the new feature SQL Query Builder (yes, I am not kidding the name was familiar), my mind started to spin.  More to the point, as the presenter picked out the com.android.providers.media package I actually went into spasms of delight because that is my favorite app to talk about within an Android.  In fact I talked about that app in my Mobile Forensic Minute episode 109 that aired February 2017. I also talk a lot about this in the book released in 2015 (2nd edition soon!) and my presentations because it is a great file that is created by the built-in mediascanner for android. Alas, this built in function was not mentioned by the moderator, nor was the very unique naming convention of the file (HINT – its a serial number) FIGURE 1. I was on the

 

Figure 1: Directory of com.android.providers.media

edge of my seat to see just what this moderator knew about this file, but I was disappointed to say the least. Well, it just got worse when the method was shown on how to convert the seconds since column to a regular date.  The conversion worked but the outcome caught the moderator off guard. I immediately cringed when it was not explained why the added date was BEFORE the modified date? Humm, how..wait…what?  Luckily people were on mute and could not ask as the presenter quickly went by and just said more research was needed as to why that was the case. FIGURE 2

 

Figure 2: date_added table and date_modifed

As the presentation moved to the Query builder I was really fascinated because, as I had previously mentioned, I wrote the SQLQuery Builder.  So, the presenter mentioned the primary key and foreign key relationships (although using other names) and as he added tables he showed the SQL command was automatically building in another window.  Wow, just like the SQLQuery Builder I had wrote back in 2015 and blogged about in Not Your Ordinary App (Part 2) ! It was like dejavu!  Alas, mine along with Oxygen’s SQL Viewer will do multiple db files, which this tool might do as well; I just did not see this demo’d.

Don’t get me wrong, I think having tools that can support applications not supported is not only cool, but a necessity. So,  If you know me at all, or have read any of my materials for the last 15 years you know I preach against the push button mentality.  My only recommendation/advise to those selling/teaching this tech: know what you are talking about before you present it to the world and give credit to those that do.

 

Posted in Information, Training | Leave a comment

The Forensic Kill Chain

Posted on June 7, 2017 by Lee Reiber

I introduced my kill chain concept to a great group at TechnoSecurity this week. It is a concept that I mashed from the military definition as well as that of the 2011 cyber kill chain of Lockheed Martin.

The developing concept comes down to a failing belief that one can just “wing it” when conducting digital forensics, particularly, mobile device forensics.  Understanding my concept is both offensive and defensive in nature, an examiner (both as a defense expert and state expert) can quickly see what areas can quickly cause an investigation to spiral out of control.

We walked through the process of knowledge -> preparation/deployment ->analysis -> conclusion/documentation -> presentation/assessment as displayed in the graphic.  By understanding a break at any point in the chain can ultimately jeopardize the case/examination the attendees quickly realized current procedures need to be updated and/or actually created.  Ending the lecture on an actual case study in which a break in the forensic chain resulted in an acquittal-again offensive and defensive measures.

I outlined to the attendees that this concept is theory and to be used as a guideline to better the processes and procedures that currently plague mobile forensic examinations.  Many procedural modifications can be inserted into this model to overcome additional pit falls, but the fact remains – we need to be and do better.

My subtitle says it all :  The strongest missions rely on the strength of the weakest link

Identify your weakest link in the forensic kill chain and work hard to make it stronger each examination.

 

Posted in Information | Leave a comment

Mobile Forensic Minute

Posted on December 12, 2016 by Lee Reiber

I will be starting a new weekly video series called the Mobile Forensic Minute. This will be hosted on The Mobile Forensic Investigation Facebook page and announced on the @MobileDeviceESI Twitter account. Follow and share both to keep up to date on the broadcast each week.

The idea behind MFM is simple: Get out some information to the community on mobile device forensics that can be expressed in a minute. We all have busy weeks and being able to watch a video in a minute or less that may help in a case, help start your week off with some education, and help to keep you current could be of benefit right. This is not an interview show, but just a simple minute of your time to express my ideas on mobile forensics, excerpts from my book, or other items that come to mind.

With my constant travel schedule it could be fun to do some shows in cities like Beijing, Hong Kong, Dhaka, Singapore, London, and many other fabulous places. Remember it’s only a minute of your time!

Tune in. Should be starting it up this week.

Posted in Information | Tagged , , , , | 1 Comment

Not Your Ordinary App (PART 2)

Posted on October 25, 2016 by Lee Reiber

cyber-securityIn the previous post we discussed the need to be vigilant in the analysis of app data obtaining from today’s mobile devices. Furthermore, I made it clear that mobile forensic software is not the end all solution to your app overload as a forensic examiner. The probability that an examiner will be faced with the dissection of an unsupported app is quite great. This post will take it a step further and help to point out, at least in a most basic way, how an examiner can uncover valuable data without relying on the automated solution “at all costs”.

In this bloggercise we will examine a SQLite database from built in browsers of both Android and iOS file systems. As I mentioned in the previous post, the examiner has to go the extra mile if they are to find the 0’s and 1’s in the digital haystack. These examples can be used with any SQLite database that an examiner might run into during the investigation.

Let me first state, running a set of search queries to identify relevant material for the case is a necessity. I find it extremely beneficial to use Oxygen Forensic® Detective to search a list of words not only over the database, but also within the files. Searching within files is a necessity to uncover strings within database files that are not fully supported, not supported at all, or simply not decoded. This way the examination has a clear scope and wandering around the file system is keep to a minimum with hyper-focus.

Figure 1: Search for email addresses

Figure 2: Database within an app that is fully user action created.

Once you have your hits and are focused on the files of interest the examination of these files can start. In my example in Figure 1 I used a regular expression ((\W|^)[\w.+\-]{0,25}@(yahoo|hotmail|gmail)\.com(\W|$)) to search for free (i.e. gmail, yahoo, hotmail) email addresses in an effort to uncover any additional addresses of interest. With this search I uncovered an email address within a database file within the Android built in browser. What is interesting is the fact this database is not the stock database for the android browser, but rather a database created by the application for storage of mobile enabled websites. “What? You say a website within a browser that stores data?” Much like a Russian hallow doll that continues to contain a replica of the doll that housed the smaller doll, and so on. Browsers are ripe with databases similar to this example when the WebKit platform is utilized. The fact that these types of databases are not processed by mobile forensic solutions is an important fact to remember. So, if a user used the browser to surf their Facebook account, the examiner will surely miss this data if they are simply looking at the Facebook app that was parsed by the mobile solution. This is a nuance artifact housed in this particular Android browser that very few even realize or even understand. Again, the critical take-a-way is to comprehend the idea that modern mobile browsers from iOS to Android are packed with these user created manifestations, but few solutions have the ability to even recognize this valuable artifact, let-alone automatically parse the information.

Take for example the file in Figure 3 viewed in Oxygen Forensics® SQLViewer. This file hosts content (yes content) of gmail messages. Not just the snippet HTML but the actual message in it’s entirety. Granted, the data in the database is only going to be the most recently cached emails when the user visited their email account, but it is possible it contains information critical to your case and no modern tool at this date will parse and decode this information automatically. This is not the gmail app, but the user accessed their gmail page from a browser. Now, since there are multiple tables that make up a database file, and Oxygen Forensic® SQLite Viewer can execute SQL Queries, but will not build without knowledge of SQL I use another tool in conjunction. Yes, this means the expert must take additional steps to decode this information.

Figure 3 : Single table of Webkit database found in Dolphin Browser for Android.

Using the CPDForensic SQLQuery Builder I am able create complex SQL queries and JOINs, convert date/time, and more. By JOINing TABLES within the database, the expert can make sense of the data quickly as observed in Figure 4. Now, the expert can copy and paste the created SQL command into Oxygen Forensic® SQLite Viewer (Figure 5) and see the fantastic results; a created command to support an app database that has not been supported before! The query can also be executed in the SQLQuery Builder to produce a report if Oxygen Forensic® Detective is not a tool in the forensic toolbox. In both the SQLQuery Builder and Oxygen Forensic® SQLite Viewer the expert can even save the query to use against another gmail database that they might run into during a later examination.

Figure 4: Complex SQL Query created using CPDForensics SQLQuery Builder.

Figure 5: Complex SQL Query from SQLQuery Builder now used in Oxygen Forensic® SQLite Viewer, creates a powerful query over multiple tables.

Data within the browser application folder is so subjective it becomes difficult for a mobile forensic tool to conform to uncovering these artifacts. Also, these treasure troves are created on the fly, per the user’s activity. Now, throw in the multitude of internet browsers available for a mobile device it becomes an impossibility that the mobile forensic solution of choice will be able to parse and decode this data in all situations. Again, it comes down to the expert behind the keyboard and their commitment to performing a complete examination.

The likelihood an examiner will run an unsupported app, or even the supported app that is not entirely decoded and parsed is quite great. However, the likelihood that data will remain hidden, unanalyzed, and undocumented by the expert should be slim so long as the will to seek and decode is great.

Posted in Information | Tagged , , , | Leave a comment

Not Your Ordinary App (PART 1)

Posted on September 22, 2016 by Lee Reiber

 

Today’s mobile forensic solution landscape is a battle of supported apps, and a race to give to the examiner a version that will decode a parse a particular app that is paramount to that case, on that day. However, statistically speaking having an almost psychic ability to determine today’s paramount app is about the same as guessing the winning lottery numbers for each lotto across the US everyday! Simply speaking, today’s popular app might not be tomorrow’s, and when it comes to examining data in a case it is always an unsupported third party app that is involved. More frequently than not, the examiners are examining apps that are not the most popular and most of the time it is the first time they have even heard of the app, let alone examine.

I want to point out some statistics that might be of interest. One, there are over 6.3 million apps available on Google Play, Apple Store, Amazon, Windows Phone and BB10 stores. Two, on average a mobile forensic solution can parse and decode ~400 unique apps. Three, the statistical probability of picking a supported app from the total available apps is ~.00006 or .006%. This means you are almost guaranteed to pick an app that is not supported than an app that is supported if randomly selecting an app from the various stores. This probability works into the mobile forensic examination more times than not, but the statistical probability is not as profound simply due to the fact software solutions support many of the “most popular” apps. However, from experience and conversation with examiners across the globe murphy’s law always comes into play in the biggest cases.

This is when our mentality as examiners will need to change. Simply put, don’t always rely on your tool to decode and parse the app! Most apps will contain settings files in the form of text, xml, json, plist, and others. These apps will predominantly store their data in a sqlite database or more times than not multiple sqlite databases. Furthermore, their temporary storage, aka cache, is also available and can be a treasure trove of evidence. The recovery of this data is where the problems arise because there is additional work involved outside the automation of the forensic tool. If an app is not decoded/parsed by automation it simply does not exist right? Of course not, the data is still there and can be retrieved and examined by the examiner, often uncovering massive amounts of critical data within the mentioned files and locations. It just means there is additional work involved.

Where would you hide your communication from prying eyes? Would it be in a popular app or an app that is not known to be a “chat app”? Say a game perhaps? Since most game apps allow for chatting with other players during play wouldn’t this be a perfect place to “meet up” with other members? Here they can devise plans, operations, and more without playing a single move within the game. When was the last mobile forensic solution to support a game and the communication methods used?

The likelihood that you will be faced with supporting an app in a mobile forensic examination is, as mentioned, a guarantee. Be prepared, and understand that these apps can easily be examined to uncover valuable data that was either not parsed/decoded or not listed as a supported app. In PART 2 of this blog, “Not Your Ordinary App”, I will show how you can support these unsupported apps to parse and decode a goldmine of data.

Posted in Information | Tagged , , , , , , | Leave a comment

What can geo-data tell you?

Posted on July 19, 2016 by Lee Reiber

GEODataIt is all in the name —mobile device. These two words tell you, the reader, that it is a device that is mobile. By mobile it simply implies that the device can be anywhere. In an effort for the device to be “aware” of the location for cellular and data reception it must seek out where in the world it might be. This is just how the mobile device works, and must work. If you believe that this is not the truth just turn off Wi-Fi, Bluetooth, and cellular (turn on airplane mode). Go outside and open up Google maps or Apple Maps and walk around. You will quickly see that your blue dot is still being tracked. However, if you turn off Location Services AND place in Airplane mode then you will be prompted to allow to get a current fix and denying this feature will in fact put you “somewhat” off the grid. However, no one wants to turn their mobile device into a simple music player, so valuable location data is always available when conducting mobile forensic examinations.

Location data can give us information to include but not limited to:

  • Photo coordinates
  • App usage
  • Cellular usage
  • Wi-Fi usage
  • Driving directions

Photo coordinates

Location information is stored in the EXIF (Exchangeable Image Format) data of a photo. This data may contain the device information, weather conditions, latitude/longitude, focus, and other markers. As indicated the latitude and longitude of images can be within the EXIF which can help to identify the location the image was taken with the mobile device. With the ability to sharing SD cards with Android devices the investigator should be cognizant of the additional information (i.e., device information) before indicating what device took the picture. Also, EXIF data does not have to be included in the image. If the photo was sent or received the EXIF data is often the first information to be removed in the compression process. This is simply done by many social networks to allow for better speed and network performance. Massive images would be a serious bottleneck in the system. However, a user can also elect to not include location information using a global setting in both iOS and Android devices. This could also be the case as to why an investigator might not see location information within the EXIF metadata.

App usage

Apps within a mobile device are a treasure trove of significant case data. With over 80% of today’s users using at least one social app to communicate there is no reason an investigator should not be going through all apps on a mobile device. Also, many have location services built-in when the app contains a picture/video capability, directions, business lookup, business check-in, or other location type services. Also, in an effort to allow the device to work better in areas of low network bandwidth things like Bluetooth and Wi-Fi are employed so the device must report general location as well. Take a look at: /data/com.google.android.apps.maps/databases/search_history.db. This database records the searched locations within the Google Map app, storing the latitude and longitude along with a timestamp. This data is in the suggestions table in the SQLite database.

Cellular usage / Wi-Fi usage

Android devices cache a tremendous amount of general location data to “help” their users have a better experience. An example from Mobile Forensic Investigations is the /preferences/SystemConfiguration/com.apple.network.identification.plist. This property list contains the IP addresses used and assigned to the iOS device when
communicating on both the cellular WAN and Wi-Fi. This property list can be fantastic for any investigation. iOS devices also cache location information in the form of cellular and Wi-Fi usage to assist it’s many users with better performance. However, many automated tools do not parse or analyze this file along with many other location and settings files. An investigator armed with the ability to manually harvest these types of artifacts can often make considerable contributions to the overall investigation.

Driving directions

A given for any investigation—remember we no longer use map books bought at the nearest convenience store. Everyone uses some type of direction app, even if they do not drive. I do not know how many times I have used Google Maps to look up an address in another country that I was walking to, or looking to see how far it was. What great evidence if an investigator is looking for commonalities with a crime and a location. Did the person research the location prior, obtain driving directions, or any other nugget?
Location information is extremely powerful in any investigation, but can be the smoking gun in cases involving two or more devices. Imagine this: While conducting an interview of two people, both say they do not know one another and have never seen each other prior to today. The investigator has seized both mobile devices and began the tedious process of working through the information. By reviewing the location data, using a timeline of events, the investigator can quickly see that the two individual devices, who are not from France, but believed to be involved in terrorist activities were .3 miles from each other within 30 minutes of each other (Figure 1 and 2). The “heat map” shows to the examiner the day and time the devices are most active. Further investigation revealed that both devices were in London’s Heathrow airport two days prior, just 10 minutes apart and in the same terminal, and the following day at a small cafe at the same time. Even though the subjects did not speak to one another this location information clearly shows the devices they had possession of were in close proximity of each other on three independent days prior to the attack.

Figure 1: Timeline using geo-data from multiple devices

 

Map

Figure 2: Mapping two or more devices to show common locations.

Having the ability to quickly build a timeline and immediately display extracted location information is critical. With this data, an investigator can quickly build credible information that can often shed new light to any investigation. The collection of the device is typically what many investigators believe is the most difficult. I would disagree. I believe the analysis of data is often the most overlooked simply because many believe the automation will recover all that can be recovered. The analysis of critical files is more often a manual process, and no file should not be overturned. Many of these most critical files are described in Mobile Forensic Investigations: A Guide to Evidence Collection, Analysis, and Presentation available on Amazon and many other outlets. Today’s mobile devices will be used in every type of crime and subsequent investigations must step up to the data that can be extracted and analyzed.

Posted in Information | Tagged , , , , , | Leave a comment

Our Global Digital Dilemma

Posted on July 5, 2016 by Lee Reiber

expert-slider-2-776x415

In the last two weeks, I have met with representatives from over 80 different countries through several digital initiatives and partnerships I am a part of. These meetings have taken place across the globe, but the the theme of each conversation is the same: digital data from a mobile device is the major focus of every type of investigation. Subsequently, as also expressed, a mobile device may be the key evidence piece in the case. However, because a tool is unable to recover the information, training is lacking or unavailable, or simply the agency is more interested in digital data from other medium the evidence is not obtained. The overwhelming consensus from the many conversations was the fact that the magnitude of mobile device evidence on a case is clear, but for the limitations expressed previously, most are weary of venturing into the mobile device forensic realm as an expert. This indecisiveness is simply, in my opinion, due to inadequate training or more likely no training what-so-ever.

Why training? As outlined in several of my blog entries and my book, Mobile Forensic Investigations: A Guide to Evidence Collection, Analysis, and Presentation, examiners from the beginning have been trained with a tool rather than trained to understand the tool and device. The “backward approach” has long plagued mobile device examiners, or should I say mobile device collectors. I think this is not the fault of the individual collecting the data from the mobile device, but rather a forced choice. Most companies, agencies, individuals simply cannot afford the outlandish pricing model of some solutions AND training. So, the only item they walk away with is going to be the tool. Enter the albatross. With a lack of training several things can happen to include: assumptions are made, case law is created, and more failures than successes.

Assumptions are made

An assumption is just a guess based upon a person’s knowledge on a subject. So, if a user has not been trained on a tool they will make assumptions on how it works based upon what others have told them, a forum has instructed, a support member has stated, or otherwise what they have guessed. There is no room for assumptions in mobile forensics or digital forensics. Assuming that a solution will be able to connect and collect data from a locked Apple iPhone 6 running iOS 9x because you own the most expensive software for mobile device forensics is a prime example. Or, with any iOS device you can recover all app data from each app running on the device. They are just computers right? With a computer I can recover the entire disk image, so a mobile device should be no different. These are assumptions based upon conjecture and lack of training. Assuming anything as it relates to mobile device forensics has no place in digital forensic incident response (DFIR).

Case law is created

Typically, in the law enforcement realm, being the catalyst for the creation of case law is not always something you strive for, especially in digital forensics. And by case law creation, I mean bad case law. For example, your agency/company receives a grant to purchase a solution that will allow you to “dump” the data from a phone, but that grant does not cover training, and said agency goes out into the field to “pump and dump” all mobile devices simply because the solution allows them to do this. This easily creates bad case law. How? Indiscriminately grabbing the data from every traffic stop or interdiction by law enforcement is illegal without a warrant, or consent. It had never been legal, but give a tool without training about the usage and legalities, created this case law. Now, every mobile device collection from a traffic stop to a terror attack is under a microscope as to whether the data from the device was legally collected. Granted, data from the mobile device should always be collected in accordance to proper procedure and laws, but because of poor decisions based upon the situation each examination across the world could have been jeopardized, not just the United States via the SCOTUS.

More failures than successes

In order for a successful collection of a mobile device using a mobile forensic solution certain criteria must be met. Things like proper driver installation, device settings, and proper cabling are at the top of the list. A device driver is a conduit, or rather a translation layer, between the mobile device and the computer’s hardware. So, a driver translates commands from a computer, and also commands/data from the mobile device. This allows the computer to “speak the language” of the mobile device. Without a driver to translate the computer’s commands and vis versa, the mobile device simply cannot communication and a failure occurs. This failure is one of the most commonly encountered error across the world, but has the simplest solution—just install the proper driver. Many operators of solutions believe they can just plug the device in and press the magical “Get Evidence” button. It is when the solution fails to communicate with the device that the first thought arises, “this software does not work”, not “I wonder if I installed the driver correctly, or at all”. With the proper installation of a mobile device driver, communication between the mobile device and solution will be successful pending all other device settings are also met. Other device settings? The second most encountered failure has to do with ensuring settings are met. Some general settings could be making sure to select “Trust Computer” for an iOS device, RSA certificate for Android, and turning on ADB if the device is not locked. By not understanding the complexities of the mobile device collection failures will be common. Eliminate or troubleshoot these problems to achieve more successes than failures.

This is a global digital dilemma that has been fostered by the need to have a mobile forensic tool, but lack of either the funds or just the reliance on the belief that training is not needed because the solution is so easy to operate. The foundation of any mobile forensic examiner should always be training. When an examiner understands the legalities of the seizure of evidence, how a solution is obtaining the data, where the data exists, how a solution communicates with a mobile device, and how to troubleshoot the frequent issues the mobile device collector becomes a mobile device examiner/expert. A solution will only be as good as the training available, and an examiner will only be as good as the training they have received.

Posted in Information | Tagged , , , , , , | Leave a comment

Chip-Off and JTAG Nonsense

Posted on June 4, 2016 by Lee Reiber

For some time now the talk in the mobile forensic world is all about ISP, JTAG, and chip-off. Let us take a look at what people are really talking about, why having an understaning of these methods is critical, and most importantly how to get to the artifacts when your mobile forensic tool balks when trying to import.

From Mobile Forensic Investigations: A Guide to Evidence Collection, Analysis, and Presentation the word “JTAG” (Joint Test Action Group) has a variety of meanings, from directly programming systems to debugging others, from Xbox hacking to forensics. In the context of the book, JTAG is described as the process of setting and reading values on the test pins accessible on the PCB of the mobile device. By using the TAPs, communication can occur via the boundary-scan path, interfacing with the Boundary Scan Registers (BSR) that interface with components on the PCB. These components can be programmed or read without the removal, independently reading, or programming each separately. (pg. 136) ISP (In System Programming), like the “JTAG” method use the TAPs, allowing communication direclty bypassing the CPU to collect the RAW binary image of the mobile device.

The removal of a device’s flash memory module and analyzing it is referred to as “chip-off”. The chip-off procedure is quite labor intensive in both the removal of the actual embedded flash memory chip and also reading of the stored data. Because of the various differences between phone models and storage types, that could range from Thin Small Outline Package (TSOP) to Fine-pitch Ball Grid Array (FBGA), the purchase of the equipment to read the information from the embedded chips and the time investment can become expensive. However, conducting the imaging of the memory chip using this method is the closest to the bit-by-bit collection a forensic examiner would expect and is similar to imaging a computer’s hard drive. (pg. 140)

It is imperitive that experts understand the methods to accomplish these types of collections as it is often the only way to have success. Simply because with today’s mobile device security provisions it is often the only way to access the coveted user data. For this technical and specialized skill it is extremely important to receive training prior to attempting these type of extractions. Okay, so you have received the training or a binary image from one of the afor mentioned techniques; now what?

Since the image is a binary file it will need to be recongized in the mobile forensic tool of choice. Often, experts have the file but find when they import the file into their tool of choice problems begin. They are simply given an error indicating that the file could not be recognized. Take an Android device for example. Since Android devices contain a varied number of “partitions” the mobile forensic tool often cannot decern the offset of the important userdata partition from the partition table. When this occurs using the following solution can help to at least obtain data from this valuable area.

Using the free tool FTK Imager from AccessData, import the binary file as an image. Immediately the file will be expanded and decoded to show the varied partitions. Locate the userdata partition, select it and right click. Select from the context menu Export As Image. Give the image a unique name, save the format as raw, and add 0 to Image Fragment Size (Figure 1-1). The 0 in Image Fragment Sizeis important as breaking up the image into several files will not allow for the sucessful import of the image by most mobile forensic tools. Once the image is created it can be imported in as a Android Physical/JTAG image by tools such as Oxygen Forensic Detective to allow for complete parsing an decoding of valuable user data.

 

 

This technique is just one way to get to the valuable data within a binary image created by JTAG, ISP, and Chip-off techniques.

Thanks for reading and please subscribe.

Posted in Information | Tagged , , , , , , , , | Leave a comment

Fast Forward

Posted on June 3, 2016 by Lee Reiber

First, before I start back into my blog (yes it has been some time), I wanted to start it off with a thank you…

It seems almost surreal in a way, with the many opportunities that have presented themselves in various ways over the years. From the time of my first “real” job as a police officer for a good part of almost 15 years, to ownership of one of the most recognized mobile forensic companies (snapped up by a global forensic company-regretfully), to seeing those in that company, not to be named, for who they really are, to writing a mobile forensic book, to now working at one of the leading innovators in mobile forensics. Quite honestly, I would have never imagined I would have been so lucky to have so many incredible experiences, met so many fantastic individuals, and be given these types of opportunities. I quite often sit back and try to think of a time I would have thought I would get the chance to interact with some of the most influential individuals in forensics. To you all, I owe you a massive thank you.

So, lets start off with some excerpts from my currently available book: Mobile Forensic Investigations: A Guide to Evidence Collection, Analysis, and Presentation , which is just a brain dump over the last 12 years of mobile forensic research and practice. Here are some tidbits on Google Hangouts:

• /data/com.google.android.talk/databases/message_store.db This SQLite database contains the Google Hangouts messages within the messages table.

• /data/com.google.android.talk/databases/babel.db This SQLite database is the conversation database for active conversations, participant names, messages, and information about the Google Hangout event. There can be multiple babel.db databases, and each database name will be followed by an integer starting with 0 (e.g., babel0.db,babel1.db,babel3.db).

• /data/com.google.android.talk/shared_prefs/accounts.xml This Google Hangout XML file lists key information to the Hangout owner and preferences for the account.

Often, in software applications for mobile forensics, information within applications are not immediately parsed. What this means for an examiner is simple: there is work ahead. The information must often be manually identified and extracted. Hopefully the information will be helpful in a Google Hangouts examination.

I am so excited to be back to contributing to not only the Mobile Device Examiner blog, but to the community in general. Please subscribe to the blog, and do not forget to leave comments and suggestions.

Posted in Information | Tagged , , , , , | Leave a comment