Cheat Engine

[flarn2006]

I have Windows XP installed in a virtual machine, and I've been experimenting with corrupting various bytes in memory at random. To do this, I have Cheat Engine running on the host computer, targeting the hypervisor process. Then I have a short piece of Lua code that changes random bytes in the appropriate range in a for loop.

However, I haven't really gotten many interesting results from it. The most interesting things I've seen are the cursor only being able to move vertically, and a small graphical glitch with the Start button. The vast majority of errors I've seen have simply taken the form of boring error messages, rather than cool glitches like you'd get in a video game emulator. Occasionally I see a dialog saying an application crashed, but even more common are the blue screens. So many blue screens! (Though I did figure that would happen.) At least the VM reboots pretty fast.

I'm figuring this is because Windows has more memory protection than video games that run on old consoles (or emulators) without operating systems. When a program tries to load data from an invalid (corrupted) address, it doesn't just load from some other process's memory; the program crashes. And if it's the kernel, that crash takes the form of a BSOD.

I tried patching KeBugCheck(Ex) (by using CE in the guest) to simply "ret" at the beginning of the function (that's one of the reasons I chose XP, no PatchGuard bullshit), but that didn't seem to have any effect. Though I'd also like to make user-mode programs simply continue in the case of invalid memory reads/writes rather than just crashing.

Does anyone know of a way to do this, like by patching the kernel's exception handlers or something? Would it be possible to modify the hypervisor (VirtualBox, which is open-source) to disable CPU exceptions, or does the hardware virtualization not support that kind of control?

[Rydian]

Well, it's more that Windows is an operating system and things are fetched with pointers and stuff is allocated dynamically and junk.

The reason you can corrupt old videogames so much is because they're blobs of binary data, more or less. Hell, the GBA and below didn't even have a filesystem. They read data from specific parts, and they'd interpret whatever they read as whatever they were trying to read.

There's a large number of reasons you're not going to get the same results. No palettes in use, the majority of data isn't code, there's format checks on incoming stuff, etc.

The closest you'll get is targeting actual individual programs outside and poking their read-only code (for those games that do mark game code as read-only, which isn't many), or if you had some way to target code in RAM and not data. Like some AOBs that target common function beginnings and randomly making them return immediately or something.

[Dark Byte]

the problem is the cpu (x86)
programs running on windows run in "paged mode"
That means that the memory layout exists out of blocks of 4KB that might be read only, non executable, or don't even exist

if you randomly change bytes, it's likely the new instructions and pointers cause execution of non executable memory ranges, but more likely non existing ranges
or the cpu tries to read non-existing memory

whenever that happens the cpu will change the execution flow to an error handler which will show an message that the program or operating system has crashed