Tuesday, August 9, 2022

Computer Hacking in RPGs


Today I will once again be speaking confidently on a subject about which I am unqualified to discuss. 

I've been thinking about hacking a lot lately. Not "hacking" like hacking a rules system. Not even "hacking" like "exploratory programming." I'm specifically talking about our favorite x-tremely kool 90's heroes who save the world by breaching computer security (and occasionally rollerblading). It's a well-known challenge of game design.

I have never actually played a cyberpunk RPG like Shadowrun or... Cyberpunk. Hacking was in Star Wars: Saga Edition but I kinda bullshitted (bullshat?) my way through those parts because I was like 16 when I ran that game. But I have read lots of different hacking rules and I've read lots of other people discussing their experiences using them, and these are my takeaways for the most common problems:

  1. It's complicated and a headache to learn, especially for the GM who has the rest of the system to learn as well.
  2. It's usually only for one player to participate in while everyone else waits on the sideline, and in Shadowrun especially is notorious for taking a really long time.
  3. Either it's realistic and confusing or it's abstracted and unsatisfying.
  4. The GM doesn't consistently integrate it into the game world, treating it almost like an afterthought.
This is really tricky because the easiest way to integrate hacking would just be to tell the players "make a hacking roll" whenever they want to cheese a device, but then there'll be a player at your table who wants to be the hacker, and they need something more in-depth in order to fulfill their fantasy.

So I have some thoughts about how to address this. Partly, this results in me creating my own loose ruleset for hacking gameplay. But also, think of this more as guidelines for how to create your own rules based on your personal design philosophy and priorities. I'm here to spotlight for you the kinds of important questions you'd want to ask and answer if you tackled this yourself. Especially the questions that'll help you avoid the kinds of mistakes that lead to something as unpopular as Shadowrun's hacking rules.

Also, prepare for some semantic satiation.

How could HACKING be boring?

Here's the first and most important question: what is the fun part about hacking? Because that's the thing we want to focus on.

Well the first thing that comes to mind is just using the stuff you're hacking! It's fun to take command of the villain's own security robots and have them turn on their master. It's fun to hijack a TV station and broadcast whatever weird shit you feel like trolling people with. It's fun to hack traffic lights and cause car crashes in the middle of a chase scene in order to get the cops off your tail. It's fun to trigger an alarm and force everyone in a compound to go on high alert, looking for an intruder who isn't there like a bunch of rubes. Hacking is like magic: it's a really flexible "toy" mechanic that let's you break the rules of an otherwise-ordered world.

But sometimes you're hacking a device just to retrieve some information, or to open or close a door, or to deactivate a security camera. Simple stuff. Important to be sure, but not that special kind of thrilling that makes you feel like you're getting away with shenanigans.

So the other thing I think is fun about hacking is the part where you have to deal with the security measures once things go poorly. You can tell I'm a bit of an asshole DM. But I genuinely like game design that's more geared towards "mechanics that create challenges for PCs" over "mechanics that give PCs more powers." I like restrictive inventory systems and breakable weapons and armor and magic that has the chance to go haywire. So if hacking leads to a crisis to deal with, I consider that a good thing.

But also, shouldn't a game activity still be fun when, y'know, you're doing well at it? Most of the time, yeah. But with hacking... well, I'm not sure. It makes more sense for it be "smooth sailing" than for it to be "fun." And I guess it's perfectly fine if those sorts of routine hacking tasks I was describing are as simple as a pass/fail "roll a hacking check." But I'm instead quite drawn to the notion that maybe hacking should never be smooth sailing.

That is to say, that all hacking actions in the game should confront the player with a tradeoff they have to make. "Would you rather have the network lock you out after getting one answer or keep probing for more info but trigger the guard alarm?" "Would you rather access the terminal inside the enemy base but be exposed to the guards or access it from a remote device but have a spotty connection?" "Would you rather attempt to steal the administrator's credentials so you can enjoy full access to the network or just go in now, reboot the system, and only have full access for one brief cycle, after which all the alarms go off? AKA would you rather have to do a risky infiltration up front or work under a tight time pressure now?" And then the enjoyment comes from strategising and choosing your preferred battles and figuring out how you can play to you and your team's strengths. It's the consequences outside of the computer terminal that make hacking interesting.

