Guest post by John Aycock
How is archaeology related to computer security?
In computer security, an important skill when analyzing malicious software is the ability to reverse engineer the code. In other words, an analyst has to be able to take an unknown piece of binary computer code, determine if it’s malicious and, if so, what it does. All of this must be done in the complete absence of human-readable source code. And the code may be explicitly constructed to make the task of analysis difficult. And there may or may not be good tools to help with the task. Reverse engineering can be an enormous challenge, like solving a massive jigsaw puzzle where the pieces can move around and change shape all by themselves.
Reverse engineering is also quite a different way for programmers to think of code, and not everyone is adept at it: in my experience with senior computer science students, maybe one student in 30 is really skilled in this area.
But this is an archaeology blog, and while it’s great to have people off somewhere doing computer security things to keep evildoers at bay, surely it doesn’t have much relevance to archaeology? Except that it does, and the link is archaeogaming.
Archaeogaming comes in many flavors, of course, and recently Tara tweeted about how she divided up archaeogaming work into three categories, one of which was applied work: ‘using archaeological methods to do things to games.’
THISSSSSSSSSSS. I kinda tried to simplify and split archaeogaming down into three broad categories for my PHD stuff – external, applied and reflexive. pic.twitter.com/mqtUtz3ufh
— Tara Copplestone (@gamingarchaeo) November 17, 2017
Games are physical and digital artifacts of human activity, and it makes perfect sense to study them from an archaeological point of view. As a computer scientist by training, I’ve been looking in particular at the implementation of old computer games, and together with Andrew Reinhard, starting to document the methodology for this “retrogame archaeology”.
As artifacts to study, computer games – barring incredible luck – often leave us in exactly the same place that computer security analysts find themselves: binary code only, with no source code. The code may be hard to analyze, even, either on purpose to try and thwart software pirates, or as a side effect of code optimizations. All this means that reverse engineering is a skill as necessary to archaeologists as it is to computer security professionals.
I’m in both the extremely fortunate and extremely unusual position of someone who’s been teaching specialized courses to computer scientists on computer security and now one on retrogame implementation. I’ve slowly come to the conclusion that I’ve been doing a lousy job of it, at least when it comes to teaching reverse engineering. I’d mistakenly thought that computer science students would just figure it out given a few pointers, and some do, but there’s lots of room to help the other 29/30 students in a much more structured way. Long-term, I think it’d be great to drop the qualifier “computer science” altogether, and be able to use the same techniques to teach reverse engineering to people in other disciplines, like archaeology.
Over this last summer, I had a talented summer student, Andrew Groeneveldt, whose task was to build some tools to help teach reverse engineering, and one of the things we were working on was an approach that would use a board game. Well, spoiler alert: board games are really hard to design. After many discussions and false starts, he came up with a design that seemed to work. Another summer student, Hayden Kroepfl, was really gifted with building computer hardware, and I had this wacky idea. I half-remembered playing a board game as a kid that had this physical device you used for gameplay, and how cool I thought that was. What if the players could have tactile physical doohickeys? Hayden built us some magic boxes with many switches and blinkenlights. The final piece was Tara coming on board to help refine the design and supply the fantastic artwork for the game.
The result of this is CIGOL – “logic”, reversed. In the game, there are two teams, and three puzzles to solve. Each puzzle is a combination of Boolean logic gates (and, or, exclusive or, and negations thereof), generated randomly by the magic boxes. To solve a puzzle, players have to figure out which logic gates have been used, and they use their magic box to probe the mysterious gates with different inputs and see the corresponding outputs.
Along the way, they collect 3D-printed “gate tokens” representing the different logic gates. To solve the puzzle, players insert the gate tokens representing their solution into the magic box, which will let them (and the other team) know of success or failure by playing different sounds.
CIGOL might seem a bit far removed from binary computer code, but the idea here is to teach some of the thought processes involved in reverse engineering without getting bogged down in low-level computer code. We’ll be writing more about CIGOL and the other reverse engineering exercises soon, but we got a number of questions about the game, and Tara was kind enough to loan me some blog real estate to ramble on about this a bit.
CIGOL: coming soon to a digital dig site near you!