Not Your Ordinary App (PART 2)

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)

 

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

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

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

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

IMEI = TTTTTTTT-NNNNNN-C

IMEISV = TTTTTTTT=NNNNNN-SS

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