9

Apple provides firmware updates for their Airport products through 'Airport Utility'. Firmware files can be downloaded with the help of ~/Library/Application\ Support/Apple/AirPort/Firmware/version.xml which contains all products and their available firmware versions:

            ...
    <dict>
        <key>location</key>
        <string>http://apsu.apple.com/data/115/041-9815.20130814.1Rver/7.6.4.basebinary</string>
        <key>newest</key>
        <true/>
        <key>productID</key>
        <string>115</string>
        <key>sizeInBytes</key>
        <integer>5674968</integer>
        <key>sourceVersion</key>
        <string>76400.10</string>
        <key>version</key>
        <string>7.6.4</string>
    </dict>
    <dict>
        <key>location</key>
        <string>http://apsu.apple.com/data/115/041-9696.20130207.Ch5g6/7.6.3.basebinary</string>
        <key>productID</key>
        <string>115</string>
        <key>sizeInBytes</key>
        <integer>5674344</integer>
        <key>sourceVersion</key>
        <string>76300.7</string>
        <key>version</key>
        <string>7.6.3</string>
    </dict>
    <dict>
        <key>location</key>
        <string>http://apsu.apple.com/data/115/041-0311.20130207.aaWs/7.6.2.basebinary</string>
        <key>productID</key>
        <string>115</string>
        <key>sizeInBytes</key>
        <integer>5627396</integer>
        <key>sourceVersion</key>
        <string>76200.16</string>
        <key>version</key>
        <string>7.6.2</string>
    </dict>
            ...

For the Airport Express (model A1392, productID 115, see WikiDevi, Teardown by Rogue Amoeba) there are 3 firmware versions: 7.6.2, 7.6.3 and 7.6.4 (current).

I downloaded all 3 versions and used binwalk (v1.2.2-1) on them. They seem to be encrypted:

$ binwalk -H 7.6.3.basebinary

DECIMAL     HEX         HEURISTIC ANALYSIS

-------------------------------------------------------------------------------------------------------------------

0           0x0         High entropy data, best guess: encrypted, size: 5673944, 0 low entropy blocks

Examining different firmware files revealed their common structure.

Offset 0-D: static string APPLE-FIRMWARE

Offset E: static hex 00

Offset F: firmware format version (?) (8 bit signed) hex 2D => format 45 (7.5.x firmwares have format version 44, 7.7.x firmwares have format version 46)

Offset 10-12: static hex 00 00 00

Offset 13: product ID (8 bit signed) hex 73 => product ID 115

Offset 14: Firmware Major Version (8 bit signed) hex 07 => major version 7 (aka 7.x)

Offset 15: Firmware Minor Version (8 bit signed) hex 63 => minor version 63 (aka x.63)

Offset 16-1F: checksum or size for following part?

Offset 20-2D: static string APPLE-FIRMWARE

Offset 2E: static hex 00

Offset 2F: firmware format version (?) (8 bit signed) hex 2D => format 45 (7.5.x firmwares have format version 44, 7.7.x firmwares have format version 46)

Offset 30-32: static hex 00 00 00

Offset 33: product ID (8 bit signed) hex 73 => product ID 115

Offset 34: Firmware Major Version (8 bit signed) hex 07 => major version 7 (aka 7.x)

Offset 35: Firmware Minor Version (8 bit signed) hex 63 => minor version 63 (aka x.63)

Offset 36-3F: checksum or size for following part?

Offset 40-12F: boot code? 344FE72ADE3CC2202D6A221A3B67B6075B0F13CA37F5DCCAE5ED626BAE0B4655E618766D703B5190CCD578BCF06D6C9ECD97265B962F49478BE1E9FDE8160E5CCDC09B0C975A3D271D988791258ACC6E679A1556F01C2100DDD0B35E8DA388119C35AC8765DB5DC6AAD6E3D7232D47B4EFA97B32AEF6FF77EDB43946103187342DF68BE88D6B005DAF7CC212777C4FA7FEFD3FD299088EE73EC6FAB1596A92835E4E2450750D9AB5F86780464E341CBFE61E7B8F224285CB3D47D3891AD614B1ABD04DB3DACE7622B22355752F29FF7C5492635F9B99F966759DA4070F23B1D20E197F72BDAFA2B36B567C8E756147A2


Do you have any idea on how to go forward?

What kind of encryption could have been used? Apple seems to use AES for Iphone and AppleTV firmware.

3
  • Why do you think that it is encrypted ?
    – w s
    Jan 8, 2014 at 7:10
  • Because binwalk finds no content sections in the firmware file and when you check for unknown compression/encryption based on entropy heuristics (-H switch), binwalk says it probably encrypted. There are only high entropy blocks and no low entropy blocks. From what I read LZMA compression can also look like this, but then you would find at least some kind of LZMA header which is missing.
    – kaazoo
    Jan 8, 2014 at 7:34
  • Great question. Have you made any progress with this?
    – ipatch
    Feb 12, 2014 at 16:55

3 Answers 3

1

If it is really encrypted you'll need to take the device apart, lift the ROM, read it and reverse engineer the code. There is some prior work that was done in the area, see here The owner of this site is maintaining shairport, it may be useful.

