Forensic Blogs

An aggregator for digital forensics blogs

by

Update: oledump.py Version 0.0.50

This new version brings updates to plugin plugin_biff.py.

This plugin can now produce a CSV list of cell values and formulas (option -c) or a JSON file of values and formulas (option -j).

Cell references are in RC format (row-column), but can also be produced in letters-numbers format (LN, option -r LN).

CSV or JSON output can be piped into my ad-hoc decoding programs.


oledump_V0_0_50.zip (https)
MD5: 30EB6A0E0924E72350B268ADDE4E4EC7
SHA256: 870167AE5576B169EB52572788D04F1FFCEC5C8AFDEBCC59FE3B8B01CBDE6CD9

by

Update: XORSelection.1sc Version 5.0

XORSelection is a 010 Editor script I wrote some time ago, and it is included in the 010 Editor script repository. You provided it with an XOR key (ASCII or HEX), and then it will XOR-encode the file open in 010 Editor (or a selection of that file).

This new version brings options.

The input box of XORSelection can still be used to provide an ASCII key (e.g. Secret) or an HEX key (e.g. 0x536563726574), and the program will behave like before.

But if you provide no input and click OK, a second input box will be displayed, to input options (prior versions display an error message).

If you type h, you’ll get a simple help dialog, and then the program will terminate:

The options you can enter are r, l and/or s.

Use option r (reverse key) if the key has to be reversed before being used. Example: Secret -> terceS.

I introduced this option because I regularly need to use little-endian 4-byte XOR keys.

Use option l (literal key) if you need to use an ASCII key that starts with 0x (otherwise this key will be parsed as an HEX key).

Option s (shift) can be used to shift the key.

Here is an example to explain the shift option: assume the key is Secret, and that you want to decode a selection of an encrypted file. That selection will most likely not align with the key (e.g. the first byte of the selection was not encoded with the first byte of the key): lets assume you need to start decoding from the 3rd byte of the key: then you need a shift to the right of 2 positions, e.g. option s2. Remark that you can also shift to the left, then you use a negative integer, for example s-1.

XORSelection_V5_0.zip (https)
MD5: 0C2776C7E02235C4949A81AAEF079F66
SHA256: 4F82BC180264FC21802A43E2E5B078EDA7B24FC655815A37948317E8F043A5CA

by

Data Recovery Blog 2

Data on a screen, various numbers highlighted green, with a red open lock Data Is Not As “Deleted” As You Think

Here at The Leahy Center for Digital Forensics and Cybersecurity, the Data Recovery team has been hard at work searching through hard drives. These drives have been wiped using different methods in order to find any Personally Identifiable Information, or PII, that can be tied back to an individual.

At this point, ten out of the twenty eight drives purchased have been fully analyzed for the purposes of recovering data. Three drives, numbered 7, 9, and 10, all contained PII data. Drive 7 used the wiping method of DBAN, which stands for Darik’s Boot and Nuke, and is a free Linux utility. Drives 9 and 10 use the Xerase method, put forth by EPS. Both of these utilities claim to offer “secure absolute destruction”, yet how secure can they be if a team of analysts is able to recover data using tools that are freely available to the public?

The Recovery Process

For this project, we are using four “freeware” tools to recover data. These tools are SluethKit’s Autopsy, FTK Imager, Bulk Extractor, and Eric Zimmerman’s “bstrings” utility for Windows. Every drive that was purchased was run through all of these tools, not only to ensure visibility of data, but to determine if one tool has superior discovery abilities for deleted data. The tools are relatively simple to begin using, but require a bit of technical knowledge to become comfortable with. We have built a beginner-friendly user guide for how to start all four tools for acquisitions of data, which can be seen below.

Autopsy: Open Autopsy.  Fill out the stating form as needed.  Select “Add Data Source” –> “Unallocated Space Image File”.  Select the first piece of the drive. 

Wait for the image to finish scanning. This will take a while.

Bstrings: Open the command line in the folder in which you extracted bstrings. Type out the command to run it on a folder recursively to search an entire drive at once. Example:  bstrings.exe -d Disk Location > File Where Data Found Is Saved\bstrings.txt Adjust the conventions to match the image that you are working on. Bulk Extractor:  Point Bulk Extractor to the desired image Ex: HDD02.001, and a directory where you would like the output to go. Turn on all scanners by checking all of their boxes Press the ‘start bulk_extractor’ button to being the scan FTK Imager: Upload disk image from the F:\Drive into FTK Imager v3.4.0.5.  On the left hand side, click on the location i.e HD1, then select the file path (it will be the only option in the evidence tree).  Upon clicking, there will be a file list in the middle column, and a column full of text and UNICODE on the far right. This is where all of the data is.  Since there is no file system, the program pulls data haphazardly.  In FTK Imager, you can use “Ctrl + F” to search from strings, but be wary of what language you are searching in.  Select the “wrap” option as well, to ensure that if a string crosses more than one line, it will be recorded in the results. Analyze Which Data Recovery Tools Reign Supreme?

At the current point in the project, Autopsy is proving to be the most effective tool for data recovery. Autopsy has a very user friendly interface. This provides ease of access and lower frustrations when dealing with drives that have been wiped. Also, Autopsy is very thorough in the way that it searches, parsing through nearly every single file, and every bit of unallocated space. FTK Imager is a very good tool as well, yet does not have a very easy interface to work with. This is not what would be known as a “deal breaker”, but plays into our analysis as we spend a lot of time analyzing these drives, so ease of access is a crucial part. Bulk Extractor is a utility that runs off of command line, but has a GUI—or Graphical User Interface—to facilitate the process for those who are not comfortable with command line utilities. This tool runs the drive analysis as raw data, and finds everything that is on the drive, which is very helpful for data recovery. 

The last tool we have used is bstrings by Eric Zimmerman. Bstrings is a command line utility that only runs as such, making it a bit more difficult than the other tools to be comfortable with. It is ridiculously thorough, as it pulls anything and everything off of the drive that’s considered a string. However, due to CPU constraints, this tool does take the longest to fully finish, often over 24 hours. 

Image of a trophy with a 1 on it

Stay up to date with Twitter, Instagram, and Facebook by following @ChampForensics so you always know what we’re up to!

The post Data Recovery Blog 2 appeared first on The Leahy Center for Digital Forensics & Cybersecurity.