UFED Physical/Logical Analyzer 4.2 offers efficiency improvements, decryption and enhanced decoding

PA42exclusive

 

 

 

 

The new Physical/Logical Analyzer release, version 4.2, is chock full of features and device support. From more efficient location mapping processes to improved decoding, this latest release is designed to accelerate your investigations and enable you to drill more deeply and intuitively into data from more than 15,000 devices.

Deeper location data analysis, more efficient workflows

UFED Physical/Logical Analyzer 4.2 offers a number of new enhancements with regard to location data. These enhancements offer more flexibility and efficiency by allowing you to access highly visual information more easily.

First, new offline map support offers maps view even when an Internet connection is not available or you are analyzing data at a workstation that is required to remain offline. Second, you can also now zoom in to locations in map view and see related event details. When you want to explore deeper relationships between locations, timelines, and analyzed data, you can jump from location information to its source event or timeline and vice versa.

Location information also allows you the ability to examine attached images, videos, audio, text, and other files identified during the data analysis process. The Data Files category in the project tree enables you to view and filter attachments within data files, locate the associated attachment event, and view its metadata and location information.

Do you frequently share your extracted UFDR reports with others using UFED Reader? Now, include the UFED Reader executable within the report output folder. This saves time for report recipients in locating, downloading, and using the UFED Reader application.

New app decoding and analysis functionality

UFED Physical/Logical Analyzer 4.2 also keeps pace with investigator demand for greater visibility into app data. Besides newly added support for apps installed on Android, iOS, and Windows Phone® devices, as well as updated support for 40 Android and 63 iOS app versions, the new release offers additional decoding and some decryption support, as well as improvements in the way app data—particularly chat app data—is displayed.

Added to analytics that show the most frequently used apps, app usage data now includes information about the last time a user launched a particular app, as well as for how long they used it. Also for the first time, view the number of messages per chat, which can help validate chats extracted using other tools that do not thread messages. Additionally, location data for chat messages is now available for export into all report formats.

Other apps-related support includes decryption of KeepSafe and WeChat apps, together with decoding support for WhatsApp VoIP call logs on Android devices. New WhatsApp support also includes the Read, Delivered and Played timestamps of outgoing WhatsApp messages for iOS, Android and BlackBerry® 10 devices. In addition, Twitter group chat messages are now displayed in Chats.

New device support includes physical extractions, decryption, and decoding

Disable the user lock for 159 Samsung Android models using SPR and SPM methods, depending on the device’s firmware version. In addition, Physical extraction with lock bypass and decoding is now supported for 58 LG Android devices released with Android version 4.2.x and above.

Decryption is now possible for physical extractions from generic Android and Samsung devices running Android 4.2 and below using a known password. Similarly, extract BlackBerry device backup data as part of file system extraction, and then decrypt the backup data with known BlackBerry ID credentials you retrieve via UFED Physical Analyzer.

Device information decoding is newly enhanced for all device types. For BlackBerry 10 this includes username, device model, PIN, IMEI, and device name; for Windows Phone devices, the information includes IMEI, IMSI, MEID, mobile operator ID, country, MAC address, and OS version. Device information for Android devices now includes the decoded Tethering ID and password, while iOS device product name and product type information are now included under device information.

Saving time in a death investigation

One Minnesota (US)-based detective working a death investigation used Physical Analyzer 4.2 to unlock a pattern locked Samsung Galaxy S5 (SM-G900V). Facing a lengthy and destructive chip-off extraction because the device did not appear to be supported for JTAG extraction, the investigator was able to run the device against a pre-release copy of Physical Analyzer 4.2. The extraction worked, and the investigator was able to use that evidence to continue building his case.

To learn more about how the new UFED Physical/Logical Analyzer 4.2 can help accelerate your investigations, download our release notes today!

A case study on mobile victimology from #CACC2014