There is a small chance that encrypted code is decrypted before sending the update to the device (I personally don't believe it), so it would be good to look into the utility that actually reads the update file and updates the Airpot Express.

1
1

For anyone who comes here from google, I can indeed confirm these devices have their firmware encrypted and gzipped compressed.

If you have any doubts about the above statement, check this out.

Also, I put together a wiki a while back documenting our findings about the AirPort family of products.

Finally, I recently started tinkering with these devices again, and successfully built a NetBSD toolchain for the ARM Big Endian variant of these devices. And if my memory serves me correctly this particular model of AirPort Express uses a MIPS Big Endian processor.

TL;DR
Use the above mentioned tools, and you can enable SSH on your AirPort device and it will persist. And come join us in #theairportwiki on freenode.net when you get a chance.

cheers 🍻
Chris

0

Like others have said, you might have to take the hardware route, and physically connect a Bus Pirate or similar device to dump the firmware. When the device is running, you will get a decrypted firmware dump.

Here's a series about this with an airport express, it's taken from this blog: http://www.hsorbo.no/ but i will copy and paste the whole thing here because i don't trust this blog to stay online. I've pieced in some photos using archive.org as well. Unfortunately the link to the key at the end is a dead link.

Reverse engineering the Airport Express Part 1

For quite some time I’ve wanted to reverse engineer the airport express base station. There are two reasons for this. The first is that within this firmware are the private Airtunes keys. The second and more important part, at least for me, is that it is almost identical to a wrt54g plus it adds usb and sound-card. Getting linux/openwrt running on this would be wicked cool. The main issue with reversing apples firmwares for these access points is that they are encrypted and the airport express decrypts the firmware when flashing so you can’t really do anything fun with the firmware-update files.

A time back I posted on twitter that I needed a broken airport expresss! I go really lucky, a friend of mine saw the tweet and gave me his broken airport. I disassembled it and found out that the flash was AT45DB321B, which is nice because Atmel keeps their datasheet public, the not so good news was that it was BGA-mounted and my old soldering station wasn’t up for this. Everybody knows I’m a real ebay-whore, so I went to ebay and ordered this excellent hakko rework-station clone (YIHUA 852D+). This had the hot-air-gun that I needed. Here is a short video when I’m detaching the IC:

After desoldering I glued it to a breadboard and hooked up some wires, this was a bit tricky as this is quite small.

Photo of flash [missing from blog]

After everything was hooked up, I attached it to my Bus Pirate and after a lot of trial and error managed to communicate with the chip.

Photo of my desk [missing from blog]

Finally i wrote this small python-script that dumped the content of the chip.

I’m now in the possession of the unencrypted firmware for airport express, but still there are a lot of stuff remaing. The firmware is compressed, and I have had no success brute-force inflating it, so I may have to start reverse-engineering the bootloader just to get to the uncompressed firmware. Another option could be running it under qemu, the decompression-part that is, should be fairly generic MIPS-code. A third option would be to flash it on my wrt54g and do jtag-debugging, if I’m really lucky I’d get serial-port and bootloader on the linksys.

There are a lot for options going forward, I’ll post a new blog-entry when I make further progress. Please excuse the bad language in this post, I don’t want to spend time on grammar now that I have this very sexy binary blob right in front of me.

Happy hacking!

Reverse engineering the Airport Express Part 2

23 February 2010 Yesterday I was analyzing my firmware-dump and I couldn’t make sense of very much. One thing that got my attention was that scattered around the firmware-dump were a lot of 0xFF. I Found a pattern, and I tried to convince myself that this was some sort of container or padding between important chunks of data. Then as the night approached BOOM, it hit me. The pattern was like this: 512 bytes of data, 16 bytes of 0xFF, 512 bytes of data and 16 bytes of 0xFF. This was significant and here is the problem/solution.

The flash chip on AT45DB321B is like a book with 8192 pages and 528 letters on each page. When I dumped it my program just read through the book carefully noting every letter. Now the airport express doesn’t do it this way, the airport just turns to the page it wants and reads what is needed (random access). Now there is one other limitation, the Airport Express doesn’t read more than 512 letters from each page. This means that he doesn’t care about the last 16 letters I have been carefully putting into my dump/analysis. I Fixed this and my brute-force decopression-program (15 line python script) found both the bootloader and the main firmware. Their md5-sums are: ff4c561a6dcce8686749594d84ff4e7d and 7db70daf035f085eb455d8de3c2099fb. A guy name James seems to have done the deployment of this firmware :) I think all that remains now is spending time with IDA Pro. I need to get a memory alignment as the start address of memory seems to be 0x8000000 + some offset.

A screenshot of the strings-window in IDA Pro (strings used in the Airtunes authentication):

Screenshot of strings

I really think this discovery makes for part 2 as I now am pretty sure the rest is doable, albeit time consuming.

PS. I had to replace every occurence of dump with firmware-dump as the text became very questionable

Reverse engineering the Airport Express Part 3

26 February 2010 A small update. Memory alignment took a few hours. I did this by dumping a lot of the string offsets in the firmware using standard unix console tools: strings -n 10 -o | grep "Audio" | awk '{print $2}' I then wrote a IDA script that dumped all load operation offsets, made a second script that brute-forced matching the offsets. The best match was 0x80010000 and not to anybody’s surprise this made IDA pro very happy and she started auto analyzing the firmware. Here is a screen shot of the memory-offsets:

IDA memory

Here is a in-action screen shot of IDA:

IDA action

I’ve done a good amount of reversing and everything is going well, still have no ETA on anything though. Subscribe to the blog or check back after the weekend if you are curious.

Reverse engineering the Airport Express Part 4

11 April 2011 The RAOP/Airtunes key is here http://static.hsorbo.no/0xff/airtunes.pem Although i have had the key for quite some time it was first made public here: http://www.mafipulation.org/blagoblig/2011/04/08#shairport

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.