Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revise FunctionHook API to require function prototype information (.NET 9+) #39

Open
alexrp opened this issue Jul 24, 2022 · 1 comment
Assignees
Labels
area: hooking Issues related to the function hooking APIs. area: samples Issues related to the sample projects. state: blocked Issues that are blocked on some other issue/work. type: feature Issues that are classified as feature requests.
Milestone

Comments

@alexrp
Copy link
Sponsor Member

alexrp commented Jul 24, 2022

This is a very long term goal.

The idea is to require the user to somehow communicate the function prototype to the API. The hook gate implementation can then use that information to perform a proper call to the hook function instead of the return address hijacking we do now:

// We now know that we are going to call the hook function. Hijack the current return address so
// that the hook function returns to the code below. This gives us the opportunity to exit through
// the gate. RAX contains the hook function address, so use RCX as scratch here.
asm.lea(rcx, __qword_ptr[exit]);
asm.mov(__qword_ptr[rsp + frameSize], rcx);
asm.jmp(done);

We would also be able to inject extra arguments in the call to the hook function, which might be useful in some scenarios.

There are two approaches we could take:

  • Take a Type parameter in FunctionHook.Create() that must be a function pointer type.
  • Change FunctionHook to have a type parameter TFunction that must be a function pointer type.

The second approach is preferable as it would enable the TargetCode, HookCode, and TrampolineCode properties to be typed properly, cutting down on error-prone casts in user code. This would require both dotnet/runtime#13627 and dotnet/runtime#69273.

The first approach would only require dotnet/runtime#69273 (which seems very likely to arrive in .NET 8), but it also doesn't get us the type safety that the second approach does.

We'll have to wait for .NET 8 and see how things look to determine what we'll do here.

@alexrp alexrp added state: blocked Issues that are blocked on some other issue/work. type: feature Issues that are classified as feature requests. area: samples Issues related to the sample projects. area: hooking Issues related to the function hooking APIs. labels Jul 24, 2022
@alexrp alexrp added this to the v3.0 milestone Jul 24, 2022
@alexrp alexrp self-assigned this Jul 24, 2022
@alexrp
Copy link
Sponsor Member Author

alexrp commented Aug 3, 2023

Function pointer introspection is confirmed to be coming in .NET 8, so the first approach is now viable. Need to think on whether it's worth doing over waiting for the second approach.

@alexrp alexrp changed the title Revise FunctionHook API to require function prototype information (.NET 8+) Revise FunctionHook API to require function prototype information (.NET 9+) Jan 1, 2024
@alexrp alexrp modified the milestones: v3.0, Future Jan 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: hooking Issues related to the function hooking APIs. area: samples Issues related to the sample projects. state: blocked Issues that are blocked on some other issue/work. type: feature Issues that are classified as feature requests.
Development

No branches or pull requests

1 participant