Archive

Archive for the ‘Computer forensics’ Category

DJI Phantom 3 Log Analysis Tool

October 24, 2016 1 comment

Rowland Johnson developed an excellent tool, DatCon, for analyzing DJI Phantom 3 log files in Java. I arranged to have it ported to Python because I am far more adept with Python and wanted something that I could extend to support newer file formats and potentially other UAVs.

The result can be found here:

https://github.com/dkovar/uav-log-analysis

It is my hope that others will build on this, adding support for other DJI products as well as adding visualization capabilities.

Feedback, suggestions, etc are always welcome.

Categories: Computer forensics, UAVs

Recorded presentation of UAV forensic analysis

I’ve been giving a presentation on the fundamentals of UAV forensics for several months, primarily for law enforcement and for other cyber security people. The presentation was recorded last month and is available on line.

https://www.youtube.com/watch?v=36rZy9V_avo&feature=youtu.be&a

50 minutes long but probably worth watching if you are interested in such things.

Categories: Computer forensics, UAVs

Mounting a JFFS2 dd image in Linux

March 16, 2015 3 comments

So there I was, holding a dd image of a JFFS2 filesystem dumped from a drone. Great, good to go! Let’s start our analysis! Not so fast, mounting one of these things is non-trivial. After much trial and error, and some Google-fu, I got the following to work in the SIFT3 forensics VM (Ubuntu).

First, test to see if the image is recognized:

khorog:dot2 kovar$ file root.dd
root.dd: data

Not a recognized filesystem and the most likely issue is big vs little endian. Let’s fix that:

apt-get install mtd-utils
jffs2dump -b -c -r -e dest_file.little src_file.big

Note: The ‘-r’ was critical and none of the Google hits I found on this topic included it. This option “recalc name and data crc on endian conversion”.

Now, check the file again:

khorog:dot2 kovar$ file root-swap.dd
root-swap.dd: Linux jffs2 filesystem data little endian

Then install a lot of kernel modules. (Some of these failed in Ubuntu 14 but the mount worked anyhow.)

modprobe mtdcore
modprobe jffs2
modprobe mtdram
modprobe mtdchar
modprobe mtdblock

Now, mount the image:

dd if=root-swap.dd of=/dev/mtdblock0
mount -t jffs2 /dev/mtdblock0 /mnt/jffs2

Et viola.

Categories: Computer forensics

Drone Forensics – An Overview

March 15, 2015 1 comment

[This is the first in a series of posts about the forensic analysis of drones leading up to presentations at BSides NOLO and SANS DFIR Summit in Austin.]

Drones (properly known as small unmanned aerial systems – sUAS) are all the rage. The market is roughly $600 million this year and is expected to be $5 billion by 2021. Drones will touch many aspects of your life, overtly and behind the scenes. They are already used commercially for mapping, precision agriculture, film making, and damage assessment. Illegal uses range from commercial services in violation of FAA regulations to surveillance and drug smuggling. And the hobby community is booming with drones as one of the hottest Christmas presents of the season.

With all of these drones in the air, the forensic analysis of drones is already important and making headlines. Who didn’t hear about the one that crashed on the White House lawn? The demand for analysis that will stand up in court is present and increasing. Tools will not solve the problem alone – we need forward thinking analysts who can work in a variety of disciplines, write their own tools, and go beyond existing techniques. Why? The key is in the final ‘S’ in uSAS. They are small unmanned aerial systems, these are entire networks with multiple operating systems in flight and spread across miles of terrain.

Let’s take a look at all the components of a popular consumer drone.

Physical components of DJI Phantom 2 Vision+

Physical components of DJI Phantom 2 Vision+

There are seven components in this unmanned aerial system:

  • Aircraft
  • Camera
  • Battery
  • Radio controller
  • Wifi range extender
  • Mobile device
  • Laptop

Each of these components potentially contains evidence relating to the incident you are investigating. The aircraft contains multiple sensors, a flight controller, radio links, a camera, motors, and more. The radio controller is pretty dumb but there are configuration settings stored in it that contribute to understanding the full environment. The laptop was probably used to maintain and configure many of the other components and will likely have artifacts relating to that work, along with the traditional Internet history, email, and messaging that might significant context. Even the battery stores digital artifacts about its history and health.

The analyst needs to physically collect and document all of these components, a potentially daunting process given that the components might be separated by time and distance. The type of motor, the custom labels on the radio controller, and the wear and tear on the propellers all tell their own piece of the story and must be correctly documented and analyzed.

Once the analyst obtains access to the physical components, they need to gain access to a variety of digital containers, and then analyze  digital artifacts that range from firmware to EXIF data in photos to plists, registry settings, and /etc/mount files.

sUAS - digital artifact locations

Here is a breakdown on some of the containers and artifacts associated with each physical component:

