Starfighter, Summer 2015

1

I don’t really like games.

Screen graphics make me nauseous. The political interactions between players are tedious. I’m not a fan of chance, I stink at riddles and it’s rare that someone can concoct a mystery that I cannot immediately resolve.

Then I became an app pentester. And not long after I started my new career, I realized I’d found a game I loved. I stayed at my pentesting job at Matasano 3x longer than any other job. Why? Every week, there was a new puzzle to solve.

Security games have context. They have worlds. Severe vulnerabilities for online banking are footnotes for CRMs. Each gig, I figured this out on the fly, designed test programs on the fly. There was time pressure. I had to think. I had to solve. So when I hosed a $50,000 “data loss protection” server for 24 hours with a single packet, or DDOS’d a high availability trading server, I felt really fucking smart. I am a utilitarian at heart, and this was my fix.

Fast forward almost a decade.

We’ve started a company to help fix hiring. We had two ideas: run job interviews for other companies Somewhere in an alternate universe, we are building a far less ambitious codebase and hating life just as much. , or build a giant game, a CTF, that replicated the experience of doing work. We had to pick one idea. The CTF/game idea, at the time, sounded like a lot more fun, so we went with it.

In 2014, my former co-workers built a CTF called Microcorruption. In it, you reverse-engineer a series of locks built on a microcontroller, exploiting flaws in the lock’s code. I loved Microcorruption. I think I got through 10 levels before I ran out of free time. I’d never before watched a machine execute instructions, step by step, seeing the stack pointer move through the program memory while meaningful numbers were loaded into registers and shuffled around. This… this is my kind of game.

You can still play Microcorruption; it’s still running. We knew we wanted Starfighter to be like Microcorruption. But we also knew it had to be more.

2

For Microcorruption, Tom wrote a TI MSP430 emulator in Go. When we began Starfighter, Tom said to me, “You’re going to write an AVR emulator.” At the time, I didn’t really think to ask why. I had no idea what AVR was beyond “an instruction set.” I just smiled and said, “Okay.”

So I wrote an emulator using the Atmel 8-Bit AVR specs. I’d never written an emulator. Or anything else as big as an emulator. It’s one of the hardest things I’ve ever done Not quite as hard as jumping over a pile of sandbags on skates, but still hard. . Each night, for almost two months, I’d crawl into bed, completely mentally drained. There were more problems to solve than I knew how to handle. And I was like a pig at a slop trough.

Tom wrote a guidebook based on his experience writing Microcorruption’s MSP340 emulator for me, but it’s only today —– long after the emulator is finished —– that I read the second half. Because at some point, it became very apparent that AVR… well, it was just plain weird.

His guidebook describes a CPU as a struct with two arrays: one for memory and another for registers, stack pointer, program counter and status bits. Those of you who know a little AVR will be amused to hear me say that I did not get very far with that design.

“Some of these instructions seem to be looking for the stack pointer in memory,” says I.

“It can’t work that way,” Tom responded.

“Yes it can.”

“No it can’t. That’s not how computers work.”

We squabbled. I really did try it his way. I pushed the square peg of Tom’s CPU description through the squiggly amoeba-shaped hole of the AVR ISA. Hard. Then I gave up and rewrote my code, putting the program instructions in one array and the the stack pointer, general purpose registers and the status register in another.

A few days later, Tom says, “Something something blah blah Harvard Architecture blahdy-blah.” I’m sure this is not exactly what he said, but I was in such a fugue state by this point that time was folding in on itself.

A Harvard Architecture has two distinct memories; there is program memory (imem, typically flash) and data memory (dmem, typically SRAM). They live in two different address spaces. The CPU reads instructions from imem, but instructions themselves read and write dmem.

This is neat because makes exploits harder to write. You can’t simply upload code in a buffer and somehow point the PC at it; that buffer is in dmem, not imem. You’ll see what I mean in a few weeks.

AVR gets weirder. The stack pointer gets IN’d and OUT’d to an IO address in memory — it’s a peripheral. “Computers don’t work that way!”, says Tom. I ignored him.

