Or the ones writing code where security doesn't matter, like HFT and video games (the former have no users, and the latter are basically impossible to make crack-resistant even if they're written entirely in Rust).
A lot of it is the same as any other sort of security stuff, but like, the tough part is that the adversary has access to the physical machine. In my understanding anyway, not a security expert.
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.
I can believe HFT developers think they don't need it.
Second, HFT developers are using very expensive FGPAs to do trading with network packets. People are quick to reach to some example where their favorite toy is used at some organization, but that's besides the point. The tools for getting code on those FPGAs is horrible and unless Xilinx adopts Rust internally I doubt much will change. Rust can be adopted elsewhere, but that's not what's making the organization money. HFT folks are not persuaded even slightly by these arguments about security and correctness. Jane Street is not a HFT firm and they will gladly tell you that.
It helps immensely to understand ones concerns, constraints, and values before assuming they're identical and them swiftly demonizing anyone that dissents. The Rust community really has done itself a massive disservice in alienating everyone that doesn't conform to its monoculture composed mostly of amateurs and unemployable extremists.
Of course, this will simply be downvoted by the pathetic and unimpressive. Nobody views this as an opportunity to even try disputing the argument or use it as a legitimate data point that Rust should strive for. They simply want obedience and mindlessness in the monoculture because they lack the tools needed to handle conflict of any kind. It's also why so many features are perpetually stuck as nightly rather than stable. The project does nothing but stultify talent into leaving for genuine innovation.
I think that it's a little unlikely that the Rust community is mostly composed of "amateurs and unemployable extremists" - a lot of the working software engineers I know are interested in or actively use it.
However, "assuming they're identical and them swiftly demonizing anyone that dissents" is an excellent characterization of, at least, the parts of the Rust community that I see on HN and Reddit.
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.
A lot of games have a multiplayer mode nowadays, that opens it up for exploits. I do not want to get my PC hacked because I connected to a game server. If you mean only single player offline games, I guess yes security is less of an issue.
