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.
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.
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: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.
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.
