The emulator's gambit: Executing code from non-executable memory
3 points by jmillikin
3 points by jmillikin
This article is extremely verbose and repeats itself a lot.
I also don't see the point, if you can get the target process to inject a VEH handler that does emulation, couldn't you instead inject a lua interpreter or something and not bother with emulation?
The writing style changes drastically through the article. The first few sections also contradict the conclusion.
If the AI-written section of the article (meaning, most of the article) is the one that matters: this is a fine “I wanted to learn about those things” article, though very verbose due to AI (which makes for poor reading in general, in my opinion.)
If the human-written section of the article is the one that matters: what is the point of those techniques, considering the permissions one needs to setup hardware breakpoints via CPU debug registers? There’s a lot better you can do with such high privileges (such as modifying page tables.)
Why bother with hardware breakpoints if every instruction is going to be emulated anyway? It would be much faster to continue emulating the next instruction instead of returning from the exception handler.
Similarly, why bother setting hardware breakpoints given that trying to execute out of non-executable address space will trap into the vectored exception handler anyway?
The author used an LLM to write this article and the code for it. It's not worth evaluating with any assumption of depth or interest in learning on the authors part.
What the heck is this clankerwork and why is it being shared here? This entire article is riddled with inaccuracies, and oversimplifications... and loads of redundant/repetitive paragraphs.
To the OP who shared this, did you read it? LLM slop continues to degrade this industry.