- 01 June 2024 (1 messages)
-
OK,thank you - 03 June 2024 (3 messages)
- 04 June 2024 (75 messages)
-
Joined. -
Guys,
Has anyone previously seen any sample of setting up a TSS (Task State Segment) for a hypervisor?
https://github.com/HyperDbg/HyperDbg/blob/834b43ece965c75bd65761386384a539bd1a3973/hyperdbg/hprdbghv/code/memory/Segmentation.c#L123C5-L123C6 -
Been working on setting a separate TSS (instead of Windows TSS) for HyperDbg, but not sure if I correctly implemented it since the interrupt stack is not within the range. 🤔
-
It still perfectly works but if we're unsure about the correctness of the implementation, it probably causes weird problems in the future.
-
(05:19:52.472 - core : 0 - vmx-root? no) [+] Information (SegmentPrepareHostGdt:123) | Host Interrupt Stack, from: ffffe58189199000, to: ffffe5818919cff0
(05:19:52.472 - core : 1 - vmx-root? no) [+] Information (SegmentPrepareHostGdt:123) | Host Interrupt Stack, from: ffffe581891ab000, to: ffffe581891aeff0
(05:19:52.472 - core : 3 - vmx-root? no) [+] Information (SegmentPrepareHostGdt:123) | Host Interrupt Stack, from: ffffe581891cf000, to: ffffe581891d2ff0
(05:19:52.472 - core : 2 - vmx-root? no) [+] Information (SegmentPrepareHostGdt:123) | Host Interrupt Stack, from: ffffe581891bd000, to: ffffe581891c0ff0
(05:24:27.278 - core : 0 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:177) | Host exception, RIP=fffff804383f5a8e, RSP=ffffe58189192ed0, Vector=3
(05:24:27.333 - core : 1 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:177) | Host exception, RIP=fffff804383f5a8e, RSP=ffffe581891a4ed0, Vector=3
(05:24:27.259 - core : 2 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:177) | Host exception, RIP=fffff804383f5a8e, RSP=ffffe581891b6ed0, Vector=3
(05:24:27.278 - core : 3 - vmx-root? yes) [+] Information (IdtEmulationhandleHostInterrupt:177) | Host exception, RIP=fffff804383f5a8e, RSP=ffffe581891c8ed0, Vector=3 -
-
@honorary_bot do have any idea about this?
-
The problem here is that the exception stack is not within the core's allocated range.
-
I don’t remember from top of my head, gonna have to recheck in the evening. So you’ve set up tss stack pointers, but the exception stack is switched to something different in exception? -
Yes, exactly
-
As stack grows downward, probably I should put the latest (aligned byte address) of the stack. But it seems that Intel didn't mention it. So, not sure whether I should put the base address or the end of the stack.
-
It’s likely just a misconfiguration, but I’ll check how I do that
-
Do you index cores by apic id?
-
Still, the base address as the stack doesn't make sense since the processor doesn't have any idea about the end of the stack.
-
By KeGetCurrentProcessorNumberEx, not sure if it's based on APIC ID or not.
-
Surely it's from prcb, so i'd need to check prcb init code, which is more than 2 minutes :\
-
But both VMCS HOST IDT exception handler and the code that I wrote use the same core number, so does it make any difference? 🤔
-
You're right, just wanted to make sure
-
Wait a sec, you were asking about TSS first, but then you're talking about IDT and exceptions
-
Also, which exception are you testing?
-
Vector number 3 (#BP)
-
A breakpoint within VMX-root mode.
-
PULSE_STATUS VmUtilAllocateStack(uint64_t aStackSize, uint64_t *aStackBase)
{
if (aStackBase == NULL)
return PULSE_STATUS_INVALID_PARAMETER;
if ((aStackSize < PAGE_4K_SIZE) || (aStackSize > g_vmm.LoaderParams.CoreRegionSize))
return PULSE_STATUS_INVALID_PARAMETER;
*aStackBase = PoolAllocPages(aStackSize / PAGE_4K_SIZE);
if (*aStackBase == NULL)
return PULSE_STATUS_INSUFFICIENT_RESOURCES;
return PULSE_STATUS_SUCCESS;
}
PULSE_STATUS VmUtilAllocateInitStack(uint64_t aStackSize, uint64_t *aStackBase)
{
PULSE_STATUS status = PULSE_STATUS_SUCCESS;
status = VmUtilAllocateStack(aStackSize, aStackBase);
if (status != PULSE_STATUS_SUCCESS)
return status;
*aStackBase = *aStackBase + (aStackSize - 8);
return PULSE_STATUS_SUCCESS;
} -
If it helps
-
pTss->Rsp0 = pHostCpu->Stack;
status = VmUtilAllocateInitStack(0x1000, &(pTss->IST1));
if (status != PULSE_STATUS_SUCCESS)
return status;
status = VmUtilAllocateInitStack(0x1000, &(pTss->IST2));
if (status != PULSE_STATUS_SUCCESS)
return status;
status = VmUtilAllocateInitStack(0x1000, &(pTss->IST3));
if (status != PULSE_STATUS_SUCCESS)
return status; -
Can you also share what you configured for HOST_GDT_BASE and how you configured other fields of pTss?
-
Is it a VMCS field? Sorry, I did that in 2015, so I don't really remember :)
-
Just wanna re-check it with my configuration since I did the exact same config but it seems the stack RSP of exception is not within range for some other reasons.
-
No, just the value of HOST_GDTR_BASE
-
I only configured IoMapBaseAddress to 100 (which is incorrect btw, but it doesn't matter in my case) and pTss->Rsp0 = pHostCpu->Stack; which is also allocated by function above.
-
Since we previously use Windows GDT and IDT as Host GDT and IDT, right now I changed the implementation to configure our own GDT, IDT.
-
Yeah, but what structy is it in?
-
or is it gdtr reg?
-
GDTR reg (for host) needs to have some entries (and the TSS should be here).
-
The TSS itself has other bits (in its entry on GDT, like LowSegmentLimit etc. ) I'm not sure if I correctly configured that.
-
Since basically I did the same in HyperDbg but still the stack is not within the expected range, I think it might be an issue with the actual TSS entry configuration in GDT.
-
Let me step back a bit. It is still not clear to me what you're trying to achieve.
-
Sp you set up a dedicated gdtr for vmx root mode, right?
-
Yes
-
Then the OS runs in a vmx non root (guest) mode, right?
-
Yes
-
So, you want to trap a breakpoint, but does it occur in vmx root on vmx non root mode?
-
And I wanted to build a dedicated gdt for Host.
-
It occurs in vmx root mode.
-
You have also filled vmcs like this?
if (__vmx_vmwrite(VMCE_HOST_GDTR_BASE, g_vmm.pCpu[CpuSlot].HostCpu.DescTables) != 0)
return PULSE_STATUS_VMWRITE_FAILED;
if (__vmx_vmwrite(VMCE_HOST_IDTR_BASE, g_vmm.pCpu[CpuSlot].HostCpu.InterruptDesc) != 0)
return PULSE_STATUS_VMWRITE_FAILED;
if (__vmx_vmwrite(VMCE_HOST_TSS_BASE, g_vmm.pCpu[CpuSlot].HostCpu.Tss) != 0)
return PULSE_STATUS_VMWRITE_FAILED; -
Since we configured TSS stack for IST3, the breakpoint should be handled with host ID (the one dedicated to HyperDbg) but the rsp of the arrived breakpoint is not within the expected range.
-
Is your root mode operating in Rind0 mode?
-
Ignore the structs, the just should be some address
-
Yes exactly. And what I need is how you filled/configureed g_vmm.pCpu[CpuSlot].HostCpu.Tss and g_vmm.pCpu[CpuSlot].HostCpu.DescTable.
-
?
-
// Task entries
uint64_t tssAddr = &(pIdtEntry[256]);
PCPU_TSS_DESCRIPTOR64 pTssEntry = (PCPU_TSS_DESCRIPTOR64)(&(pGdtEntry[VMM_HOST_TASK_SEG_DESC_NUM]));
pTssEntry->P = 1;
pTssEntry->S = 0;
pTssEntry->Type = SYS_SEG_TYPE_AVAIL_TSS64;
pTssEntry->LimitLow = sizeof(CPU_TSS64);
pTssEntry->LimitHigh = 0;
pTssEntry->BaseLow = tssAddr & 0xFFFF;
pTssEntry->BaseMid = (tssAddr >> 16) & 0xFF;
pTssEntry->BaseHigh = (tssAddr >> 24) & 0xFF;
pTssEntry->BaseAddrHigh64 = (tssAddr >> 32) & 0xFFFFFFFF;
pTssEntry->AVL = 0;
pTssEntry->G = 0;
pTssEntry->DPL = 0;
pTssEntry->DB = 0;
pTssEntry->L = 0;
// TSS
pHostCpu->Tss = tssAddr;
PCPU_TSS64 pTss = (PCPU_TSS64)(tssAddr);
pTss->IoMapBaseAddress = 100; // 104 ?
pTss->Rsp0 = pHostCpu->Stack;
status = VmUtilAllocateInitStack(0x1000, &(pTss->IST1));
if (status != PULSE_STATUS_SUCCESS)
return status;
status = VmUtilAllocateInitStack(0x1000, &(pTss->IST2));
if (status != PULSE_STATUS_SUCCESS)
return status;
status = VmUtilAllocateInitStack(0x1000, &(pTss->IST3));
if (status != PULSE_STATUS_SUCCESS)
return status; -
Rind0 mode?
-
ring 0
-
Yes, but curious to know, could run in any different modes? 🤨
-
Well that's why it's working like that
-
You have no ring transition
-
You're already in ring 0
-
So no stack switch for you
-
Of course you could run VMX root ring 3
-
But it's a breakpoint (so shouldn't it use Tss.IST3?)
-
Didn't knew that 😳
-
Like a user-mode application running in VMX root mode?
-
From top of my head - only NMIs, double faults and smth else would have a separate stack
-
Don't really remember about int3, but it makes sense not to switch the stack for it
-
You can create an operating system running in VMX root, right? It would have both kernel and user mode
-
Ah, if it's the way you say, then that's why the stack is not within the range.
-
yes, it just uses your current rsp
-
So, basically the implementation is correct.
-
So stack switch is for NMI, DebugOrTrap (int1 though, not 3), double fault, machine check
-
It makes sense to swap stack for int1, because you can trap task switcch with debug registers
-
but int3 is just a code breakpoint
-
Makes sense.
-
Anyway, thank you for always being helpful. You saved me a lot of time for this.
-
No problem!
-
- 05 June 2024 (2 messages)
-
Hello everyone,
I've made a somehow big update in the HyperDbg. Now, it utilizes a dedicated HOST IDT and HOST GDT, different than the Windows IDT/GDT. This update will address a specific category of bypasses for HyperDbg, although there are still many bypasses to address. This change influences the handling of interrupts, especially NMIs for halting cores in VMX root-mode. lt may introduce instability issues in various systems, potentially leading to crashes. If you're using HyperDbg, please switch to the 'dev' branch and re-build and test it to help us identify any problems. Currently, it works well on my 12th Gen machine, but I'm uncertain if it's universally stable. If you encounter any crashes or BSODs, please notify me before the release of v0.9 (the next version). The best way to test it is using events (EPT hooks) with a high rate of execution (e.g., using !epthook on nt!ExAllocatePoolWithTag and meanwhile pause the debuggee).
The 'dev' branch:
https://github.com/HyperDbg/HyperDbg/tree/dev
GitHub built artifact for those who can't build:
https://github.com/HyperDbg/HyperDbg/actions/runs/9384856535GitHub - HyperDbg/HyperDbg at devState-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
-
None
- 06 June 2024 (3 messages)
-
One more thing to mention, if you guys encounter "invalid address error", this new instruction is for fixing it:
https://docs.hyperdbg.org/tips-and-tricks/considerations/accessing-invalid-addressAccessing Invalid Address | HyperDbg DocumentationConsiderations for accessing memory in different modes
-
The primary difference is that previously (before v0.9), the '.pagein' command doesn't guarantee locking all the cores and immediately after the '.pagein' command, you couldn't apply any events (e.g., !epthook or !monitor) but since HyperDbg uses a dedicated Host IDT at its newest version, it is guaranteed to lock all the cores after running the '.pagein' command. Hence, you shouldn't have any problem applying events after forcing OS to bring the pages into the page-table or make them present in the current process's memory.
- 08 June 2024 (3 messages)
-
Hi guys!
As a new feature, starting from v0.9 HyperDbg will support monitoring EPT hooks on physical addresses (previously it only supported virtual addresses), mainly through the 'MemoryType' parameter. You can now use it from the 'dev' branch.
https://docs.hyperdbg.org/commands/extension-commands/monitor -
This is mainly useful for those who want to monitor PCIe buffers.
- 09 June 2024 (5 messages)
-
HyperDbg v0.9 is released! ✨
It features monitoring physical addresses for tracking read/write to PCI-e and IOMMU buffers. Plus, HyperDbg now uses a dedicated Host IDT/GDT.
🔗 Check it out: https://github.com/HyperDbg/HyperDbg/releases/tag/v0.9.0
📖 Read more:
https://docs.hyperdbg.org/commands/extension-commands/monitor
# Added
- The !monitor command now physical address hooking
- hwdbg is merged to HyperDbg codebase
- strncmp(Str1, Str2, Num), and wcsncmp(WStr1, WStr2, Num) functions in script engine
# Changed
- Using a separate HOST IDT in VMCS (not OS IDT)
- Using a dedicated HOST GDT and TSS Stack
- Checking for race-condition of not locked cores before applying instant-events and switching cores
- The error message for invalid address is changed (more information)
- Fix the problem of not locking all cores after running the '.pagein' commandRelease v0.9.0 · HyperDbg/HyperDbgHyperDbg v0.9.0 is released! If you’re enjoying HyperDbg, don’t forget to give a star 🌟 on GitHub! Please visit Build & Install to configure the environment for running HyperDbg. Check out the ...
-
Joined. - 10 June 2024 (2 messages)
- 12 June 2024 (1 messages)
- 13 June 2024 (98 messages)
-
HyperDbg supports debugging 32-bits apps. You just need to use special commands (e.g., 'u32' instead of 'u' for disassembling codes), but in case if you use the wrong command ('u32' on a 64-bit app or 'u' on a 32-bit app, it will show a message and notify you. Other than everything is similar to debugging a 64 bit app.
-
About kernel modules, is there any 32 bit driver on a 64 bit machine? If I remember correctly that's not possible in Windows. 🤔
-
here is screen from process monitor, i dont see those modules neither in user or kernel mode
-
@HughEverett hey man! I don’t know why I recalled it now, but remember you were asking about vmx root ring3 mode? The obvious example is when you’re running VMware workstation on windows. When you launch a VM, your Windows becomes a vmx root, right? That basically means it keeps working in vmx root, while still having kernel and user modes ;)
-
Not sure if I understand it correctly, what is this screen?
-
HyperDbg doesn't support 32 bit operating systems but it fully supports 32 bit applications in 64 bit operating systems.
-
Oh, that's interesting. Initially I thought that they virtualize the entire system and handle these things from Host Kernel-mode, but this kind of design (using Host User-mode) is really cool. 👌
-
here is full screen. guest is w10 x64. process monitor shows all loaded modules by particular process (like WSOCK32.dll in which im interested), but i cant find any reference to it in hpyerdbg
-
Did you try the 'lm' command in HyperDbg? Isn't it what you need?
https://docs.hyperdbg.org/commands/debugging-commands/lmlm (view loaded modules) | HyperDbg DocumentationDescription of the 'lm' command in HyperDbg.
-
The 'lm' command has a 'pid' argument, did you try that?
By default if you're in the context of hyperdbg-cli.exe then it shows the modules of the hyperdbg process. You can check it by using the '.process' command. -
HyperDbg> lm um m kernel pid 1240
user mode
start entrypoint path
00007ffd88860000 00007ffd888770d0 C:\Windows\System32\KERNEL32.DLL
00007ffd865f0000 00007ffd865f92c0 C:\Windows\System32\KERNELBASE.dll -
Use it like: lm m sock pid 1cb0
-
You mean the process uses some kind of anti-debugging techniques?
-
HyperDbg simply reads the user mode modules list from PEB but it's highly probable that due to an anti-debugging technique the process hides it's PEB.
-
WSOCK32.dll is user module, so you can simply read it's address from any other processes.
-
The addresses remain constant in Windows (before you restart), which is in contrast to Linux (which creates new ASLR addresses each time you run a new process).
-
Yep, that's interesting. I don't have any idea where they gather their user-mode modules list. 🤔
-
Also, if you have problem loading symbol files for your target process, try to run a similar 32-bit process (that loads WSOCK32.dll) and then HyperDbg even if you switch to other processes, still uses the old symbol table. Which will be useful for your case.
-
Does it work? Is your process corrupting symbol hashes?
-
Are you sure the address is valid?
-
Did you check this? https://docs.hyperdbg.org/tips-and-tricks/considerations/accessing-invalid-addressAccessing Invalid Address | HyperDbg Documentation
Considerations for accessing memory in different modes
-
Are you sure that you're using the latest version v0.9?
-
I'm pretty sure I changed the error message for invalid access
-
Once you run HyperDbg it shows the version + build.
-
Could you test the same command (which restarts your computer immediately) with v0.9?
-
Crashed?
-
No BSOD? Just restart?
-
🤔
-
Could you change the flag of the '.pagein'?
Use it like:
.pagein u Address
And if it crashed again:
.pagein pf Address
https://docs.hyperdbg.org/commands/meta-commands/.pagein.pagein (bring the page into the RAM) | HyperDbg DocumentationDescription of the '.pagein' command in HyperDbg.
-
I'm gonna see whether it's a #PF misconfiguration or a VMware error. Because generally, we're just injecting page-fault, it shouldn't crash the vCpu. 🤔
-
And one more thing, are you sure that you're using the '.pagein' in a valid process?
-
I mean you might accidentally inject the page-fault while HyperDbg is in its own process (hyperdbg-cli.exe), in this case, a crash is inevitable.
-
Since the address is not valid/assigned in hyperdbg-cli.exe's CR3.
-
You could check the current process by using the '.process' command.
-
And it also crashes without 'u' in the '.pagein'?
-
I think I understand the problem. This crash happens probably because you halted the process in the kernel-mode right before switching to another process.
-
@HughEverett seems like you have a symbol engine. Do you use MS DIA?
-
You need to grab the execution in other ways (other than using .process).
-
Do you start the process using the '.start' command?
-
Could you try to start it with the '.start' command? and once HyperDbg halted your process, reaching to the entry point, use the '.pagein'.
-
Yes, HyperDbg uses DIA SDK.
-
.start (start a new process) | HyperDbg Documentation
Description of the '.start' command in HyperDbg.
-
Or if you can halt the process any other ways, like putting breakpoint somewhere or any other methods, then use the '.pagein'. I think the problem is with the state we intercept the execution using the '.process' command. 🤔
-
One option is using the '!monitor' command with 'x' attribute on the memory range of the main module of the target process. In this case, if you're main module fetches instructions, then HyperDbg halts debuggee for you.
https://docs.hyperdbg.org/commands/extension-commands/monitor!monitor (monitor read/write/execute to a range of memory) | HyperDbg DocumentationDescription of the '!monitor' command in HyperDbg.
-
Are you sure? The way that we start process is not same as other debuggers.
-
HyperDbg doesn't use the DEBUG flag for the CreateProcess win32 API.
-
If you couldn't fix the issue, I'll come with more options/solutions tomorrow. I'm gonna go sleep now. 😴💤
Will continue tomorrow ✋ -
Joined. -
-
Good morning everyone. Have a nice day.
-
- 14 June 2024 (26 messages)
-
No, neither the 'x' command nor an invalid command switch to another process, all of them stick to the current running process without continuing debuggee.
-
Didn't get it, does it fix the problem? 🤨
-
.sym reload will continue the debuggee the debuggee but .sym load doesn't continue it.
https://docs.hyperdbg.org/commands/meta-commands/.sym -
You just need to run '.sym reload' one time and after that the symbol table remains constant until next '.sym reload'.
-
Yes, this is expected behavior since by default once you load HyperDbg it transfers only 64-bit symbols.
-
.sym load load symbol files based on the current symbol table that is available in the debugger (host) not debuggee. If you need a specific process (e.g., a 32-bit process in your case) you need to use the '.sym reload' since the details of the symbols are not available at the debugger (host).
-
No still it needs to '.sym reload' to build a symbol table. You can add symbols manually if you want.
-
But still I think the best way is to '.sym reload' one time (e.g., start the process and then .sym reload pid xxx), then use the symbol table for the rest of your debugging commands.
-
-
(Strong IMHO) I'd rather have full understanding and control over my code. Especially given the fact that windows kernel programming environment has a lot of extra limitations of what you can do.
-
Agree. I'm using it for almost one month, although it's helpful in some cases but doesn't make good suggestions most of the times.
-
It's not about the money :)
-
HyperDbg is currently stable, with most of its functionalities now available in Debugger Mode rather than VMI Mode.
I recommend starting with OST2 videos, as HyperDbg is little bit different than classic Windows debuggers and requires users to be familiar with some specific concepts and considerations before using it.
https://www.youtube.com/playlist?list=PLUFkSN0XLZ-kF1f143wlw8ujlH2A45nZY - 15 June 2024 (31 messages)
-
Hi there! Kind of yes, but not just that. I'd say it's a software that manages some sort of virtualization overall. If we're talking about Intel specifically, it's a software for managing VMX mode execution of CPU (put aside platform and external devices for now). EPT is a feature of VMX. There are many other features as well.
-
If you're familiar with a concept of page faults, then it's the same thing, it's just not an exception but rather a "VMX event"
-
I mean yes, you could say so
-
Yes
-
You have to fill out the VMCS properly and completely and set handlers for vmx exits first.
-
Unfortunately, partial implementation of the hypervisor is not feasible
-
So you have a concept of host mode and a guest mode
-
Host mode is where hypervisor is executed, guest is where a guest OS is executing
-
whenever you execute vmlaunch instruction, you enter vmx guest mode
-
for that you need to initialize vmcs guest fields
-
then, in order to return to host mode, some sort of vmexit event is needed in guest mode
-
and surely you need properly configured vmx host vmcs fields
-
hopefully this clarifies how vmx works
-
As an additional resource, you might also find the "Hypervisor from Scratch" tutorial helpful in understanding how VMX works. You can access it here:
https://rayanfam.com/tutorials/TutorialsWe write about Windows Internals, Hypervisors, Linux, and Networks.
-
It depends on the type of the VMX event, like sometimes you need to readjust RIP value or something, but in general you don't need to reconfigure much between vmresumes
-
EPT describes guest physical memory to host physical memory mapping
-
What mode do you want to run your code in?
-
-
Good morning everyone. Have a nice day.
-
Good Moring Ting Zhang Qi - 16 June 2024 (43 messages)
-
Hi! Still not sure what you mean by "virtualize"
-
You have a CPU, right. When VMX is enabled, you can execute either in VMX root or VMX non-root (guest) mode.
-
If you have a shell code, you may just execute it as either VMX root or VMX guest
-
Do you imply physical memory virtualization?
-
Yes, I've mentioned it here
-
By virtualizing the current system, do you mean entering to VMX guest mode with a custom EPT?
-
Sorry to choke you on that one, but it's much easier to understand each other when you use common technical terms, which come from Intels Software Developers Manual in this case
-
There are many vmexit conditions available in VMX. Like cpuid instruction for instance. I'd recommend skimming through vol 3 chapter 28 of Intel's SDM.
-
You cannot use the 'k' command within a !epthook script since it's a command not a script function, but you can write the functionality of the printing callstack by using a simple script.
-
I think I wrote something similar for one of my projects years ago, lemme check.
-
? n = 5;
? m = 50;
? for (j = 0; j != m; j++) {
temp = @rsp + (j * 8);
printf("%llx", temp);
for (i = 0; i != n; i++) {
is_valid = check_address(temp);
if (is_valid == 1) {
temptemp = temp;
temp = poi(temp);
is_valid2 = check_address(temp);
if (is_valid2 == 1) {
printf("-> %llx", temp);
} else {
test1 = db(temptemp);
test2 = db(temptemp + 1);
if (test1 > 1f && test1 < 7f) {
if (test2 == 0x0) {
printf(" (%ws)", temptemp);
} else {
printf(" (%s)", temptemp);
}
}
}
} else {
break;
}
}
printf("\n");
} -
-
-
Yes, you basically need something like the above script.
-
hey there, is it possible to discard handling of cpuid instruction in the hypervisor and leave it to the cpu? -
-
Unfortunately not, it is an unconditional vm exit
-
As @honorary_bot mentioned it's an unconditional VM-exit but generally HyperDbg won't touch the results of CPU's CPUID registers. So, the problem here is just VM-exit timing, other than that HyperDbg won't modify the CPUID results (we just set the hypervisor bit, and Hypervisor signature which can be ignored by a simple script).
-
then is there any way to prevent the guest from spamming cpuid instruction, it absolutely kills performance
-
I have a specific program which does that
-
if ran without hypervisor, performance is okay
-
Why don't you nop those CPUID instruction?
-
I believe it uses cpuid to get information from it plus time measurements
-
You can write a HyperDbg script to nop all occurrence of CPUIDs. Something like this:
!cpuid pid XX {
// CPUID = 0F A2
eb(@rip, 90);
eb(@rip + 1, 90);
} -
You can also find the execution of RDTSC/RDTSCP instructions for timing by using the !tsc command and nop it similar to the above script. Also, manual investigation might be needed to avoid breaking the process's semantics.
https://docs.hyperdbg.org/commands/extension-commands/tsc!tsc (hook RDTSC/RDTSCP instruction execution) | HyperDbg DocumentationDescription of the '!tsc' command in HyperDbg.
-
Man, btw, there is a tiny case where you should still adjust cpuid result for the guest. You need to readjust cr4.osxsave and cr4.pke to reflect not the host mode, but the guest mode when returning data to the guest. Those cpuid bits depend on cr4: leaf 1 and leaf 7 respectively
-
I think its not possible if the function which executes cpuid is virtualized
-
like what kind of virtualization? you mean obfuscated?
-
yes, these proprietary software protectors bruh
-
Maybe we should introduce techincal terms in this chat in order us to understand each other better? :)
-
😅
-
yes
-
not instruction length actually, memory size is the correct term
- 17 June 2024 (93 messages)
-
Yes, you need to disable exceptions/faults/traps (not exactly interrupts in HyperDbg terms). Anyway, both of them are possible in HyperDbg by using the !exception and !interrupt commands along with short-circuiting.
Please check:
https://docs.hyperdbg.org/commands/extension-commands/exception
https://docs.hyperdbg.org/tips-and-tricks/misc/event-short-circuiting!exception (hook first 32 entries of IDT) | HyperDbg DocumentationDescription of the '!exception' command in HyperDbg.
-
You need something like this:
!exception 1 pid XX {
event_sc(1);
} -
Other than, if you're dealing with the Debugger Mode, you can also tell HyperDbg not to intercept Traps or Breakpoints and later short-circuit it by the !exception command. Something like :
test breakpoint off
test trap off -
No difference, works the same in both user-mode and kernel-mode.
-
Use the '!dr' command along with short-circuiting mechanism:
https://docs.hyperdbg.org/commands/extension-commands/dr!dr (hook access to debug registers) | HyperDbg DocumentationDescription of the '!dr' command in HyperDbg.
-
@instw0 check these videos:
https://www.youtube.com/watch?v=OBcTwRkCE68&list=PLUFkSN0XLZ-kF1f143wlw8ujlH2A45nZY&index=50
https://www.youtube.com/watch?v=Z6HAO4btkCM&list=PLUFkSN0XLZ-kF1f143wlw8ujlH2A45nZY&index=60Dbg3301: HyperDbg 08 06 Debug Register MonitoringView the full free MOOC at https://ost2.fyi/Dbg3301. This course is an introductory guide to HyperDbg debugger, guiding you through the initial steps of using HyperDbg, covering essential concepts, principles, debugging functionalities, along with practical examples and numerous reverse engineering methods that are unique to HyperDbg. Whether you have an interest in reverse engineering or seek to elevate your reverse engineering skills with hypervisor-assisted approaches, this course provides a solid foundation for starting your journey.
-
exactly
-
Just make sure to use a printf to make sure it works as expected since I never test short-circuiting with the '!dr' events.
-
But it should work
-
add semicolon
-
event_sc
-
reconnect to HyperDbg? This error is not related to this event.
-
Another unrelated error happened there.
-
use it like :
!dr script {
event_sc(1);
printf("ignoring debug reg modification from %s, pid: %x\n", $pname, $pid);
} -
It's okay, you just need to tell HyperDbg not to intercept breakpoints/traps if you want to use Windbg.
-
this one
-
What do you mean?
-
You mean HyperDbg didn't intercept hardware breakpoint accesses? or it ignore them successfully as expected?
-
you mean once you try to access them (view the list of debug breakpoints) windbg won't show them?
-
I don't understand what you're trying to do. 🙂
If you want to ignore them using the '!dr' command, then why do you expect them to be triggered? -
HyperDbg can also manually inject #DBs which is how debug breakpoint registers notify about their trigger events.
https://docs.hyperdbg.org/commands/scripting-language/functions/events/event_injectevent_inject | HyperDbg DocumentationDescription of the 'event_inject' function in HyperDbg Scripts
-
Why? HyperDbg's 't' command has problem? 🤨
-
Is it also the same for the instrumentation step-in (the 'i' command)?
-
Ah, got it.
-
When you run (test trap off) HyperDbg won't handle traps anymore. Everything is passed to the OS (Windbg).
-
No the problem is that cpuid will cause VM-exit before trap flag by default in Intel processors.
-
CPUID unconditionally cause a VM-exit and in HyperDbg a trap flag (#DB) will also cause a VM-exit but in Intel processors, CPUID has precedence over #DB (or more accurately RFLAGs.TF), that's why HyperDbg first receives and handles CPUIDs then processor triggers trap flag.
-
I'm thinking of a fast patch to this. Are you currently stepping through these instructions? I mean how do you test it?
-
I think this can be handled by a combination of the '!exception' command and the '!cpuid' command, but not sure. 🧐
-
Wait a moment, I'll make a patch, and will let you know.
-
@instw0 pls checkout to this branch and recompile HyperDbg:
https://github.com/HyperDbg/HyperDbg/tree/trap-cpuidGitHub - HyperDbg/HyperDbg at trap-cpuidState-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
-
Let me know if it fixes the issue, I added this check to this branch (but not test it):
https://github.com/HyperDbg/HyperDbg/commit/ddbf929aa2043d0a65887e4fd428bfe6afddd43fdetect and handle CPUIDs with TRAP flag · HyperDbg/HyperDbg@ddbf929State-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
-
Don't use the '!tsc' for now, just try to see if HyperDbg shows this message or not?
Does it show this message? -
So, the way that VMProtect detects hyperviosr (HyperDbg) is not based on this trick.
-
It depends, CPUID is an unconditional VM-exit but RDTSC/RDTSCP only cause VM-exit when you use the !tsc command in HyperDbg.
-
Hi,
Scala is used as a part of porting HyperDbg into the hardware (Chip & FPGA) debugging (hwdbg). It is mainly written based on the Chisel language: https://www.chisel-lang.org
If you want to test and use hardware debugging, then you need an FPGA. Basically, this Scala code that I wrote for hwdbg generates Verilog and SystemVerilog (HDL) codes that are synthesizable into FPGAs.
For the issue I posted on GitHub early today, I didn't mean to modify the Scala code, I just meant to show you how I implemented the evaluation engine in hardware, so basically a simple modification on the INC++ and DEC++ operands in the C code is needed.
I wrote the evaluation engine in Scala (https://github.com/HyperDbg/HyperDbg/blob/45b88f652d071e0f3c11b1f84b8a2a2d6556972a/hwdbg/src/main/scala/hwdbg/script/eval.scala#L97).
The concept is the same, HyperDbg makes a script buffer using C/C++ codes and once the script buffer is ready, we'll send it to the hwdbg (through either Serial port or shared BlockRAM). The generated hardware part (the Scala code) is responsible for running those script buffers that we generated in the script engine.Chisel | ChiselSoftware-defined hardware
-
HyperDbg has a dump command (previously requested by @ricnar) and documented:
https://docs.hyperdbg.org/commands/extension-commands/dump!dump (save the physical memory into a file) | HyperDbg DocumentationDescription of '!dump' command in HyperDbg.
-
But it transfer buffer over serial.
-
If you need any other kind of implementation, I think you can easily implement it by creating a new command based on this dump command.
-
and of course, create a PR so everyone can use it. 🙂
-
-
-
-
Could you share disassembly of instructions after popfq?
-
No, none of them are related to EPT hooks.
-
Let me send you a link about its design.
-
Please check this doc:
https://research.hyperdbg.org/assets/documents/kernel-debugger-design-1st-edition.pdf -
It explains how these commands (specially the instrumentation step-in) is implemented.
- 18 June 2024 (8 messages)
-
Only the 'i' command (instrumentation step-in) uses MTF (Monitor Trap Flag). Other stepping command like 't' is implemented same as WinDbg by using RFLAGS's TF.
-
NMI is not realted to step-in or step-over, HyperDbg just uses NMI to halt (pause) all cores in the Debugger Mode.
-
Not sure if I correctly understand what you mean. 🤔
What is event(!cpu)? - 19 June 2024 (25 messages)
-
For !tsc Yes, for !cpuid No. CPUID is unconditional VM-exit. Here is a list of instructions with unconditional VM-exit.
-
We process it as VM-exit, not interrupt.
-
RDTSC is configured from VMCS, VMCALL is unconditional VM-exit and !msrread !msrwrite use MSR Bitmaps. Take a look at Hypervisor From Scratch, I think it gives you an idea how HyperDbg works internally:
https://rayanfam.com/tutorials/TutorialsWe write about Windows Internals, Hypervisors, Linux, and Networks.
-
You need to provide more details. What is the generation of your processor? which version of Windows? and how to reproduce it?
-
Not related to hyperdbg, but vmprotect does not care if you break at cpuid or at the nop. https://github.com/jmpoep/vmprotect-3.5.1/blob/d8fcb7c0ffd4fb45a8cfbd770c8b117d7dbe52b5/runtime/core.cc#L771
-
Ah yes, my bad. It actually cares 😀 https://github.com/jmpoep/vmprotect-3.5.1/blob/d8fcb7c0ffd4fb45a8cfbd770c8b117d7dbe52b5/runtime/core.cc#L306
-
Conditions checks for each extension command is basically software-side implemented. RDTSC/RDTSCP cause conditional VM-exits (not remember, either on primary or secondary proc-based VMCS controls).
-
Development progress update: hwdbg has reached the point where it can run HyperDbg scripts (dslang) for chip/FPGA debugging. Still under development!
https://github.com/HyperDbg/HyperDbg/tree/dev/hwdbg -
-
@xmaple555 we need to think of the best way to parse scripts of the hwdbg debugger. The registers and pseudo-registers of the hwdbg is different from x64 registers. 🤔
-
Basically, hwdbg registers are like @hw_pin0, @hw_pin1, @hw_pin2, ..., @hw_pinX and @hw_port0, @hw_port1, @hw_port2, ..., @hw_portX. We need to find the best way of adding these registers (and new pseudo-registers) to the parser.
-
VMCALL is unconditional, !dr needs configuration. Pls check this file as it's the file responsible for configuring events:
https://github.com/HyperDbg/HyperDbg/blob/master/hyperdbg/hprdbgkd/code/debugger/events/ApplyEvents.cHyperDbg/hyperdbg/hprdbgkd/code/debugger/events/ApplyEvents.c at master · HyperDbg/HyperDbgState-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
-
hey there, im trying to build solution and getting:
- 20 June 2024 (66 messages)
-
有没有自己人？😁
-
Ah, this one is also mentioned by another person in issues. This one should be updated in the phnt repo that we used it as a submodule. We could also update HyperDbg's fork and comment it. I'll fix it.
-
Not sure what you trying to do? The division by zero error you're trying produce is handled in VMX root-mode because all of the events (except !epthook2, not !epthook) execute assembly in VMX root-mode, so it's not handled by guest (Windows) IDT and it's passed to HyperDbg's HOST IDT exception handler.
-
Yes
-
Just added a check? Any modification to the TF Flag?
-
Yes a trap flag generates a #Db.
-
If I were in your shoes, I tried to make a simple application with your target technique (popfq TF), and I try to trigger the behavior in HyperDbg like showing a message using (LogInfo) without modifying anything. Once I was sure that this technique can be correctly detected (by seeing the message), then I try to modify the guest state. I think this is the best approach to handle this VMProtect technique.
-
Yes, but it depends on when CPU gives us this #Db, the reason such a technique exists is because CPUID has precedence over #Db's exception bitmap vm-exit.
-
Ah, unfortunately this feature is not working as expected. We previously had a discussion in this group and conclude that this feature is not working. You need to use a virtual serial device.
-
.
-
Larry you can follow this discussion, it's probably the problem with verifying packets.
-
Still don't understand what you're trying to do but if you want to trigger an exception in your target user-mode app, you need to inject an event in HyperDbg by using these functions:
https://docs.hyperdbg.org/commands/scripting-language/functions/events/event_inject
And:
https://docs.hyperdbg.org/commands/scripting-language/functions/events/event_inject_error_code
These are the functions that deliver exception to the guest debuggee application. The assembly code you used in your event will cause division by zero in HyperDbg's VMM which is simply handled in VMX root-mode and it's ignored by HyperDbg's division by zero exception handler.event_inject | HyperDbg DocumentationDescription of the 'event_inject' function in HyperDbg Scripts
-
Depends on how CPU behaves in this case. If it triggers immediately then you need to inject a #DB.
-
User-mode try/catch?
-
Are you analyzing a driver?
-
I think you need to create a user-mode application with the same technique.
-
It's easier to modify a user-mode application and introspect it's behavior. Try to make a similar check function check in user-mode.
-
And also post your function here if it's possible. I'm gonna check it too.
-
No, it's the case for HyperDbg. Windows (OS) doesn't have any details about the presence of a top-level (ring -1) debugger.
-
In VMI mode, traps/breakpoints are not intercepted by default.
-
In the Debugger Mode, traps/bps are intercepted.
-
Is it (the entire 4kb of the target page) located on a page with high rate of memory access?
-
So, that's the reason. HyperDbg puts hook on entire 4 kb granularity of the page boundary. Not just 4 bytes. Because it's how EPT works.
-
So, each access to this 4kb cause a VM-exit, but HyperDbg filters it and only show you the accesses on your target address range.
-
Why? 🤔
-
Can you check the entire page boundary?
-
Yes. Get a printf from it
-
And also not sure if you already knew it or not but the $context pseudo-register shows you the address of the memory accessed by the instruction that triggered the hook.
https://docs.hyperdbg.org/commands/extension-commands/monitor#context!monitor (monitor read/write/execute to a range of memory) | HyperDbg DocumentationDescription of the '!monitor' command in HyperDbg.
-
No, the page boundary start from PAGE_ALIGN(001995A4) which means you need sth like:
00199000 l fff -
Or from 199000 to 199fff
-
Ah, so that's the reason
-
The rate of access is too high
-
It does not make that much difference.
-
Once you try to hook 001995a4, HyperDbg will automatically hook the entire page boundary (00199000 to 00199fff) for you.
-
It just doesn't show you once it's not within the range but not showing you doesn't mean it didn't happen.
- 21 June 2024 (4 messages)
-
群里天天都在聊啥
-
看不懂英语
-
有没有自己人讲讲😊
-
祁 同伟
This is an English-speaking group. Please send your messages in English only. You may use an online translator if needed.
___
这是一个英语群组。请仅以英语发送您的消息。如有需要，您可以使用在线翻译。
@hyperdbg / Public archive of HyperDbg Telegram messages.
