There's no reason it's "impossible," although if you had said "impossible to generalize" I would agree with you. Same with spoofing file descriptors, subsuming mutexes, etc.--it's not impossible, just decidedly nontrivial, extremely failure-prone, and of little value. I remember reading about (the source escapes me at the moment) what was essentially the World's Most Batshit Replay Attack being constructed by rebuilding the memory space of a weakly random crypt program at a known point, then playing it forward. I'll check and see where I remembered seeing it.
OK, fair enough point. But we are talking about a
game here. Meaning, probably at least several hundred MB's of allocated memory. I would rather try something 'easier' -- easier used very loosely -- like injecting an exception-catching DLL that hooks the relevant Win32 Create/Close functions, periodically saves program state, and attempts to rewind operation on crash.
BTW, I only just now realized (after typing that) that Schilcote was mentioning a PocketPC game. I still hold that this is next to impossible for any non-small game -- which would have thousands of open handles -- but OK, sure, you could more than likely do it for a program of this size. I hadn't even got to the matter of GPU or other hardware state and initialization.
But rebuilding all memory would still not address the problem of why it crashed. It might be restored, only to crash again a nanosecond later under the same circumstances. So to modify my previous statement, you can (1) restore all memory, or (2) restore precise game state. But #1 may be a futile effort, and #2 is impossible
without reverse engineering the full game. Doing #2 would take 20 years for a AAA PC game that chaotically organized state in memory. It might be easier instead to simply solve the crash issue, or rewrite the game, or decompile/disassemble it for bug fixing and modification.
That is actually all processes can be started from. But yes it would be excessively non-trivial to write a generic system. Depending on that particular game you might find it's doable but that would require you to investigate first.
You're talking about how Windows works underneath. CreateProcess must be reimplemented to accept a handle to a buffer or
memory-mapped file. I suppose you could write it to disk first, but that still isn't what I was getting at -- that you can't automagically resume program operation using dumped memory of the complete address space.