[a simulated computer, which is inside the world simulation, is just another subroutine inside that simulation. Telling the computer to execute an unexcutable function will break the world, if the world is poorly written. (it will have to have its own exception handler routines to catch the divide by zero error. Most programs rely on the OS's professionally written exception handler, but that one usually defaults to nuking naughty processes, which would nuke the world simulation, in the event of a serious fault, like a divide by 0. Writing an exception handler is "Serious business".) This is because for something to happen in the world, the world has to process it. The simulated computer is really just an emulator, and everything run on that computer, is really running on the computer that is hosting the world. As such, saddling the simulated computer with unsolvable problems will saddle the world computer with unsolvable problems. A turing complete machine is able to simulate any other turing complete machine, at the cost of performance. This means for the simulated computer to run at the appearance of full speed, the whole world has to slow down to match. There is fundamentally no such thing as an infinitely fast processor, which means that our magnificent bastard can be "attacked" (made to become frustrated, or bored) by simply overloading the world simulation. We can do this with boring, absurd shit-- like loading virtual computers up with REALLY cranky code. Since it is pretty predictable that we would do this, he would likely have optimized the software so that computer simulations will be given greater performance, which means running the code natively, instead of nesting it. This is where the problem with the divide by 0 error comes into play. If the simulated computer's emulation thread is running native code directly (High level emulation), there is no efficient way to trap exceptions. To trap exceptions perfectly, you have to demote the process with a hypervisor, and this means reinstating the performance hit. You dont get your cake and eat it too. Making the simulated computer divide by 0 was a simple (if ballsy!) test to see what kind of exception handling the magnificent bastard has instituted. That the world didnt even hiccup a little from it, shows that he has elected to risk his computer melting to slag from excessive processor loads from simulating simulations. Next up, is seeing how it handles such basic things as buffer overflows inside simulated simulations. This could have 1 of 3:possible effects, depending on how the world simulator is written:]
[1) Nothing of note happens from our vantage point. The access violation is properly trapped. Outside our vantage point, the world simulation hiccups a little, as memory gets shuffled around to prevent it being overwritten by the access violation.]
[2) "Mysterious shit" happens around the simulated computer, as the access violation garbles some of the nearby memory OUTSIDE the simulated computer's process. Material types suddenly and inexplicably change. Tiles of "Unknown Type" material, blocks of floorless wall, and sudden holes of empty space, and other anomalies appear-- similar to what happens when you use buggy hacking tools, like Tiletypes from DFHack.]
[3) The access violation causes an unrecoverable exception, and the world process is halted. Congratulations, you broke the world. This happens when the access violation overwrites fundemental program code on the stack, leading to nonsense instructions which raise the panic. The OS that the world simulator is running on will trap the exception as best it can by terminating the thread with an error message, then will attempt to clean up the memory, and return it to the free pool. This is the "oops!" version of a buffer overflow vulnerability-- instead of an executable payload, random garbage gets shoved into the execution pipe, which crashes the process.]
[as you can see, regardless of the severity of the outcome, the magnificent bastard *WILL* notice that I am up to nefarious shit, if for no other reason than the sudden spike in lagginess it will cause. This will force him into taking direct actions. If multiple people are engaged in such antics, it will occupy all his time in trying to circumvent the loss of fun in the simulation, making him vulnerable to actual tactical blunders. The "moody dwarf" exploit I have planned will almost certainly get his attention, if the divide by 0 fun didnt.]
[We have a choice in what we want the payload of the moody dwarf exploit to accomplish. We dont know enough about our target platform (The REAL computer that the world is running on) to properly disable its input devices. What we DO know, is that it is likely an Intel or compatible processor. This means we DO have a thermonuclear torpedo if we want to deploy it. Intel processors have a HARDWARE level exception handler, known as the
"Triple fault reset". By carefully structuring the injected code segment, we can create such an event, which *WILL* reboot the computer, and force it to lose data. A triple fault is NOT recoverable.]
Poll
4 (14.3%)
Author
Topic: If Bay Forum were a Mountain Hall, continued... FULL DISCLOSURE (Read 266386 times)