What is mobile victimology? The concept of “victimology” involves in-depth analysis of a victim’s life, including the normal and abnormal patterns of life over the days, weeks, even months leading up to a violent crime.

Mobile devices help this process because they are so intimately tied to an individual’s life that they often help to fill in incomplete or inaccurate witness statements, surveillance video footage, credit card receipts, and other information.

As this February 2014 article in Police Magazine noted:

Smartphones, GPS devices and other mobile media can be good starting points in any investigation, whether the victim is alive or deceased. The existing, deleted, and hidden data stored on them can help you develop leads to focus your investigation and move it forward. The data can also serve as corroborative or exculpatory evidence, along with mobile carrier data.

In a post-Riley world, of course, getting access to this degree of data requires proper legal authority: written consent, a search warrant, or a defensible exception to the search warrant requirement. Once you do identify the device as a nexus to a crime, however, its evidence can make all the difference.

Case study: mobile victimology in action

Last week at the Crimes Against Children Conference, Ronen Engler, senior manager of technology and innovation joined Michael Hall, chief information security officer at DriveSavers Data Recovery, Inc., to present how just this type of analysis helped prove how a rapist had premeditated the murder of his rape victim.

Their session was a corollary to a case study offered by the Dallas County District Attorney’s felony chief, Brandon Birmingham, together with Carrollton Police Det. Dena Williams and the DCDA’s special field bureau chief, Russell Wilson. Over that session, the three detailed how rapist-murderer Franklin Davis Googled the name and location of his victim, Shania Gray, as well as phrases like “Best way to get off a sexual assault charge” and “Gun shows in Mesquite,” after which point he purchased a gun and used social media to harass and intimidate Shania.

Davis also used a mobile app to spoof messages from Shania that appeared to recant her accusations against him, which he then used in his own defense. Our case study, published jointly with DriveSavers, shows how forensic examiners were able to prove definitively that not only had the messages come from his phone, not hers, but also the level of premeditation he engaged in. Davis was sentenced to death in November 2013.

Have a case study you’d like us to feature? Leave us a comment!

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!

Cellebrite APAC assists NGO in the effort to end human trafficking

Human trafficking is epidemic across the world, perhaps especially in the Asia Pacific (APAC) region, where the prevalence of trafficked persons is more than twice the global prevalence. There, the non-governmental organization (NGO) NVADER assists law enforcement in identifying both victims and suspects in human trafficking crimes.

As NVADER founder and executive director Daniel Walker explains in the video below, human trafficking is one of the fastest growing forms of international crime, bringing US$32 billion in revenue each year to criminal organizations. That’s because it’s one of the lowest risk, highest gain forms of crime, with criminals selling and reselling women and children—and incurring low penalties even if they are caught.

That’s why Walker founded NVADER in 2012. Acting on tips from informants, other NGOs, or law enforcement agencies requesting assistance, NVADER spearheads intelligence-led operations to gather what Walker calls “compelling evidence” against human traffickers.

Yet investigators often found themselves with limited evidence. “During some of our operations in Southeast Asia, we saw that the police would leave the perpetrators’ cell phones on them and never seize them as evidence or of potential avenues for further investigation,” says Walker.

“It became apparent that they did not have the technology to properly analyze the cell phones.  Once of our volunteer staff who had used a UFED as part of an investigation in the New Zealand Police, suggested that we contact Cellebrite.” It was then that Terry Loo, of Cellebrite APAC, arranged to procure a donated UFED Touch to the NVADER team.

Next came training, not just for NVADER staff, but also for local law enforcement agencies, which the NGO empowers to do their own investigations. “Local police in Thailand, for example, now know that any cell phones can be examined. When we are on site they are much more willing to seize them and/or include them as part of the forensic search,” says Walker.

In a single year, the NGO rescued 40 women and children from Thailand, Laos, Cambodia, Myanmar, Kenya, Uganda and Rwanda, and has facilitated the successful arrest and prosecution of 14 perpetrators. Walker anticipates that the number of extractions will grow, from the five processed since the UFED donation, to many more.