Aircraft:

  • Two Linux systems
    • OneOpenWRT runningBusybox
      • flight controller, media server
      • Filesystem – squashfs, overlayfs, jffs2
    • One Ambarella A5s IP Camera Reference Platform running Linux
      • camera controller
      • Filesystems – ubifs
  • One micro SD card

Radio controller:

  • OpenWRT Linux system
    • Wifi range extender
    • squashfs, overlayfs, jffs2
  • One USB port to configure the controller

Battery:

  • Queried via USB port on aircraft when attached to maintenance application on OS X or Windows

Mobile device

  • IOS or OS X
  • Many possible apps, including home-grown

A complete analysis of this system will be non-trivial, and a single tool will not give the analyst access to all the relevant information. There are several different flavors of Linux, at least one mobile operating system and at least one standard operating system. There are at least five different file systems, many of which are not recognized by commercial tools. Some artifacts are only accessible via USB and vendor defined protocols. Others require accessing the sUAS’s network and using ssh to connect to the systems. Some systems are running on flash media and maintain no state information after loss of power.

To further complicate the situation, each vendor will use a different collection of components, and those components will vary within their product line and new vendors will enter the market monthly. The open nature of the mission planning software and the flight controllers encourages customization. New sensors and new uses for drones will push both the application of drones as well as the legal and social borders around them.

The forensic analysis of drones, and the larger cybersecurity landscape around them, will be very complex, very fluid, and very exciting. Stay with us as we explore it in depth.

Categories: Computer forensics, UAVs Tags: , ,

SANS DFIR Summit Prague – Blue Team Perspectives slides

I gave a presentation at SANS DFIR Summit in Prague this morning. My presentation was designed to introduce DFIR practitioners to the larger business context that they might be working within. This could help with career progression, avoiding frustration in the workplace, or developing your reputation within your firm to name just a few possibilities.

Any and all feedback on the presentation is welcome.

Blue Team Perspectives – SANS DFIR Summit Prague

Patents in the DFIR community space

Good morning,

David Cowen announced that he has submitted a patent application for NTFS TriForce. Let me start off by stating that I admire David quite a bit, I think TriForce is very useful and pushes into new territory, and that I am not angry at anyone, least of all David.

That said, I’m very concerned. The discussion is going on over in G+. Here is my very off the top of my head contribution to what may be a very interesting discussion. I hope others chime in.

From the G+ post:

 —–
David,

I think my response may have been phrased in overly strong language. I’ve given some thought to why – why I am concerned and why my response was more emotional than the situation warranted.

My perception was that your tool was well supported by the community, and that through your beta program, presentations, and blog posts you were engaging with the community to help develop it. I, rightly or wrongly, mentally lumped it in with other reasonably priced tools that were closely tied to the DFIR community. So when I saw your patent post my immediate thought was “There’s another tool that I’m not going to want to support any more.”

Your post set off warning bells in my hindbrain. My experience with patents has almost always been negative, and in some very personal ways at times. I’ve had colleagues say “I’m doing this for all of us” on more than one occasion. Even when they were being honest, there were negative repercussions.

I think you’re going to run into prior art issues, and quite a few of them. I think that this may be part of my emotional reaction. My perception is that the prior art may be the DFIR community’s work and I’m reacting to the perception that you may be trying, directly or indirectly, to patent the work of many other people.

I fear that you may set off an arms race in the DFIR community. Maybe it is going to happen anyhow and you’re just getting there first. I don’t really want to be a part of that, and I’m not going to be thrilled about watching it happen if it does occur.

Guidance is a very poor example to cite of good behavior with respect to public relations, community engagement, and good business decisions. If they are your model for pretty much anything, you’re elevating my level of concern.

There are other ways to protect and control your intellectual property without patents. Sharing your thoughts on why you’re going with patents rather than licensing would be helpful.

Someone asked me if I am angry. I’m not. I am quite concerned though and I look forward to seeing how this plays out.

-David

IRcollect – collect incident response information via raw disk reads and $MFT parsing

ircollect is a Python tool designed to collect files of interest in an incident response investigation or triage effort. This is very beta code. I’m hacking on it regularly, using it to learn about internal structures, finding minor and major issues, …. Use it at your own risk! If you have advice on how to address issues I’ve encountered, please share ….

In the process of writing this, I added data run parsing and ADS detection to analyzeMFT so those are now available.

The github site has more details and will be updated much more regularly than this blog.

Running as local admin, it:

  • Opens the raw disk
  • Reads the master boot record, collects a copy of it, and uses the MBR to find partition and disk information
  • Using the MBR information, it finds the NTFS partitions.
  • Working from the start of the NTFS partition, it finds the $MFT
  • It collects a copy of the $MFT and then builds a list of all the files on the system and their data runs
  • Using the file list and data runs, it collects interesting files through direct reads from the disk, bypassing access controls.

All collected files are stored in a directory specified with the -d option. They are further organized by hostname and the date-time the script was run.

Requirements:

