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