This year I'm at the Pass the Salt 2019 conferences. You'll find my notes updated in real time here.

Kill MD5

by Ange Albertini (slides)

Ange starts by saying that he does not know much about crypto, and he had help from Marc Stevens, a hash-collision cryptographer. This talk should provide a high-level overview.

A property of hashes is that you shouldn't be able to guess a hashed content from the hash value. This is still true, even for MD2, Ange says.

Hash collisions are separated in two types: identical-prefix and chosen prefix.

A collision is separated in 4 parts: the prefix, its padding, the collision block, and the suffix. Only the collision block changes between two collided files.

For a chosen prefix collision, the two prefixes can be completely different. It means the state of the hash function will be different in the two files when computing the collision blocks.

MD5

MD5 is mostly dead since 2008 when a practical attack was demonstrated.

To further prove this point, Ange computed a few demos colliding JPGs, executables, MP4s, GIFs, etc. He even went as far as doing a collision of four different file type for PoC||GTFO: PDF, PNG, PE and MP4.

There a few different algorithms to exploit MD5 collisions, with varying difficulty.

To craft a file that is collidable, the common approach is to have a comment in the file; in the collision block, the comment will mask a chunk that is isn't in the original file. In order to have a file format that isn't collidable, don't put comment in it, or remove comments before computing hashes.

To conclude, Ange said that MD5 isn't a cryptographic hash, but a toy function. Do not use it to compute hashes. His work was meant to prove the real-world feasibility of hash attacks.

Dexcalibur - automate your android app reverse

by Georges-B. Michel (slides)

An obfuscated Android app will usually be split in multiple .dex stages, first a packer, then a loader and then the payload. Only the first stage is usually available for static analysis, the rest is usually done dynamically, and can be very cumbersome.

That's why Georges started developing a toolkit in order to discover automate this process: Dexcalibur.

Dexcalibur integrates many tools: baksmali for disassembling, as well as file identifiers, parsers, static and dynamic code analyzers, and instrumentatioon with Frida. He added a modular heuristic search engine on top of that, as well a web UI.

The current limitations is that it can't hook native code on do symbolic execution of bytecode. To fix that, Georges intends to integrate radare2 in Dexcalibur in the future.

In a demo, Georges showed a crackme running in an emulator, and being analyzed in real-time in the Dexcalibur web UI. It works by extracting all the code present in an APK, then instrumenting it before running it. There are default hooks, for filesystem access for example. The code is then run, and at hook points, the analysis engine will evaluate a few rules in order to provide the most complete view of the reversed app possible.

As an example, if code is called dynamically (reflection), Dexcalibur will still update the cross-references (xref) in order to have a complete call graph.

Reversing a firmware uploader & other NFC stories

by Aurélien Pocheville (slides)

Aurélien started with a warning to always be careful when manipulating LF NFC tags. He once erased one by mistake when attempting to use a brand new proxmark.

The Chameleon Mini: Rev E is an NFC writer tool, that is widely available online. Unfortunately, it only worked with Windows, so Aurélien decided to reverse its loader in order to create a multiplatform free and open source solution. Since it was based on a reversed iceman tool, he thought it was just a case of finding an AES key. When launching the tool, it looked like a simple DFU programmer, but he didn't know that at the time.

In order to reverse the firmware builder, he started with Ghidra, a relatively recent RE and decompiling toolkit. Very quickly by looking at the code, he found an AES key, and attempted to decrypt the code with it. It wasn't successful. Afterwards, he looked again at the data-preprocessing, and after a two attempts, found that both the data was run through a rolling xor, and the key was used in decryption mode for encryption (and vice-versa).

Looking the flasher, he found that the AES was decrypted (in encryption mode), but the rolling-XOR was kept. On-device bootloader undid the rolling XOR.

In the end, he had a working solution, but it can still be improved.

He then presented a small puzzle with NFC tags controlling access to an apartment complex, which he cloned for a friend, but then ran into an anti-clone protection that triggered erratic behaviour.

Improving your firmware security analysis process with FACT

by Johannes vom Dorp (slides)

IoT devices are growing, and more and more devices are used as part of network attacks. FACT is a tool to help doing firmware analysis in order to improve security.

A typical firmware analysis, Johannes says, starts with unpacking. Then you'll gather information with the help of a tool in order to attempt identifying obvious weaknesses. Then, if there is nothing obvious, one should start doing reverse engineering. The goal of FACT is to automate the first three parts, leaving RE as a manual phase.

The initial goal in 2015 was to improve on binwalk, which mostly does extraction and discovery of files. The goal was to make a new tool with even more automated phases, and being as extendable as possible. FACT is still using binwalk for a lot of use cases, but its internal tools have also replaced it for many operations.

In addition to combining unpacking with various tools, FACt does parallel analysis, provides result visualization, a plugin system, and stores its results in a query-able database, which can be used for comparison or statistical analysis. Many statistics are already provided by default.

