DIY app forensics: What does it take?

Digital evidence from the millions of apps currently available in the Google Play Store is frequently material to criminal and civil cases and investigations. Yet app evidence is time consuming and costly to decode, analyze, and produce while facing deadlines and a backlog of cases.

What’s in app support? At Mobile Forensics World this year, you have a chance to find out. On Tuesday, June 3, John Carney and Don Huettl, of Minneapolis (Minnesota, US)-based Carney Forensics, are presenting a two-part lecture and live demo on what it took for them to develop plugin support for the Burner Android app. We took the time to sit down with John and get the story behind the lectures.

Cellebrite: What first drove you to start developing plug-ins to support third party apps?

John Carney: We’ve seen a dramatic change in mobile phone architecture in recent years as smart phone and tablet makers rely on apps as basic building blocks.

This makes for an industry challenge faced by tools vendors and examiners alike.  Over one million iOS apps and one million Android apps are available today through app stores, but automated forensic analysis is supported for only a few hundred.

And, even though scripting capabilities exist for examiners to develop their own forensic app support, very few are decoding apps and writing the scripts and plug-ins to probe their device evidence.  We wanted to attempt to show examiners a path forward and how to get involved.

CB: How did you come to choose this particular app?

JC: Mobile messaging apps are an extremely interesting family of mobile apps that phone users are shifting to in great numbers all over the world as they abandon traditional text messaging offered through the service providers.

We noticed examples of these apps that support message deletion and user-specified retention periods after which they are deleted.  Snapchat is perhaps the best example.  TigerText is another.  We chose to support Burner.

We wanted to see if we could find message evidence after the message was deleted or “burned”, and to support a new app that the tools vendors did not support.  Cellebrite now supports Burner on iOS, but ours is the only Burner plug-in or script available for Android.

CB: What challenges did you face at the outset?

JC: We had to choose a reasonably interesting app that was supportable and an app platform that made sense for us. We made our determination using three criteria:

  1. We wanted to add something of value to existing app support. For example, because GoSMSPro uses the same core data structures that UFED already supports to decode other SMS, we found there was really no work to be done.
  2. The app data couldn’t be too difficult to acquire. It would be fruitless to try to support an app whose data is encrypted.
  3. Along similar lines, we wanted to support an app that would give us plenty of artifacts to uncover. Some app developers, who are experienced with writing secure apps, do a lot of garbage collection and data wiping along the way. They don’t leave much behind as a result.

Burner, as it turned out, gave us an almost “Sherlock Holmesian” opportunity—after the phone number is burned, we found we had a shot at finding artifacts left behind, and we did!

Then, we had to construct a development environment that gave us about half a dozen features that would make our research, development and testing flow more easily. Basically, we built a “nest” for doing productive work: in the short term, nimble, fast, cost effective results, and for the long term, investment in future development.

For example, virtual phone support—Android emulators—allowed for experimentation across makes and models without a significant cost outlay. We could then create two virtual phones and have them call and text each other from a single platform.

For another example, platform virtualization allows us to take advantage of various computing architectures. Developers can use Mac, Windows or Linux platforms for full flexibility in the development environment.

Another challenge was that we had to learn how to decode mobile apps evidence, which proved to be one of our most critical challenges. We also had to learn how Cellebrite encodes phone evidence for reporting our results, and advanced analytic options like timelines, maps, and activity analytics.

On the other hand, having looked at other plug-in writing environments, we can say that UFED Physical Analyzer offers the best support for developers. It is equipped with advanced SQLite and plist decoding, highly modular decoding chains, and it provides an excellent debugger. We don’t have to worry about flash translation layers, reconstructing file systems, or parsing common phone data structures.

We wanted to be 80% done with plug-in development from the moment we started, and UFED gave us that level of advanced and broad-based support in a way that many other tools do not.

CB: What did you find you needed in terms of resources (time, team members, etc.)?

JC: We needed a skilled software engineer with digital forensics training who understood object-oriented development and who could quickly learn Python.  Don Huettl had those skills and was also a clever designer who constructed a highly innovative development environment. Don came to us as part of an internship with a degree program from a nearby academic institution, where I serve on the advisory board. In addition to the right people, we needed time to decode our app, and write and test our Python code.  We also had to learn how to present our project so that examiners could understand and appreciate what we had done.

This took several iterations of slide decks, including a comprehensive live demo of our development environment. Don shows how we decode the app, take the script and turn it into a plug-in, put it on a decoding chain, perform the examination, and then create a report—all in a way that anyone could understand, even if they don’t have a background in scripting.

Documentation is key to this process. It’s good scientific practice anyway, but in this case, it provides the framework for learning how to do this. Besides documentation of our own methods, we found that the Iron Python libraries and .NET libraries were critical to our success, and important for sharing with the community. Finally, we found that we needed more than one UFED Physical Analyzer license to support the decoding, development, and testing of our plug-in.

