Dent game: an example of nonexistant security

In Norway, there's a commercial campaign (ending 15.4.) for Dent candies; you're invited to play a game (www.dent.no), and the best scores win some prizes (the coolest prize is a free cinema-ticket for two valid for 1 year). Since the prizes are attractive, I was wondering what kind of security they implemented. Surprisingly (or not; Norwegian companies have a bad track record with security issues), the answer is none!

Before submitting my result, together with my data (email address and phone number), I fired up wireshark and found out the following:

• They first connect to stats.indexstats.com to report some basic statistics (a cookie with base-64 url, among other stuff, is sent and an empty GIF is returned).
  

• Then a simple POST request is sent with the score and entered data about the user. Everything through ordinary HTTP, and everything in cleartext! Some binary data is returned, but I haven't bothered to figure out what it is.

So it's trivial to record the traffic into a file, change the score, and resubmit the better score by e.g. netcat. (No, I haven't done it myself -- the hardest part seems to be guessing high enough to win, but still plausible score.)

What could have been done differently? It's impossible to secure an application 100% when the user has full control over the computer, but I think that just AES-encrypting the sent data with a key preshared between the client and the server would have risen the hacking bar significantly. You'd have to download the raw flash file, try to find the encryption key inside it, guess the encryption algorithm, etc. If the encryption key is not stored contiguosly in the file, then you'd also have to reverse-engineer the flash code to see what's going on.

In any case, very badly done web application.

Inkscape

I've been looking for a long time for some visio-like vector drawing program for Linux. Well, I've recently tried Inkscape, and, while still not a Visio replacement, it does its job pretty well even for technical diagrams.

MIPS CPU simulator, CMake

Today I've published the first version of a MIPS CPU simulator; you can read more about it here. Even though the version number is 0.9, the program is not in any case beta: it is quite stable, CPU torture tests pass in 32-bit and 64-bit environments, and there seems to be no open security holes, though error "reporting" is sometimes unfriendly: the simulator shall call abort() if the simulated program tries to access memory outside of its allocated range.. but I think that's still way better than doing random stuff to random memory. Work on better error handling is the top priority right now.

I'm also using this opportunity to learn about the CMake build system.

IT Underground 2008

I have again attended the IT Underground conference in Prague, where I gave a short lecture about PKI in practice. Soon I shall also upload the slides from the talk.

MIPS CPU

Things have been pretty hectic here, so I haven't had much time to post anything. Recently, I've begun a new personal project: writing a simulator for the MIPS I CPU arhcitecture. I chose this particular CPU because it's the simplest architecture for which gcc can generate code. There are many other MIPS CPU simulators out there, but all of them do more than I need, so I decided to write my own as simple as possible. The ELF loader and symbol lookup are finished, and now I'm working on developing test vectors for the simulator (a very boring part).

As for why I'm doing this - the answer will hopefully be clear soon :-)