3
$\begingroup$

In an Earth that has long since reached the Singularity, the point at which human life can be uploaded into a digital simulation, and that most humans live inside this simulated world, outside is a small number of humans that keep the systems running, why they do this is not important, lets say it just happens

Then a piece of Malware or a computer virus turns up and starts to do lots of damage in the simulated world

Lets make some assumptions:

  • Either no help from outside the simulation, or anyone outside the simulation can only watch, they are unable to assist.
  • The Malware/Virus, must act like a Zombie acts, it moves slowly, but once it infects a file (person) that file must become malware capable of infecting other files
  • Can be blocked by firewalls, however if enough malware presence takes place they can breakdown the firewall
  • Once infected, the file is not instantly killed and turned, then die slowly and the turn into a Zombie
  • Once a file is infect it needs to be irreversible, that file (person) is permanently corrupted (dead)
  • There must be a way inside the Simulation to fight it, similar to shooting it in the head. but this is just what the simulation people see, it doesn't happen like that

How would this malware act from outside the simulation? if we assume those inside the simulation see Zombies. then how would the outside observer see this happening from the computer end?

So far i'm thinking getting through the firewall would probably be something akin to a Distributed Denial of Service (DDoS) Attack, and the malware might infect a file, and then cause a memory leak so that person slowly dies and then becomes a Zombie. but the inside simulation way of killing them, is some form of "Task Manager, End Process" gun... (that's not supposed to sound as stupid as it does)

Also for the sake of argument, lets say its not practical to "backup" an entire person maybe due to drive space, so once the person is dead, they cannot be restored from backups

Edit: as this is seeming too broad.

The part i'm struggling with the most in terms of computing is how a single piece of malware, would be unable to get through whatever defenses put before it, but multitudes of that same malware (no difference in base code) are able to overcome it this is how it would appear from the outside looking in, from the inside it would appear as the humans putting walls in the way.

$\endgroup$

closed as too broad by MichaelK, ArtificialSoul, Ash, Gryphon, sphennings Aug 8 '18 at 15:43

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • $\begingroup$ The answer to this very much depends on what ‘normal’ activity looks like outside the simulation.. $\endgroup$ – Joe Bloggs Aug 8 '18 at 9:23
  • 1
    $\begingroup$ I think you've missed the point. The analytics and monitoring you might do for a web application look completely different to those you do for a database, which is in turn completely different to the way the heuristics in an antivirus program function and can be 'looked at'. Generalising this up to a singularity-style simulation of the world means that 'how this looks' is entirely up to you: The way the simulation functions at a fundamental level will completely change how it's monitored, as well as how the virus attacks. $\endgroup$ – Joe Bloggs Aug 8 '18 at 9:32
  • 1
    $\begingroup$ For example: How do the symptoms of this zombie-ism manifest inside the simulation? If it's a visual symptom for those inside the simulation then the virus must be affecting the 'visual' bit of the simulation for some reason. How this 'looks' to an outside observer depends on what tools the outside observer is using to assess the system health of the 'visual' bit (regardless of how the virus is spreading etc). $\endgroup$ – Joe Bloggs Aug 8 '18 at 9:35
  • 1
    $\begingroup$ @BladeWraith, what is the actual problem that you are asking for help with? You seem to have pretty much everything down pat already and you are exercising lots of author discretion here (that is to say: you make stuff up yourself how you want things to work). So what is the issue? Why are you suddenly — on this particular issue, whatever it is — asking us to come up with things for you? What is the issue that blocks you and what kind of answer do you need to resolve that issue? $\endgroup$ – MichaelK Aug 8 '18 at 9:57
  • 1
    $\begingroup$ Well no-one has any idea what kind of software or hardware can recieve the consciousness of a human either and you do not seem to have any problem handwaving that bit. You have invoked computer magic for that and just authored it up. Why can you not do the same for this supposed "malware"? Malware, I must add, that has nothing in common with present day malware and viruses; their respective complexity being magnitudes apart. Your question is essentially: "Right... I have no idea how servos and pneumatics work, so I need someone to tell me how the T-X series of Terminators work". $\endgroup$ – MichaelK Aug 8 '18 at 10:22
1
$\begingroup$

Inside a simulation, life continues as we know it.

