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, 0×61) 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”.