3 ms·

EXCEPTION_ACCESS_VIOLATION is well-defined & memory safe. That's just a crash, same thing that happens when Helix crashes because it called .unwrap() on an erro

EXCEPTION_ACCESS_VIOLATION is well-defined & memory safe. That's just a crash, same thing that happens when Helix crashes because it called .unwrap() on an error. It's correctness that affects the user experience, not memory safety. From a cheating perspective, memory safety is entirely irrelevant when the game code is running on the users' computers, where they have full control over the machine code of the client, their own RAM, and the bytes being sent to the network. There are plenty of important use cases to care about memory safety, but video games executing on players' computers ain't it.

veber-alex 4y ago
> EXCEPTION_ACCESS_VIOLATION is well-defined & memory safe. That's just a crash, same thing that happens when Helix crashes because it called .unwrap() on an error. Just because both of those things cause a crash doesn't mean they are the same. Crashing due to an incorrect .unwrap() is a bug in the business logic of the application, the developer made a wrong assumption. EXCEPTION_ACCESS_VIOLATION is a crash due to a memory issue that a memory safe language would have prevented. > It's correctness that affects the user experience, not memory safety. Memory safety is part of correctness, your program can't be correct if it crashes with EXCEPTION_ACCESS_VIOLATION.
steveklabnik 4y ago
In addition to what my sibling comment said, > where they have full control over the machine code of the client, Part of the state of modern anti-cheat is developers taking extreme measures to fight exactly this. Developers don’t just throw their hands up in the air and say it’s unfixable. The softwares I mention run as kernel modules, hook into all sorts of parts of your system, and sometimes even stream new mitigations to be executed as the game is running. That’s why an RCE in this software would be extremely bad.
Rusky 4y ago
EXCEPTION_ACCESS_VIOLATION itself is well-defined and memory safe, but the program constructs that cause it are generally not. A use-after-free or null pointer dereference may cause an access violation in one run but corrupt memory and keep going in another. This is a very typical approach to building an exploit- find something like this and then tweak the input to turn it into something worse. This also plays into undefined behavior- unless the source language itself guarantees that a particular program will generate an access violation, chances are the access violation only happens by luck. For example, null pointer dereference is typically UB rather than specified as a crash, because while accessing the actual address 0 will reliably cause an access violation (assuming you are in such an environment), field projection and array indexing can move that address up out of the 0 page and lead to arbitrary memory access.

veber-alex 4y ago

> EXCEPTION_ACCESS_VIOLATION is well-defined & memory safe. That's just a crash, same thing that happens when Helix crashes because it called .unwrap() on an error. Just because both of those things cause a crash doesn't mean they are the same. Crashing due to an incorrect .unwrap() is a bug in the business logic of the application, the developer made a wrong assumption. EXCEPTION_ACCESS_VIOLATION is a crash due to a memory issue that a memory safe language would have prevented. > It's correctness that affects the user experience, not memory safety. Memory safety is part of correctness, your program can't be correct if it crashes with EXCEPTION_ACCESS_VIOLATION.

steveklabnik 4y ago

In addition to what my sibling comment said, > where they have full control over the machine code of the client, Part of the state of modern anti-cheat is developers taking extreme measures to fight exactly this. Developers don’t just throw their hands up in the air and say it’s unfixable. The softwares I mention run as kernel modules, hook into all sorts of parts of your system, and sometimes even stream new mitigations to be executed as the game is running. That’s why an RCE in this software would be extremely bad.

Rusky 4y ago

EXCEPTION_ACCESS_VIOLATION itself is well-defined and memory safe, but the program constructs that cause it are generally not. A use-after-free or null pointer dereference may cause an access violation in one run but corrupt memory and keep going in another. This is a very typical approach to building an exploit- find something like this and then tweak the input to turn it into something worse. This also plays into undefined behavior- unless the source language itself guarantees that a particular program will generate an access violation, chances are the access violation only happens by luck. For example, null pointer dereference is typically UB rather than specified as a crash, because while accessing the actual address 0 will reliably cause an access violation (assuming you are in such an environment), field projection and array indexing can move that address up out of the 0 page and lead to arbitrary memory access.