|
|
|
|
|
by armchairhacker
1250 days ago
|
|
This is why you rewrite it in Rust \s But seriously, one of the reasons games should maybe be less C++ and more memory-safe languages, if not Rust then languages like C# or JavaScript. And maybe incorporate formal methods into game-dev. The code which handles server responses should be sufficiently isolated from any of the unsafe code (e.g. rendering), so that you can ideally prove (or non-ideally, at least be very confident) that a server response cannot cause arbitrary code execution. Maybe it still won't be sufficient against state actors, but it would mean that you can reliably play an old game like you can reliably view a webpage. I would not be surprised if COD and GTA have remote-code exploits, though. |
|
So for the new version of Flight Simulator, they divided it into core game engine and "content packages" that fill the rest (airplanes, landscape, missions, other assets). Packages get loaded into a virtual file tree[2]. Packages may contain custom code, usually compiled from C++ to WASM, but the code is executed in isolated containers and it does not have access to the underlying file system. It only sees contents of its local package within the virtual file system.
As a result, the shiny airplane you bought from some online marketplace can't read your documents folder and send its contents to remote servers anymore. It remains an issue with many other games where third-party modifications ship as unrestricted DLLs, even on authoritative-looking platforms like Steam Workshop. For example, a pathfinding fix for Command & Conquer on Steam is just a DLL swap[3] - this should make security-concious people very uneasy.
[1] https://docs.flightsimulator.com/html/Programming_Tools/WASM...
[2] https://docs.flightsimulator.com/html/Developer_Mode/Menus/T...
[3] https://steamcommunity.com/sharedfiles/filedetails/?id=21371...