Vendor Puzzles in Cyber Fire
Cyber Fire has been running continuously since 2009, with a suite of roughly 300 home-grown puzzles. Puzzles are arranged by category, with each category attempting to teach a set of related skills, in a gentle progression that tries to teach new skills as people play.
In 2011, we began inviting vendors to contribute puzzles that demonstrate the value of their product, in exchange for hosting events. Vendor Puzzles are your opportunity to show off your product or service with the technical workers who would be using it.
How it Works
Foundry events from Foundry 16 forward will feature a single vendor category for all vendor puzzles. Each vendor is invited to contribute two (2) puzzles for inclusion within the category. Your puzzles will be labelled with the name of your company, so that participants will know who to come and ask for help. While we cannot guarantee every puzzle will be unlocked by participants, we will try our best to order things so that every vendor gets at least one puzzle unlocked within the event.
Deadlines
These are our usual deadlines. Dates may vary for specific events: read your emails!
Deadlines are firm: we work on a tight timeline!
Rough Draft
Typically due 8 weeks before start of event
The rough draft should be a writeup of what you intend to run. We’ll help you to make sure your work doesn’t overlap too much with anything else, and that it fits into the event.
Initial Working Draft
Typically due 6 weeks before start of event
Your Initial Working Draft will be in the MOTH format, and allows us a week to help you make sure it actually runs in our contest without causing problems.
Final Submission
Typically due 3 weeks before start of event
Final Submission is in the MOTH format. We may still ask you to make a few minor changes, but your puzzles need to be in good shape and ready to ship by this deadline.
MOTH Development Server
We use the MOTH puzzle server for our events, and we require puzzles to be in MOTH format, with progression of points, attribution, strictly codified answers, and more.
The best way to ensure your puzzles are going to work in our system is to use the development server we created. This will try to render your puzzles and show you how they’ll appear to contestants. It will also break if your puzzle metadata is incorrectly-created, so you can fix them before you send them to us.
Unfortunately, we don’t have funding to correct vendor-submitted puzzles, so if you send us puzzles that don’t work with our server, we can’t fix them for you. Making sure your puzzles work with the development server is a near-guarantee that we won’t reject your puzzles for being incompatible.
Some things that make Cyber Fire different
- When someone at a contest answers a puzzle, it unlocks the next puzzle for everyone at the contest.
- We don’t allow anything that will hurt a participant’s computer without them taking some step acknowledging that they’re dealing with danger. Usually this means you wrap the badness in a password-protected zip file, or include it in a disk image. We’re trying to avoid one-click pwnage.
- We use the MOTH puzzle format. The Development server will help you here.
Good Puzzle Writing Philosophy
The development server example categories have a good overview of writing good puzzles: please go through them.
Your puzzles should point out what your company does that is unique, without requiring your product. Rather, craft puzzles that illustrate how much time and effort people would save if they were using it instead of the “old way”.
Anybody can catch up by doing equivalent work: This one is violated a lot in computer security games: typically there’s an “early answer” bonus, or points decay over time. Unless you’re trying to teach people how to obsessively check for new puzzles, or how to hammer in answers as quickly as possible, don’t do this.
Everybody has the same odds: Everybody has to feel like they have the same chance to win as everybody else, and this has to last through the whole game. The rules have to be the same for everybody, and questions about the rules have to be referred to either a comprehensive rulebook, or a single authority whose decisions apply to everyone; likely both. Everybody gets the same platform for appeals, and decisions need to be documented in a way that even people who didn’t ask are both informed about them and can see them (or have them repeated) at any time.
Winning isn’t true/false: It’s fine, in a game played for the sake of the game, to have a “winner” and “loser”. But if you’re trying to teach something with the game, participants need to be able to benchmark how they did against the winning team. So rather than a true/false answer, there should be some measure of score, progress, or something else. If possible, you want to devalue scores to the point where it’s just an interesting aside, because what you’re trying to accomplish is learning.
Frobozz Magic Checksum Company
As an example, let’s consider the Frobozz Magic Checksum Company, who sells a product that reports on the MD5 checksum of every file in a file system.
First Puzzle: find a file by checksum
A good first puzzle for the Frobozz product would be to provide participants with a hard drive image, and ask them to track down the file with checksum d3b07384d113edec49eaa6238ad5ff00.
This can be done by hand, but all the participant has to do with the Frobozz product is upload the image and enter the checksum, and they’re done. The answer is the full path to the file, which is conveniently provided by the product.
Second Puzzle: Count matches from a list
The second puzzle provides a list of checksums, and asks the player to find all files on the previous image that match any of the checksums. Easy with the Frobozz product, just drop the list into a text box and click “Go”.
The answer requested is the 42nd match of the sorted list of matching files. Just click the “path” column to sort, and go down the the 42nd entry, and paste it in.
Third Puzzle: Track changes over time
The file system has checkpointing capabilities (like btrfs). Players are now asked to look up a file by checksum, and paste in checksum of the the 5th checkpoint revision of that file. This is just a few clicks in the Frobozz system, but it could be an hour of work or more by hand.