CB: What skills did you and your team members already have, and what skills needed to be developed or sourced?

JC: We had software architecture, design, and engineering skills.  I was a software engineer and architect in a former life and an experienced mobile device forensics examiner for the past five years.

Don was an experienced software engineer who learned computer and mobile forensics and got certified during his degree program.  He was looking for a challenging internship.  We didn’t need any more skills than that.

CB: What technical challenges did you face at various stages in the project?

JC: We had to learn how to decode mobile apps including SQLite app databases and how to expose other artifacts and files in our mobile app.

We had to find phone emulators for Android phone models and learn how they worked and what didn’t work. The quality of the emulators and how many features they support or don’t support figured into this research.

For example, creating two different virtual devices—different makes and models—with a full range of functionality might mean that different VOIP apps, or forwarding rather than simply sending and receiving text messages, crash the emulator. We had to figure out how to work around the bugs.

We also had to learn how UFED Physical Analyzer organizes and structures phone data for presentation to examiners. In other words, we had to figure out how to plug the examination results back into UFED PA so that reporting and analytics would work on the back end.

We had to learn and develop debugging techniques for perfecting our Python script and plug-in. Even for a software engineer with plenty of experience, the debugger, which provides an atomic level look at code execution and data, is important to figure out why something isn’t working.

Fortunately, the UFED’s support for the debugging environment in Python shell made this trial and error process much easier.

CB: What have you learned thus far about the plug-in development process?

JC: We’ve learned that the process is very dependent on the specific mobile app that we have targeted to support.  We have to become experts on our app. This involves understanding the app’s user model, what the app’s purpose is, what it does and doesn’t do, and so forth.

Decoding the app, in turn, requires understanding the connection between the user model and the data model. You can’t have just a passing knowledge of the app and expect to be able to write a plug-in; you need to understand the app at the same level as its own developer.

We’ve learned that encryption and cleansed data are not our friends as we attempt to acquire and report phone evidence.

We’ve learned that leveraging UFED in our work is like standing on the shoulders of a giant.  Physical Analyzer helps us with decoding, reporting, and debugging.  And all of the various pre-existing UFED plug-ins acquire, translate, reconstruct, and prepare mobile app data for us so that we can do our best work.

We’ve learned that we have to document our process and our code so that we can remain nimble, grow our team, and develop quality plug-ins.

CB: What will you be exploring in future research and development?

JC: Many app families are interesting to us including personal navigation, spyware and malware, and also payment. We want to explore additional mobile apps that have not been decoded and automated by any of the tools vendors yet, but that are desperately needed by examiners.

Because we’ve only developed one plug-in, we don’t yet have a quantitative idea what kind of time commitment is required for different kinds of apps.

However, understanding that mobile examiners are busy people, it may become possible and necessary for people to plug in to the process at different points and share their skills and aptitudes. Rather than developing “cradle to grave” plug-ins, in other words, one person might focus on decoding, another on script testing, etc.

We also want to construct a development environment for iOS including iDevice emulators so that we can develop multi-platform app plug-ins.

Join John and Don for their two-part presentation in Oleander A on Tuesday, June 3. From 11:00 – 11:50 a.m., John will present “A Case Study in Mobile App Forensics Plug-in Development – Examiners/Developers to the Rescue (Part 1). From 4:30 – 5:20 PM, Don will present “A Case Study in Mobile App Forensics Plug-in Development – Build Your Own Plug-ins (Part 2). We hope to see you there!

How the past 6 months have shaped mobile forensics trends: MFW 2013 panel

Since releasing our “Trends in Mobile Forensics” white paper in January, the industry has continued to rocket forward. In just six months, some of our panelists’ predictions have remained accurate—and others have arisen. Watch the video to learn more, and keep reading for some additional highlights (and presentations) on mobile apps, evidence validation and gang suppression, among other things:

Mobile forensics as its own subspecialty

David Papargiris, director of digital forensics at Evidox Corp., believes that mobile forensics is becoming its own discipline because phones are so much more complex. For example, even three years ago, malware on mobile devices was unheard of. In addition, Papargiris believes that issues like apps and chip-off extractions are a good reason for mobile forensics to be a separate discipline.

Heather Mahalik, mobile forensics technical lead with Basis Technology and a SANS Certified Instructor, noted that specialization is already happening among defense contractors. In her lab, hard drive forensic specialists don’t handle mobile devices at all and vice versa.

Her team’s ability to specialize has led them to methodology like chip-off extractions, which are most handy on devices damaged by water, bullets or explosives, devices whose locks can’t otherwise be bypassed, and so on. “We rely heavily on tools like UFED to parse the data,” said Mahalik.

