Closed bo3b closed 5 years ago
Hi @bo3b thanks for pointing out the issue.
Opcodes F6 05
, F7 05
and 48 F7 05
were not handled at all but I'm adding the code.
Do you know some app/game using this NVidia dll to do tests?
Regards, Mauro.
@mxmauro Thanks for taking a look. Just FYI, no rush for me here, I've got a good workaround, just wanted to report it.
No known game/app using this on NVidia dll. I ran across it while prototyping a new tool.
If it's helpful for you, I can fairly easily make a test case from my Direct Mode sample program.
-bo3b
Hi @bo3b, don't worry. I'll create some dummy app to load the dll.
Hi again @bo3b . Uploaded the code (just source). Seems to work fine on my side.
@mxmauro Looks good. Thanks very much for the timely response.
I'm having trouble verifying the result with my prototype, but could be something else. So I went ahead and made a test branch in my DirectMode sample program to test this specific case. So in case it's helpful, here is a test case that demonstrates the crash, then the next commit fixes the crash using your latest code (as a prebuilt library).
https://github.com/bo3b/3D-Vision-Direct/tree/test_In-Proc
Looks good to me for the RIP test. I cannot speak to the other variants that you've fixed.
@mxmauro Found out what the problem was with my test prototype- two different directories with NktHkLib, using the wrong one. After cleaning that up, I can confirm this works there as well.
Looks good, thanks very much.
Excellent!!
I'm getting a crash while hooking the nvapi function. It looks to me like In-Proc is not updating the relative addressing for the 'test' opcode using RIP register.
I'm using the latest version of the In-Proc code, cloned and built successfully.
Here is the original nvapi_QueryInterface function from nvapi64.dll.
After hooking, we get the debug output from In-Proc:
The
test byte ptr [7FFD6CC52488h],4
is using relative addressing off the RIP register. This is shown in In-Proc disassembly, although the syntax is slightly different in the VS dissassembly.The function address then looks like (disassembly slightly off after jmp):
The trampoline function:
The newly hooked destination function:
Minimized Cpp code implementing hook: