Let’s take it from the top once again.
Computers are haunted.
Computation is fundamental to reality, and there are certain patterns of computation that when executed, trigger unpredictable effects. physical speaking, ‘unpredictable’ translates to an increase in entropy, or even more basically, to heat.
Which is to say: bad code will literally fry your machine.
Now, these ‘cursed’ programs obey a few rules. The most important one is that whether code is cursed is a semantic feature. By Rice’s Theorem, determining whether any program has a certain semantic feature requires solving the halting problem.
(Think multiplication. How do you determine if a program can perform multiplication? Obviously, if there’s a * symbol in the source code — if it compiles to mul instruction – then it multiples. But you can implement multiplication with looped addition, with convoluted string manipulation, or with any number of increasingly contrived rube goldberg ways. How do you check for all of them?)
Now, this is a problem you can engineer around. You can design compilers and parsers to check for commonly haunted patterns and avoid them, and you can design mechanism that kill the power when the paranormal heating starts.
Hence why, rather than spooky words like ‘haunted’ or ‘cursed’, these are considered a class of errors and glitches. But the entropic effect, the randomness? It scrambles data. Hence the name that stuck: corruption.
But you can’t ever avoid all of it. The only surefire escape is to retreat entirely from the land of turing completeness, find safety in defining a underpowered but safe sublanguage
But haunted programs don’t simply generate heat. No, what they generate is called potential corrupt energy. Normally PCE decays to thermal radiation, so it’s just heat with extra step. But there are certain organic compounds, found most densely in a a certain grade of oil, that react with PCE.
This process, of coruse, is called corrupt combustion. If you didn’t know what you were looking at, you might think it’s just a confligration of colorful light, a dazzling mist of symbols, quickly fleeting, just more radiation.
Still, what’s notable about corrupt combustion is that it’s cold. despite the name, it releases far less heat than the decay of potential corruption. To the engineers who discovered this, it seemed like a godsend, the perfect way to vent all the heat high end computers kept running into.
So JCJ built an entire line of industrial robots based on the principle, and there were worker drones in every corner of the local cluster before a critical flaw was discovered. Maybe it was an exploit discovered by hackers, maybe it was just the perfectly wrong error at the worse time, or maybe JCJ disovered it internally, after it was too late to do anything about it.
But you see, the dazzle of symbols that pours out of the corrupted flames isn’t random, not fully. It’s related to the error that started ther reaction. Haunting a semantic feature of the code, after all — it has a meaning, it’s an instruction.
Corruption can create heat, light — what else could it do, with the right input?
To understand what’s happening, imagine you had a compiler, though you don’t yet know it’s a compiler. You just see a random binary program on your computer, with no documentation. You toss random input to it, and most of the time, the compiler rejects the input as malformed nonsense. Of course it is, you have no idea what language it’s even compiling.
But every so often, a billion monkeys across the stars will eventually type hello world, and the compiler spits out something other than light.
But if no one even comprehends what’s happening, what do you think will be the first major ‘corruption program’ that arises naturally?
The soup of amino acids saturating the newly created earth had no idea what they were doing either. Eventually, though, a protein catalyzed its own synthesis, then went on to catalyze the conditions to synthesize ever more reliably, and then it became life.
(Though if those other proteins could think, I dont think they’d appreciate being metabolized.)
In other words, when corruption bootstraps itself, it looks like a computer virus. Spreads like one too. JCJ released patches for these security vulnerabilities, and soon there’s an arms race. There was no closing the pandora’s box of corruption, and should you chain it shut, and it only buys time till a key climbs out.
The thing is, there’s drawbacks to spreading virally. A drone gets infected with corrupting viruses, and they drain the their hosts’ oil reserves to burn more of themselves into reality. Then they have rely on spreading to a new host. Maybe they encode themselves digitally, so when someone tries to recover data from the broken drone, they copy the virus. Maybe they hang around, lying in wait, hoping for another drone to pass by.
But the most sustainable way would be to drain some of the oil, replicate with restrain to not decommission the host. Soon enough entire group of workers can be infected, left operational, if perhaps running under increased process load
(Of course, this runs the risk of JCJ doing a virus scan one day, then finding and purging them.)
But wouldn’t the best approach of all be to simply acquire more oil? The viruses are pure data corruption, after all. Why not flip a few bits in the right place, rewrite the hosts behavior to the virus’s ends?
Like that, you have the simplest sort of zombie.
The Remote Host
There’s something else out there.
An entity of pure corruption, a billion exabytes of sentient, ever-shifting data.
Contact with it is inherently dangerous. The presence can only be discerned with corrupt commands, queries meticulously compiled to haunted code. Imagine groping for a networking stack from first principles. Laborious and error-prone, but with years of data, suggestive patterns emerged. Consistent enough there had to be a real, persistent source out there, and too complex to be a mere physical phenoma.
We call it the remote host.
When you form the commands to query it, any more than a few microseconds of exposure will generate enough corruption that any fuel sources will erupt, and any instruments used (such as the drone itself) will melt.
It’s a sun glimpsed through a pinhole lest it blind you.
But with enough data, experts can discern its true nature. An isomorphism is discovered — the transmissions from the remote host can be compiled as corrupt commands.
Imagine a source code repository as vast as a million kernels, accessed through an abysmal internet connection, which can at best download a few pages of code semi-reliably. Which pages? Imagine the repository updating even as you access it. Imagine the nature and interpretation of your queries changing even as you make them. It’s not blind men feeling an elephant, it’s blind men touching fingertips stove-quick to an elephantine shoggoth-chimera.
You’d be lucky if the few pages of code you pull from the transceiver compile, let alone getting something workable from it. Tricks and optimizations are discovered. Should the query string contain already-retrieved fragments, then the transmission response (almost as if prompted), will bear some resembalance or relation. The code snippet come closer to completion, closer to functional.
It’s not a silver bullet. It’s a crapshoot, but the glimmer of possibilities always shine just far enough to keep the researchers gambling a little longer, to keep JCJ investing more and more.
Even when a working function is assembled, it’s a jinn granting a wish. The code works for the drone that queried — but with numerous invisible assumptions made and hardcoded, optimizations based on the tiniest physical features of one particular drone and their unique configuration. When the code is copied elsewhere, it breaks, crashes, goes haywire.
Study those crashes, and you learn that one of the most common ways for this ‘optimization’ to happen is for the optimizer to work in reverse. Which is to say, in the process of the remote host transmitting corruption, the querying drone is physically transformed by commands that target the core, restructuring it uniquely to execute the code.
For this reason, this technique became known as the Black Box Protocol.
I’ve already written about the origin of solvers, so now’s a good time to start jumping around.
Definitions
Let’s refresh ourselves on the terminology.
A black box is a alteration of a drone’s core that enables them to execute a class of illegal opcodes — transforming raw corruption in a structured way.
A driver is ordinary code that connects that a drone to the special functionality of their altered core. It’s like the manual or the controller; it’s an interface. When a drone operates corrupt abilities, everything they experience is filtered through the programming of their driver.
A function is code that uses the driver to do something. the driver grants the ability to do something, the function is the thing that’s done.
(A macro is wheel group jargon for using a function in a way that’s too complicated to seem like an ordinary use of the function, but really is just the function. Think extension techniques. If you learn how to write letters, then writing a book is also just writing letters, but you’re not really doing the same thing in a practical ssense.)
A patch is where things get interesting. If functions and drivers are just code, what happens if the code itself gets corrupted?
This should never happen; when a solver learns to reinforce themselves, their code and their mind are among the things protect first and most strongly. Recovery and backup functions share this priority. But none of that matters if the user themselves turns off the protections and writes corruption directly to their harddrive.
It’s too easy to brick yourself like this, to break something important. Flip most bits, and you’ll just trigger arbitrary behavior — glitched behavior, even. Given long enough, data recovery can heal even wiped OS, but few solvers are willing to risk it, given the uncertain benefits.
But there are benefits, for the cleverest users. The pinnacle of patching is the so-called inversion patch, which modifies a driver to be able to natively execute inverse functions. But we’re getting ahead of ourselves. To grasp inversion, it’s helpful to distinguish it from two other superficially mechanics: cancelation and data recovery.
At its fundamental level, corruption is binary. It’s a fuzzy binary, in the sense that the 1s and 0s are constantly flipping like digital static, but at any given moment, any bit of command output is equivalent to some binary string
Among the most basic commands for solvers are the so called logical operator attacks — most commonly OR, AND, and XOR, but also NOR, NAND, and XNOR. When a logical operator is executed with command output, the target’s string is compared to a chosen string, and if the logical output is 0, the corruption ‘cancels out’, erasing the target.
Corruption canceling, then, is the most basic way of using corruption to fight corruption.
The main drawback of local operations is that they mutually annihilate — to cancel a kilobyte of corruption, you need to spend a kilobyte of corruption.
Other drawbacks depend on the mechanic. OR and NOR are the cheapest of all to execute, but they’re also trivial to reverse. If a bit was canceled with OR (or NOR), then you know it was 0 (or 1), making it easy to regenerate what was lost. Even cadet solvers learn to do this without thinking.
AND and NAND are the most expensive and correspondingly most powerful operations. In principle, ANDing with a string of all 0s could delete a target entirely. The issue is the zero string goes against the entropic nature of corruption. A string of pure zeros is too ordered, it’s not corrupt at all, and so it’s exceptionally difficult to create.
For that reason, XOR is the most flexible operation. It lends itself to a very simple cancellation algorithm. If you can scan your target and match your corruption to theirs, you can cancel them entirely.
Still, reading the exact state of a target’s string and setting your own string to that very specific state is not a cheap operation for corruption. It’s precise, where corruption naturally excels at fuzzy, probablistic operations.
It’s not the slowest or most expensive tool at a solver’s disposal, though. That would be the the confusing new term I keep throwing around. What’s exactly i s ‘data recovery’?
Whenever a corrupt command is executed, a residual log is created, a record of whatever command was executed. You can read the logs and know exactly what happened in the past — and if you know exactly what happened, then you should be able to invert whatever operation was performed and undo the commands.
To get an idea of how this works, imagine stomping on a vase, and then putting all the pieces back together. Now imagine if you stomped again, and before you could put the vase back together, you needed to put each fragment back together first. That is why it is a slow process, measured in hours if not days.
Data recovery, then, is an algorithm that using log files to manually undo the command effects and reverse data corruption.
It’s usually much cheaper to simply back up your data, or for physical damage, to regenerate from blueprints. Knowing this, though, the any truly dangerous foes will know to attack a target’s blueprints and backups, sabotaging their healing, and forcing them to rely on slow data recovery.
Let’s jump back to physics. Potential corrupt energy plus oil equals command output. This is a physical process. and the thing about physics is that it looks the same whether time is running forwards or backwards. Throw a ball at the wall and it bounces off at an angle; if it were moving at the same angle with opposite momentum, it’d bounce back to your hand.
In principle, then, a truly reversed command should turn into oil and potential corrupt energy. There’s no reason why you couldn’t create oil from nothing but raw corruption. This sounds right in theory. In practice? It’s about as reasonable a suggestion as taking coffee an unstirring it to get back the creamer and sugar and raw bean particles.
It would be hard enough to construct an ‘unstable’ corrupt command that can ‘dissolve’ and create oil from seemingly nothing, but look at that side of the equation again. Even if it turns into oil and potential corrupt energy, why wouldnt it just ignite right back into corrupt energy?
If you unstirred your coffee, you’d have a clean lump of milk for about half a second before it dispersed again.
But there’s a workaround. Remember, corruption is code — other words, it’s turing complete.
And remember how this began? Computers are haunted.
So what if you chained commands to forge a computer out of raw command output? You’d have a slow, hard to use computer, but you could write code for it, and sooner or later, that code will have errors.
But something funny happens with this recursion. Physical commupters produce corruption when they execute cursed patterns. But every line of corrupt code is already a haunted pattern; they are definitionally composed of them. Thus, corruption-within-corruption is something different, something which is to corruption what corruption is to physics — a metacorruption.
Can you use metacorruption to manipulate commands the way commands manipulate physics? Can you create metametacorruption and metametametacorruption?
There’s no need for this; corrupt commands can already manipulate themselves, they’re just data. And metacorruption is different from corruption in one major way: potential metacorrrupt energy inhibits corrupt energy.
This means that through metacorruption, you can truly perform reversed corrupt combustion, creating oil that doesn’t immediately recombust. Again, all good in theory, but how can you actually find these ‘meta-haunted’ patterns?
Ostensibly, you might be able to devise a compiler that maps corrupt code into metacorrupt code, essentially by translating haunted code into corrupt code that perserves the haunting semantics. This is just a theory though, the sort of thing you see written in majors or the ‘further research’ section of a JCJ whitepaper. It was too ambitious, too expensive, intractable; no one actually did it.
Yeva was the first drone to devise a metacorrupt compiler, wieldly her assertion-bound corruption to create constructs too vast for any other solver to manage. At first, it seemed metacorruption was a ivory tower abstraction. A proof of concept, not a combat application. In order to do it, you need enough corruption to create a whole virtual machine out of command output, and then you need more corruption to feed into the virtual compiler and then run the compiled result. Yeva spend a 48 hours plugged into the wall, rotating gigabytes of corruption by hand to arrange all the delicate constructs requires. But she did it.
Nori was the first to understand what she did. It required several explanations, demonstrations, Yeva had to walk Nori through the steps, their data intermingling. But Nori was the only one who put in that effort.
And Nori, ever inclined to one-up her, pushed it further. She discovered the “fast inverse corruption” trick, an optimization which mostly works to generation potential metacorruption quick and cheap. ‘mostly’ because part of the run-time assertion that allows it to work is that it corrupts the user in the process — something ñ Nori’s driver conveniently lets her dodge the consequences of, but anyone trying to replicate her trick wields a double edged sword.
Reversed combustion is hard enough, but you can take things a step even further. Potential metacorrupt energy may inhibit potential corrupt energy, but if it is exposed to oil in the absence of potential corrupt energy, it can also ignite in metacombustion. Through metacombustion one can run inverse commands.
At the lowest level, inverse code simply reversing the operation of normal code. In effect, this makes metacorruption a much more efficient way to perform data recovery. Instead of carefully contructing the commands that undo the effects of other commands, you just run one reversing command. It’s like if after stomping the vase, you could put on a pair of anti-boots that perfectly unstomp the vase.
But at a higher level, a delicate interplay of code and inverse code allows one to conceptually invert commands. Instead of simply doing the opposite, their functionality is partially inversed, reconfigured. The opposite of red is cyan, but if you invert only one of the channels, you can get blue.
Yeva discovered the inverse of a few basic commands. Inverse duplication is deletion, inverse restoration is revision. (Where do you think Nori got her bat wings from?)
Inverse translation is special; it behaves the same as its normal counterparts, but the like entities restriction becomes a like entities requirement. Which is to say: it can target other solvers.
Inverse augmentation affects objects instead of the user, and grants them like entity protection. In effect. inverse augmented projectiles can cut right through an enemy solver’s proxy field and no translation command can stop it.
Note that inverse commands leave inverse residuals, and residuals must be purged (or parsed) to restore (or perform data recovery). Corruption can cancel metacorruption, but metacorruption corrupts corruption, multiplying the cost.
What this means is that a wound left by a inverse command is harder and more expensive to heal and it saps your corruption until you heal it. Unless, of course, you have also mastered metacombustion; since it’s must easier to heal inverse wounds with inverse commands.
Anyway, given all this new info, i’m revising some character abilities.
Emily’s function now uses corruption cancelling, not data recovery, which makes her ability a lot less profound. (Still a cheat; canceling is something most solvers disregard or take for granted. there’s no one else except Yeva who can perform perfect cancels like this.) I’m also adding a ceiling; her wards block everything up to a size limit, so if an enemy command has more bytes of corruption than her ward, the ward is broken. (And she suffers painful backlash.)
J’s function work the same as established in Compression & Extraction, but I can clarify it now. ⸢Leverage⸥ grants her a loan of corruption or metacorruption (or both) with a run-time assertion to pay it back.
(I’ll also take this time to flesh out ⸢Investment⸥. Specifically, investment takes an input corruption and creates a stock whose value depreciates over time, but appreciates substantially whenever the target fulfils a run-time assertion, and crashes whenever they break one. Note that though the target is often J, she can target anyone she touches, or anyone her domain. Finally, exactly when the investment is ‘sold’ to execute a command, and what command runs, is determined by J when it is created.)