Skip to content

Latest commit

 

History

History
77 lines (41 loc) · 4.34 KB

introduction.md

File metadata and controls

77 lines (41 loc) · 4.34 KB
Raw
  • Introduction

The analysis of iOS devices for incident response is per essence challenging.

Usual acquisition tool only collect users data while the interest of the analyst reside in what the system is doing. The usual way to get access to the full device is by jailbreaking the device or using specialised tools reserved for law enforcement. The downside of this approach is a lost of trust in the final state of the device.

This talk focused on using an Apple feature that service for diagnostic and debugging of devices for shop repair and developers. The sysdiagnose process on Apple device collect many data on how the system behave and is typically what an analyst want to look at.

  • Collecting sysdiagnose artefacts

The sysdiagnose is generated by a user action and it trigger a process which create an archives containing many system informations in a various range of formats that are rather typical from Apple OSes:

  • plist configuration files
  • logs and output of commands
  • sqlite databases with application history
  • ...

The result can be extended by pushing extra profile to the device that turn on extra debugging and enhance the content of the arc

-- Collecting sysdiagnose archive on IOS

While the process is well described on Apple website, we will quickly show how to start the acquisition process on an iPhone and how to retrieve the data via a few different techniques ranging from AirDrop to usual forensics tools.

-- Collecting sysdiagnose archive on other Apple devices

The research leading to this talk is coming from the need to analyse iOS devices. In practice the feature which is used is available through all the Apple OSes:

  • Mac OS (MacBook Air, MacBook Pro, Mac Pro, iMac...)
  • Watch OS (Apple Watch)
  • iPad OS (for tablets)
  • TV OS (Apple TV)
  • ...
  • Extracting information from sysdiagnose archive and building timeline

In this part we present some Python script to extract all timestamped information from the Sysdiagnose archive in order to build a timeline in your favorite timeline analysis tool

-- Splunk & timesketch

In order to perform investigation on the gathered data, an easy solution is to import in a dedicated SIEM system. In this part, we will present how we standardise the output from our script to easily im port them in SPLUNK to perform forensics analysis. We also developed a TimeSketch module to import the generated timeline in TimeSketch. The parsed format can be reused for any timeline tools import.

-- Challenges

Sysdiagnose is calling different tools and commands to generate its output. Unfortunately all those tools have their own format output, especially regarding timestamp format. We will present some specificities of Sysdiagnose output and how we handled them.

  • Identifying IOS system tampering using Sysdiagnose artefacts

In this section we shows practically how an iOS device can be analysed by using the sysdiagnose artefacts and their value: applicate update history, running processes, memory mapping...

-- Examples of investigation

In this section we shows practical examples of analysis with sysdiagnose. A set of sysdiagnose acquisition have done on test devices to simulate a few scenarii and prove the effectiveness of this analysis technique.

  • Issues with sysdiagnose

The sysdiagnose process raise a few issues and concerns:

  • The data are collected by a process that runs on the investigated device. The output can only be trusted as long as it runs normally. Rootkits and binaries alteration could affect the results and lead to wrong conclusions.
  • The format of the files included into the archive depend on the version of iOS and running applications. SQLite DB schema, for instance, can radically change with application update. Keeping a working toolset therefore require continuous research, testing and validation.
  • The sysdiagnose output is mostly undocumented. Every single file need to be manually analysed and understand to correctly interpret the results and avoid pitfall and wrong conclusions.
  • Alternatives way to check integrity

In this last section we discuss how the integrity can be checked by using more intrusives methods that could be assimilated to a jailbreak. While those techniques give a full access it also question the value of the result from a forensic perspective and the trust that remains into the device after this rather intrusive process.

  • Conclusion and references