But the big stumbling block in this design space, and the broader conversation about real world hacking in general, is the persistent fixation on the "technical opacity" of the subject. That normies like us don't understand computers well enough to be able to get a handle on even the basics of hacking, and that it's nearly impossible to depict it both accurately and accessibly, whether it's in film and TV or in gaming. The cliche refrain is that, "real hacking would be boring to watch. It's mostly just sitting and writing code for hours and then waiting for it to compile for even more hours, which isn't exactly easy to make thrilling."

But what if I told you that this "problem" is actually just an illusion? Let's talk about...

Mr. Robot is a psychological thriller TV show about vigilante hackers trying to take down capitalism while dealing with mental illness. It was created by Sam Esmail and aired on the USA Network for four seasons from 2015 to 2019. It is a very spoiler-heavy show but I won't be revealing anything about the plot or characters in it.

I liked it okay. I thought the first season was way better than the other three, unfortunately.

Mr. Robot has been universally praised for its depiction of hacking. It is painstakingly accurate and well-researched while also thrilling and easy to follow. There were tons of major figures in the cybersecurity world who served as consultants on the show and the result is basically nonstop hacking-porn.

But whenever people praise the accuracy of the show, they're usually just talking about the technical aspects like terminology, equipment used, visuals, practices, etc. Y'know, stuff that shouldn't actually matter much to the normie audience. To us, it's all technobabble anyway. But it's the kind of thing that normies like to hear is really well-done. When an expert says, "hey, you probably didn't realize it when you were watching, but all that mumbo jumbo the characters were saying was all actually authentic!" then people love that. We just enjoy knowing which medical dramas/courtroom dramas/police procedurals/whatever get it right versus which ones are full of nonsense, even when we can't personally tell the difference.

But I feel like that's really underselling Mr. Robot's achievement here. The truly commendable thing about this show isn't its commitment to technical accuracy. It's something else, something that renders the entire public discourse on the topic completely hollow:
Mr. Robot is one of the only media depictions of hacking that shows that hacking is, like, 90% social engineering.
Yes, the vast majority of what hacking actually entails is just normal deception and thievery skills. Maybe it's pretending to be a hustler on Fifth Avenue handing out your mixtape to random pedestrians, banking on at least one of them to plug it into their device at home and upload your malware themselves. Maybe it's seducing someone in a bar for a one-night stand so that you can wait until they're asleep and then steal their work ID and make a clone of it. Maybe it's running up to someone at the bus stop and desperately pleading to borrow their phone so you can make an emergency call because you're in a jam, and then using that opportunity to steal their bank login info. Sometimes it's literally just sending somebody a dangerous URL that looks innocuous and tricking them into clicking it.

Once you see this for yourself, suddenly every other media depiction of hacking seems even more ridiculous somehow. Sure, you can give them a break for making up something cheesy since the "real thing" is allegedly really hard to dramatize. But that's not even true. The real thing is actually really cool and easy to make thrilling.

If you can write a heist movie, a crime drama, or a spy thriller, then you already know how to write good hacking fiction. And as an RPG designer, if you know how to write a scenario based on infiltration/heists, investigation, or social intrigue, then you can incorporate hacking into gameplay. When a player says they want to play a hacker, inform them that being trained in the "hacking" skill is only a small part of what they're asking for. Hacking is a way of life, n00b.

Does that sound hyperbolic or overly simplistic? Let me give a more mundane example.

If you grew up in one of the "digital native" generations like me, you might relate to this. Have you ever had an experience where someone left their computer unattended with their social media open, and then someone else (probably a child) posted from their account and wrote, "YOU'VE BEEN HACKED"? We can laugh at that kind of thing because, well, for one thing it's funny. But also because we often laugh at the kid who called this little trick "hacking."

Except the kid is kinda right.

I mean, don't get me wrong. This is just about the most simple "hack" you can perform, and any real-world cybersecurity endeavors are definitely going to require more technical knowledge than that. But in any type of security operation, the keys to success are simplicity and minimizing risks. If you wanted to steal someone's identity info, would it be better to write some kind of malware that you can get into their home device remotely while using expensive tech to keep your digital footprints covered or would it be better to just grab it from their already-open-and-logged-in device (or even from a sticky note left next to their device)? To a hacker, you almost always prefer an option like the latter one.