However, because these specialists go deep–“sector by sector”–on the devices they do examine, parsing is a “huge issue,” said Mahalik. She questioned whether examiners are fully aware of what they might be missing after they get their data and print a report. “What if a third-party app is the only way [your suspects] communicate?” she asked. “The tool needs to obtain that data.”

Asked what her caseload is like, such that her 4-person team can fully analyze every handset, Mahalik responded that priorities are ranked—and not every device that comes in is processed. “Knockoffs and simple phones are easy because we know exactly where to look,” she explained, while iPhones – especially those containing apps – can take a few weeks.

Dan Morrissey, a sergeant with the Sacramento County Sheriff’s Department, questioned whether mobile forensics was progressing to a point where chip-off extractions—still considered by many to be “hacking” despite efforts to legitimize it within the forensic community—become less popular than wiretapping. “Encryption is getting better, so if [evidence is] not intercepted in transit, we don’t get it,” he explained.

Even so, Papargiris pointed out, while encryption tools like BitLocker led to the same thought process, the forensic community ultimately overcame the issues with better technology and live acquisition.

John Carney, chief technology officer at Carney Forensics, agreed that specialization appears to be a trend. However, he also pointed out an apparent trend towards the integration of computer and mobile forensics.

That fit with an observation from audience member (and 2012 panelist) Shafik Punja, a Calgary, Alberta, Canada police officer, who pointed out that mobile forensics’ foundation remains in the bits and bytes and binary data derived from computer forensics, making the original discipline an important “fallback” to dealing with mobile devices.

Apps are another rich source of data that may require specialist skills, such as Python programming. Learn more in Mr. Carney’s presentation on the subject:

A need for analytics beyond data

The days are going away where all an examiner had to do was dump the phone and give a report. That’s because at one time, asking for everything on phone was doable; today, storage is moving into terabyte territory, not just because of what phones can store but also because of how much removable media like microSD cards can hold.

Because digital forensics’ ultimate goal is to put the suspect behind the keyboard, mobile forensics needs to be about not only how to extract the data, but also perform analytics and explain the data. In cases where investigators don’t know what to look for, analytics can help them determine keywords and other basic information to drive a case forward.

One type of casework where this is most critical: gang suppression. “There’s a distinct difference from the way things used to be on the gang scene compared to where they are now,” said Morrissey. Thirty years ago, gangs were large, paramilitary organizations with distinct hierarchies.

This made it easy to pinpoint and disrupt their leadership. Now, however, small hybrid gangs have created an “asymmetric” threat. Their communication activity is more limited, and they lack a consistent leader. Moreover, members may switch alliances as often as it suits them.

Morrissey observed that this activity echoes what has been happening in overseas battle theaters for about the past 10 years. “In the 2000s in Iraq and Afghanistan, we hit everyone’s houses, dumped their phones, and mapped out their networks. But it killed communication events because we took their phones.”

To avoid a similar problem here, first responders, who come in contact with phones on a daily basis, need to get device data into the law enforcement information cycle faster so that it becomes actionable. How do teams like Sgt. Morrissey’s combat gang threats like these? Take a look at his presentation:

Training, certification and ensuring data accuracy

Joe Church, founder and owner of Digital Shield Inc., raised the related issues of casework and court. When your forensic tool pulls SMS, location information or any other data, do you look at where in the file system the tool is extracting from to verify the data is true and accurate? How do you validate (for example) the 99 SMS messages the tool tells you are there?

Audience members responded that you can look on the device, or else refer to call detail records that can corroborate dates and times. You can also verify with other tools to show due diligence in ensuring that your original tool was correct.

Church pointed out, though, that this process is very time consuming. Cases pile up at the same time that supervisors demand results “today,” which forensic examiners must balance against the eventuality of having to face a defense attorney and expert witness who have had time to mount reasonable doubt as to whether you could have missed information.

Why is this important? “Experts” have gone on the record to testify that they were never properly trained, or else admitting to it on listservs and forums. An untrained, uncertified forensic examiner presents another way for the defense to attack; certification provides a baseline for the court, showing that the expert had to pass a test at one point that says s/he knows how to utilize the tool.

Mahalik raised the point that even if you are certified, you still have to know how tool currently works in its latest version; a UFED certification from 3y ago is outdated. Carney added that if you own 5 tools, you must be able to stay up to date on them all (another argument for mobile forensics as subspecialty).

But the basics are important, too. Some investigators continue to believe that they only need training to learn how to push a button, a matter of policy compliance rather than developing skills. Morrissey noted that even chain of custody can be breached when officers take pictures of evidence with their own phones, forget to isolate a device from its network, or pile evidence devices on an examiner’s desk.

Mr. Church presented at MFW in greater detail about mobile forensic validation. Learn more:

What trends have you spotted in over the past 6 months, and where do you see the industry headed? Leave a comment!