Go Home, Windows EXE, You're Drunk
28 points by Qyriad
28 points by Qyriad
Epic's Easy Anti Cheat does this to spawn the linux version of the anticheat helper when wine is detected.
I've been wondering about this. I've poked a handful of games with bespoke anti-debug features that check for attached debuggers and check other running processes or windows for known RE tools, and some also have WINE detection logic, but so far have not seen any try to leave the WINE environment. For example, debugging via ptrace and GDB are completely undetected. Interesting to hear EAC may actually do this.
Lately, I've been playing around with syscall user dispatch in linux which apparently allows recent wine versions to handle windows syscalls more completely!
Does anyone happen to know which Windows syscalls are customary to direct call? I've looked at the syscall tables before and surprisingly basic ones would change between point releases. I'm struggling to find a list of which are reliable, but I'm very curious.
Since Windows 10, some syscalls have been remarkably stable. E.g. NtCreateFile, NtReadFile, NtWriteFile, NtDeviceIoControlFile, NtClose, NtCreateProcessEx and a bunch of others.
But yes, this is still very unusual and there are zero guarantees. It's mostly multiplayer games or some "security" software that would resort to this.
EDIT: I'd also note that there's almost no practical use for using raw syscalls instead of going through ntdll.dll unless you enjoy making things harder for yourself. The only advantage is it's harder to intercept but that could also be a disadvantage depending on the software.
Post title is bad.
It should be "Go home Windows EXE you're traumatized"
Regarding syscall emulation, iirc, OSF Mach has a syscall for letting a userland port handle a given syscall for a given process but I couldn't find anything indicating whether it is supported on XNU. Time to test, I guess.