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.