originally I investigated an issue with Bitdefender and chrome failing to start while hooking NtOpenProcess or NtCreateFile. Later i realized, that Bitdefender does nothing bad. Its hooks are just forcing MCH to use MIXTURE_MODE instead of default hooking. Once I disabled Bitdefender and set flag MIXTURE_MODE to force using mixture mode chrome is failing to start again showing only black tabs. There is definitely a problem in chrome while using MCH's MIXTURE_MODE.
It look like everything was success, import and export tables are all patched, but somehow chrome doesn't load properly. What is wrong?
All I know is that the problem is happening in the MAIN chrome process. Other chrome child subprocesses seems to be OK with MIXTURE_MODE.
Our testing hooks are only using minimum code like return orig(params).
I am using W10 x64, but i think that OS is not important.
I am using latest beta version of MCH3 downloaded in viewtopic.php?f=7&t=28273.
I was able to do a workaround using FOLLOW_JMP. It helps to bypass Bitdefender's jmp hooks that cause to use MIXTURE_MODE. But that is not a pernament solution, or is it?
Can you try to look into this? Do you need more info? Thx.
The main problem with FOLLOW_JMP is that you're not hooking the target API, anymore, but the other hooking library's callback function. Which means that if the other hooking library unhooks, your hooks will not work any longer, either. Other than that, FOLLOW_JMP should work pretty well...
Lines with * are bitdefender's code.
Code: Select all
0:009> u ntdll!ntopenprocess ntdll!NtOpenProcess: *00007ff8`8ee46580 48b85c060597f77f0000 mov rax,7FF79705065Ch *00007ff8`8ee4658a 50 push rax *00007ff8`8ee4658b c3 ret 00007ff8`8ee4658c 03fe add edi,esi 00007ff8`8ee4658e 7f01 jg ntdll!NtOpenProcess+0x11 (00007ff8`8ee46591) 00007ff8`8ee46590 7503 jne ntdll!NtOpenProcess+0x15 (00007ff8`8ee46595) 00007ff8`8ee46592 0f05 syscall 00007ff8`8ee46594 c3 ret 0:009> u 7FF79705065Ch *00007ff7`9705065c 48b800000497f77f0000 mov rax,7FF797040000h *00007ff7`97050666 50 push rax *00007ff7`97050667 48b890100697f77f0000 mov rax,7FF797061090h *00007ff7`97050671 c3 ret 00007ff7`97050672 4c8bd1 mov r10,rcx 00007ff7`97050675 b845000000 mov eax,45h 00007ff7`9705067a f604250803fe7f01 test byte ptr [SharedUserData+0x308 (00000000`7ffe0308)],1 00007ff7`97050682 50 push rax 0:009> u 7FF797040000h *00007ff7`97040000 4156 push r14 *00007ff7`97040002 55 push rbp *00007ff7`97040003 4881ec08010000 sub rsp,108h *00007ff7`9704000a 4c89442470 mov qword ptr [rsp+70h],r8 *00007ff7`9704000f 4c894c2478 mov qword ptr [rsp+78h],r9 *00007ff7`97040014 4c89942480000000 mov qword ptr [rsp+80h],r10 *00007ff7`9704001c 4c899c2488000000 mov qword ptr [rsp+88h],r11 *00007ff7`97040024 4c89a42490000000 mov qword ptr [rsp+90h],r12 ...
Code: Select all
mov rax,7FF79705065Ch push rax ret
Any idea how to make FOLLOW_JMP work again?
Writing my own follow jmp routine for this case comes up in my mind, but maybe you will want to improve your default routine to handle this case.