Making Hacking an OSR Style Problem
The temptation for GMs in sci-fi games is often to treat hacking as a black box. A skill roll for some abstract cracking of the Gibson that would be too complicated or boring to play out, usually with some allusion to the opening of The Matrix.
OSR games encourage a different approach, though. The 'OSR Style Problem' is an open-ended one with no set solution, that the players can approach from any direction. Pits too wide to jump across, getting daylight into a vampire coven. That kind of thing.
(Image from Dungeon Dressing, Floors and Trapdoors)
But the thing that is so scary about making rulings around stuff like this in sci-fi games is the sci part, the science! These systems have to make sense in-universe while also presenting an interesting challenge to the players. I work with this shit all day, and I'm still daunted by it. Are we stuck with hacking forever being consigned to the off-screen check?
I think not. Thankfully, the reality of hacking is often a far cry from what you see in movies. The pure technical problems of encryption and secure protocols are refined constantly, yet hacking is a bigger industry than ever. It's where these ironclad algorithms fail (or more likely where they haven't or can't be implemented) that are the usual targets for the attacker.
Hacking is ripe for making gameable, open-ended and interactive situations — if only we know how to quickly cobble together convincing fictional systems for the players to crack. I've tried my best to outline my approach below. I find that it results in players making cooler objectives for themselves, and as a side effect, also results in grittier in-depth world-building.
I'm gonna go through this in three parts. In part one I'll go over general GM guidelines for approaching these kinds of problems. In part two we're gonna get into some cybersecurity weeds to get some useful real world tools, and in part three we're going to put it all together and see how we might present one of my favourite systems - Prospero's Dream's O2 Distribution System from Mothership. At the bottom you can find a checklist you can copy into your GM notes.
Part 1: Tips for Outlining Systems For Your Prospective Hackers
Insecure Systems are Gameable Ones
(Photo by Dima Pechurin on Unsplash)
When we're thinking about security systems for an RPG — we want them to be breakable. If the players have an amazing idea involving some convoluted hack — we want them to be able to pursue that.
Avoid the 'quantum sysadmin', who just so happens to have thought to defend where the players are attacking because your system doesn't feel secure enough.
Instead, pause the session, if you'd like to chat about it with the players, and lock in how the systems work before the players tackle it.
If they spot an obvious flaw, great. Issues only start to arise when the flaw is always the same one, so just shake things up a bit and you'll be fine.
Avoid Technobabble
Technobabble is great for screenwriters who want to handwave explaining a system, but as GMs we want our players to understand the technology they're using on some level — so they can exploit it.
"Tier 2 Access" sounds sci-fi, but "Engineering Credentials" says something about how one might acquire this access and gives ideas for what it can be used for.
Dropping a "Reverse Polarising Energiser" into the description sounds impressive but kills the conversation. "The part that stops the energy being thrown back into the system, overheating it" begs the question of what one could achieve by removing it.
If You're Stuck, Think Simple, Cheap and Low Tech
(Photo by Diogo Cardoso on Unsplash)
The cassettepunk aesthetic means that you can get away with pretty much anything. On top of this, once they're in the wild people will use systems as they please, regardless of what any systems engineer might tell them. They'll put tape over sensors, share user accounts and do who knows what with locks. Additionally, there is no lower limit to what corners the company can cut. All labour is unskilled labour because you can just get an android to do it, so you either put up or get replaced.
Unless you and your players are comfortable talking about them, don't worry about ACKs or magstrips or anything complicated like that. Signals, cards, wires, panels, plugs and the like are sufficient detail.
And Don't worry about whether the system you've suggested seems sensible! Many real world systems aren't. It being internally consistent is sufficient and it being evocative is a plus.
Accept Feasible Solutions
(Photo by Fernando Lavin on Unsplash)
If the players give something that sounds feasible but breaks your system in ways you didn't expect (e.g. There's a wireless key for this door? I'm just going to blast common values on all frequencies until I get a match) they have probably discovered an equivalent to a real world exploit, and you should pat yourself on the back for crafting a realistic system.
Ask them how they do it and lay out requirements and possible costs (usually it'll take time, or maybe you risk breaking the thing permanently). If they have reasonable tools and accept the costs, let it work. If it becomes a boring universal solution, start having the corporations look to patch it (or just kill the crew off).
If you Can't think of an immediate Consequence for hacking, Start a Clock
Cracking into systems is, understandably, frowned upon. So unless a ship is completely derelict and independently owned, eventually some sysadmin will come sniffing through the logs, and if your players are not careful the company will find traces of what they've done.
If you think there should be a consequence but can't nail one down, start a clock for the company cracking down on the crew. Maybe they start pushing out patches to fix vulnerabilities the crew exploited, or just put an enormous bounty on their heads.
If you're not familiar, you can swot up on clocks in the Blades in the Dark SRD.
A good procedure for this is to gently remind them when discussing the costs that they'll draw negative attention, and then if their cover-up involves computers, that'll probably be a hacking roll. How long the clock is (or how much the existing clock fills) depends on their result. Tell them you're tracking the negative attention, you might even want to have the clock be completely public. Once a clock is full, you can introduce that consequence whenever you'd like.
I personally love to catch them just after mission hand ins, when the blood is still drying. They never expect it.
Let Hacking Rolls Skip Requirements
(Photo by Moritz Erken on Unsplash)
So you may wonder where the hacking skill comes into all this?
Hacking rolls lets you skip getting authentication or having a specific plan for exploiting a system to get authorisation. You just roll to hack and get your "I'm in" moment.
If a player's plan leans on technical expertise from their character, doesn't have sufficient detail to your liking, or has clear risks (e.g. "I'm gonna stick the live wire into this machine to short out the authentication module") - you may want to call for a roll to assess consequences.
It also lets you get hints for potential attack vectors without investigating.
It's also a great check to see what consequences (if any) befall the crew from OSR style computer misuse that otherwise succeeds without needing a roll. They may know how to fire off a script, but can they cover their tracks? That takes an expert.
If you'd like to make the hacking roll less of a bypass and more of an alternative, I'd recommend Mothership's fantastic Hackers Handbook to make it a more involved and granular procedure.
Part 2: Useful Real World Concepts
Apologies to anybody who has had to sit through cybersecurity training recently. This will sound very familiar.
Authentication and Authorisation
The only reason a player will want to know how a system works is to break it, so we can consider our systems primarily through the lens of security.
When trying to think about how a security system works, remember that what a hacker wants is access to functionality. A security system will check a user for these two requirements:
Authentication: Is the user who they say they are?
Authorisation: Should the authenticated user be able to access the functionality they're trying to access?
Authentication
Can be checked in a few different ways (known as factors):
Something you Know (Knowledge)
(Photo by Salah Ait Mokhtar on Unsplash)
e.g. A password, a security question, a pin code
Knowledge factors are an excellent excuse for a puzzle ass puzzle (remember, always scatter three hints!) — so make passwords or security question answers uncoverable with a little detective work.
Something you Have (Possession)
(Photo by Matt Artz on Unsplash)
e.g. A keycard, an authenticator code, or being at a particular terminal
Possession factors can give you as the GM a macguffin to dangle in front of your players. Why bother going deeper into the facility? Well, how else are you going to get to the admin terminal?
Something you Are (Inherence)
(Photo by Roman Petrov on Unsplash)
e.g. Biometrics (fingerprint, DNA), visual confirmation by a trusted party
Inherence factors are brilliant fodder for social engineering (or just sheer violence) from the players. Convince the mark they have a voice memo to record them saying "Open". Record it and play it to the voice recognition module on the door. Or maybe just cut a finger off for the fingerprint scanner.
Accept Any One Factor
Real systems use multiple factor authentication for security's sake. But as a GM, I'd recommend accepting authentication of any one factor for anything other than a campaign defining security system. Getting two could fill a whole session.
Accepting any one authentication factor gives your players many approaches to the problem of spoofing this authentication.
I'd say for any given system, decide on a few factors it'll be expecting. It doesn't necessarily have to accept all three types, but should at least accept two different types.
Authorisation
This is where what most people would think of as hacking kicks in. How do we get the computer to let us do something we couldn't otherwise?
This will usually be an alternative to acquiring authentication. Either you get admin access or you crack the terminal.
For this, combine the above advice with one extra handy tip:
Think about what functionality different users need, and minimise their allowances accordingly
(Photo by aboodi vesakaran on Unsplash)
Allowances are the different ways you can manipulate an object. For example, doors can be pushed or pulled. Some can only open one way.
System designers have an idea called "Principle of Least Privilege". You should only give users access to the bare minimum allowances needed to use the system in the way you'd like.
This is helpful to us because it can inspire how the devices look and feel to use. For example, unless our system absolutely needs to be portable, it'll probably be big (because that's cheaper and more secure).
Part 3: Putting It All Together on Prospero's Dream
(Photo by Simone Hutsch on Unsplash)
In honour of Mothership Month, let's look at one of the systems any crew on the game's premier hive of scum and villainy Prospero's Dream will certainly want to tamper with: the O2 Distribution System
In the book we have the following to go on
...After decontamination [the crew] are issued an O2 credstick which acts as wallet, passport, and locator aboard the station. It must be preloaded with credits, and any debts or purchases are automatically deducted from it (taxes and fees are automatically withdrawn daily).
Seemingly from tables in the book these credsticks can be jailbroken, and can come without ID.
So when we're thinking about how the O2 distribution system comes up in play, we can consider our checklist below
So let's think up some answers:
- What does it restrict access to? You might think oxygen - but the book makes it seem more like it restricts access to the station. I'll go with that.
- Authentication: The credsticks come loaded with ID. I can't think about what that ID would be so let's go simple, crap and low tech: it's a photo of your company card. The station is littered with cameras. There's a room somewhere with thousands of screens where some poor saps are manually comparing your face to your ID at random intervals throughout the day. That covers Inherence (do you match your ID?) and possession (do you have your credstick?)
- Authorisation: If you're authenticated, you are authorised if you have sufficient creds loaded onto your stick. We presumably check this by checking a database of credstick IDs and balances.
- Enforcement: So the question is how do we enforce this? Again - simple crap and low tech: Accounts are charged automatically based on a simple check of time on station. Bounties are automatically placed on people with negative balances, there are O2 checkpoints all over to challenge people moving around. If we decided this system restricted access to Oxygen we might instead just cut off the oxygen supply.
- How do users interact? My interpretation of how it's authenticated and enforced seem to suggest that everything is handled by the station's security. So that can help us figure out what it looks like. Probably the stick itself is just inert (maybe like a USB stick with an emitter in it) - and security stick it into a reader to get the information off it. I'm imagining grimy stationary terminals with a screen, keyboard and port.
- How does it work? Well our above answer covers this but it seems to be more a legal than tech framework - but there is some tech there: How does the cred stick know where you are? Simple and crap: there's thousands of cheap little receivers scattered all around the station logging a unique identifying signal each credstick emits. You can pinpoint somebody to a few metres based on which receivers they are in range of. This likely also factors our Authentication.
So how could we exploit this interpretation of the O2 system? You might have some ideas. I'd probably try cloning somebody else's credstick signal, but that'd likely cause me problems when either they run out of O2 or I get caught with a mismatched ID and signal. Maybe I could break my credstick's signal emitter? When I'm caught I could expect a clock to start as the dream cracks down on credstick fraudsters.
So there we go, from a simple roll to a powder keg of poverty and death. Fun!!!
Thanks for reading all this. It's a massive labour of love on my part. If you want to see some more of my Mothership thoughts, check out:
- My Standard Mothership Employment Contract
- 1d20 Sci-Fi Software Frameworks and Command Line Tools
- 1d12 Illegal Bioprinter Schematics
A Checklist For Creating a New System
- What does it restrict access to?
- How does it authenticate users?
- A Knowledge Factor
- A Possession Factor
- An Inherence Factor
- How does it check user authorisation?
- How does it enforce user authorisation?
- In brief, how does the user interact with it?
- In brief, how does it provide access to the thing it's restricting?