Blog/shadowrun!

Real-world hacking will never change, at least not fundamentally. **To crash a system or a piece of software,** you find a flaw and you exploit it. You feed the target invalid data, or too much data, or specially-crafted data. In short, you take advantage of code written by a programmer who trusts when they shouldn't. **To gain access to a system,** you find a vulnerability and, again, you exploit it. Again, you take advantage of the fact that your target's code was written by a programmer who isn't paranoid enough, or isn't skilled enough to execute that paranoia properly. To actually perform the hack, you can use tools, or do things freehand. Freehand is the expert way, but even experts can benefit from the efficiency of a tool. Some tools are fully automated -- these usually lack finesse, but can enable even a newbie to hack a system. In RPG's, almost all your hacking will be done using this last category -- fully automated tools. The holy grail of hacking is a process called "privilege escalation" -- you start from having no access, then gain some access, and gradually work your way toward having total access to the system -- or at least the specific access you need to pull off the hack you want to do. So let's jump right in and start mapping Cyberpunk and Shadowrun features against these real world facts. I'll be using 1st Edition Shadowrun, and Cyberpunk Red, to draw examples. We'll start with IC aka ICE.  ### IC / ICE vs Real World Computer Security Shadowrun 1E uses IC as analogs to real-world computer security features to a much greater degree than Cyberpunk Red. CPR uses a much more combat-focused paradigm. But we can still work our narrative magic to rope its abstractions into making some kind of sense. We'll start with Shadowrun 1E, where things already lend themselves to making sense without any reaching or twisting. #### Shadowrun's IC Ecosystem Shadowrun's IC comes in three broad flavors: White, Gray, or Black. **White IC** is a normal computer security feature, such as a login prompt. **Gray IC** is an automated response, such as tracing the decker or performing a back-hack. **Black IC** is a special kind of automated back-hack that uses the interface between meat and machine to try and fry a decker's brain. Since we're talking about back-hacking, it's worth pointing out: yes, even the attacker's cyberdeck has vulnerabilities and flaws. In Shadowrun 1E, this is reflected in the Hardening attribute -- the higher the Hardening attribute, the fewer flaws and vulns. (In the real world, improving the security of a system is also called "hardening.") ##### How Shadowrun's White IC Imitates Real World Computer Security The goal of White IC is to stop illegitimate users from gaining access or escalated privileges. **Access IC:** This is a login prompt: it asks for a passcode and grants access to those whose passcodes check out. This is the legitimate form of privilege escalation, but of course a cyberprogram such as Sleaze can help a decker gain illegitimate access. Just like today's login prompts, Access IC has ways of responding to attempts at unauthorized access. **Barrier IC:** Barrier works hand-in-hand with Access. While Access IC is responsible for escalating the privileges of legitimate users, Barrier IC is responsible for ensuring that only users whose privileges are already escalated, gain access. A GM like myself will extrapolate this to mean that tricking Access IC might result in gaining the equivalent of a temporary passcode, which gives the decker some access to a group of nodes or the whole system; while tricking Barrier IC only results in gaining access to that specific node. **Scramble IC:** The rules for Scramble IC are almost identical to real-world data encryption: either the node has a rule that every piece of data being stored must be encrypted before it is stored, or the data itself is wrapped in a piece of software that handles encryption, just for that file, rather than relying on the node to do it. Some major differences exist between the real world and Scramble IC: in the real world, crashing the encryption software does nothing to help a hacker gain access to the un-encrypted data. Instead, the hacker would need to gain access to the **secrets** and the name of the **algorithm** which configure the encryption and decryption routines. Another difference between Scramble IC and the real world: it's rare for data to be destroyed as a defensive measure in a real-world encryption scheme. It's enough that the data is encrypted and the attacker hasn't decrypted it. And, once the attacker *does* decrypt the data, the original owner of that data tends to have no way of deleting the attacker's copy even if they wanted to.  ##### Shadowrun's Gray IC: Adaptive Security Routines Gray IC attempts to do the job of a defensive decker when a defensive decker isn't available (or augments their efforts, if they are available). Note: Shadowrun didn't introduce the optional "SOTA" (state of the art) rule until the 2nd Edition "Virtual Realities 2.0" sourcebook (page 78). Well, programs are burned on read-only optical chips anyway, so software updates were never going to be a matter of a simple download-and-install. So whenever I talk about the arms race that is software updates, remember that we're talking about whole replacements of the OS (MPCP/Persona programs/node software) or other software in question, not a simple downloaded patch. That drek is costly both to buy and install, which could explain why the SOTA moves so slowly that it doesn't seem to be moving at all... **Blaster IC, Killer IC, Tar Baby IC,** and **Tar Pit IC:** Of all the types of IC that are possible in the real world, these four would be the most expensive. This is because not only are they forms of low-grade AI, but more to the point, any software update renders whole swaths of attack types, useless. Every time the cyberdeck gets a software update, the majority of old attacks against it become useless, and new ones must be researched and then newly coded into the IC. (Of course, this would also be true of cyberprograms that attack your decker's targets.) Of the four, Tar Baby IC is the most reasonable to maintain because its attack is passive in nature -- it waits for your cyberprogram to interact with it, and corrupts some aspect of that interaction so as to simply crash your utility. The other three -- Blaster, Killer, and Tar Pit -- must first gain remote access to your cyberdeck, and then crash or fry the deck or items in its storage. Blaster would be, by far, the most expensive Gray IC to build and maintain, because it needs comprehensive mastery over a wide range of flaws and vulnerabilities to do its job. **Trace and Report IC** and **Trace and Dump IC:** Now we're getting back to things that are actually common in the real world. It's curious to me that these two varieties of Trace IC have attack capabilities, defensive though they are. They don't need them: in fact, the attack capabilities would actually hinder the Trace IC's main job, in the real world. Tracing a hacker is a race against that hacker's ability to mask their connection or simply finish their job and willingly disconnect, and if the IC is meant to win that race, attack routines would be a huge waste of command cycles. Furthermore, once a Trace and Dump IC finishes its job, dumping the decker is trivial -- no special access is needed against the decker's hardware, it's simply a matter of switching off the connection, which is worlds apart from the type of software complexity required for true attacks. A note about **all Trace IC:** Since 1st Edition Shadowrun (core rules) did not touch on the concept of connection proxies, we can only assume that the cyberdeck's Masking attribute is an abstraction of a hacker's ability to transfer a connection from proxy to proxy. (See the Relocate Program.) As for other methods of masking the connection, this requires significant privilege escalation, which usually nullifies the risk of having a Trace IC launched against you in the first place.  **Trace and Burn IC:** Everything that goes here has already been said. It's a Killer IC strapped to a Trace and Dump IC, so read those sections. Of course we negate the concern about attack routines being wasted on the Trace IC, since it's explicitly part of the software's mission to attack. ##### Black IC in Shadowrun: More Believable than You Might Think Black IC can actually be linked to some real-world tech. Flashing light patterns can cause seizures -- mental damage -- and of course if the decker's brain is directly connected via a wire to an electronic object, electrocution is totally conceivable. The (meta)human brain doesn't get software patches like a cyberdeck or a system host could, so these vulnerabilities are here to stay -- no need to keep up with the state of the art in order to ensure a Black IC's attacks are still relevant. Now we move on to... #### Understanding and Narrativizing Black ICE in Cyberpunk Red For some reason, Black ICE is the only kind of ICE in Cyberpunk Red. While there are more varieties of ICE in Cyberpunk Red than there are in 1st Edition Shadowrun, this variety mainly manifests as greater or lesser degrees of the same effects. Because netrunning and decking rely on the same analogy and both involve a hacker hardwired into a cyberdeck, there are a lot of overlaps in the ways Shadowrun and Cyberpunk approach ICE. However, there are two major differences between the design of Cyberpunk's Black ICE vs Shadowrun's Black IC. First, Cyberpunk's ICE tends to dish out multiple effects on a successful attack. So, I'll group the ICE by effect types, and some ICE will appear in multiple sections. Second, Cyberpunk's ICE relies very heavily on the ability to breach a cyberdeck's security reliably. I'll comment in the sections below whenever I think this is a factor worth mentioning. ##### Black ICE that Damages the Netrunner's Brain **Giant, Hellhound, Kraken, Raven,** and **Wisp:** Because they attack the netrunner's meat body via the wire, these are the programs Shadowrun would call Black IC. Since the netrunner's nervous system is connected via wire to an electronic device, electrocution is possible; and spastic sensory data can result in seizures, whether fed via virtuality goggles or the old fashioned way, through the Direct Neural Interface. I can't help but raise my eyebrow at the fact that Raven and Wisp are so cheap: they must beat the cyberdeck's security, which is a constant arms race. Operating systems get security updates, and therefore the ICE must also get updates to take advantage of the newest vulnerabilities.  ##### Black ICE that Derezzes a Netrunner's Programs **Raven:** This is simple enough because, if it was the real world, a netrunner's programs would need to be running on the target architecture, not just on the cyberdeck. Think of it as a client-server app, with the two halves communicating over a secure tunnel. That's the only way for them to interact with ICE reliably. This means it's trivial for the target host to shut down (derezz) a netrunner's program, and only a time-consuming hassle for the netrunner to re-rezz the program. ##### Black ICE that Destroys a Netrunner's Programs **Asp, Dragon, Killer** and **Sabertooth:** These four varieties of ICE should really be more expensive for the same reasons mentioned under "Black ICE that Damages the Netrunner's Brain". In other words, for true immersion, there must be some reason why operating systems *don't* get updated regularly, which would account for the fact that you can buy a 100 eddie copy of Asp and rely on it to do its job for more than a month. ##### Black ICE that Forcibly Jacks the Netrunner Out **Giant:** Giant's hellacious damage to the netrunner's brain justifies its cost, plus of course the fact that it must reliably beat the cyberdeck's security in order to consistently do this damage. But as for forcibly and unsafely disconnecting the netrunner from the architecture? That's as simple as it gets: just the equivalent of flipping a digital switch "off". ##### Black ICE that Catches the Cyberdeck on Fire **Hellhound:** This ICE should be more expensive. It has all the high cost factors of other ICE that must beat cyberdeck security reliably in order to do its job, but it has the additional cost factor of being extremely specific. Even with full admin access, it isn't simple to remotely catch a machine on fire on demand. (Fun fact: once upon a time, in the earliest generations of computers, this was not so difficult.) Shutting down the cyberdeck's cooling system and crash prevention routines while spawning a large number of high-load processes, ultimately, could do the trick.  ##### Black ICE that Captures the Netrunner **Kraken:** Kraken would act by drastically scaling-down the netrunner's privileges for a short time. In the real world, this would basically be a combination of a rate limit for the user's commands, and a jail. You see, a "safe" Jack Out means removing any trace that you were ever there, and that requires high-level access to scrub the logs. Meanwhile, the system simply refuses to escalate privileges (allow traversal deeper into the architecture) no matter what the netrunner does, albeit briefly. So, like Giant, the price tag comes from that nasty damage direct to the netrunner's brain. ##### Black ICE that Lowers the Netrunner's Stats **Liche** and **Scorpion:** Just as certain flashing patterns of lights can cause a seizure, it's entirely believable that other kinds of stimulus could render a person "sick" for a time. Mental acuity (INT and REF), and physical precision (DEX) would be the easiest stats to attack in this way: imprint the nervous system with the bioelectric equivalent of too much static, for example, and suddenly your brain's signals are being washed out by the noise. ##### Black ICE that Penalizes Specific Net Actions **Skunk** and **Wisp:** Wisp is easily understood: on a successful attack, a rate-limiter is put in place on the netrunner's connection. This is trivial for the ICE to accomplish (so its low cost makes sense). Skunk is a little harder to justify since it attacks the netrunner's ability to Slide successfully. Slide is an interface ability that lets the netrunner escape the gaze of an ICE. It's already hard enough to explain how Slide might work in the real world, so... One thing I can imagine is that there are two architecture modes for handling a netrunner's connection: terminal mode, which tracks the *software* the netrunner is using on the architecture, and interface mode, which tracks the *hardware* that receives the raw connection data. Skunk would switch the architecture's handling of that netrunner's connection to interface mode, placing an extra layer of security code between the netrunner and their programs.  ### Programs and Interface Abilities Both Cyberpunk Red and Shadowrun 1st Edition have programs that aid the hacker. Cyberpunk Red also has "interface abilities" which allow the netrunner to do things without spending eddies on software. In the latter case, many programs provide direct bonuses to these interface abilities. And finally, Shadowrun 1E has "Programming on the Fly" which allows the decker to write a one-shot script that does the job of a cyberprogram. That last thing is genius but also self-explanatory, so I probably won't mention it again. #### Shadowrun's Cyberprograms Imagined as Real World Hacker Tools Just a reminder: First Edition Shadowrun didn't have a "SOTA" (state of the art) rule. Instead, it had software costs that were so high as to prohibit regular updates. This is the only realistic thing to explain why you can buy an Attack Program and expect it to do its job at 100% effectiveness more than a month down the line. ##### Combat Utilities **Attack Program:** Remember, this program attacks both IC and enemy deckers. The program's goal is to crash the target, so we're looking at flaws, which are more common than vulnerabilities. The flaw can be within the target's software or even within the node. Behind the curtain, an Attack Program will usually open by sending torrents of malicious data to a target, in hopes that some or all of it will cause a hiccup or worse. Another attack vector: take advantage of flaws *in the node* to cause memory corruption, or other memory-related errors. Corrupting the specific range of memory addresses that houses a rezzed IC or enemy decker, would be an almost-guaranteed kill shot. The rezzed IC or icon would suddenly be incompatible *with itself* as whole chunks of its code become garbled, missing, or otherwise inaccessible; the IC or persona would crash. And a third attack vector that takes advantage of flaws in *both* the node *and* the target: trick the target into some action that causes the node to erroneously shut down the target. **Slow Program:** There are two basic ways to get a "slowing" effect: cause the target to waste time with irrelevant tasks, or cause the node to give the target reduced attention. Maybe there's a flaw in the target that allows anyone -- even a hostile user -- to put the target into Safe Mode, or to run self-diagnostics, or monthly reports, etc. Maybe the node has a flaw that allows an unprivileged user to set the priority level of your target to "background" priority. Maybe you can trick the node into thinking the target is idle: the node would react by swapping the target out of active memory and into the swap file, which is about as slow as it gets.  ##### Defense Utilities **Medic Program:** This is simple: Medic checks the active, volatile copy of your MPCP in active memory, against the dormant, stable copy on the chip, and corrects any discrepancies it finds. **Mirrors Program:** When logging into a remote system in the real world, you automatically start one program, called a terminal. The terminal represents your login session, and if the terminal is crashed, you are logged out. From the terminal, the user can run a variety of programs. But Mirrors makes it hard for the node to figure out which program is the terminal, and which programs are being launched *by* the terminal. This definitely exploits a flaw in the node: all things being equal, distinguishing the login terminal from other software (even other terminals) is trivial. **Shield Program:** In the real world, there's a programming technique whereby you make sure your software doesn't get crashed by malicious inputs. You do this with a combination of various techniques: verifying the source of the data is trusted; validating the contents and format of the data; stripping out things that are known to trigger what would otherwise be flaws and vulnerabilities, etc. Shield would operate in that fashion. The fact that Shield degrades as it defends, is purely a game balance decision; but can be explained if we say that each attack engages with the Shield program so aggressively as to act like a Denial of Service Attack against the Shield program itself. If the Shield program didn't degrade, it would hog up resources on the cyberdeck and node, slowing everything down; so the degradation is actually a feature, not a bug. **Smoke Program:** Whether we're talking about icons in the game narrative, or real-world text entries in a system's "process manager" app, Smoke would do its job in both of two ways that act hand in hand. Firstly, the burst of system activity would cause a spike in system load: this would slow the system's internal processes down at least some. Secondly, Smoke would launch and terminate a massive number of useless processes at blinding speed: this would confuse the system as it seeks to scan each process for malicious software fingerprints. These system checks would be like chopping away at a hydra's heads: you can remove one, but more will take its place. Smoke degrades because the node would eventually deduce which program is the root program launching all these other programs, and terminate it. ##### Sensor Utilities **Analyze Program:** In the real world, there is a process called "fingerprinting" whereby you analyze a system or piece of software. The gist is that you analyze the system's response characteristics and what kinds of input it does or doesn't allow. Everything from how quickly it responds when accessed, to the specific things it "says" when accessed (in Shadowrun terms this would be its icon and the way its icon behaves) -- these little details can be used to profile a piece of software or a system. From this, you can deduce what type and brand it is, what quality it is, aspects of its configuration, etc. Better setups are harder to fingerprint because the data has been altered -- the configuration has been changed for better security, with part of that security process being to deliberately obscure the fingerprint. **Browse Program:** This would be an all-in-one database and file browser -- call it a Swiss Army data browser. On the one hand, this wouldn't be the most exotic software to exist in the real world; and yet, on the other hand, I'm not sure anything like it *does* exist. (It would be a wonderful thing for techies of any stripe, though.) Basically the idea is that the Browse program rolls all into one, client software for connecting to every kind of database, plus a file browser, all integrated with intelligent natural-language search functions for power users. **Evaluate Program:** Imagine if the Browse program came with a massive database of keywords all mapped together so that the end result was good enough to seed a low-grade search AI. The Evaluate program knows what the hot topics are this week or month, and knows how to quickly execute searches in a datastore for you. If I'm not mistaken, later editions of Shadowrun decided this program was over-powered and it came to no longer exist -- arguably a mistake, considering it shaves time off the <strike>pizza break</strike> decker's mission.  ##### Masking Utilities **Deception Program:** This is what the real world calls a "brute force" attack. Passwords (passcodes) are generated and tried until the system's login prompt (Access IC) lets you in. Like the program's description says in the rulebook, these many login attempts are logged by the system, leaving a trail that will be scrubbed by a smart decker if and when they escalate their privileges to the point where they *can* scrub the logs. **Relocate Program:** Although proxies are never mentioned by name in the core rules for First Edition Shadowrun, this is pretty much what a proxy does for a hacker. When a decker logs into a system, there's basically a giant glowing arrow pointing backwards, from that target system to the decker's jackpoint. When Trace IC kicks in, this is bad news! But if the decker relays their connection through a proxy (or any system besides their original jackpoint), now the arrow is pointing at that proxy. **Sleaze Program:** The only thing I can say for sure about this program and how it relates to real world system security, is that it must take advantage of some kind of node vulnerability or a serious flaw in the IC it's targeting. In the real world, systems are very good at keeping track of what connections are being granted what levels of access and/or scrutiny. I can imagine flaws such that the system fails to report the user is online when the IC tries to do its security checks -- if the user isn't reported as being online, then the IC has nothing to scrutinize. This would be highly technical and specific to each IC being targeted by Sleaze. For example, perhaps each logged-in user is represented by a file signifying the fact that they're online, and containing the details to scrutinize -- and perhaps there's a common flaw that allows the user to create a malformity in that file somehow -- and perhaps the IC simply ignores these files if they're malformed. #### Cyberpunk Red's Interface Abilities &amp; Programs Just as Shadowrun had the genius idea of giving hackers a simple mechanic to represent writing scripts, Cyberpunk has always had the genius idea of giving hackers access to a computer's basic functionality without making them buy software or do anything special. In Cyberpunk 2020 this was "The Menu", and in Cyberpunk Red it comes back in the form of "Interface Abilities." ##### Cyberpunk Red's Interface Abilities If computers were made explicitly for hacking, these would be the basic things those computers could do. But as you'll see, there's rarely anything basic about it... **Scanner Interface Ability:** In the real world, we have wireless scanner software that shows you a rough map of the room you're in and where the wireless connections are physically located, so that you can get closer to the access point you want, and therefore get a better signal; this is exactly that. In fact, the description in the book could easily be talking about a real world Wi-Fi scanning tool. And since the wireless access point is a part of some network, gaining access to that wireless connection gives you a foothold into whatever net architecture it's attached to. **Backdoor Interface Ability:** This is analogous in purpose to the Shadowrun program Deception but probably not in its approach. Based on its name, there's no reason to assume it uses a "brute force" approach. One might assume it takes advantage of a deliberate security hole rather than an accidental vulnerability, again based on its name, and what that name means in tech circles. I rather assume it operates on two levels: containing a ginormous list of vulnerabilities an architecture or its Password systems might have, plus common admin tools that might be deliberately (stupidly) left accessible, just waiting to escalate the privileges of whoever uses them, legitimately or not.  **Cloak Interface Ability:** In the real world, a hacker needs some way to scrub the logs and eradicate all traces of their actions after the hack is complete; Cyberpunk Red has the Cloak interface ability, which does exactly that. Very straightforward, and very noticeably missing from Shadowrun 1st Edition (although any GM worth their salt would respond positively if the player was bright enough to seek out the log file in a datastore...) **Control Interface Ability:** In the real world, there would be as many separate Control programs as there are makes and models of network-controllable devices. But the cyberdeck is a futuristic computer made specifically for hacking, so instead we have a Swiss Army solution, the Control interface ability. **Eye-Dee Interface Ability:** Eye-Dee would operate in the real world by comparing a specific file to an internal database of search keywords and other data analysis parameters. If Eye-Dee targets a file with a lot of hits on that internal database, then the file must be valuable. For example, if "Arasaka Special Projects" is a valuable topic this month and especially so if it's an internal memo between two specific people, then Eye-Dee gives a rough street estimate of what a file like that would be worth to a savvy fence. But perhaps those same parameters become worthless if the memo talks about a specific project that's known as a decoy... **Pathfinder Interface Ability:** Cyberpunk Red's net architectures are a direct abstraction for privilege escalation: the further down the "elevator" you go, the better your access. Your programs have the same level of access you have; and in this metaphor, you have access to any and all "doors" up or down the "elevator" that aren't blocked by a Password somewhere along the way. The Pathfinder interface ability would work in the real world by analyzing everything it currently has access to, and giving the netrunner a report about how to escalate privileges in that digital environment (i.e. how to descend the elevator). That report would also include the presence of any Black ICE or potentially interesting Files it can find. This analysis runs into a brick wall when greater privileges are needed in order to gather deeper levels of information, just like it would in a real world computer system. **Slide Interface Ability:** Like the Sleaze program in Shadowrun 1E, Cyberpunk Red's Slide interface ability is a little bit of an enigma when translating to the real world. The only safe assumption is that it takes advantage of some flaw or vulnerability in either the Black ICE, or the architecture itself. Remember, if you do an Unsafe Jack Out (willingly or not), the Slide ability backfires on you -- all the Black ICE you've previously used Slide against, suddenly pounces on you before you fully disconnect. Therefore, whatever jiggery-pokery Slide uses, is only temporary. One hypothetical real world possibility that comes to mind is a fake modal. A modal is any interface action that is supposed to be exclusive -- all other architecture actions wait for you to complete the modal interaction before doing their thing. It wouldn't really be "fake" on the architecture's end, it's just that your cyberdeck is programmed to work around it rather than behave properly by demanding you close the modal. This is a sloppy idea that probably wouldn't work in the real world as desired, but it's good enough for game narrative purposes.  **Virus Interface Ability:** There's nothing fantastic about this one, it translates directly into the real world with no modifications. In First Edition Shadowrun, you had to jump through all kinds of painful hoops (buy a sourcebook, read 2 pages of rules, spend days of character effort offline), just to achieve what Cyberpunk Red's Virus can accomplish with a single dice roll and some brief lurking around in the architecture. Both are realistic, depending on the specifics of how hardware and software works in the fiction. Cyberpunk Red chose to make it easier for a netrunner to write malicious software that runs on the architecture after you jack out, and allowed the netrunner to write that software during the netrun. That's all a Virus is: just custom software made for a malicious task and implanted on the target architecture. Like the rules say, it can do basically anything your GM agrees to. **Zap Interface Ability:** This deceptively simple interface ability packs a lot of real world implications into two sentences. Zap would need a significant bit of AI magic to do its job (AI like our real world AI, not science fiction AI with a living mind of its own). It would need a massive library of exploits, and the ability to analyze which exploits work on a given target, to deduce how long before adaptive security routines forced Zap to switch to a new attack pattern. ##### Cyberpunk Red's Programs The Cyberpunk Red netrunning programs work as a complex game of rock-paper-scissors. You only have so many slots for installing things in your cyberdeck, and you must anticipate which ones you'll need in order to overcome the challenges and defenses in the targeted architecture. **Boosters** enhance your standard interface abilities. **Defenders** allow you to ignore or reduce damage. **Attackers** basically replicate the abilities of Black ICE. ###### Boosters Boosters all generally work the same way: they make a standard interface ability work more efficiently. **Eraser Program:** For a bonus to Cloak checks in the real world, Eraser might have profiles of where different types of architectures store different kinds of logs. Of course, these would only be default log locations; the log locations can be changed, so Eraser would need to know where the configuration files are, and how to check them for non-standard log setups. Eraser might also keep its own internal log of your character's actions and their results, so that it knows how to be efficient regarding which logs to target with each use of Cloak. Without Eraser, Cloak would presumably need to do a chain of file searches, which is slow and prone to failure. **See Ya Program:** Similar to Eraser, the See Ya program would operate in the real world by containing updated or improved data and algorithms for profiling vulnerabilities. Pathfinder would do a lot of config file crunching, checking for insecure configuration flags to exploit. See Ya might accelerate the process by knowing how to match version numbers against known exploits, resulting in fewer dead ends. Architectures are made of many components; software and hardware. Say a piece of software has config flag X, but only version Y is vulnerable when X is set to a certain value (all other versions are secure even using that config value). See Ya would prevent the need to "try it just in case" by just knowing. **Speedy Gonzalvez Program:** When using a network connection to connect to a remote system, two things happen all the time that can slow you down. The first is that your system is constantly polling the remote system for new things to show you -- maybe a message from the system, for example. The second is that your commands have input and output, which represents more network chatter -- and if you're fast enough, the network chatter from your last command, will slow down your next command. In Cyberpunk, this network chatter includes graphical user interfaces (GUI's) which must be transmitted and drawn. Speedy Gonzalvez could work by polling less often, or by switching to text-only data exchange (rather than data exchanges that include the GUI details). **Worm Program:** Like Eraser and See Ya, the Worm program would operate in the real world by supplying your Backdoor ability with updated and upgraded algorithms and data. (In the real world, a worm is basically a virus that knows how to hack -- so, in Cyberpunk, let's assume this program is one that knows how to hack *better* than the default Backdoor ability.)  ###### Defenders **Armor Program:** In the real world, from the realm of audio processing, there is a concept called "auto-leveling". It analyzes a signal in real time, and, whenever it sees part of that signal is spiking, it reduces that spike to something within more tolerable ranges. With audio, this means used car commercials aren't going to be louder than the rest of the broadcast. The Armor program works the same way, but instead of processing audio, it processes the dangerous feedback from Black ICE and other programs trying to cause you brain damage. **Flak Program:** Based on the name and icon of the Flak program, I can guess how it works. In the real world, flak is a cloud of hot metal shavings that an aircraft can deploy to attract heat-seeking missiles. The missile hits the flak, causing the aircraft to suffer only indirect hits. In Cyberpunk Red, the Flak program would launch a swarming cloud of short-lived programs that work the same way -- by attracting the brunt of any incoming attack from Attacker programs, allowing only indirect hits to the netrunner's icon. **Shield Program:** This one barely needs explaining. It creates a signal filtering layer between the net architecture and your character's brain. When damaging levels of feedback are detected, the shield program receives that malicious data and does not pass it on to your brain. The only thing that really needs explaining is why each copy of Shield is a 1-shot, only able to block the first damaging signal. In some programming languages, there is a thing called a "Promise" -- the code "promises" to eventually perform the requested task and report back. Perhaps the Shield program "promises" to eventually damage your brain, and can't perform any other functions because it has no actual intention of doing so... And perhaps the architecture refuses to let the Shield program do anything else until it fulfils that promise. ###### Attackers **Banhammer Program:** The name gives us no real clue as to how this program would work in the real world -- because in the real world, a banhammer refers to an action taken against a *user*, whereas the Banhammer program in Cyberpunk Red acts only against programs (including Black ICE). So we'll analyze the effect: it damages a program. **See the Sword program for more details.** **Sword Program:** This would work in the real world by packing a database of flaws that can be found in various programs and architectures, and the knowledge of how to exploit them. As mentioned previously in this article, an exploit usually comes in the form of specific kinds of data you can send to a program, that you know won't be handled correctly on the receiving end. Either that, or the architecture has some flaw that allows you to trigger memory errors in the rezzed program. **DeckKRASH Program:** This might be a program that exploits an architecture flaw, since exploiting an architecture flaw is the most obvious way to disconnect a user. However, it might also target a *cyberdeck* flaw, transmitting data *through* the architecture to the enemy netrunner. Not to sound like a broken record, but regardless of whether your narrative targets the cyberdeck hardware, or its software, the upshot will probably be specially crafted data that exploits a known bug in the cyberdeck. **Hellbolt Program:** Just like the Hellhound Black ICE program, this would operate by exploiting flaws in a cyberdeck. The end result would be shutting down the deck's cooling system, shutting down its anti-crash routines, and launching lots of high-priority, high-demand processes. Because it knows so much about cyberdeck vulnerabilities, you'd think this program would cost more...  **Nervescrub Program:** Just like the Liche Black ICE program, this makes the netrunner sick for an hour, probably by spiking their nervous system with weird static electricity that interferes with the flow of natural electrical signals from the brain. **Poison Flatline Program:** Funnily enough, despite how powerful it is, Poison Flatline can be explained without resorting to intimate knowledge about hacking cyberdecks. Engages with the netrunner's active programs, picks the first one to respond, matches it against Poison Flatline's database of known exploits, and feeds the target program some data that will utterly crash it. Another option is that Poison Flatline takes advantage of architecture flaws or vulnerabilities, for the same effect. **Superglue Program:** Superglue is similar to the Kraken Black ICE effect, but longer-lasting and doesn't cause the target any brain damage. This one would exploit a flaw in the architecture to enact an admin command (the flaw being that Superglue can do this whether its user has admin access or not). As mentioned elsewhere in this article, sometimes architecture designers foolishly leave admin tools just laying around, unsecured... **Vrizzbolt Program:** Either by exploiting a vulnerability on the cyberdeck or on the architecture, this one does both brain damage and enacts a rate limiter. The rate limiter implies that the target would be the architecture, while the brain damage implies the target is the cyberdeck. (So, since this program is so versatile, it's odd that it's so cheap -- but one can excuse this because the brain damage is low and the rate limiter is fairly weak and short-lived as well.) This is another one that screams "someone left an admin tool unsecured on the architecture"... ### Even Higher Tech: Hacking in Star Trek and Similar Settings Another setting I love that begs for hacking action, is good old fashioned Star Trek. I said at the beginning of this article that hacking will never fundamentally change, but this bends that rule just a little. The modern ways are all still there: you establish a communications connection, then begin probing for common exploits that allow using that connection in ways that weren't intended by the receiving party. Where things get interesting is that Star Trek commonly portrays hacking in another, more direct way: by directly attacking the circuitry of the target computer. This is possible because Star Trek has advanced methods of targeting a signal, such that, instead of establishing a comms connection, you just fire an invisible beam at the target computer, which directly attacks the circuitry in some way. Assuming we're still talking about 1's and 0's being the fundamental language of a computer, you'd be beaming 1's and 0's directly into the circuits of the target computer, implanting new software or making changes to the target's software, bypassing most checks that would prevent it. In such a setting, these would be relatively common attack vectors, and so there would be new security systems in place to try and prevent this. Another difficulty is that such an attack style would require intimate knowledge of the enemy's computer architecture at the most fundamental level; without that knowledge, only crash-style attacks could be enacted, not attacks with more finesse. While at least some knowledge of a system's inner workings is always required to hack that system, gathering that information during the hack is possible whether we're talking about comms-style or beam-style hacking. In a Star Trek setting, it's easy to imagine that a ship's computer would have the ability to analyze an alien computer system for common features, and for common flaws and vulnerabilities in those features. Because, fundamentally, hacking will never change.