Alternate Securities

This post is part of my final project for one of my university courses, Computer and Network Security. For this project, I researched and created a presentation on ARGs, or Alternate Reality Games. I previously wrote a similar post for my Assembly Language course.

Much like Choose Your Own Adventure Games, in the last post, Alternate Reality Games have been something that have interested me for a very long time. The combination of puzzle solving, exploration, and general mystery really gets me excited, and I'm always looking for ways that something could be interpreted differently to get a different answer.

What is an ARG?

If you don't know what an Alternate Reality Game is, the easy explaination is that it's a interactive narrative that uses the real world and various forms of media to tell a story. A more in-depth understanding can be found via Wikipedia, if you're interested.

To start off the project, everyone in the class gave an introductory presentation about their topics. This presentation went over a bit of background information, as well as prior work in the area that our project was in. For my presentation, I decided to talk about a few better-known ARGs, and to explain some of the puzzles and storytelling that they employed. The three choice ARGs that I decided to go over were Fortnite, the Potato Sack, and Cicada 3301.

Fortnite

While Fortnite as a game might not seem like prime ARG material, the way in which the in-game world and story has progressed has many ARG elements. The most notable portion of this ARG happened in 2018. During this time, information was hidden within game assets, and various real-world events happened. The narrative of Fortnite tied all these events together into a story that changed the in-game world of Fortnite. A much more detailed explanation can be found on the Game Detectives Wiki.

The Potato Sack

The Potato Sack was an ARG run by Valve to promote the release of Portal 2. It employed clues distributed in 13 independently developed games, encoraging players to work together to find the solution to the puzzles. The ARG ran from April 1, 2011 until the release of Portal 2 on April 18. A more thorough breakdown of the events during this ARG can be found on Wikipedia.

Cicada 3301

Of the three ARGs I went over in the presentation, Cicada 3301 was by far the most complex. Its extensive use of complex cryptography mirrored some of what we were learning during the course, and it has the theme that I am still the most interested. Cicada 3301 is still ongoing at the time of writing. Information on this is spread across the internet and no single source is effective to link to, but Wikipedia is a good start as always.

Creating ARGs

As the culmination of my project, I wanted to report on the result of running my very own ARG. I was set on creating an ARG that I could run on the UAF campus, involving students and progressing a story towards collaboration among students. I only ran into one really big problem during this: creating a compelling narrative is hard.

I had a set of puzzles that I wanted to use, I had ideas of activities and events, I knew where I could put up posters. But the one thing I needed I couldn't figured out: how can I tie all these parts together with a story?

While doing research on existing ARGs, one thing becomes very clear: the single thread between all of them is a compelling narrative. A story that guides players of the ARG along, enticing them with more information, teasing them bit by bit to look for the next clue. Without a story, players of an ARG wouldn't have any motivation to continue solving the puzzles.

I had a few ideas go through my head, but none of them really worked for the still-snow-covered environment that the UAF campus was. Eventually, I compromised with myself: I'll take some inspiration from a conversation I had early. The idea for my next steps came from some feedback on my background presentation from my instructor:

It would be neat to make generic tech that would let small groups create ARGs locally, like in the department or in a big housefull of roomates [sic].

So, I began work on an ARG creation platform.

Another roadblock

I had a new goal now: creating a platform where users could easily work on and lay out ideas for ARGs. I planned to have a complete tool set that could generate puzzles, export any required files, and even help map out real-world events and activities. I had an idea, knew the tech stack I wanted to use, and set out to create some mock-ups for the user interface. Unfortunately, that's about as far as I got with the idea.

As tends to happen with me and larger projects, I get sidetracked. This time, I got sidetracked for a few weeks.

Two weeks or so before the final presentation was due, I went back and went over what I'd need to do to finish things up. To put it lightly, it was a lot. Much more than I'd be able to get done in time.

Aiming a bit smaller

I decided to change gears again. Rather than work to complete the huge task that I unwisely set upon myself, I split into another, slightly more manageable task: create a small ARG for my class.

I planned to use the mock-ups and other materials I had already created to help guide a short, bite-sized ARG based on the topics we had learned in class over the course of the semester. Topics like openssl encryption, network manipulation, and buffer overflows. I had a good start for all of these - I could base the puzzles on some of the homeworks we had done - and I could work it into my presentation in an engaging way. I set to work exploring some of the encryption possibilities with Openssl.

A word on Openssl

I never want to work with Openssl's command line interface ever again. Namely, I don't want to have to deal with their embedded salt encryption format. I spent a very large part of the last two weeks of my project on a puzzle involving Openssl. The general idea was something along these lines:

• Players are given an encrypted string, and need to find a key
• Once they find their key, they are able to decrypt the string and are presented with instructions to encrypt a different string with their key.
• This newly encrypted string would be submitted to a verification server, and new instructions would be given if it decrypted successfully.

I wanted very badly for this to work. I invested hours from multiple days into trying to make it work, but a lack of documentation and inconsistent information on the way that Openssl embedded salts in its messages made it incredibly difficult to make any progress. If it is documented somewhere, I have not found it.

The final product

With only about a week left until I needed to submit the presentation, I changed gears yet again. I changed from full fledged encryption, to much simpler math operations. I hide clues in various resources we had used through the semester, and then finally used the mock-ups I planned on showing during the presentation to help lead the members of my class into the puzzles.

I used Remix to quickly build out a base web service, and Prisma to facilitate database connections. I really love using both of these tools, and I've found that they help make project configuration and database management so much  more painless.

The website I created consisted of a simple HTML form and a short leader board of all class members that completed all portions of the puzzle. Players would find their initial key through a code hidden in the initial spreadsheet that was used to sign up for presentations. Once they had submitted that key, they would then be given further instructions. There were a few more steps, detailed in the image above.

Overall, it seemed that members of my class did enjoy playing and completing the mini-ARG that I created. In all, three people were able to complete all puzzles - two students, and my instructor.

Finishing up

I really enjoyed having an opportunity to conduct research into some existing ARGs, as well as a chance to spend time investigating how to create my own. The end result of my project unfortunately did not reflect as much about computer security as I had hoped, but in all I am glad that I had the opportunity to create and learn what I did. In the future, it would be wise for me to keep the following in mind:

• The scale of projects should be smaller. The scope of both of my initial ideas was far, far too large; nearly causing me to not complete the project at all.
• Be concious of the time that I have. Hand in hand with the previous point, when planning for my project I didn't consider the time that I needed to spend on other tasks, for my job and for other courses.
• If something isn't working, find something else. I ended up putting a lot of time into banging my head against Openssl. If I would have looked for other options earlier on, I would have had a better chance at creating a more engaging game

The final code for my puzzle-processing server can be found at https://github.com/katlyn/cs465-arg. It's very specialized, but it may be a resource to see how to implement similar projects in the future.

Two articles for university in a row! I really need to get better at writing blog posts (but who knows when that will happen). Unfortunately, there won't be any personal updates this time around, but maybe sometime soon.