And, while the NGO is still in its infancy, Walker further anticipates a strong showing in Thai courts. “We are opening an office in northern Thailand early next year and the UFED will be used much more frequently,” he says.

New iPhone 5s/5c, iOS 7 and Samsung Galaxy S4 support with UFED 2.2.0.0 and UFED Physical Analyzer 3.8.5

Cellebrite is proud to be the first and only mobile forensics vendor to support physical extraction, user lock bypass, and decoding on selected Galaxy S4 devices, Galaxy Tab, and Galaxy Note:

This new support already helped to rescue two small children from sexual predators in the US. While still in beta, our UFED 2.2 software enabled investigators to recover and parse text-messaging and other app data located within the Galaxy S4’s file system. The data showed two suspects communicating with one another, and as a result, enabled the investigators to locate both victims, take the suspects into custody, and build a strong case against them for both the assault and production of child pornography.

Extraction and decoding when iTunes backup is enabled

iTunes backup encryption has frustrated mobile forensics examiners for some time. Cellebrite customers would successfully extract an iPhone’s file system, but then find that UFED Physical Analyzer couldn’t parse the data. Without knowing the passcode for iTunes encryption, the data was simply unattainable.

As of today’s release, Cellebrite is now offering two new extraction methods from iOS devices that have iTunes backup encryption enabled, even if you do not know the password. Available with the Advanced Logical extraction option in UFED Physical/Logical Analyzer, the methods for iOS devices are:

  1. With the iTunes backup encryption enabled and without entering the password
  2. When the device is jailbroken

The extraction wizard presents the device model, iOS version, and iTunes backup configuration, and lists which data can be extracted using each method. The application indicates a specific recommended method per iTunes Backup configuration and jailbroken status.

Customers who asked for support around this feature received a beta version of Physical Analyzer 3.8.5. “I recently posted about an encrypted iPhone 5 where the phone did not have a pass code, but it did have the backup files encrypted,” said James Howe, an Ohio detective, on a listserv. “[With the new version of Physical Analyzer], I was able to access the phone’s contents and complete the exam. None of the other software I had access to did anything for me. It was a breeze once it got going.”

New physical extraction and decoding support for devices with Chinese chipsets

An update to UFED CHINEX adds support for physical extraction and decoding with user lock bypass not only for Android devices with MTK chipsets, but also for devices with an Infineon chipset. Added to existing extraction and decoding for MTK and Spreadtrum chipset devices, this means Cellebrite now supports 99 percent of “Chinese devices” currently on the market.

Download our release notes for full details about these versions. If you’re not yet a customer and would like to try the new iOS capabilities, try out UFED Physical Analyzer for 30 days free!

UFED Physical Analyzer 30-day Trial

How our forensic R&D makes the previously impossible, possible

Before we launched our HTC and Motorola user lock bypass, our forensic customers had to go to through a painstaking process to recover data from these Android devices: obtain a search warrant to serve on Google, either to recover backup data or to obtain or reset the device user lock. In some cases, such as with a phone that was turned off, they may even have had to serve paper on the carrier as well.

This process could lead to delays because it could take days or even weeks to secure the paperwork and reach a law enforcement liaison. The providers’ success was limited by the type and complexity of the user lock—if they agreed to comply at all. This could slow down or altogether halt investigations’ progress.

Thanks to our work on this bypass, a number of happy customers have been able to access critical evidence which they previously could not. Said Deputy Steven Mueller of the Defiance County (Ohio) Sheriff’s Office and the Northwest Ohio Technology Crimes Unit: “I was given a HTC PD15100 in December with a pattern lock. I was unable to acquire it then. Today with the updates it is being acquired as I write this.” Mueller later updated us that he and his team were able to successfully carve graphics files from the image.

To learn more about how to perform user lock bypass and file system or physical extraction on HTC Android devices, see our new video: