Not Your Ordinary App (PART 1)


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?

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/ 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/ 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



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


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

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

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/ This SQLite database contains the Google Hangouts messages within the messages table.

/data/ 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/ 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

Today’s IMEI(SV)

IMEII helped with a couple of posts in the last month that dealt with International Mobile (Station) Equipment Identity (IMEIs) produced and displayed by both mobile forensic software and also by the carriers themselves.  The assistance was primarily dealing with examiners finding a discrepancy with what the carrier was showing in Call Detail Records (CDRs) and what was produced by the mobile forensic software and even the identification label on the device themselves.  Lets cover a little bit of information on IMEI numbers first.

IMEI numbers are used as a serial number for the device.  Much like the serial number you might find on other items like cameras, TVs and stereos.  However, the IMEI is also used by the mobile carrier to identify the device over the cellular network via the Equipment Identity Register (EIR).  This helps to deliver content, assist with subscriber to equipment correlation, equipment maintenance and equipment allocation.

The IMEI is a 15 digit number composed of several subsections: Type Allocation Code (TAC), Serial Number(SN) and a Check-Digit(CD).  Since 2004 however IMEI Software Version numbers or IMEISV are being used to assist with a carrier’s identification of the software version running on the device.  This feature can assist with upgrades, notification to users and maintenance of the user device by the carrier.  This number is composed of the TAC, SN and SV for a total of 16 digits (sometimes 17).  The check digit is generally dropped from the IMEISV.  The check digit can be calculated, if missing, by dropping the SV digits and using Luhns Algorithm against the remaining digits starting at the right most digit.  The layout of both the IMEI and IMEISV is described below.

T = TAC digit
N = Serial Number digit
C = Check Digit
S = Software Version digit



What becomes confusing to examiners is the fact that some mobile forensic software will report two IMEI numbers and identify one as the calculated and the other as the IMEI.  Furthermore, telco carriers will often send back CDRs that display the IMEISV and not IMEI.  Since they are slightly different (last two digits typically) the comparison with the IMEI that is listed on the identification label or displayed by the mobile forensic software does not match.  These discrepancies can lead to problems when documenting and even testifying to the identity of the device if not clearly understood.

For both the IMEI AND IMEISV The most important numbers are the first 8 and the next 6 (TAC and Serial Number).  The numbers following will either be the check digit (with a 0 filler to reach 15 digits) or the software version composed of two digits.  What should also be known is that the two software digits can change over time based upon an update to the device’s software.  With today’s devices this can be a frequent occurrence!  With Android devices pressing the common *#06# will list the IMEISV in the form of 17 digits (TTTTTTTT-NNNNNN-C / SS) whereas iOS devices will simply display the common 15 (TTTTTTTT-NNNNNN-C).  However, both CDR data from carriers and mobile forensic software often only list the standard IMEI number while others list the IMEISV.  At times some mobile forensic software lists both!

As long as the examiner understands that the significant numbers within the IMEI or IMEISV are the first 8 and following 6 clarity can easily be demonstrated and described when requested to do so.

By knowing:

  •  the exact IMEI that is listed on the identification label can be derived from the IMEISV to show unequivocally they are the same,
  • that the multiple IMEIs listed by the forensic tool are just the IMEI and IMEISV,
  • and the returned IMEI from a telco that is off by a few digits is the IMEISV not the anticipated IMEI, you can make an informed analysis and conclusion.

More tips and information can be found in my book, Mobile Forensic Investigations: A Guide to Evidence Collection, Analysis, and Presentation

Good Luck!

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

Chasing Digital Device Tech

networkAs everyone knows, mobile digital devices and the data contained on these devices is here to stay.  I do not think anyone ever thought a small mobile telephone would ever fade away, but the growth of the tech is another story.  I would argue Moore’s Law is challenged by the smart-device’s of today with growth of components exceeding any expectation.  This frequently used compounding yardstick in tech is often the driving force behind mobile device manufacturing and research.  As the article suggests these companies are really competing against themselves – determined to build a better digital mousetrap.  Honestly, the mousetrap is built to mesmerize the consumer into a yearly upgrade.  Upgrading our tech to keep up with the technological advances steamrolling across the globe is often mind boggling; far exceeding any manufactures’ forecast.  Yes,  we digital consumers must have the newest tech – no matter the probability the tech will be outdated at the time of release.  This inundation of tech is often a tsunami, but is what  creates the digital landscape of our lives.

The digital finger print in our everyday lives is nothing short of amazing – from computerized kitchens, cars, homes and businesses our lives have been immersed and essentially governed by tech.  Just contemplating the likelihood of not interacting with some form of  programmable tech every day is an impossibility – just Google it!

What about our global digital landscape – is that any different?  Our nations, our countries, our world are attached to a digital grid with exponential growth and potential; often controlled, captured, manipulated and infiltrated. Preparing for tomorrow with innovation, organization and leading edge leadership today is a necessity.  This means tech is not going to wait for our ok to advance,  or to gain knowledge on how it operates, stores data, sends data or hides data. Tech will continue to compound without our ok, and the digital landscape will continue to encompass even more of our daily lives.  It is not the self-reliance on tech that is alarming, but more the self-imposed ignorance that data within the tech actually exists that is chilling.  Proactive conversation and understanding rather than reactive pretext and conjecture is how to navigate the evolving global digital landscape.