pip install analyzemft

Status:

VERY beta. Active development daily, often hourly.

Currently collects master boot record, $MFT, and live (corrupted) registry hives. User can modify table in ircollect.py to specify any files they desire.

Thank you to:

  • Jamie Levy for mbr_parser
  • Willi Ballenthin – bit manipulation code, lots of useful tips for analyzeMFT

Adventures in Powershell for IR

July 18, 2013 1 comment

So, I wanted to access locked registry hives. Simple enough using F-Response, but it devolves into various solutions that are not well supported after that. I came across one solution that was of particular interest from a response side but also from an attack side:

Using PowerShell to Copy NTDS.dit / Registry Hives, Bypass SACL’s / DACL’s / File Locks

In short, it opens a read handle to the C volume, parses the NTFS structures, and reads the files directly thus bypassing all access controls and locks. You do need to be local admin to run it.

This is great for getting locked registry hives, or for remotely copying NTDS.dit without deploying hacker tools on the remote system. Bear in mind that the remote system needs to be running the WS-Management service. This is not running by default on our Windows 7 desktops, but the author mentioned that it is running by default on Windows Server 2012.

There are a number of niggling issues with getting PowerShell scripts to run. This article covers almost all of them nicely: Execution Policy

However, it didn’t cover one issue – what happens when you try to do:

Set-ExecutionPolicy RemoteSigned

and get a registry access error?

This post explains how to edit the registry directly.

Once you’ve worked your way through those issues, you can grab local and remote files to your heart’s content.

DFIR Fiction Reading List

January 12, 2013 4 comments

The Digital Forensics and Incident Response fiction reading list, in no particular order:

  • Ender’s Game – Orson Scott Card
  • Jumper and Reflex – Steven Gould
  • Most anything by John Grisham
  • Daemon – Daniel Suarez
  • Zero Day and Trojan Horse – Mark Russinovich (yes, that Mark)
  • Pretty much anything on the Access Data or Guidance Software support web sites
  • Blue Nowhere – Jeffrey Deaver
  • Halting State and Rule 34 – Charles Stross
  • Zero History – William Gibson
  • American Gods – Neil Gaiman
  • The Magicians – Lev Grossman
  • The Night Watch Trilogy – Sergei Lukyanenko

Digital photography and social networking anti-forensics

November 11, 2012 Leave a comment

I attended a superb class on OSINT the other week. One of the topics covered using geolocation data in digital photographs found on social networking sites to gather intelligence on suspects.

Geolocation is all the rage, and numerous complaints and even lawsuits have been directed towards companies collecting and (mis)using geolocation data. Despite this, the public is sharing more of their location data every day, and companies are spinning up new services to encourage them to do so. Photographs are one of the primary sources for geolocation data, and Flikr, Facebook, and Instagram are but some of the major players making use of the data. Many of the services accept an uploaded photograph, store the geolocation data for their own use, and then strip it out of the photograph so that users can only see what the service presents to them.

But what if you lie to the service? You can do so through some of their GUIs, but there is a better way – lie in the data you upload.

These four photographs were taken by me in Prague of this year.

But, when I run the following command:

./spoofexif.py -sd 01/01/2001 -ed 12/31/2010 -sh 0 -eh 8 -l “Waya, Fiji” -b 50 -d photos

and then upload the resulting photographs to Flickr, they appear to be taken in Fiji sometime in the last decade, always between midnight and 8AM.

Flickr’s representation of the spoofed images.

At the moment, spoofexif.py can do the following

usage: spoofexif.py [-h] [-sd BEGINDATE] [-ed ENDDATE] [-sh BEGINHOUR]
 [-eh ENDHOUR] [-l LOCATION] [-b BOXSIDE]
 [-d DIRECTORY | -i IMAGES]
optional arguments:
 -h, --help show this help message and exit
 -sd BEGINDATE Start date
 -ed ENDDATE End date
 -sh BEGINHOUR Start hour
 -eh ENDHOUR End hour
 -l LOCATION Location to place photograph
 -b BOXSIDE Length of side of bounding box
 -d DIRECTORY Directory containing photographs to modify
 -i IMAGES Name of image file to modify
  • It takes a date range and randomly spreads the specified photos out over the entire range. You can modify a set of winter photographs with “-sd 11/01/2006 -ed 02/28/07”
  • It takes an optional pair of hours and spreads the photos out over that range of hours. So, if you have a collection of dinner photos, you’d use “-sh 18 -eh 23”
  • It takes a location and spreads the photographs randomly in a box with a side of length -b. This allows you to scatter your Prague photos around Paris, or to make it appear that you vacationed in Fiji when you were really in New Jersey.
  • And you can specify an entire directory or just a single file. You can send your entire photo library back in time ….

I can detect my own modifications, and it has given me some ideas on how to detect other people’s. But can Facebook, Twitter, or Instagram detect your time machine/teleporter?

Code available by request.