But hacking is just one part of cybersecurity, and when you study cybersecurity, you're definitely focused on the computer parts. But an IT guy making sure their company has a firewall on their network isn't the kind of thing your player is talking about when they say they want to play as a hacker. For that, you want what I'm selling: basically just a rogue but with some digital "spellcasting" powers. This is what Mr. Robot understood about the subject and what you'll benefit from as well: you need to focus on how you are using your hacking powers and what you're using them for, rather than on how the hacking itself works.

This sounds like the "just handwave the hacking parts" solutions

That's fair. I don't want to dismiss the idea of exploring the technical direction entirely, I just want to point out that it can be a relatively small part of this if we design it that way. But it is the part that remains an unsolved design challenge, so let's dig into it a bit more.

Pretty much the exact wrong way to do it is that solution you often see in so many video games: hacking is represented with a puzzle minigame. In Bioshock it was that Pipe Dream-inspired puzzle, in Deus Ex: Human Revolution it was a territory-control labyrinth navigator, in Mass Effect you play Frogger or Simon Says depending on the version you played, in Cyberpunk 2077 it's that columns-and-rows number sequencing game, and so on. Sometimes these are fun and enjoyable, but they're very gimmicky and a total cop-out. There's no reason to disguise the technical stuff into something completely different and unrelated.

But don't mistake me as saying that I think you should somehow force your players to type Linux prompts into a console, either. While I am going to help you delve a little deeper into the technical side of hacking, I'm still going to ultimately advocate for a fairly-abstracted approach. There's no benefit to be gained from that degree of detail. All of that is just a language and architecture used to represent ideas, and it's the underlying ideas that are worth focusing on. You are capable of understanding more of them than you might think.

With that being said, I've created a rough draft of a generic "hacking procedure." Here's a link, give it a read, tell me what you think, and enjoy my design notes (and some other related thoughts) below.

Design Notes

As I see it, these are the baseline components that are always involved:
  1. You identify a device you want to hack.
  2. You have a means to access it (a "terminal").
  3. You issue commands.

    And a fourth thing that's nearly always present:

  4. You have to deal with security measures.

1. Hackable Devices

This is the part that requires the GM to be properly seeding the game world with opportunities to use your skills. Getting right to problem number 4 from the beginning of this post, I think that there's a bit of a misunderstanding of the true source of the issue.

The more sci-fi your setting is, the more likely that any given piece of technology is computer-based, and is therefore hackable. So I have faith that, if you're running a futuristic game, you'll remember to include the kinds of devices I just listed. You don't actually have to intentionally place hackable devices in your game, because you probably already filled it with an overabundance of them already. What you really need is to be prepared to run a world where almost everything in it is hackable. It's not that the world didn't have hackable devices in it. It's that, when the player asked if they could try taking command of the starship from the control panel next to the bathroom, you weren't prepared for that possibility and you aren't sure how viable it is and what kinds of obstacles there'd be and now you've seized up.

In order to make this manageable, I think there are just a handful of "rules of thumb" you can internalize which will help you resolve these situations much more easily. This is where all the bits in the procedure about networks comes from. Once you learn the logic of networks, the types they fall into, what kinds of devices and contexts make use of which kinds, and so on, it actually handles most of the uncertainties you'll have with hacking. It's also kind of surprising! The "internet of things" is a nightmare for security. For example: cars would have their own network, but because modern cars have Bluetooth, that means that it's totally possible to remotely hack a car from a cell phone. I'm hesitant to recommend you even running "hacking gameplay" in a modern day setting unless you implement some strong limitations on a PCs' knowledge in this area (which my document includes some suggestions about). We live in a very tech-insecure era.

But it's also useful mental framing to ask yourself "does this device deal with info or does it do something or is it both?" I know that the "do something" devices sound more fun to hack (like commandeering an enemy mecha in combat) but information is also a very, very valuable game element. It is the fuel of plans, it is the fuel of ambition, it is the fuel of adventures themselves. Sometimes info is the goal itself. You're here to steal the Death Star schematics, your rival company's corporate strategy, the admiral's battle plan, etc. Sometimes it's just a means to an end that you decide you need mid-adventure. To find the princess, we need to learn the location of the detention block on this space station. To hack this company's records, we need to learn their passwords. To infiltrate this admiral's camp, we need to learn who has proper clearance so we can either use them or disguise as them. My intuition is that rolls for doing stuff should be harder than rolls for learning stuff. If they hack a starship, they make one (easier) roll to learn about its specs and one (harder) roll to take control. If they hack the Death Star, they make one (easier) roll to learn where the tractor beam controls are or which prisoners are scheduled for termination, and one (harder) roll to open and close the doors or turn off the trash compactors.