Today we need forward thinking, thought leaders with a unique set of problem solving skills.  These should be baseline traits of the digital forensic road warrior of today.  In order to combat this digital environment one cannot wait for a better tool, feature or method, but take the lead and build it, devise it or craft it.  This was the idea behind not only my book, Mobile Forensics Investigation: A Guide to Evidence Collection, Analysis, and Presentation, but also the SQLQuery Builder application.

The Mobile Forensics Investigation (MFI) book is a way for any examiner to gain a better angle and understanding of completing a holistic mobile device examination without reliance on automation.  The SQLQuery Builder gives the power to the user to create powerful queries to collect and extract from SQLite database files used throughout the digital world to store valuable evidence.  Using both of these in conjunction with any digital investigation hopefully can start to fill the technology awareness chasm.

Today’s digital examiner is facing an onslaught of data from the massive number of digital endpoints, which are constantly barraged by an endless supply of both malicious and benign information. Being proactive and not reactive in our investigative approach can help to overcome our already extraordinary forensic deficit.  However, this is entirely up to you..


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

Mobile Forensics Investigation: A Guide to Evidence Collection, Analysis, and Presentation

AftMobileForensicser all of the requests to dump my brain into a book I finally listened producing MobileForensics Investigation: A Guide to Evidence Collection, Analysis, and Presentation. It is currently in most book outlets and also McGraw-Hill Education for pre-order since it will not be on the rack until after the summer.  It is my hope this book makes it into every university forensic program and onto every examiners desk.  No need to rely on a vendor to support your mobile forensic curriculum, this book covers it all – from beginning to end – to turn an investigator into an examiner.

Mobile Forensics Investigation: A Guide to Evidence Collection, Analysis, and Presentation leads examiners through the mobile forensics investigation process, from isolation and seizure of devices, to evidence extraction and analysis, and finally through the process of documenting and presenting findings. This book is not just for those starting out in mobile forensics, but contains information for the seasoned examiner. This book not only gives you knowledge of available mobile forensics tools, but describes and documents how these tools work to collect and analyze mobile device data.  The valuable information will allow you to better collect analyze and present your findings and processes in a court of law or discovery forum.  This holistic approach to mobile forensics, featuring the technical alongside the legal aspects of the investigation process, sets this book apart from the competition. This timely guide is a much-needed resource in today’s mobile computing landscape.

  • Provides you with a holistic understanding of mobile forensics from the basics to advanced analysis
  • Notes offer personal insights from the author’s years in law enforcement
  • Tips highlight useful mobile forensics software applications, including open source applications that anyone can use free of charge
  • Case studies document actual mobile forensic cases
  • Photographs demonstrate proper legal protocols, including seizure and storage of devices, and screenshots showcase mobile forensics software at work
  • Advanced techniques feature SQLite parsers and Python scripts

I hope the community enjoys the book as much as I did writing it.  Feel free to use the Amazon link below to pre-order your copy!

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

iOS Timeline with CookieMonster

Giving a video/blog post a try.  Today, I am looking at the Cookies.binarycookies files contained within the Library/Cookies folder on iOS devices – generally in the Application folders. Many apps contain this file when utilizing their built in web browsers.  When used by an investigator to create a mobile device timeline, these files can be of great use.

The tools that are used in the video are all available for FREE.

Hope you enjoy this information and content.

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

Android Driver Problems Solved

Processing of an Android device with a solution running on a Windows computer can at times be difficult. Not because of windows, but because of the many different types of Android device profiles available. At last count there were over 12,000 different types of Android profiles from smart phones to tablets to IoT. This can obviously create problems when connecting this device to a solution running on a Windows platform if the particular driver for that device is unavailable. Just Google “<device name> + driver” right? This typically will yield a plethora of results where 99% are either fake or a link to an advertiser. But first, why does an examiner need a driver anyway?

For any communication to occur a driver must be installed whether it be a keyboard, mouse and in this context, a mobile device. Simply, a driver is a piece of software that acts as the middle man – converting communication from a device to a format whereas the Windows OS will understand and move on to the targeted application. Think of it as a translation service. As mentioned, this is a simple explanation for one type of driver, but makes the point – Android ADB drivers are needed for an application to communication via the Windows system to the attached Android device.

An Android device must have ADB available when conducting a logical or physical collection (Of course JTAG and ChipOff are exceptions). Some may say ADB is not needed for a physical collection via USB because the device is locked and the examiner could not switch ADB on. So, since they could not enable ADB it therefore was not enabled and subsequently the data was still extracted. This is type of conjecture is generally false because solutions that utilize a bypass method for Androids are using custom ROMs or images that will enable root and thus ADB = ON. This allows for installation of vulnerabilities to obtain access to the device’s file system that is typically unavailable due to device permissions. So, again ADB is needed to access the device and as such a driver will be needed.

Instead of spending hours looking for a driver, an examiner should install the Universal ADB driver from Koush. This Universal ADB driver is hosted on the Github repository. There is not a need to download the source code and compile the application because an already compiled Windows installer can be located at the bottom of the page. This Universal ADB driver is updated continuously by Koush and has been used in many of my examinations when ADB drivers could not be found elsewhere. Koush is also the developer of the ClockworkMod that many mobile forensic solutions physical collection techniques are based upon and a frequent contributor to the Android community. This Universal driver is a package that contains the vendor (VID) and product IDs (PID) that have been rolled into a single driver and once installed are registered within the Windows system. When the examiner plugs in a device, ADB will now be recognized when previously Windows was unable to find a suitable driver. With ADB now available the device can be collected with the tool of choice.

Enjoy and Good Luck!

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