Hey there!
The God of frequencies Michael Ossmann visited us again this year at the TROOPERS16 and showed us how to break another device using a specific setup.
Last time he introduced the HackRF One to us (Read here:https://www.insinuator.net/2014/08/hackrf-one-the-story-continues/), but this post is a short summary of his talk about “Rapid Radio Reversing”, he is a wireless security researcher, who makes hardware for hackers. Best known for the HackRF, Ubertooth, and Daisho projects, he founded Great Scott Gadgets in an effort to put exciting, new tools into the hands of innovative people.
White-box cryptography is a relatively new field that aims at enabling safely cryptographic operations in hostile situations.
A typical example is its use in digital-right management (DRM) schemes, but nowadays you also find white-box implementations in mobile applications such as Host Card Emulation (HCE) and the protection of credentials to the cloud.
In all these use-cases the software implementation uses the secret key of a third-party which should remain secret from the owner of the device which is running this executable.
Last year on the Hex-rays plugin Contest the Dynamic IDA Enrichment (DIE) plugin won first place, so we decided to have a look and play around with it.
DIE extends IDA to add Dynamic Data to the static analysis. So after the installation, we are able to perform the static analysis using a lot of supporting information from the actual execution of the binary under assessment.
Since DIE is purely written in Python you will need at least Python 2.7 and IDA Versions prior to 6.8 won´t work. In the current version DIE will only work on Windows which will hopefully soon be available cross-platform.
In the beginning of September, I had an opportunity to take part in BlackHoodie – a reversing workshop for women organized by Marion Marschalek, senior malware researcher at Cyphort, Inc. It took place on 5th and 6th of September at University of Applied Sciences St. Pölten, Austria.
Besides me, 14 more young women from different countries came to attend the workshop; the overall atmosphere was very friendly and productive. Before the actual event all participants were getting preparatory assignments and recommendations (not to spend our two days on learning the very basics), and during the workshop itself we got our hands on analyzing and reversing some actual malware samples. I personally found it very interesting how one can detect and overcome several layers of anti-analysis protection. I left the workshop excited and packed with some new knowledge as a basis for further skills development – it’s just the beginning! 😉
The below post was originally written on February 9th as a little educational exercise & follow-up to my BinDiff post. (This research was actually triggered by a relative asking about that strange Fritz!Box vulnerability he heard about on the radio). Once we realized the full potential of the bug we decided against publishing the post and contacted several parties instead. Amongst others this contributed to the German BSI press release. Given the cat is out of the bag now anyway, we see no reason to hold it back. We will further take this as an opportunity to lay out our basic vulnerability disclosure principles in a future post. This topic will also be discussed in the panel “Ethics of Security Work & Research” at Troopers
Reverse engineering is generally thought of as using debuggers, disassemblers and hex editors. Much as I love hex editors, IDA and staring at opcodes for the last few years I have been focused on applying my reverse engineering methodology to larger, composed systems. At Troopers TelcoSec day this year I will be presenting Bluevoxing which demonstrates how this approach works. Bluevoxing is about reverse engineering how web based “audio one time password” systems work. Simply put audio one time password systems use a short audio file as an authentication token. When I discovered these systems I was intrigued as reversing them would involve a range of techniques and tools from web testing, audio tools, signal analysis, phreaking and cryptanalysis. The disassembler would be of no use instead I would have to employ audio tools such as audacity and ruby-processing.