2. Means of Access

In the same way that you must be adjacent to an enemy to hit them with your sword or you must be sitting at the helm of the ship in order to steer it, you can impose requirements on where and when a PC is allowed to hack a device. This is another point in the process that you can make into the main challenge rather than focusing on the act of hacking itself. Oftentimes, just "getting into the system" is sufficiently hard to act as good gameplay.

You control where the PCs do their hacking from, making hacking a very location-based activity. Physically manuevering yourself into a spot and then escaping is easily an entire adventure by itself. If the device/network is wireless, then the PC has a lot of freedom to hack from anywhere within signal range. If it's wired, then they have to stay put wherever their terminal is plugged in, either from their own device they've brought or from a built-in console. Either way, keeping the hacker defended and/or unnoticed while they work is the true solution to making hacking a fun multiplayer activity.

Once again, a super wide-area network like the Internet or the PSTN removes a lot of the challenge here because there are built-in terminals everywhere.

This is the trickiest part to get right, I think. Here were my thoughts when I designed this.

At first I thought: unlike many adventurous actions in D&D, there's rarely a risk that you'd "fail" at issuing a command. Either you know what you're doing or you don't, and if you know what you're doing then it's just a matter of time. So if we streamline things for a moment here, let's temporarily ignore the factor of "security measures" (which we'll talk about next). Without those, then it looks like the first key variable in gamifying hacking is to introduce a time cost. I see three main ways to implement this:
  1. No variation. You simply set a time cost for each kind of command that can be performed. The player knows exactly how long it'll take them to do any given action and has perfect control over how this resource is spent. The GM just has to decide how "valuable" each command is in terms of the time it costs to perform.
  2. Roll to determine the time cost. When you want to input a command, you have to roll. You're guaranteed to succeed, but you roll to determine how well you succeed. "Alright, looks like this will take me about..." rolls dice "...3 rounds to complete." The problem with this is that, once the hacker has made their roll, they don't have anything to do for that whole timespan because their character is locked down in hacking mode. Everyone else gets to act on their turn, y'know?
  3. Roll pass/fail each time increment. This means that you need to roll turn-by-turn and have a source of pressure that has a meaningful impact at least as frequently. This works really well in combat and dungeoncrawls. In combat, the hacker PC can spend their turn working on their console while the action unfolds around them, and every round they pray they roll successfully so they can finally step away from the computer and out of vulnerability. In a dungeoncrawl, there might not be hectic chaos happening every turn, but there is going to be a random encounter roll (plus maybe other effects like torches burning) every turn, which means that every roll does count. This option stays exciting, giving the hacker an action to perform each round and keeping everyone on their toes, not knowing how much longer the process will take. I know I said this isn't the kind of thing you typically "fail" at but you can always justify this roll as "hasn't found the thing they're looking for yet," which actually is pretty realistic, so ultimately I probably like this option the most.
This is the simplified overview of the ruleset I've
been making fun of throughout this post. Here's
another helpful guide
if you're a masochist.
Another big can of worms is asking, "what kinds of commands are/should be possible in the game?" Is it even possible to exhaustively catalogue all of them? And if it were, is that even a desirable solution? I mean, the standard set of Linux networking commands is essential for a real hacker to know, but if I listed them out for you along with their definitions then you'd immediately understand that they are exactly the type of "real world detail" we can comfortably streamline out of the game and abstract into a fluff description or a die roll.

You could always leave it as a freeform element. The player just thinks of something they'd like to use the device to do from their own imagination, and if it seems to make sense then you can do it. And in most contexts, that sounds reasonable to me. When you think about "hacking a door," you can probably come up with every function of the door just from your noggin': open, close, lock, unlock. If you're "hacking a car" then I suppose you get to drive it around, play with the radio, turn on the A/C, etc. But that's the sort of thing that it can become difficult to improvise a DC for when it comes to the roll, or a default time cost if you're going that route.

I'd like some framework to help me categorize commands. I actually quite like the one in Kevin Crawford's Stars Without Number. There are six basic hacking actions, three for "info" hacking and three for "doing stuff" hacking:
  1. Answer a specific question (easy). I would treat this the same as "find something." 
  2. Get general information (medium)
  3. Complete database acquisition (hard)
  4. Supress a system, AKA, turn it off for as long as you're hacking at the terminal (easy)
  5. Subvert a system, AKA, take control of it and use it to do the things it was built to do. If you leave the terminal, it'll just keep following your last command (medium)
  6. Sabotage a system, AKA break it, triggering an alarm (medium, surprisingly)
