Update README.md

merge-requests/1/merge
_xeroxz 4 years ago
parent 0a16aaaf91
commit 634e660515

@ -19,12 +19,12 @@ This project works on all versions of Windows 10-x64 (2004-1507).
# HookChain - information and order of hooks...
* ###bootmgfw.efi
###bootmgfw.efi
`bootmgfw.ImgArchStartBootApplication` between windows versions 2004-1709 is invoked to start winload.efi. A hook is place on this function in order to install hooks in winload.efi before
winload.efi starts execution. On windows 1703-1511 the symbol/name is different but parameters and return type are the same: `bootmgfw.BlImgStartBootApplication`.
* ###winload.efi
###winload.efi
winload.efi between Windows 10-x64 versions 2004-1709 export a bunch of functions. Some of those functions are then imported by hvloader.dll such as `BlLdrLoadImage`.
Older versions of windows 10-x64 (1703-1507) have another efi file by the name of hvloader.efi. Hvloader.efi contains alot of the same functions that are inside of winload.
@ -33,23 +33,23 @@ You can see that Microsoft simplified hvloader.efi in later versions of Windows
If you look at the project you will see hvloader.c/hvloader.h, these contain the hooks that are placed inside of hvloader and are installed from a hook inside of winload. 1703-1507
requires an extra set of hooks to get to where Hyper-v is loaded into memory.
* ###hvloader.efi
###hvloader.efi
Hvloader.efi (found in windows versions 1703-1507) contains alot of the same functions that can be found inside of winload.efi as explained in the section above. In Windows 10-x64 versions spanning 1703-1507,
Hyper-v is not loaded from a function found in winload.efi but instead of the same function found inside of hvloader.efi. These functions are `hvloader.BlImgLoadPEImageEx`
and `hvloader.BlImgLoadPEImageFromSourceBuffer` for 1703 specifically.
* ###hvix64.exe (Intel)
###hvix64.exe (Intel)
hvix64.exe is the intel version of hyper-v. This module along with hvax64.exe does not have any symbols (no PDB). To find the vmexit handler I simply signature scanned for `0F 78` (vmread instruction)
and then xreferenced the functions that contained this instruction to see if they were called from a stub of code that pushes all registers including xmm's. It took me a little to find the correct
function but once I found the stub (vmexit handler) and c/c++ vmexit handler I was able to make a good enough signature to find the vmexit handler on all of the other Intel
versions of hyper-v.
* ###hvax64.exe (AMD)
###hvax64.exe (AMD)
hvax64.exe is the AMD version of hyper-v. This module along with hvix64.exe does not have any symbols (no PDB). To find the "vmexit handler" if you want to call it that for AMD hypervisors,
i simply signature scanned for `0f 01 d8` (VMRUN). AMD Hypervisors are basiclly a loop, first executing VMLOAD, then VMRUN (which runs the guest until an exit happens), and then
I simply signature scanned for `0f 01 d8` (VMRUN). AMD Hypervisors are basiclly a loop, first executing VMLOAD, then VMRUN (which runs the guest until an exit happens), and then
VMSAVE instruction is executed, the registers are pushed onto the stack, the exit is handled, then VMLOAD/VMRUN is executed again the cycle continues...
# Usage

Loading…
Cancel
Save