[Bug 56968] New: Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

Bug ID: 56968
           Summary: Easyhook remote hooking does not work, breaking some
                    game modding frameworks
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: kernel32
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

There exist game modding frameworks that uses EasyHook, for example,
https://andrasteframework.github.io/content/1.0.0/index.html

EasyHook remote hooking uses ReadProcessMemory to fetch module handle and
function addresses before using CreateRemoteThread to perform remote hooking
with the fetched function addresses

On wine, this breaks at
https://github.com/EasyHook/EasyHook/blob/16f641c8e2197b01095f548c94dcbe696a...

When trying to fetch export directory from remote process' kernel32.dll's PE
header, ReadProcessMemory would succeed, eliminating the fallback codepath
outright, but the ExportDirectory buffer would then get filled with 0s. With an
export directory data structure filled with 0s, EasyHook would not be able to
do much with CreateRemoteThread as functions fetched at
https://github.com/EasyHook/EasyHook/blob/16f641c8e2197b01095f548c94dcbe696a...
are all unavailable.

Patching the routine with a loop to loop until the function addresses can be
fetched, it seems that it's not (just) a timing issue either because the loop
just seems to go on forever.

Interestingly, through patching EasyHook itself and force the fallback code
path at
https://github.com/EasyHook/EasyHook/blob/16f641c8e2197b01095f548c94dcbe696a...
which grabs export directory from PE NT headers, it can actually fetch an
export directory, then eventually fetch the addresses of LoadLibraryW,
FreeLibrary, GetProcAddress, ExitThread and GetLastError, but not VirtualFree
and VirtualProtect

With the EasyHook patches and dotnet48 installed, it is currently enough to
keep EasyHook going as it is now able to continue it's code injection and init
routine with LoadLibraryW.

Would it be possible for remote processes to fetch export directory from remote
PE headers? Would it be possible to fetch address to VirtualFree and
VirtualProtect? Thanks!

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

Fabian Maurer  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Fabian Maurer  ---
Created attachment 76797
  --> https://bugs.winehq.org/attachment.cgi?id=76797
Sample to reproduce the issue

Attaching a sample program made from EasyHook code

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

Fabian Maurer  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |download, testcase
     Ever confirmed|0                           |1

--- Comment #2 from Fabian Maurer  ---
Confirming

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

--- Comment #3 from Fabian Maurer  ---
Created attachment 76798
  --> https://bugs.winehq.org/attachment.cgi?id=76798
Hack to work around the issue

Attaching a dirty hack that should make it work.

No idea why it would work that way, but apparently it does. Not sure about
64bit though...

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

--- Comment #4 from Dmitry Timoshkov  ---
(In reply to Fabian Maurer from comment #3)
> Created attachment 76798 [details]
> Hack to work around the issue
>
> Attaching a dirty hack that should make it work.

+        void *ptr = &sec[i].VirtualAddress;
Looks like a typo, '&' should not be needed.

Does your hack work if it's only done at the end of perform_relocations()?
Probably when relocating a PE image the loader is also supposed to fix up
VirtualAddress field in every section in the sections table.

Also NtProtectVirtualMemory() probably should be called only for the section
table, not for every random section in the PE binary.

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

--- Comment #5 from Fabian Maurer  ---
> -
>    void *ptr = &sec[i].VirtualAddress;
>
> Looks like a typo, '&' should not be needed.

No, we need the address of where the VirtualAddress is stored, not where it
points.
> Does your hack work if it's only done at the end of perform_relocations()?
> Probably when relocating a PE image the loader is also supposed to fix up
> VirtualAddress field in every section in the sections table.

I suppose so, since we have "get_rva( module, sec[i].VirtualAddress );" before,
otherwise that would need to be changed. But I only really tested the case
without relocations.
> Also NtProtectVirtualMemory() probably should be called only for the section
> table, not for every random section in the PE binary.

Probably, it's just a dirty hack. Not sure how it should exactly work,
especially since on 64bit you can't put a pointer in that VirtualAddress DWORD.

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

--- Comment #6 from Dmitry Timoshkov  ---
(In reply to Fabian Maurer from comment #5)
> > -
> >    void *ptr = &sec[i].VirtualAddress;
> >
> > Looks like a typo, '&' should not be needed.
>
> No, we need the address of where the VirtualAddress is stored, not where it
> points.

Why do we need it and where? If you mean the NtProtectVirtualMemory() call,
it's already done by passing '&ptr'.

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

--- Comment #7 from Dmitry Timoshkov  ---
(In reply to Fabian Maurer from comment #5)
> > Does your hack work if it's only done at the end of perform_relocations()?
> > Probably when relocating a PE image the loader is also supposed to fix up
> > VirtualAddress field in every section in the sections table.
>
> I suppose so, since we have "get_rva( module, sec[i].VirtualAddress );"
> before, otherwise that would need to be changed. But I only really tested
> the case without relocations.

In the case without relocations sec.VirtualAddress already contains correct
address.

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

--- Comment #8 from Fabian Maurer  ---
> Why do we need it and where? If you mean the NtProtectVirtualMemory() call,
> it's already done by passing '&ptr'.

Because I modify the "VirtualAddress" value here:
> sec[i].VirtualAddress  = (UINT_PTR)get_rva( module, sec[i].VirtualAddress );

but that is readonly, so I need to make it read-write.

So we now have
> void *ptr = &sec[i].VirtualAddress;

which is the pointer to the address I want to modify. And since
NtProtectVirtualMemory needs a pointer to a pointer I pass "&ptr".
> In the case without relocations sec.VirtualAddress already contains correct
> address.

Sure, there is no relocations, but that programs expect the sec.VirtualAddress
to not be an offset but an absolute value.

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

--- Comment #9 from Alexandre Julliard  ---
(In reply to Fabian Maurer from comment #8)
> Sure, there is no relocations, but that programs expect the
> sec.VirtualAddress to not be an offset but an absolute value.

sec.VirtualAddress is an RVA, not a pointer. That program is broken.

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

--- Comment #10 from Fabian Maurer  ---
> sec.VirtualAddress is an RVA, not a pointer. That program is broken.

I thought maybe there is weird behavior in windows, but I retested against
windows and the program only seems to get away with it because the windows dlls
don't have a ".edata" section.

Not sure if we want to mimic that windows behavior to make that broken program
happy.

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

Dario  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #11 from Dario  ---
I think this might be related to issue
https://bugs.winehq.org/show_bug.cgi?id=57395 although the attached patch does
not work for that issue.

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

--- Comment #12 from Fabian Maurer  ---
(In reply to Dario from comment #11)
> I think this might be related to issue
> https://bugs.winehq.org/show_bug.cgi?id=57395 although the attached patch
> does not work for that issue.

Why do you think they are related?

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

--- Comment #13 from Dario  ---
«Resident Evil - Seamless HD Project» and «Resident Evil 2 - Seamless HD
Project» do work while «Resident Evil 3 - Seamless HD Project» does not.
Injecting DLLs of all three games only use a few methods from the standard
library and Libwebp. The one that does not work though, additionally uses
functions from KERNEL32.dll in its injecting DLL, namely
«FlushInstructionCache», «FreeLibrary», «GetCurrentProcess», «LoadLibraryA» and
«VirtualProtect».

All of the three look similar in their implementation, but in the one that does
not work the methods for loading high definition textures are never executed.

[Bug 56968] Easyhook remote hooking does not work, breaking some game modding frameworks

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56968

--- Comment #14 from Dario  ---
(In reply to Dario from comment #11)
> I think this might be related to issue
> https://bugs.winehq.org/show_bug.cgi?id=57395 although the attached patch
> does not work for that issue.

Likely not related to the issue I mentioned in my previous comment, but I have
a workaround for that issue: https://bugs.winehq.org/show_bug.cgi?id=53775#c12