I think that's a pretty well thought out framework, so I figured it'd be better to build on top of it rather than start from scratch. There were a bunch of little questions that were bugging me. If you hack a vehicle or robot or something so you can control it, how long does your control last? Permanently? Until you step away from the console? Until the security measures boot your ass out? And if your command is a simple information retrieval, then how long does it take to read the info once found? As a rule of thumb, I've always just allowed my players to receive and process information pretty much instantly, rather than struggling to figure out how many paragraphs of text a person can read in 6 seconds or 12 seconds or 18 seconds, or how well they can skim a schematic for flaws or something. But at the same time, I think we can definitely imagine the difference between a brief answer and something that would take so long to read that it's better to just grab the whole hard drive and run away with it so you can read it later.

4. Security Measures

There are some purists who don't consider it hacking unless you're dealing with cyber-obstacles. They would argue that everything I've described up to this point is just guidelines for any "Use Computer" gameplay. They're probably right, but it was important for us to lay the foundations.

Security measures will perform either prevention, detection, or response. This is an easy thing to understand in the abstract, but very difficult to be specific about. It is extremely unique to each device, network, piece of software, etc. It's changing constantly as computer engineers patch up exploits and security nerds find new ones. If you set your campaign in the 80s, 90s, 2000s, today, or the future, then the exploits available will be completely different from one another. This is the time to handwave and technobabble your way through the description, understanding that the underlying event taking place is, "the PC is navigating the system and learning about it until they discover an unintended possbility built-in."

So my solution was to introduce a generalized idea of each of these three security measures at different stages of the procedure: getting set up at a terminal with connection, gaining Access, being Detected, being traced, and facing a response.

To get past each of these, you could either do "pure hacking" (sitting at the terminal looking for exploits), use a gadget that does the job for you, or maybe do it at least partially "legit." A good example is Access. You could determine the password with a program that uses a brute force method, you could get a gadget that lifts it from the target device for you, or you could just go spy on the user and genuinely learn the password.

What I like about this implementation of security measures is that it automatically generates those kinds of "lose-lose" tradeoff situations I described near the beginning of the post. It puts PCs in a position where they have to decide if they want to keep pushing their luck in order to get more out of their hack. Sure, it lacks some nuance. There are so many unique security and access conundrums that this procedure doesn't account for, but I think it's pretty solid.

I also like it because it validates one of the most realistic parts of hacking: that you'll probably try to do as many of these steps as you can from the safety of your home with as much time as you need. Most or all of the steps can be done with zero risks if you just take enough time. Then, the tropes of D&D itself and the sorts of adventures you'll be getting into will give you plenty of incentives to do things faster, and therefore, riskier.

If you want to read the emails off your enemy's lawyer's laptop, then you could spend a week doing that remotely. But maybe you only have a few days, so you decide to shorten the first step and go to his office in person so you can use a shortcut to get past Access, and then do the rest at home.  And if you only have an hour or two, maybe you'll just do every step in person, getting someone to distract him so you can just use his laptop directly for a few minutes.

Another Promising Route

By far the coolest hacking is what some folks call "hardware hacking," where you're exploiting physics itself. Messing with the temperature of something, causing vibrations and capturing their wave pattern, using magnets, etc. These usually fall within what's called "side-channel attacking".

In a way, this brings us back to the sorts of "less computer, more social engineering" Mr. Robot stuff I was talking about earlier. While cybersecurity folks consider hacking to be "getting past computer security," computer nerds themselves instead define it alternatively as "exploratory programming." You take a piece of technology designed for a human to use and then use it in a way it wasn't designed for. You reject the intended inputs and create or find alternate ones, or even use the intended inputs in unanticipated ways. In "pure hacking," you're just doing this in the computer protocols. But sometimes there are literally no flaws in the protocols! Really well-designed programming might not have any exploitable inputs.

That's where hardware hacking comes in. No matter how strong the programming is, it still has to be run on a device with physical components. The best metaphor I've heard is a pinball machine. In pinball, your two intended inputs are the flippers you can use to smack the ball. But you could discover an unintended input as well: lifting the machine itself from one side and manuevering the ball through balance and repositioning. That's technically hacking!

