GetOtherOperationCount (and therefore its test, Check_OtherOperationCount) was always failing under WOW64 because the size check for this info class is not correctly implemented for WOW64. Simply remove this query, it was only being used to validate the previously obtained values anyway.
- Fix "initialization error 1" on Windows 7/8/8.1 and supported (= with known syscall tables) versions of Windows 10
- Zero extend the value of RAX on x64 when returning an NTSTATUS
- Fix access violation on instrumentation callback removal on Windows 7/8/8.1
- Add scl::Wow64GetModuleHandle64 to get wow64cpu.dll from a WOW64 process
- Always apply WOW64 gateway hook to the X64 far jmp at wow64cpu!KiFastSystemCall/X86SwitchTo64BitMode
- Remove hack in ApplyUserHook() that was applying a duplicate WOW64 gateway hook. No longer needed because the far jmp in wow64cpu.dll is shared by ntdll and win32u
- Remove J.R.R. Tolkien novel length comment about the layout of the WOW64 gateway call on Windows 10 and the associated hack for it
- Remove hack in GetCallDestination() for WOW64
- Remove code for hooking of and writing jumper code for FF 25 jmps (absolute indirect far jmp)
- Remove 1000 byte global 'tempSpace' buffer (great name) and replace it with a 7 byte function local one
- Rename lots of things to make slightly more sense
- Remove unused function parameters
- Same thing as previous commit, but for native x86
OK, I admit I clearly stopped trying here. But I bet I still put more effort into this lazy hack than Obsidium put into their hook detection
- Write WOW64 x64 transition detours as far jmps
Obsidium checks syscalls for hooks, or at least it tries to. But if something only kinda looks like the original it's good enough. And thus was born: the absolute far jmp with segment selector that doesn't actually change the segment. Good to go!
Tip for Obsidium: take a cue from your competitors at VMProtect and try doing something that's actually innovative and hard to bypass instead of these hardcoded byte checks. I almost feel second hand embarrassment committing this
- Enable NtUserQueryWindow hook for Obsidium profile
Obsidium thinks anyone who simply has a WinDbg window open is out to get them, and uses some 1990s era detection techniques like window enumeration to find these evil hacker tools. Guess what, some people use WinDbg and IDA for their work (shock!). Isn't it ironic that Obsidium protected software is actually more user friendly when you run it in a debugger?
Matthijs Lavrijsen