The general purpose registers and IO are in reserved data memory address space. The status register is also in the dmem address space. Yes, computers work that way, Tom. Some instructions look in a reserved location in IO memory to retrieve the stack pointer. But you can read all about registers on page 8 of the ATMega8515 Datasheet Summary. And in my corner of the Starfighter game, you’ll get to play with all of this stuff.

AVR is not like MSP430. It’s not like X86. It is not, as Thomas claims, “like someone vomited up an instruction set”. It’s a complicated microcontroller instruction set designed for tiny parts with small programs that don’t change often. To date, I’ve ‘discovered’ 142 instructions through test code. There are something like 16 load and 13 store instructions. A summary table can be found on pages 10-12 of the ATMega8515 Datasheet Summary.

Well, I did say I wanted to work on something more fun, didn’t I?

3

Yeah, so… I was planning on telling you more about our game. Sorry. I have a tendency to natter.

Back in the dawn of time, before electricity and running water, when dinosaurs roamed the earth and stack pointers weren’t peripherals and an emulator was “just a pair of arrays”, Patrick wrote a post about what we’re doing. The one where he said there’d be tech trees.

The goal in Microcorruption was trivial. Flip a bit, open a lock. Lock software gets patched; overflow memory, open a lock. Starfighter is more ambitious. It has PVP elements. I draws on all the fun stuff we’ve done over the years at Matasano. Stuff like when Tom called me and asked if he could have a truckload of pork bellies (CME ticker:GBP. And: I told him no.) delivered to our house.

For the past two months, Patrick has been been building an online trading market. A virtual stock exchange with realistic limit order book markets. With NPCs that trade, in real orders. In Patrick’s tech tree, your gameplay can move markets. At some levels, you’ll play not just to game the market but to compete with other players —– if that’s how you get your fix.

(Y.T., knowing diddly about markets, is very much looking forward to playing the market tree.)

Players on the security tech tree are given a handheld device of the sort a trader could carry around the floor to execute trades. But you’re not a trader; you’re more like a runner. A gopher. Your handheld is locked; you’re not allowed to trade. So you learn AVR. You subvert the device. Escalate your read-only privileges to read-write. Submit your own trades. Crawl through the HVAC ducts into the machinery of the market and see how much damage you can do.

Don’t want to learn AVR? Don’t worry! Patrick’s trading application is just the sort of third party JSON/REST tool you’d see on a day trader’s desktop. But — there’s always a ‘but’, isn’t there? — in upcoming levels, to get high-performance access to the markets, you’ll benefit from writing low level code to talk to markets.

But not necessarily AVR. Thomas built a compiler for Starfighter. This, dear reader, is why you have been waiting ever so patiently for our release. As it turns out, even a crappy compiler is tricky to write.

Unlike Microcorruption, we wanted Starfighter to be multi-architecture. It will be, but in chapter 1, only sort of. Instead, players work with C, with an executable bytecode IR, and with its translation into AVR.

It is a terrible compiler. I could barely write enough C to test my AVR emulator and I know it’s a crappy compiler. Hint: terrible is part of the point.

We’re giving players the dev kit for the handheld trading device. You can program it in AVR assembly. But the vendor also offers support for a very limited dialect of C, compiled to bytecode IR or to AVR. Emphasis on “limited”. You know, because we did less of the fun stuff for you.

(In later releases, we’re hoping to do a tech tree with challenges that focus on compiler design.)

4

Just two months ago, Tom and I were driving to the grocery store and he says in the most idle and preoccupied tone, “This code base is really ambitious.” My reply: “No shit? You’re just now figuring this out?” Then I punched him in the shoulder.

Our code is a hot mess (of Golang and React) right now, but I’m excited.

We set out to build a game that would make it easy for people around the world to demonstrate raw aptitude for programming, and to spice it up with the endorphin fix we get from reversing and breaking complicated systems. I think we picked the right foundations to build on. Electronic trading is a huge problem domain that reaches into distributed systems and high-performance computing. Low-level software security pulls in compiler theory, cryptography, and language runtimes.

Network API programming! Trading! Order books! Assembly language! Runtime security! Cryptography! Reversing! Us pretending all our bugs were intentional, to make things more like the real world!

I think we’ve given ourselves a lot of places to go. We’re looking forward to seeing where you go with it. See you in a “few” weeks!