Cracking Linksys “Encryption”

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”.

Bookmark the permalink.

20 Responses to Cracking Linksys “Encryption”

  1. axet says:

    yes it is :)

    encryption – when you hide / change data. obfuscation – when you change execution order of the code and inject useless loops and commands.

    you are cool!

    • André says:

      Encryption is something that should be impossible/impractical to decode without both of two things: the method and some sort of key. This allows only authorized parties to have access to the concealed information. Some algorithm can be considered cryptographic at first but be “broken” over time; if techniques or technology arise to decode the message without knowledge of those. That’s what’s happened to, for example, Caesar’s cipher; nowadays it’s more of an obfuscation than an encryption method.

      Obfuscation is much broader and generally means “making something harder to understand/interpret”. Which usually is indeed done by messing with code/text order, loops and such, but can be as arbitrary as adding 1 to each byte/letter or swapping every odd pair of them.

      This is then, of course, the second case, since you don’t need to know the “key” 0xFF to gather information about the encoded information. In theory you could even make changes to this configuration file without understanding the XORing process at all. So calling it “encryption” is really a stretch.

  2. freddy says:

    This seems to be a common pattern of obfuscation. My previous, ISP-branded router was a device from Arcadyan. It allowed exporting settings that turned out XORed with 0xFF as well.

  3. skaa says:

    “XOR 0xFF” == NOT

  4. http says:

    Well, even if it would be really correctly encrypted with best-practice and all, you would still have access to their private key that way. The moment someone publishes the algorithm and key(s), like you here, it’s “game over”. The only disappointment maybe is that they used an algorithm that simple.

    • Craig says:

      As long as the key was unique to the device and not reasonably predictable, then publishing the key from my router would only affect my router. They already have standard encryption algorithms in their code as well, for supporting HTTPS administration.

      Of course, that would also mean that you couldn’t use the backup config from one WRT120N on another WRT120N, which might be a requirement.

  5. Bill says:

    Wow…just, wow. That is unbelievable.

    I love your posts. Keep ‘em coming!

  6. Jose Xavier says:

    I need to thank linksys to make craig wrote a post that I understand from the vegin to the end :)

    Anyway, even when i cant understand what you did I like your posts :)

  7. 911Ducktail says:

    Excellent post. Your blog is one of the most useful, informative and *interesting* blogs I’ve ever come across

  8. Amihai says:

    Give them some credit.
    Xoring with 0xff leaves you with not even a single bit as before! They get the most different file they can get ;)

    (It’s a joke ;) )

  9. Sniper_X says:

    When I find these gems and cannot change the equipment, firmware or fix the issue, I simply pick a password, and encrypt it, then I take that encrypted hash and make THAT the password.

    Now, as you read that, you likely came to the conclusion that this secures NOTHING any better than before, and by saying that, you would be right.

    However, when we look at an unencrypted config file (whether we cracked it or it was left in the clear), like in this instance, we still look at this file and determine if the data is truly “in the clear”.

    Looking at my password, you would see an encrypted hash of some crazy value, and assuming that the device allows for VERY LONG passwords, you will ASSUME it’s encrypted.

    That is a social engineering trick I have used MANY times on files that are not secure when in production / “the field”.

    EVERY single person I have invited to crack my devices using this “hashed password”-password has assumed it was encrypted and spent time DECRYPTING it, only to find that:

    A) It was strong enough to give up the attempt

    or

    B) They actually DID decrypt it, and tried that password, only to find out that it was NOT the password!

    Only ONE person, AFTER giving up, and MUCH later in a conversation with me had a moment when it “Clicked”, he looked at me and asked me directly if that is what I had done.

    I denied it in the group, but later admitted it to him privately.

    When left with security devices that are not secure, you have to improvise.

    • Perk says:

      +1. That is very clever! Good idea!
      -1. You just told everyone about it so we can’t use it.

    • M says:

      Stories about what your friends tried is not something people should be basing their security off of: the plural of anecdote is not data.

      Much better to have potentially sensitive data in cleartext than “protected” by a scheme like that. If it’s in cleartext I have a clear understanding of what I may permit myself to do with this file (i.e. be very careful that it doesn’t end up where someone can get it). If it’s protected by the assumption that people who look at my password maybe kinda sorta think it’s not my password, I had better be treating the file exactly as though it were in cleartext — in which case this misdirection would be useless anyway.

      I will grant that your story is amusing and carries a certain charm, but please do not mistake that for it being remotely safe.

  10. Alex says:

    Haha :) I really enjoy your ending, that it took you more to write a blog post than to break their encryption.
    Nice work!

  11. Pingback: Linksys (cisco) needs to enhance their encryption. Linksys WRT120N firmware easy cracked. - b-real.org

  12. Pingback: Linksys et son chiffrement en carton « Korben Korben

  13. Brandon says:

    They could of at least used RC4; that’s not very resource intensive and uses very little lines of code to implement.

    XOR with a single byte is just pathetic.

  14. Pingback: Linksys et son chiffrement en carton « Mes idées HIGH TECH

  15. Pingback: Linksys et son chiffrement en carton

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>