A keyword is asked for by the site with very little else as a clue. It doesn't take much to see that this is x86 opcode - run it through ndisasm and you get this:
All rather promising, but there's a few things to note:
- The first instruction jumps over the next two. These jumped instructions look pretty suspicious so perhaps they aren't code. If they are data, then this can be recoded as the DWORD 0xa3bfc2af. This isn't relevant now though ;)
- Almost at the end of the code there's a relative 'call', but no matching 'ret' (at least in the reachable code). The following instructions seem like nonsense, so it seems likely that the code uses an old trick to embed data within code. The 'call' puts the address of the following instruction on the stack, then branches the execution. The code does later check that a value popped from the stack (0x41414141) so it seems that everything after the call is in fact data, not code. Later, it also checks this area of memory for the value 0x42424242 but that is nowhere to be seen!
Notice the iTXt section? A quick look at the libpng site shows that this section should hold text, not the garbled junk that's actually there. The text looks hard to recognise, but the two '=' signs at the end is a dead give away for Base64 encoding. Sure enough, a little ipython work and the output was saved to a file. Running it through ndisasm gives a load of junk so its not more code, but the first four bytes are the ascii character 'B' or 42 in hex! That means that this is what's missing from the code - maybe not actual code but embedded data.
Adding this to the code (and fixing the relative offsets) gives us:
Forgive the silly code labels - I wasn't going for production code here! Running the resulting binary through a debugger shows that the code copies the data after 0x42424242 and does a lot of bit fiddling with it. Follow the code and watch the memory it's messing with and you will end up with: