BlockInput and NtUser* options

[x64dbg]

BlockInput and NtUser* options

[aswerw]

I think I found the problem regarding the error message.

I haven't looked too much into the ScyllaHide source, but I'm guessing hooks are done on the first break event?

If the module isn't loaded at the time of the break event (packed process, breaking on DLL Entry, etc), then you will get the error message.

The error message seems to be from not checking if GetModuleHandle/GetProcAddress succeeds before calling DetourCreateRemoteNative32.

I guess the only problem here is that the error message is kind of bad for the situation. So, I guess this is more of a feature request: Currently, there is a pop up for every failed hook, which is a bit spammy, and the message is a bit vague. It would be nice if it popped up only once with a list of the failed hooks.

As for the crash with DummyB, i'm not sure what the problem is there.

[Mattiwatti]

This seems to be ~three separate unrelated issues. I can reproduce DummyB crashing on all OSes, but DummyA only on Windows 10. For both, I can only reproduce the crash in WoW64 mode (possibly also native x86 but I have no installation on hand to try this). x64 versions of DummyA and DummyB work fine if, as you say, the module is loaded at the time the process starts. To summarize what I'm seeing:

• WoW64 syscall hooking, especially on Windows 10, is completely fucked (which syscall is being hooked specifically doesn't matter very much). This has been the case for a while now but I don't know if anyone is willing to fix to fix this. PRs are welcome of course.
• On Windows 10 (not precisely since RTM, but still a quite early Windows 10 release) win32u.dll addresses should be used rather than the user32.dll ones of previous OSes. win32u.dll is essentially the ntdll.dll equivalent for Win32k syscalls in Windows 10 and is in \KnownDlls so its virtual address is the same for all processes (strictly speaking probably only per container if we're using dirty Windows 10 technology anyway, but I'll settle for that.)
• You're right that it's pretty hard to hook DLLs that are not yet loaded, and this is indeed the cause of the useless error. This is only really possibly a concern for user32.dll/win32u.dll (if it's not statically linked). The proper fix here would be to delay these hooks until (if ever) these DLLs are loaded, not to skip them completely. But that would also be a lot more work, because we'd have to check on each LOAD_DLL_DEBUG_EVENT if a not-yet-hooked DLL is being loaded, and if yes, whether it should be hooked. As a band-aid you could also set a DLL breakpoint for user32.dll to reapply the ScyllaHide hooks when it loads. Not ideal, but how many real world (even obfuscated) executables do you really see that load user32.dll dynamically? For a commercial protector it's not quite as simple as changing all static imports to LoadLibrary calls, because the ntdll loader behaviour is very complex and has many subtle side effects which may affect the runtime behaviour of the program (e.g. the DLL load count and order). Though of course in most cases this will work fine and there is probably plenty of malware that does this thinking it's super clever.

I agree with you that the error message is both unhelpful and spammy. I'll see if I can come up with something better (and make it one-time). But the underlying issue is really trying to hook a DLL that isn't loaded. The first issue doesn't help either; I'm not sure if anyone actually understands the WoW64 syscall hook logic on Windows 10 given the huge pile of hacks collected over the years. If so, it's definitely not me :)

[Mattiwatti]

I kind of forgot about this issue, but it seems that due to various recent(ish) bugfixes this is now fully fixed. There have been a number of changes to improve or fix user32.dll/win32u.dll hooking (especially on Windows 10) as well as WOW64 hooks. So I can't say precisely when or how this was fixed, but it should be working now.

I was wrong about dynamically imported functions not being hooked by the way; at least the x64dbg plugin reinjects on every LOAD_DLL_DEBUG_EVENT. So user32 hooks work as you would expect. There was another (now fixed) bug that was causing this.