In order for things to work for the ULYSSIS CTF, we had to configure a bunch of routers (in this case, a D-Link GO-RT-N150). However, the web UI config was very limited, but we suspected the actual config format underneath was much more flexible.

In the web UI, there’s an option to import and export a config file. But on first sight, it looks like nothing useful at all:

Searching on the Internet doesn’t yield much either. However, on further inspection, one can see the following:

  • 5ea3a417 is 4 bytes long and looks rather random, so it’s probably magic.
  • 00000040 and 000007a0 Look like big-endian ints, probably the length of something.
  • Then there are 16 bytes of random data: 6b2ff49e bcde1ba0 461d903c b00ee198
  • Following that, a bunch of null-terminated strings are found.
  • Random data for the rest of the file.

Let’s try making sense of those integers first. The string starts at offset 1C and end at 5C. In other words, that’s where the 00000040 comes from!

The file is 2044 bytes long. In hexadecimal, that is 07fc. Subtract 5C (start of garbled data) from that, and you get 7a0. This probably means that blob is one whole instead of multiple things concatenated.

Now, if you look closer at the random data, it starts with the following bytes: 1f 8b. That’s the magic header for gzip.

Decompressing that data reveals an XML file with a plethora of options not available in the web UI. \o/ This isn’t of much use unless we can create these files by ourself, though. However, the only thing we still need to figure out is the 16 random bytes. I suspect this is a hash of some sort.

So, let’s try a bunch of hash functions with an 128-bit output on the data: (The output we want is 6b2ff49ebcde1ba0461d903cb00ee198)

Nope. What if we try this instead?


So, here’s the file format:

The implementation is left as an exercise for the reader 🙂

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.