Outside the simulation has a few possibilities of different "skins" which can temper or encourage the beings outside the simulation to act differently.

  1. The simulation is Sims-like. The programmers see what inside-simulation characters are seeing and doing. (Perhaps with a top-down or scrolling view).
    • Yes, corruption is happening to files, but they look like people, which makes the situation all the more helpless to the onlookers.

  1. The simulated people are programs. A program runs and performs actions on files or disk independently, meaning that all people (including sim-zombies) are programs with rights to perform tasks in the desktop.
    • A corrupted person will then look like a corrupted program. Perhaps the action speed (action.eat) isn't triggering as normal, leading to errors on screen or a bogged down processor.
    • A buildup of these sorts of maintenance actions and errors (simulator tries to force Tim.exe to perform Action.eat in addition to generating an error and logs) can seriously bog down both the processing computer and simulation, causing time to even freeze or glitch in the simulation.
    • Even given a speedy processor which can handle the volume of errors, messages should be spamming the screen repetitively (especially Tim.exe has been terminated with the Taskkill.gun)
    • Outsiders will likely be concerned at the state of the computer.

  1. The simulated people are files. The sim-humans (and sim-zombies) are all files having actions done upon them.
    • In this case, Action.eat is performed by Sim.exe to file Tim.hmn
    • This is important because Sim.exe is the only thing allowed to modify computer tasks and generate errors. In all likelihood, it is the only thing that can even read a Tim.hmn file.
    • Either Sim.exe or Virus.exe is performing the Action.corrupt to file Tim.hmn
    • The file Tim.hmn has been altered and will prompt responses from either Sim.exe or Virus.exe the next time either program reads from Tim.hmn.

Yes, this means the entire thing can be masterminded (or handled) by the simulation itself. It need not even be exterior malware, just an action created by the devs or AI of the simulation program.

Most importantly, there will be no errors or warnings at all to those on the outside.

Either Sim.exe will believe all is in order (no errors) or Virus.exe will be hiding (and Sim.exe will be reacting to the Actions inside Sim.exe) thus generating no errors as well.

Onlookers will have no clue anything is wrong, unless they start looking into the files or at the diagnostic viewer.


These three are all similar to real-life issues.

  1. In Sims 2 and Sims 3, worlds would start corrupting with hints in game. Sims (virtual people) would get stuck in odd places, die randomly, have their family trees replaced with question marks or crash the game when clicked. Adopted babies would all be clones, and plenty of other horrific details before finally degrading into total failure (unable to launch).
  2. The WannaCry virus was big, flashy and demanded the users attention. It ran on its own and would delete files if users failed to pay up. Similarly, adware which spams pop-ups on the desktop was also irksome and running on its lonesome.
  3. The email or keylogger viruses are stealthy and can go under the radar for days, weeks, months, years, etc. until you went poking around for them. Their goal is spreading and gathering data as you used the computer.

  1. Sims World is the most concerning if actively watching the simulation. Watching things go wrong with the tiny humans is traumatic. Nothing can be done, and it warrants a moderate amount of attention after the initial upset.
  2. Humans as Programs is the most concerning if the computer is used for literally anything else. Error messages would be rampant, and attention with intention to fix would occur sooner rather than later. If nothing can be done, it will continue to cause massive upset and (possibly) loss of use of the device.
  3. Humans as Files is the least concerning, but perhaps, the most devastating of all. Every last bit of data could be corrupted before the tech-guy comes back from his vacation. New humans uploaded into a zombie war zone and corrupted near instantaneously. Once noticed, it will cause massive upset and near constant alarm (unless shut down/burn the computer is a viable option) as the virus continues its stealthy rampage.

All of the actions you seek to have your sim-humans and sim-zombies/virus take and the computer's/simulator's reactions all depends on which architecture assumption you take in handling your human programs/files/visuals.

From there you can assess what the effects are of the computerized equivalents in your sim-zombie apocalypse.

Hope it helped (and sorry it was long winded)!

$\endgroup$
0
$\begingroup$

Assumption 1:

Your simulation is massively distributed: Each 'person' is a distinct system that just happens to interact with other bits of the simulation in a way that seems real to them, but there is no centralised computer managing the simulation. It's reasonable to assume this for a variety of reasons, from resiliency to being able to manage latency.

Assumption 2:

