Arcadyan IAD Decrypter v0.05 released

Today I would like to announce a major update to the Arcadyan IAD Decrypter which you might know from the IP-Phone-Forum or from my previous blog post. It is now capable of decrypting the new “OBC6” configuration backup file format used in Arcadyan routers such as o2Box 6431. However special steps have to be taken if you want to use this method to recover your VoIP credentials (vide infra).

• arcadyan_decrypter_v0.05a.zip

What has happend since February?

Firmware versions up to 1.01.22 used the “CFG5” format which could be decrypted by my old Decrypter (v0.04). Somewhere around the end of September 2013 o2 started to roll out a new firmware (version 1.01.23b) to their o2Box 6431 devices. With this updated firmware the configuration backup layout was changed in a way that my previous v0.04 version of the Arcadyan IAD Decrypter could not handle it anymore.

Obfuscation and more obfuscation

When analysing the new firmware I found out that o2 (or Arcadyan) have made an effort to thwart static analysis of their binary. They have introduced some kind of control flow obfuscation. Call addresses of interesting functions which implement their new file format are now computed dynamically (at runtime). In a nutshell their “protection” works like this:

1. During the boot process the addresses of all protected functions are linked to a unique number in a hash table (see picture).
2. Static calls to protected functions are replaced by a lookup/trampoline function which fetches the original address from the hash table by its unique number. Control flow then resumes at the result of the lookup (see picture).
3. The arguments to these protected functions are either passed via a memory section which is maintained by the protection or by fetching the local variables from the previous stack-frame via an additional pointer.
4. The protected functions start with some extra code to restore the arguments from the according source to the original argument registers $a0, $a1, …

This mechanism could be defeated easily by two IDA Python scripts. One which builds the hash table with the information from the boot process. For each call to a protected function a second script then looks up the original address in the hash table by its unique number and places the result as a comment next to the protected/dynamic call.

It turned out that most of the old “CFG5” config scheme remained the same. Only at two places there was some XOR-functionality added: right before and after the second decryption step of the “CFG5” format. These additional XOR operations process the intermediate buffers which hold the semi-decrypted config file. In “OBC6” format they contain a preceding 0xA0 byte large table (more precisely: two tables, 0x80 and 0x20 bytes). After that follows the ciphertext/plaintext which contains a variable number of 4-byte long “tags”. These tags determine the distance to the next tag as well as the starting index within the 0x80 byte table. The bytes between two tags are XOR’ed with the chars from the 0x80 byte table. Finally all chunks are concatenated, the new size of the merged chunks is returned and the buffers are processed the same as in “CFG5” format.

What are you o2/Arcadyan guys trying to achieve with your obfuscation techniques? Wouldn’t it make more sense to focus on improving the quality and features of your SOHO routers instead of adding even more obscurity to your configuration file format? If o2 customers were satisfied with what you deliever how do you explain 103.000 hits/8.000 downloads/640 replies of people who want to replace your router in this thread? And that does not even include people who only read my blog, other blogs (here and here) or the o2 forum itself.

Even Hansjörg Schmidt, member of the parliament of Hamburg, dislikes “Zwangsrouter” as he posted on twitter:

Drecks Zwangsrouter kann eingemottet werden. Firmware entschlüsselt & Passwörter ausgelesen. Fritz!Box läuft. Eat this, O2! #fb

Obtaining VoIP login data from firmware 1.01.23b

When looking at the obtained plaintext it turned out that all PPPoE or VoIP login credentials were empty. A closer look revealed that the important parts are censored from the config backup file each time a user downloads it through the web interface. Well played Arcadyan.

To my delight I can still provide another way to obtain your login data: Open your router and attach a USB-TTL cable to it. If you don’t have such a cable you can get them on eBay for a few bucks. Just search for “USB DATENKABEL NOKIA 7360 7710”. You can rip off the cellphone dock connector and add your own female connectors.

The pins are already placed on the PCB and so no soldering is required on your router. The pinout is as follows (see picture as well):

Pin 4: ground
Pin 3: RX of router connect to TX of cable
Pin 2: TX of router connect to RX of cable
Pin 1: not connected (pin is marked with a white triangle on PCB)

You can then interrupt the bootloader and dump the flash chip with the help of brntool and the following command:

For o2Box 6431 run:
brntool.py --serial COMx --read=o2Box6431.bin --addr=0xB0040000 --verbose --size=0x40000

For o2Box 4421 run:
brntool.py --serial COMx --read=o2Box4421.bin --addr=0xB0020000 --verbose --size=0x40000

Now you can use my new version of the Arcadyan IAD Decrypter to obtain your PPPoE and VoIP data from that file even if you are on firmware version 1.01.23b.

arcadyan_dec.exe -d o2Box6431.bin o2Box6431_decrypted.bin > o2Box6431_output.txt
strings.exe o2Box6431_decrypted.bin > o2Box6431_strings.txt

For more detailed information on how to dump the flash see this thread (German language).

Acknowledgment

Special thanks go to Daniel Meyerholt, astraflo and Jan Newger. “You know who you are” 😉

tl;dr

Arcadyan IAD Decrypter v0.05 published. However VoIP credentials of 1.01.23b firmware can only be obtained by dumping the flash.