Perusing the release notes for the latest Linksys WRT120N firmware, one of the more interesting comments reads:

Firmware 1.0.07 (Build 01)

– Encrypts the configuration file.

Having previously reversed their firmware obfuscation and patched their code to re-enable JTAG debugging, I thought that surely I would be able to use this access to reverse the new encryption algorithm used to secure their backup configuration files.

Boy was I giving them way too much credit.

Here’s a diff of two backup configuration files from the WRT120N. The only change made between backups was that the administrator password was changed from “admin” in backup_config_1.bin to “aa” in backup_config_2.bin:

OFFSET backup_config_1.bin backup_config_2.bin ---------------------------------------------------------------------------------------- 0x00001468 9E 9B 92 96 91 FF FF FF |........| / 9E 9E FF FF FF FF FF FF |........|

Two things to note here:

The first letter of each password (“a”) is encrypted to the same value (0x9E)

The same letter (“a”) is encrypted to the same value (0x9E), regardless of its position in the password

I immediately suspected some sort of simple single-byte XOR encryption. If true, then XORing the known plain text (“a”, aka, 0x61) with the known cipher text (0x9E) should produce the XOR key:

0x61 ^ 0x9E = 0xFF

Applying the XOR key of 0xFF to the other characters in the password gives us:

0x9E ^ 0xFF = a 0x9B ^ 0xFF = d 0x92 ^ 0xFF = m 0x96 ^ 0xFF = i 0x91 ^ 0xFF = n

And XORing every byte in the config file with 0xFF gives us a decrypted config file:

00000000 33 34 35 36 00 01 df 60 00 00 46 ec 76 31 2e 30 |3456...`..F.v1.0| 00000010 2e 30 37 00 00 00 00 00 00 00 00 00 00 00 00 00 |.07.............| 00000020 00 00 00 00 00 00 00 00 00 00 00 00 57 52 54 31 |............WRT1| 00000030 32 30 4e 00 00 00 00 00 00 00 00 00 00 00 00 00 |20N.............| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 61 64 6d 69 6e 00 00 00 00 00 00 00 00 00 00 00 |admin...........| 00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000000a0 00 00 00 00 00 00 00 00 61 64 6d 69 6e 00 00 00 |........admin...| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000100 00 00 00 00 00 00 00 00 30 2e 30 2e 30 2e 30 00 |........0.0.0.0.| 00000110 00 00 00 00 00 00 00 00 01 01 01 00 00 00 00 01 |................| 00000120 00 00 00 01 00 00 00 00 00 00 00 08 32 39 34 38 |............2948| 00000130 33 31 30 35 00 01 00 00 00 31 39 32 2e 31 36 38 |3105.....192.168| 00000140 2e 31 2e 31 00 00 00 00 00 32 35 35 2e 32 35 35 |.1.1.....255.255| 00000150 2e 32 35 35 2e 30 00 00 00 00 00 00 04 00 02 00 |.255.0..........| 00000160 01 00 00 00 00 00 00 00 00 00 00 00 00 00 4c 4f |..............LO| 00000170 4f 50 42 41 43 4b 00 00 00 00 31 32 37 2e 30 2e |OPBACK....127.0.| 00000180 30 2e 31 00 00 00 00 00 00 00 32 35 35 2e 32 35 |0.1.......255.25| 00000190 35 2e 32 35 35 2e 32 35 35 00 00 00 00 00 00 00 |5.255.255.......| 000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001b0 00 00 00 00 49 52 51 3d 30 20 50 4f 52 54 3d 30 |....IRQ=0 PORT=0| 000001c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ...

This is truly atrocious. Given that “encrypting” the backup configuration files is done presumably to protect end users, expecting this to thwart any attacker and touting it as a product feature is unforgivable.

OK, I don’t really care that much. I’m just disappointed that it took longer to write this blog post than it did to break their “crypto”.