Each system manages it's own security. This is required because otherwise your 'virus' would just overrun the whole system without any further fuss, and you'd find the virus spreading in ways that (from within the simulation) seem impossible. This also prevents an easy 'fix' or easy backups of the system, but does remove the concept of 'firewall', because 'firewall' isn't something you'd see from inside the simulation. To maintain security each simulated thing will only interact with other simulated things in ways that you would expect to see in the real world: They do the minimum amount they can to keep the simulation going, but other than that refuse all connections that might be malicious. Anything that isn't a taste trying to access the 'taste' port will be blocked.

Assumption 3:

The 'virus' attack vector is something to do with the interfaces between various bits of the system. If you want to get very specific: It's an exploit of a specific interaction between the tactile interface and the pain response subroutine (biting, scratching etc are required for the virus to spread, you can't get it by just looking at a zombie). This prevents objects that don't simulate pain from getting the virus, so it can't spread through simulated bricks or simulated mortar. It also explains why the zombies act differently: They're trying to spread the virus through the only viable attack vector in this simulated system. If they have to navigate their way through the rest of the system (walking into walls, breaking down barricades, not getting shot etc) in order to do so then that's just tough.

Assumption 4:

The simulated people's personalities are 'cached', and there is some function of the 'person' simulation that periodically accesses and modifies this cache. The virus spreads by hi-jacking this function and slowly overwriting the personality cache with copies of it's own subroutines. If the 'personality' cache also ties in with other systems on the person then degradation of that cache will lead to apparent physical changes and alterations in motor function/apparent needs. In some items (like rocks) no overwriting of the cache is done. It's a rock and will always be a rock. You can't zombify a rock.

How will this appear to external engineers?

That very much depends on how they're monitoring the system. Assuming these engineers are read-only (otherwise why is the virus not spreading using their tooling?) they could be doing anything from monitoring average cpu usage across the distributed systems through to tracking the overall usage of the 'drunk' subroutine to try track down a bug that makes people text their exes at three in the morning. Depending on exactly what the virus does it might manifest in a variety of ways at the hardware level, but given that it will still need to be running a simulation of a zombie I'm going to guess that the hardware stats will appear the same as they would for the 'person' simulation. You might find a hardware similarity that doesn't exist in the person simulations though, for example vastly diminished usage at 'sunrise'.

One thing that I would expect would be that their software monitoring would be done using a periodic 'ping' of data from the various systems (one way, to maintain security and work nicely in a distributed world). As the virus overwrites the cache on the 'people' system this functionality would disappear, leaving your engineers receiving less and less useful data from virus-susceptible-systems over time. This virus would appear as a series of people-systems 'going dark' without sending the appropriate 'I just died' pings.

Of course, they can still go around using their 'I am a drone' system to gather other information that the distributed systems will let them gather (visual information, for example), but other than that none of the distributed systems will give them any information, limiting them only to diagnostic information that can be gathered from within the simulation itself, but that's basically flying around the simulated world looking for zombies...

PLEASE NOTE

This is me sticking my finger in the air and making some very broad assumptions about the nature of your post-singularity-capable-of-simulating-consciousness-but-still-monitored-using-windows-7-for-some-reason simulation. Really you can make it work however you like: The whole system is up for you to design.

$\endgroup$
0
$\begingroup$

Different types of IT applications are monitored differently. Even the same type of application can be monitored differently between companies depending on what the specific company considers relevent/meaningful/critical to that organisation.

If an IT function was monitoring something akin to a VR world, then their monitoring functions would be unique to that and reflect the things they were interested in shown in a way that makes the details they care about highlighted above the "noise".

Think of a log file for an application that dumps out lots of messages about an application (memory usage/stuck threads/cpu usage etc.) No-one is realistically going to continuously read the log file to find information. They would use scripts to parse the file for items relevent and display them using something more appropriate like a dashboard showing cpu/memory usage as a graph and stuck threads as a warning indicator.

If I was monitoring a VR world, I'd imagine something like a floating 3rd person view, free-roaming view of the world similar to online games when you are dead or waiting to respawn. I would then be able to select avatars in my VR world and bring up a dashboard to display stats on them (memory/cpu/disk space etc.) in the form of a "vitals dashboard". If I noticed unusual activity or non-responsive avatar I could debug further by inspecting the memory or dumping memory to file for analysis. A zombie could take the form of stuck threads responsible for cognitive function leaving the physical movement functions to operate without explicit instruction.

I'm not 100% sure what answer you are looking for, so I'll wait for your feedback.

$\endgroup$

Not the answer you're looking for? Browse other questions tagged or ask your own question.