Week 7 – 2016

Week 7!

  1. Software Updates:
    • DME Forensics updated DVR Examiner a couple weeks ago to 19.0 and I forgot to mention it. Then they released a minor update to 1.19.1 last week (that I also didn’t mentioned, apologies). The latest version adds a few more file systems (bn_MBR, SA_X and SA_x_264, ef_JPG and SSF0_P) and fixed a few bugs. The new update also has expanded the detection algorithm to assist in identifying the file systems used.
      DVR Examiner 1.19.1 – Support for Everfocus, Pelco, Bosch and many other DVRs [Updated]
    • Magnet Forensics updated IEF to version 6.7.5. This update added parsing of the iOS and Android TextMe app, Kik 9.2.1 on iOS and IEF will now expand and search compressed archives by default.
    • Eric Zimmerman has updated LECmd (which he released last week) to version 0.6.0.0. This new version adds output to XML and HTML as well as a quiet switch to suppress screen output. There was also a bug fix for switching the TargetModified and TargetLastAccessed timestamp in output in the previous version.
      LECmd v0.6.0.0 released!

  2. Hexacorn has a blog post about a (most probably never used) persistence mechanism involving an easy launch menu found in some Toshiba laptop trackpad software. The interesting thing about this mechanism however is that it requires the user to launch the application, and I can’t imagine too many people would use the feature. Still, good to be aware of none-the-less.
    Beyond good ol’ Run key, Part 34

  3. Magnet Forensics has announced a webinar on Advanced SmartPhone Forensics on the 8th March. The talk will cover obtain a data extraction from the phone, and then parsing the resultant data with IEF.
    Advanced Smartphone Forensics, hosted in partnership with Teel Technologies
     
  4. There have been lots of blog posts relating to the FBI’s request for Apple to assist in unlocking the iPhone 5c in the San Bernadino shooting massacre so I thought I’d combine them all into one section.

    Jonathan Zdzairski has a good tldr post regarding the request made by the FBI and how it could be implemented. It doesn’t provide any opinion on whether or not Apple should comply, just the facts as to how they could achieve what the FBI is asking.

    TrewMTE has an interesting post regarding questioning your morals on the situation. The question raise is “as what point do you think Apple should help”; they have the means to do so, but the question is when should they say “this is for the greater good”. I’ve been on the fence about the situation; on one hand I don’t like the idea immediate unwarranted access to information; we’ve seen abuses of this in the past. On the other hand, in this instance the company has the means to provide an encrypted dump of the phone and allow the government to try and brute force the password.

    Vladimir Katalov has a blogpost regarding Elcomsoft’s capabilities should they be afforded a signed bootloader. If the passcode was 4 numeric characters the passcode could be obtained within an hour, or a few days if it was up to 6. I feel as though the question the public should be asking is “are we ok with the government brute forcing encryption”, since this is not a question of the information provider decrypting encrypted information for them. If we’re ok with the government attempting to access information (when it is warranted) then that should answer the question shouldn’t it? We as a society appear to be ok with law enforcement obtain access to locked boxes when it’s warranted, why are digital devices different?

    I do like TrewMTE’s list of stages; it really does make people question whether there is a way to preserve privacy for the masses whilst catching people smugglers or terrorists with nuclear capabilities.

    Similarly though, Zdzairski has a second post regarding the philosophy of privacy in code. He states that Apple shouldn’t even be able to comply with the order. This is actually where I see Apple moving to in the future. We’ve seen it with other companies in the past; they turn over the unintelligible mess to whomever requests it through the court and says good luck.

    Zdzairski has another post regarding his interpretation of the court document; he states that Apple would be required to create and ultimately validate and defend a forensic tool for breaking into their devices. I think I interpret the section regarding what the FBI was requesting from Apple slightly differently to Zdzairski. I may be wrong, but I feel like the FBI is just trying to find a way to utilise a technology like the IP-Box to break into the phone. The FBI just requires a temporary version of iOS to be loaded onto the phone by Apple that allows a user to send unlimited codes with no software delay (as mentioned in the Elcomsoft blogpost, the 5C has a software based delay rather than a hardware based delay). I don’t think Apple is required to create a validated forensic tool, and theoretically they could also comply by loading the software onto the device (specifically only for that serial and IMEI combination) and then when the phone resets the OS is gone – similar to how Zdzairski’s original method worked. Patrick Gray mentionned on the latest episode of Risky Business that the wording would suggest that Apple doesn’t need to hand anything over to the FBI afterwards but then agrees that in the future Apple will probably require user password for firmware updates/DFU mode which ultimately gets rid of their ability to comply.

    Zdzairski also posted his opinions on why the device probably doesn’t have anything of interest on it. Lastly he has also posted up about his thoughts on why the FBI didn’t compel Apple to take an iCloud backup of the device.

    A Message to Our Customers, Apple and FBI
    Moral Ethics of Backdoor iPhone 5C
    tl;dr Apple’s technical capabilities under FBI AWA order
    Code is law
    Apple, FBI, and the Burden of Forensic Methodology
    Risky Business #399 — Apple vs the Government of the United States
    10 Reasons Farook’s Work Phone Likely Won’t Have Any Evidence
    On FBI’s Interference with iCloud Backups

  5. Jared Atkinson has two new posts this week. The first post relates to installing his PowerForensics toolkit using either the PowerShell gallery or GitHub. The second post relates to the Invoke-ForensicDD cmdlet. This post explains a bit about the cmdlets similarities with the unix DD command.
    Installing PowerForensics
    Forensic Friday: Invoke-ForensicDD

  6. Thomas White at Tribal Chicken has a post up (last week, but it was updated again this week) with a new volatility plugin which attempts to extract Apple FileVault 2 Volume Master Keys. I like how he explains his methodology of locating the key and then shows the commands a user can use to test it out.
    Extracting filevault2 keys with Volatility

  7. Harlan Carvey has two posts up this week. The first post shares Mary Ellens toolist as well as a bit about Eric Zimmerman’s new LECmd tool. I think the main take away is this sentence: “information should be available to the analyst, but I also believe that it’s the responsibility of the analyst to (a) recognize what information can be derived from various data sources, and (b) be able to correctly interpret and utilize that data”. Lastly he finishes with a second “in the trenches” story about incompetent IT staff.

    The second post provided a plugin update for the appcompatcache regripper plugin to allow it to work with Windows 10.  He then continues onto comment on the use of the PECapture tool and its potential use and finishes with an “In the trenches” about computer networking.
    Tools, Links, From the Trenches, part deux
    Links

  8. WeAre4n6 have a new post up about thumbnail databases on Android. These databases usually have a name similar to imgcache* and contain JPEGs. As a result an examiner can carve out potential files of interest.
    Do not miss: new thumbnail databases in Android OS

  9. There were two posts up by the students at Champlain College this week. The first was an Introduction the teams project on data extractions from jailbroken iOS 9 devices. This research will cover a comparison of the data obtained from an iPhone before and after a jailbreak. This is quite useful research to have as occasionally there may be no option for an examiner other than to jailbreak the device, so it’s good to have some research to explain what is changed.

    The second was an introduction to Mac RAM Analysis. The team will be looking into an analysis of memory on a current Mac computer, with a report covering their analysis. I haven’t had to do much memory analysis on Mac computers but I do know that Macquisition by Blackbag is able to extract memory. While they’re at it, it would be good as an addendum to do some testing on the memory that can be obtained when a computer is rebooted into a tool like Macquisition; the tool uses up less than a gigabyte of memory, and on a 16GB system, that’s still a lot of information that could theoretically be obtained should the system maintain power during the reboot.
    IOS9 JAILBREAK INTRODUCTION
    MAC RAM ANALYSIS INTRODUCTION

And that’s all for Week 7! If you think I’ve missed something, or want me to cover something specifically let me know at randomaccess3+thisweekin4n6 at gmail dot com.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s