A forum for reverse engineering, OS internals and malware analysis
feryno wrote:Primary Processor-Based VM-Execution Controls bit 28 = Use MSR bitmapsI want to "HOOK" RDMSR, when PATCHGUARD read MSR[0xC0000082], I return the original address of KiSystemCall64.
set to 0 = all guest executions of RDMSR / WRMSR cause vm exits
set to 1 = you need to enable corresponding bit in MSR bitmap to intercept MSR you like.
Because you didn't intercept RDMSR, I'm only guessing that your bit 28 of the above control was 1 and corresponding bit in MSR bitmap was 0. Remember MSR bitmap VMCS field is PA, not VA, but to change any bit you need to have it mapped into some VA.
Which MSR you want to watch? You can access some guest MSRs by executing RDMSR in root mode, some guest MSRs are in VMCS so you get them by vmread, some are / are not in VMCS according settings of some control bits (save IA32_EFER VM-exit control and so on).
There are also MSR exit store address and VM entry load address, but that should not lead into missing RDMSR vm exit.
myid wrote: I want to "HOOK" RDMSR, when PATCHGUARD read MSR[0xC0000082], I return the original address of KiSystemCall64.https://bitbucket.org/Nukem9/virtualdbg ... ter#cl-311
Before this, I use WRMSR to set a new MSR[0xC0000082] value.
Do you know my mean? It means I can "HOOK" functions on SSDT without disable PATCHGUARD.
myid wrote:I want to "HOOK" RDMSR, when PATCHGUARD read MSR[0xC0000082], I return the original address of KiSystemCall64.Yes such method you want to use is perfect. The new address you want to write into MSR 0xC0000082 will be executed instead of KiSystemCall64. On RDMSR you'll send original value to patchguard (that's address of KiSystemCall64) so patchguard won't bugcheck. There won't be any hook in SSDT, just this trick with MSR so OS will run without problems and patchguard will be active. This is exactly how Kaspersky klhk.sys is doing it. You need to run this at every CPU/core in SMP - after you solve your settings of things I wrote in previous post (as currently you can't see vm exits at RDMSR of 0xC0000082).
Before this, I use WRMSR to set a new MSR[0xC0000082] value.
Do you know my mean? It means I can "HOOK" functions on SSDT without disable PATCHGUARD.
DeadDead wrote:Thanks. Let me check it.myid wrote: I want to "HOOK" RDMSR, when PATCHGUARD read MSR[0xC0000082], I return the original address of KiSystemCall64.https://bitbucket.org/Nukem9/virtualdbg ... ter#cl-311
Before this, I use WRMSR to set a new MSR[0xC0000082] value.
Do you know my mean? It means I can "HOOK" functions on SSDT without disable PATCHGUARD.
https://bitbucket.org/Nukem9/virtualdbg ... ter#cl-247
Like this? Since I wrote something exactly like you are describing. I never really finished it and it was intended for Windows 8 only. Use any code I guess. (This was also somewhat based on virtdbg)
feryno wrote:YES. Could you give me a demo code? :Dmyid wrote:I want to "HOOK" RDMSR, when PATCHGUARD read MSR[0xC0000082], I return the original address of KiSystemCall64.Yes such method you want to use is perfect. The new address you want to write into MSR 0xC0000082 will be executed instead of KiSystemCall64. On RDMSR you'll send original value to patchguard (that's address of KiSystemCall64) so patchguard won't bugcheck. There won't be any hook in SSDT, just this trick with MSR so OS will run without problems and patchguard will be active. This is exactly how Kaspersky klhk.sys is doing it. You need to run this at every CPU/core in SMP - after you solve your settings of things I wrote in previous post (as currently you can't see vm exits at RDMSR of 0xC0000082).
Before this, I use WRMSR to set a new MSR[0xC0000082] value.
Do you know my mean? It means I can "HOOK" functions on SSDT without disable PATCHGUARD.
