Reverse Engineering Flash Games

3 comments


Dec 7, 2014
Unproprietary 0.4: Nov 25, 2015
Unproprietary 0.5: Sept 11, 2016

unproprietary-0.5 [sig]
unproprietary-0.4 [sig]
unproprietary-0.3 [sig]
unproprietary-0.2.1 [sig]
Git repository: git clone https://www.altsci.com/repo/unproprietary.git

Lume is a simple point and click Flash game available from Steam and Humble Bundle. I got it as part of of the Humble Weekly Sale: Amanita & Friends bundle and played it because I was interested in playing a short puzzle game one night. Since it's only 30 MB, it's pretty much guaranteed that it's a short game. It took an hour or so to complete and had some excellent puzzles. One of the main features of the game is the graphics which were made by a good artist with good style. Today, I was able to reverse engineer the game in a short amount of time using some custom tools I wrote, so I'm going to release them and ask for pull requests. Reverse engineering file formats is not a difficult process, but it is time consuming and it is more difficult to automate, so tools that do the work for us are valuable. That is why I'm releasing this simple set of tools I wrote.

If you'd like to follow along, you can buy Lume on Humble Store for $5.99. It supports Linux, Mac, and Windows. Lume has a Metacritic score of 69 and a high score of 83 by GameShark. A sequel was released recently called Lumino City (5 days ago) and it has gotten good reviews. It looks brilliant but it isn't released for Linux yet.

Read more »

Automating Let's Encrypt No Sudo for 9 Domains

Let's Encrypt Nosudo Scripts 0.1 [sig]

Let's Encrypt is a free SSL certificate authority that is designed to let users encrypt their website correctly. This has let me save around $81 creating certificates for all my domains (9 domains with Let's Encrypt, one without). Let's Encrypt was designed for the overly-trusting user who is willing to run code they download off github as root. Experience and paranoia teaches us not to run untrusted code as root or even as a user that isn't fully sandboxed. How do we deal with this? This technical document is for the admin who can read code and find vulnerabilities in Bash, Python, and protocols, not for the faint of heart.

Let's Encrypt Nosudo was designed for that. It takes a few hours to sign 10 certificates, so maybe 30 minutes per cert. But Let's Encrypt only issues certs with duration of 3 months which means that every 2-3 months you have to spend 30 minutes per cert. If you have 9 certs, that's a huge time investment. So like me you want to automate Let's Encrypt so that you don't have to spend 5 hours every 2-3 months. This is what these scripts are for.

Read more »

SAT Problem Solved


Aug 14, 2015

sat1-0.1.tar.xz [sig]

I solved my first SAT problem and in doing so, I had to write a valuable improvement to satispy, a simple and powerful Python frontend to minisat and lingeling. I'm making a pull request to netom, the author of satispy and I am publishing my code on Github since the original was published on Github. Allow me to show you the problem I was working on and the possibly elegant solution.

Read more »

AES Ciphertext Collisions Anomaly


April 8-10, 2015
Permalink
keystream_dupe-0.6.tgz [sig]
keystream_dupe-0.5.tgz [sig]
keystream_dupe-0.4.tgz [sig]
keystream_dupe-0.3.tgz [sig]
keystream_dupe-0.2.tgz [sig]
keystream_dupe-0.1.tgz [sig]

In this very basic cryptography exercise, I have written a simple test of the quality of a cipher. For RC4 and stream ciphers, we can encrypt \x00\x00\x00\x00 to get the first four bytes of the keystream. I do this for the first 1048576 keys (assuming big endian and 64-bit keys) with RC4. Then I find out how many random keys I have to try before I find the same first four keystream bytes. I do this 1024 times. The data shows that this is around 4 million keys.

For block ciphers like AES, we have to do it slightly differently, but the concept is the exact same. I encrypt "GET / HTTP/1.1\r\n" which happens to be 16 bytes, the exactly correct size to fit in a single block of AES plaintext. I store the first four bytes of the ciphertext for the first 1048576 keys (same assumption as above but 128-bit keys). Then I do the same with random keys and I compare the first four bytes of the ciphertext against the first four bytes of the 1048576 partial ciphertexts. I find out how many random keys I have to try before I find the same first four ciphertext bytes. I do this 1024 times. The data shows that this is around 3 million keys. As you can clearly see, this is far smaller than RC4 (which is known to be vulnerable to many attacks).

Update

To test whether the problem is in AES or RC4, I used my system's random number generator (Linux /dev/urandom) to generate random bytes of keystream and tested how many attempts it would take to collide 1024 times. It took on the order of 4 million. This proves that the issue is either in AES or in RC4 and my system's random number generator. Since my system's random number generator is as good a source of entropy as I have, I must conclude that there is no issue with RC4 and that there is an issue with AES.

Read more »

next »