In a demonstration of the tool, Johannes showed how a binary can be found vulnerable to heartbleed in a router firmware, as well as the many generated statistics. In another, he showed the crypto material that was found in the image, in an executable; you can then search for other occurrences of the same key for example. There also various ways to do a search in all the firmwares: from a quick search, to an advanced one, to a raw mongodb query; it's also possible to search by yara rules.

The compare feature allows comparing two different versions of the same firmware for example, to find only what changed, or the common software. This can be used for example to find what bug was fixed in a given version. Or, in Johannes example, if a fix actually fixes the core issue.

cwe_checker: Hunting Binary Code Vulnerabilities Across CPU Architectures

by Thomas Barabosch and Nils-Edvin Enkelmann (slides)

Another tool is presented here, to automate a part of the vulnerability research tasks, with an accent on supporting multiple CPU architectures. In order to do that, cwe_checker works with an intermediate representation (IR), generated by BAP, an open source reverse engineering tool.

Nils says cwe_checker is inspired by clang-analyzer: it find potential bugs by looking for heuristics of varying complexity. It has a modular structure, and is written in OCaml, like BAP which it builds atop. CWE stands for Common Weakness Enumeration, and is named like that because each specific heuristic analyzer has a given number, and they check for various issues: integer overflow, null dereference, TOCTOU race, etc.

cwe_checker does symbolic execution BAP's Primus engine, although it can be time consuming, especially with path explosion. That's why it's only optional by default.

cwe_checker uses a variety of techniques; for integer overflow, it currently checks for instructions run before a malloc-family function, but other functions can be added. For NULL dereference, it has a list of function that can return NULL, and verifies if NULL is checked for in the return value with varied flow analysis in the IR.

FACT, presented in the previous talk, integrates cwe_checker. The project also provides integration with IDA Pro with python scripts.

In conclusion, Thomas says there are few false positives or negatives, so they want to improve the checks, but also add more checks and different type of analysis.

Unlocking secrets of the proxmark3 RDV4

by Christian Herrmann

Proxmark3 is the third iteration of a board designed for RFID research. It works at 125kHz, 13.56MHz, as well as contact tags. It's a versatile tool.

Recent high profile uses include an attack on the Tesla model S key fob that could be cloned with a Proxmark3; another one was the VingCard vulnerability, that affected 140 millions door locks.

The previous revision had a few issues, so a kickstarter was made to launch a newer, smaller, more powerful version. The new design allows for antenna customisation which is critical depending what tag you want to address, has onboard memory, etc.

The new version now supports chip-and-pin cards (ISO-7816), with an extension for snooping what happens in an exchange and run commands. It also has a bluetooth and battery add-on, allowing to use it wirelessly with a smartphone (if it had an Android/iOS app).

There's an ARM processor on board, and an FPGA on-board for RF processing. The command line tool has many different commands, as well as high-level lua scripts. It can work in standalone mode, or with client that does the computation or crypto attacks.

Workshop: Let’s play ColTris - understand and exploit hash collisions

by Ange Albertini

slides This workshop is an intro to hash collisions, and how to exploit each one with relation to file formats.

At first we used hashclash to compute md5 collisions with an empty prefix with the md5_fastcoll tool. Then we used a prefix we generated. These are identical prefix collisions.

Fastcoll is easy to do, but hard to use, because you need a file format where you can skip the identical random data in the collided blocks, but also use the modified bytes to have an effect on the files being different. For example, if the different bytes control the length of a comment block, then you can have variable comment blocks length, different on each of the two files, meaning they will be interpreted differently.

When you want to craft a reusable collision, you need to plan a header that will contain two files, depending on where the comment blocks are, and this way, with your two headers, you can generate two colliding files at will.

Next, we started using unicoll, with the poc_no.sh script in the hashclash tool set. This attack works by modifying only a single byte in the collision block; there is no padding, and only two bytes are modified, by being incremented. It takes longer to compute (a few minutes instead of seconds), but since the modified byte is only incremented, it gives more control when creating collisions with some file formats.

Using unicoll, it's possible to exploit the PNG file structure, by varying the byte size of a block in big endian: this gives you a jump of +0x100, more that enough to have varying data in the skipped chunk.

Next, Ange showed how to use fastcool with the GIF format in particular, which has a structure that allows using it. GIF is quite old, and its sublock and comment structure allows using fastcoll, which is very useful for computing fast collisions.

In the end, Ange explained the constraints of the chosen prefix attack, and how to implement it using the hashclash cpc.sh script. The length of the prefixes don't matter, but having a file format that tolerates appended data is important. It's this attack that Ange used to generate a reusable PE format collision. If block alignment is properly handled, it's possible to chain collisions, which can be used for mixing file types, or modifying content in a per-block fashion with unicoll.

That's it for part 1. Part 2 is continued here, and part 3 here.