Forensic Blogs

An aggregator for digital forensics blogs

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.

 

by

Bluetooth Tracking Reboot

New Team, New Goals, Same Tools

Frequent readers of this blog may remember last semester’s Bluetooth Tracking Project. It focused on developing methods to trilaterate the position of a Bluetooth device based off signal strength.

This semester, the goal has shifted. Our team will build and implement a network of stand-alone Bluetooth monitoring devices. We are basing this off of research and methodologies developed last semester. These devices will use publicly available toolsets and low cost hardware. They will collect and report information on Bluetooth devices to a central hub. This will make the findings easy to view.

Tools used last semester are being used for this project. Last semester the Bluetooth team used  blue_hydra and ubertooth in conjunction. Both provided key information regarding the functioning of the trilateration. Because we no longer need the same feedback, we decided to focus on using blue_hydra as the scanning tool. The hardware Ubertooth, and he underlying software library, will still be utilized. This will simplify the scripting process of our project immensely. Unlike last semester, we’ve decided to use the Raspberry Pi model 3 as the base of our sensor nodes. The current team is more familiar with this type of hardware. It’s also compatible with all the hardware and software required for the project. Plus, we have them handy.

 

Current Bluetooth Progress

We started out familiarizing ourselves with our new goals and the research from last semester’s Bluetooth project. We used the installation guide from last semester. This ensured that all our hardware is properly configured. Over the past few weeks, we have focused on testing and configuring the hardware and software. We are progressing nicely. When we have a functioning model, future reports will outline the code.

Another big aspect we have been tackling is creating a server infrastructure for collecting all the data. By nature, the sensor nodes distribute across a large physical area. They will need a way of reporting the data they have collected. We decided to take a more structured approach. We implemented an elasticsearch cluster that the nodes can connect to. Elasticsearch has a wealth of built in features, the biggest being an inherent compatibility with kibana dashboards and the elasticsearch python library. The Elasticsearch Python library ships data from our nodes to our Elasticsearch cluster. Kibana allows us to visualize, manipulate, and collect metrics. This makes it easy to view Bluetooth devices that have been collected from our nodes.

Wrap Up

When laying the groundwork for this project, we took into account previous work. It was important to set up the project in a way future teams would be able to build without making radical design changes. Last semester’s Bluetooth team had thorough methodologies and research. This enabled us to start making infrastructure choices immediately. Our next steps will focus on executing our code outlines and building out the server infrastructure.

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

The post Bluetooth Tracking Reboot appeared first on The Leahy Center for Digital Investigation.

by

Cracking Encrypted PDFs – Conclusion

TL;DR: PDFs protected with 40-bit keys can not guarantee confidentiality, even with strong passwords. When you protect your PDFs with a password, you have to encrypt your PDFs with strong passwords and use long enough keys. The PDF specification has evolved over time, and with it, the encryption options you have. There are many encryption options today, you are no longer restricted to 40-bit keys. You can use 128-bit or 256-bit keys too.

There is a trade-off too: the more advanced encryption option you use, the more recent the PDF reader must be to support the encryption option you selected. Older PDF readers are not able to handle 256-bit AES for example.

Since each application capable of creating PDFs will have different options and descriptions for encryption, I can not tell you what options to use for your particular application. There are just too many different applications and versions. But if you are not sure if you selected an encryption option that will use long enough keys, you can always check the /Encrypt dictionary of the PDF you created, for example with my pdf-parser (in this example /Length 128 tells us a 128-bit key is used):

Or you can use QPDF to encrypt an existing PDF (I’ll publish a blog post later with encryption examples for QPDF).

But don’t use 40-bit keys, unless confidentiality is not important to you:

I first showed (almost 4 years ago) how PDFs with 40-bit keys can be decrypted in minutes, using a commercial tool with rainbow tables. This video illustrates this.

Later I showed how this can be done with free, open source tools: Hashcat and John the Ripper. But although I could recover the encryption key using Hashcat, I still had to use a commercial tool to do the actual decryption with the key recovered by Hashcat.

Today, this is no longer the case: in this series of blog posts, I show how to recover the password, how to recover the key and how to decrypt with the key, all with free, open source tools.

Overview of the complete blog post series:

Cracking Encrypted PDFs – Part 1: cracking the password of a PDF and decrypting it Cracking Encrypted PDFs – Part 2: cracking the encryption key of a PDF Cracking Encrypted PDFs – Part 3: decrypting a PDF with its encryption key : don’t use 40-bit keys (what you are reading now)