Rust for Embedded Systems: Current state, challenges and open problems

Although both cracking (as in "software cracking") and cheats were very similar security fields back in the day (both boiled down to reverse engineering) cheating has diverged enough (due to modern anti-cheats and anti-piracy becoming very different countermeasures) that I'd consider them vastly different nowadays.

Some categories of exploits unique to games:

- Aim hacking (pointing the mouse cursor to enemy heads)

- Recoil/spread cheats (mouse compensating for weapon recoil or bullet spread)

- Botting/botfarming (playing resource-intensive games automatically)

- Wallhacking (showing players through walls, or making walls semi transparent)

- Miscellaneous passive assistance (like overlaying a predicted path for a ball in a game, drawing precise location for footsteps/other player sounds, etc.)

- Modification of game state (like sending your character's position at will, allowing you to fly or go through walls)

Some of these have analogues in app security:

- Botting detection is probably very similar in both MMOs and CloudFlare)

- Hidden information is not very different from what we do in web apps (only send the state that the client needs and has access to)

- Preventing game state modification is solved by having a strongly authoritative server (again pretty normal in app land)

But even in those, what makes games very unique compared to other apps is that they're hard real time: you have hard requirements for each frame time; it's expensive to calculate in-server all things that a player should be able to see every single frame; packets take time to travel over the internet so you have to give it some slack (or enemies could pop out of nowhere when crossing doors); client sometimes needs information that you'd like to remain private (you need player positions even behind walls to provide 3D sounds)...

Modern anticheats usually resort to just scanning the memory for running cheats, trying to detect a cheat reading/modifying the game memory, etc. but cheats have come to great lengths like having actual cheat hardware (DMA devices on PCIe[0]) that cannot be detected since it's running outside of the computer software.

[0] https://blog.esea.net/esea-hardware-cheats/

My comment was more for consideration in the design of new languages, in particular, the development of the frequently cited as not existing, simple, C-like language with memory safety features. In that case, in a green field scenario, there are a few ways to achieve statically known memory-boundary respecting iteration and general access. Further, there are several existing methods of achieving 'generics'. The real design challenge would be in finding the simplest implementation that does not overly burden potential developers.

I am confident that it could be done, but it would take some grave dissatisfaction with Rust (which is currently at the top of the adoption curve in the memory safe, but GC free space) for the proposed language to take off.

I'd bet HFT has already got all the best static analysis money can buy, not that they're cowboying it more than anybody else.

Memory safety isn't just about "security". Sure, that's a huge issue, but it's also about not spending a month debugging why the login fails one out of a thousand logins because the user's password gets replaced by what seems to be a pointer, but one that doesn't point at anything, starting with the 5th character, or why your HFT code should have ordered 10,000 shares but instead ordered a pointer's worth of shares, or why the second level crashes after precisely the 1023rd frame with completely incomprehensible errors, or any number of other things.

I do not know why any sane developer that has worked through such a thing even once would be willing to entertain the notion of programming without it if it weren't utterly forced on them. I enjoy reading such tales of diagnostic heroism; I don't enjoy being in them anywhere near as much as some programmers apparently do.