Conversation

I still don't understand what's the point of these "releases". If you want to execute code without allocating executable memory just implement an interpreter. It's simpler, better, faster, less suspicious, and everyone is already doing it.
2
6
You believe packaging an entire interpreter in your application is more stealthy than abusing existing instructions through SEH? I am having trouble seeing how an interpreter would be "simpler" or "less suspicious". Got any public examples?
2
1
It's possible to create a VM in raw assembly that's as little as few hundred bytes. Furthermore IMO it's fair to say that an application single stepping its own instructions isn't a common occurrence. Might be more reasonable if you did this in another process using debug API.
1
1
I'd be interested to hear more on the latter. How would you detect an application single stepping legitimate instructions if it is done with SEH exception handling? (Keeping in mind realistic factors like maintaining performance.)
2
simply register a pair of VEH exception and continuation handler. You'll see a pattern of single step exceptions thrown, followed by continue with modified rip. I can't come up with a single legitimate use case that would result in this pattern.
1
1
Two things: 1. Registering a VEH exception handler and checking every single exception to detect a pattern of single steps could cause significant performance issues if you perform that system-wide. 2. A legitimate use case here would be a debugger single stepping through an app.
3
1. as said already, two comparisons won't even make a dent in an incredibly expensive operation like throwing an exception and handling it via SEH. 2. a debugger does not debug itself, and it does not normally modify rip after every single instruction.
1. EOP has a significant performance hit, yes, but an attacker does not need to care about performance, AV does. That's why it still matters. 2. This was addressed in my previous replies.