Here's a really, really amazing video (almost 45 minutes) about physical security and its role in this space. It's very entertaining and educational, if a bit surface-level. He uses a few fancy tools now and then but this honestly exposes my whole "gadgets" mechanic as being a bit nonsense. The "gadgets" that a hacker PC should invest in are things like wrenches, drills, bolt cutters, and the like. Or whatever the fuck this thing is. Hell, your own OSR PC might even already have a lot of the most useful hacking tools on them right now. Like what I said before about security measures and commands, I'm hesitant to recommend that you get too specific or crunchy. But if a creative PC comes up with a way to use their tool to achieve something with a computer that seems to make sense, validate that. "Can I use my magnet to erase the data?" "Can I open the car door with my crowbar?" "Can I plug into the network by unscrewing a wall panel and messing with the wiring in the walls?" Just because you've introduced hacking rules doesn't mean this stuff shouldn't still be possible.

Okay but what if you made it stupid instead

Fuck everything I've said up to this point. It's all absolute garbage. Purge it from your mind. The best hacking rules are the ones that emulate all the dumbest Hollywood tropes and misconceptions you can think of. You get a bonus on your rolls for every additional pair of hands on the keyboard. Difficulty is measured in the number of rapid pop-ups on the screen. Every process has a loading bar with a percentage for some reason. You have to manipulate a bunch of 3D polygons into a certain configuration (I recommend you literally hand the player a Rubix Cube, or maybe collect a bunch of little hand puzzles so you can keep switching it up on them). To find and exploit bugs, you have to go into a virtual reality space inside the computer and run D&D combat using a virtual avatar against a bunch of pixel-y monsters with "glitch" powers. And there are summons called "viruses" and "worms" you can use like magic. If you want to retrieve information, it's always in visual form, and every time you try to retrieve more you have to verbally shout "ENHANCE!"

Thanks for sitting through all that. As a reward, I got you this present.



  1. Optional Rules 3 & 4 seem like they'd pair easily together, essentially a usage die for Detection based on age. An ancient device uses a d20 while the most cutting edge uses a d4.

  2. I have some IT security background and I 100% agree on your approach. Thanks for this wonderful article. I only have a few remarks. Sorry if it is obvious I haven't yet read your actual rules.

    First the fact that a device is connected to the web doesn't the importance of the access point location. You can think of a network as a point crawl. Some security measures act on every nodes, but other only act at the frontier of the system. So if you try to hack from your home everything will be more difficult. It will be easier to do it from an access point inside the building, and even easier inside the server room.

    Second thing is the logs. You may assume that a modern door keeps a log of all identities that have used it in the last month. Everything is hoarding as much data as possible for various reasons.

    Your 3rd rolling option is the best one for gameplay but also for realism. Hacking is an exploration and escalation process. You often need to take shots in the dark and have some luck to progress.

    Last there is one type of consequence that I think you missed. The system might collect enough info about the attacker that it might be able to lock him out of the network. (Maybe it is included in what you call a Response)

    1. Oh hell yeah these are just the eyes I needed on this post. I'd love for you to read the rule document and then revisit these thoughts, I think you'll find that most of that is addressed in them. At the same time, I also really would love to hear more feedback like this from someone with more knowledge than me.

    2. I am not a security expert but reading the rules is exactly what I plan to do as soon as I can!

  3. I have read the rules and I find them awesome! I would probably use them almost as is. I am not sure about the code preparation option. It seems hard to use for what it does. I personally use a FitD system close to CBR+PNK so I would probably allow network knowledge to grant increased effect or reduced threat and have threats advance a detection clock but I can see that it is not a solution for other systems.

    In the additional ideas I like the priviledge one the most. I don't feel it adds too much complexity and can be omitted at first to allow the players to get used to the system. Then introduce it to present more options to them: should they stay in the say zone and grab whatever is there? Or should they go directly to the secure area? Security is hard and valuable resources are often left in the wrong zone.

    The exemples at the end are great!

    Honestly I don't understand how Cyberpunk RED failed to provide something like this.

    1. IMHO CP Red even failed in ways its predecessors excelled, so I was already over it when I got to the hacking rules.

      Anyways, great stuff, Dwiz! Some really good thoughts there that will come handy when the cyberpunk game I'm working on with a friend gets to the digital stage so to speak.