This is a guest post from Graeme Neilson
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.
My methodology was:
- collect a large sample set of audio one time passwords
- extract the raw audio file from the samples
- somehow convert the audio file into a number…
- analyse the numbers…
When I set out steps one and two seemed fairly straightforward but three and four were unknown. However one of the mantras of my reverse engineering methodology is assume you will be able to reverse the system. As more information is collected about the system it should become possible to test different hypotheses regarding how the system operates. In my experience deconstructing the problem into small problems and solving them progressively one at a time is generally successful.
Collection of audio one time passwords involved using web testing tools. I needed a proxy to collect all the requests and responses made to the authentication system. I chose mitmproxy as it was python based and I could write any plugins I needed. In this particular case the audio file was delivered in a flash container so I needed a script to save only the flash files from all the web traffic. This is done very simply in mitmproxy as it provides a flow object containing the request and the associated response. This let me save the flash files with timestamps from the request. Having timestamped audio one time passwords was useful in later stages. Once the flash files were obtained I could use swf tools to extract the audio as an mp3.
The next step was challenging as I now had to work out how to convert the audio information into a number. This required delving into the world of signal analysis. Some old protocols exist which were designed for this task. For example, SS5 was used by telcos for in-band signalling over telephone networks. It uses multi frequency signalling to send information over the voice channel. The other well known signalling mechanism is dual tone multi frequency (DTMF) which is the tones you hear when you dial numbers on phones. Using audacity to manually inspect the audio files led me to conjecture that the audio one time passwords used multi frequency signalling, in particular pairs of frequencies. Clearly they were not DTMF and the frequency bands were similar to SS5. For conversion of the audio I used sonic-annotater and a vamp pitch plugin (pitch is frequency) to convert the audio into frequency values at particular sample rates. The last step was mapping frequency pairs to an integer using 2 in 6 encoding. I could test different mappings and then statistically analyse the resulting numbers for randomness.
From there I used the information gained to create my own audio one time password generator using ruby-processing and a system with a low latency linux kernel (the frequency pairs are only milliseconds long). So no hex editors, debuggers or disassemblers in sight, instead plenty of audio tools and an excuse to buy a professional sound card. If you want to learn more about how to think like a reverse engineer feel free to come to the training I am running at Troopers. See you there!
———–
*
**Graeme Neilson*
Lead Researcher & Security Consultant | Aura Information Security
we clearly and simply make you more secure