Forensic Blogs

An aggregator for digital forensics blogs

by

Mobile Forensics Update 2

Introduction

If you read our last blog post, you know that the Mobile Forensic team ran into some issues early on. We are happy to share that we have since overcome those issues, and we’ve hit the ground running with our project. We are no longer using the LG G6 devices mentioned last month due to issues rooting these devices. Instead we are using Nexus 7 tablets running Android 6 and 7.

Two apps we pulled and analyzed data from are Snapchat and Telegram. Before we set up accounts, we had to create different personas for each team member. The personas we came up with were Johan Smith, Tony Pepperoni, and Mallow Operator.

Snapchat

Before we started collecting our data, we had to figure out what actions we would go through so we all had data we could compare. Some of the actions to generate data for Snapchat included adding each other as friends, creating a group chat, and posing to a story. When generating data for analysis, we kept track of who sent chats to whom, what time we did each action, and if anything went wrong. After pulling the data with adb, we compared the timestamps and actions from the pull with our datagen log. We were successfully able to see what Snapchat saves and what we can find on the phone.

Telegram

When we were setting up Telegram, we had to setup Google Voice numbers in order to create our profiles. With Telegram we also had to figure out what actions we wanted to take so that each person could get similar pull results—hence the creation of another datagen. With Telegram our actions included adding contacts, joining different groups, and sending videos and stickers. We kept track of timestamps again and then compared the data and the pull. We decided to use both Cellebrite and adb to see if there was any benefit of one tool over the other. At the moment, we’re still analyzing Telegram to see if there is anything noteworthy so stay tuned!

Conclusion

With these pulls we were able to see what data Snapchat and Telegram save on your phone. We were looking to see if any unusual data was saved by the applications. So far nothing has stood out with either Snapchat or Telegram. The next app we will be doing a datagen and pulling is LinkedIn.

Stay tuned for more updates to come and follow us on Twitter @ChampForensics, Instagram @ChampForensics, and Facebook @ChamplainLCDI.

The post Mobile Forensics Update 2 appeared first on The Leahy Center for Digital Investigation.

by

SIFT Update 2

Introduction

This month at the Senator Leahy Center for Digital Investigation, we started analyzing our data. As a part of the SIFT research team, we used our knowledge of digital forensics to scan through files in order to find artifacts that would help us put our criminal behind bars. After we found artifacts, we went on to conduct keyword searches where we found very useful evidence for our investigation.

Experience

We have learned so much over the past month about SIFT. SIFT allows for artifact gathering, and keyword searching. Artifact gathering involves going into the imaged drive and gathering potentially incriminating files, or anything that could be useful to a digital investigators analysis. Pair that with keyword searching and a strong case can be built and argued in criminal court.

Originally SIFT had major issues in the srch_strings function within Autopsy. This was a major issue because srch_strings is used for keyword searching, an essential part of a digital investigator’s case.  Being new to SIFT was difficult because as a team we did not know how to fix this problem. Eventually, we learned the issue occurred because SIFT runs an older, unsupported version of Autopsy (Autopsy 2.24). The only way to fix this was to import a new version of srch_strings into SleuthKit. After importing the new version, we managed to get keyword searching to work with up to three characters, and on the letter “e” alone, got 3 million hits.

For our project, our data gen had us searing for “cyanide”. Therefore, a keyword search for “cyanide” would be useful in finding files that contain information about the poisoning.

Conclusion

Finding artifacts and searching for keywords are extremely important to a digital investigator. Within the coming weeks, we are going to be recovering deleted files from the disk image. Stay tuned for our next blog about recovering deleted files.

The post SIFT Update 2 appeared first on The Leahy Center for Digital Investigation.

by

Extracting DotNetToJScript’s PE Files

I added a new option (-I, –ignorehex) to base64dump.py to make the extraction of the PE file inside a JScript script generated with DotNetToJScript a bit easier.

DotNetToJScript is James Forshaw‘s “tool to generate a JScript which bootstraps an arbitrary .NET Assembly and class”.

Here is an example of a script generated by James’ tool:

The serialized .NET object is embedded as a string concatenation of BASE64 strings, assigned to variable serialized_obj.

With re-search.py, I extract all strings from the script (e.g. strings delimited by double quotes):

The first 3 strings are not part of the BASE64 encoded object, hence I get rid of them (there are no unwanted strings at the end):

And now I have BASE64 characters, I just have to get rid of the doubles quotes and the newlines (base64dump searches for continuous strings of BASE64 characters). With base64dump‘s -w option I can get rid of whitespace (including newlines), and with option -i I can get rid of the double-quote character. Unfortunately, escaping of this character (\”) works on Windows, but then cmd.exe gets confused for the next pipe (it expects a closing double-quote). That’s why I introduced option -I, to specify characters with their hexadecimal value. Double-quote is 0x22, thus I use option -I 22:

This is the serialized object, and it contains the .NET assembly I want to analyze. .NET assemblies are .DLLs, e.g. PE files. With my YARA rule to detect PE files, I can find it inside the serialized data:

A PE file was found, and it starts at position 0x04C7. I can cut this data out with option -c:

Another method to find the start of the PE file, is to use a cut expression that searches for ‘MZ’, like this:

If there is more than one instance of string MZ, different cut-expressions must be tried to find the real start of the PE file. For example, this is the cut-expression to select data starting with the second instance of string MZ: -c “[‘MZ’]2:”

It’s best to pipe the cut-out data into pecheck, to validate that it is indeed a PE file:

pecheck also helps with finding the length of the PE file (with the given cut-expression, I select all data until the end of the serialized data).

Remark that there is an overlay (bytes appended to the end of the PE file), and that it starts at position 0x1400. Since I don’t expect an overlay in this .NET assembly, the overlay is not part of the PE file, but it is part of the serialization meta data.

Hence I can cut out the PE file precisely like this:

This PE file can be saved to disk now for reverse-engineering.

I have not read the .NET serialization format specification, but I can make an educated guess. Right before the PE file, there is the following data:

Remark the first 4 bytes (5 bytes before the beginning of the PE file): 00 14 00 00. That’s 0x1400 as a little-endian 32-bit integer, exactly the length of the PE file, 5120 bytes:

So that’s most likely another method to determine the length of the PE file.