Microcorruption - Overview, level 1, level 2

Overview

This is a war game where you are tasked with defeating a lock - it's a computerized lock that sounds really forbidding but ultimately turns out to have more holes than a sieve. The game does a good job of staying playable for new people as it has several versions that are all pretty much the same but the minor differences prevent cut and paste jobs.

Additionally, the makers of the game do a nice job of leading the player down different paths to explore not only different attack vectors but also prevent the same one from working over and over again.

As a side note, I originally started this game with the intention that my son would learn a little about computing. He didn't make it much past the first few levels - apparently prying locks open to steal imaginary bearer bonds isn't exciting enough. I suppose that is a good thing on some levels. But he did learn about the binary, octal and hexadecimal number system - which is a solid start. You can view our (my, at this point) progress as "SamnDad" on the website.

Some notes about the environment:

<action src dest>

This is the format for the assembly language for the game. This style is generally considered the reverse of Intel x86 assembly language which  puts the destination before the source.

little endian

0x1234 goes into the registers as 3412

Despite not having intel style syntax for the language the processor is little endian like many Intel processors.

Thanks Texas Instruments for being weird.
 

cmp a b yields flags based on result of: b-a ...  Good to remember for flags.

Useful websites for delving into the particulars of the processor:

http://www.ti.com/sc/docs/products/micro/msp430/userguid/as_5.pdf

http://en.wikipedia.org/wiki/TI_MSP430

New Orleans – level 1

I set a breakpoint at main and again at create_password. Create_password seemed like a good place to start, and I thought it was odd that it ran before the getsn() was called and as I watched the memory it filled in a string of letters as a I stepped it through. Naturally I tried that string, and it worked.

Interestingly the game appears to be designed for there to be a preferred solution because when I tried to overflow the buffer and trample the code, it cut me off at 100 characters despite that I entered 300 characters. This overflow works in later levels but not earlier levels. And so the game appears to be designed to train you to look for certain things.

Key learning elements: how the interface works, stepping through code and using the tools and understanding the user interface.

Sydney – level 2

The program stores the incoming password and puts it at 43a0, above which starting at 4400 is the code itself.  

Sets SP to point at 43a0 (first letters of incoming _password) and preserves SP in r15 where the incoming pass starts.

Compares a literal (0x4624 - F$) to 0x00(r15) which means r15+0 offset. As it turns out that literal is part of the password.

Jumps to (44ac) if not zero.

Whereupon it clears r14 and puts r14 into r15 and returns...

r15 has 0.

r15 is tested for 0, and if not zero goes to unlock door.

R15 0 goes to fail.

This repeats 4 times basically, so the password is hard coded not in memory but in the code itself in the form of looking for things to test against.

So: 4624 6a70, 574c, 5554

or: F$jpWLUT

EXCEPT that endian-ness counts:

2446706a4c575455

$FpjLWTU

Key learning elements: endian-ness, identifying key components of the code and stepping through those parts, flags and comparison.

Notably, buffer overflow is prevented at these early levels.