- 01 July 2024 (9 messages)
-
Joined. -
No. Unfortunately, the stepping mechanism only works in the Debugger Mode (not VMI Mode). -
Not sure if I understand. Can you elaborate on what to be addressed in ntoskrnl? 🤔
-
You can use the 'lm' command to get the base address of different modules.
https://docs.hyperdbg.org/commands/debugging-commands/lmlm (view loaded modules) | HyperDbg DocumentationDescription of the 'lm' command in HyperDbg.
- 02 July 2024 (11 messages)
-
Joined. -
Hi,
sorry for the late reply
Actually there is a design issue with HyperDbg that whenever you clear an event, it cannot be removed immediately. Instead HyperDbg first disables the event and when you continue the debuggee (using the 'g' command) it removes it from the EPT page tables. So, you need to continue debuggee before applying next EPT hook. This design issue will be solved in the future but if you cannot continue the debuggee for any reason or you need to apply your new event immediately, then you can simply disable it (event d all) and HyperDbg won't trigger it for you anymore. -
But if you removed it and you continue debuggee and pause it again, if the error happens again (while the hook is removed) it's potentially a bug that needs to be investigated.
-
So, it still shows this error? 🤨
-
Ah, got it. Could you create a GitHub issue for this? I'll try to investigate it hopefully tomorrow.
-
👍
- 03 July 2024 (60 messages)
-
The '!monitor' command just changes the attributes of EPT page tables but the '!epthook' changes both EPT page table attributes and puts 0xcc (int3) breakpoints, but I think your target anti-hack method tries to read/write from the page table and compute the time it takes (probably by using RDTSC/RDTSCP) instructions which is performed normally if you just use '!monitor x' but if you use '!monitor rwx' then probably it detects !monitor too. Please take a look at these documentation explanations:
Design of !epthook:
https://docs.hyperdbg.org/design/features/vmm-module/design-of-epthook
Design of !monitor:
https://docs.hyperdbg.org/design/features/vmm-module/design-of-monitorDesign of !epthook | HyperDbg DocumentationDesign of !epthook command
-
Int3 is hidden, if it's a user-mode process check, it shouldn't notice it 🤨
-
No difference, it shouldn't notice it from the kernel mode too.
-
It probably checks for the time it takes to respond to a memory read which will reveal that HyperDbg is monitoring that special page.
-
Otherwise, I can't think of a method to check the memory alteration for !epthook. 🤔
-
It's actually possible in the VMM module to apply events immediately, but it's not exported to the user this way. Because the script engine IR generator is in the user-mode. If you want to do it, you can directly modify the source code and apply the event using a custom function. But, it's a really cool feature I think. 🤔
I'll add it to the future to-do list but it probably won't be ready soon since it needs fundamental design changes.
One way around it is by using:
event (with a pause() function) + g + new event
So, once your script is running, it continues the debuggee immediately after applying the first event and when your event executes the pause() function, the debugger is paused and the second event will be created. (If you didn't understand what I mean by this, please let me know, I could elaborate it more). -
Exit script? What do you mean? Like disabling the event? 🤨
-
There are a couple of functions for disabling/enabling and removing or short-circuiting events here:
https://docs.hyperdbg.org/commands/scripting-language/functions/eventsevents | HyperDbg DocumentationFunctions related to events
-
You can use them along with the $event_id pseudo-register.
-
Like a function return? 🤨
-
@xmaple555 implemented the functions logic, you can use it like a function.
-
Constants & Functions | HyperDbg Documentation
Description of constants and functions
-
No, pause will pause the debugger immediately. Context is preserved.
-
You need to ask @xmaple555 to fix it, I don't know that much about the script engine parser. 🙂🙃
-
What do you mean by dynamic calls calculation? 🤨
-
Wait, you cannot put two !monitors in one page?
-
I thought it's possible. 🤔
-
Not sure if I understand what you mean but !monitor receives (to/from) parameters from the script expressions:
https://github.com/HyperDbg/HyperDbg/blob/a691c1df3be48660907fcf93840302a8c4650ff4/hyperdbg/libhyperdbg/code/debugger/commands/extension-commands/monitor.cpp#L204HyperDbg/hyperdbg/libhyperdbg/code/debugger/commands/extension-commands/monitor.cpp at a691c1df3be48660907fcf93840302a8c4650ff4 · HyperDbg/HyperDbgState-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
-
Which means you can calculate your addresses in global variables and use them as parameters to the !monitor.
-
E.g., !monitor .FromGlobalVar .FromGlobalVar+0x85 script { ... }
-
Wait couldn't you put multiple !monitor hooks in one page? As long as I remember it was possible. 🤔🤔🤔
Not a big deal BTW, you can handle it through the script.
E.g., check for your ranges within if conditions. $context pseudo-register contains the address of accessed memory address. However, I'm pretty sure we support multiple !monitor(s) on same page at some point. 🤔 -
Why don't you check ranges within if conditions?
-
Like put a !monitor on an entire page, and check for the $context.
-
This one again could be handled from the by the method I told you earlier (pause())
-
You can use global variables to check your $context with dynamic ranges.
-
Maybe a combination of loops could help.
-
if i was allowed to use monitors on same page, it would help a lot :)
- 04 July 2024 (7 messages)
-
It's just the matter of handling complex logic of hooks in different pages. I'm so lazy to think about it since the algorithm of handling multiple hooks and events could become complex. 😅
-
But sure, I'll add it to the future todo list.
-
Thanks for reporting it, I'll check it.
-
I think it's shared between all drivers. I see caaes where it's not shared but if I remember it correctly, it's generally shared between different processes (but not sure). 🤔
-
Sure
- 05 July 2024 (24 messages)
-
I was able to reproduce this error.
https://github.com/HyperDbg/HyperDbg/issues/409 -
It seems that it's because HyperDbg doesn't remove the !monitor hooks correctly when the address is not available in HyperDbg's address space. 🤔
-
Since this address is only valid in the target process memory, not HyperDbg's view of memory (cr3).
-
Eduard Please switch to this branch and test it again:
https://github.com/HyperDbg/HyperDbg/tree/fix-monitor-removeGitHub - HyperDbg/HyperDbg at fix-monitor-removeState-of-the-art native debugging tool. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
-
Test this one and ...
-
this one.
-
Both of them should be fixed.
-
I changed the logic of clearing !monitor events.
-
Also please try to test it with different conditions and different ways if you can. At the moment it passed all of my tests but since the logic of clearing these kinds of events is changed, I might break it in some other ways, so performing a complete test would help a lot.
-
Once you've done testing it, please let me know so I'll merge it to the 'dev' branch.
-
That's great. I merged it to the 'dev' branch now.
-
Yep, this is what I told here:
-
.
-
But generally you have tons of options, you could disable/enable events instead of clearing them. Or use a nop+jmp infinite loop at the @RIP register.
-
This one is really hard to solve. 😅
In HyperDbg we use NMIs for halting cores. This mechanism should be changed to IPIs instead of NMIs.
The reason why it doesn't support immediately clearing of events is because we might halt the core in the middle of handling an event and conclude to remove them. In that case, the event will trigger BSOD since its structures are freed. But, using IPIs will make sure that handling one event will be finished, and then another VM-exit happens which will halt the core. -
Using IPIs by itself is okay but since HyperDbg is highly dependent on NMIs, changing it to IPIs will probably break lots of its functionalities. That's why I didn't dare to change it to IPIs yet. 😅
- 06 July 2024 (8 messages)
-
Anyone tried hyperdbg gui? -
It's not ready yet. These days I'm working on it together with another team member. I'll let you guys know once it's finished.
- 07 July 2024 (19 messages)
-
Didn't get it 🤔
It doesn't work with 1 in the '!monitor'? -
Could you please make a GitHub issue with the sequence of commands I could reproduce the error?
If there are multiple ways of reproducing error (e.g., it crashes with both 1 and 3 length) make sure to include all sequences separately so all of them will be fixed. -
Hello guys, I need some help here
I'm trying to install EfiGaurd to disable PatchGaurd in my local machine,
But I cannot find the option to add a boot option, or enter the boot setup.
I disabled the secure boot and make it legacy, but the problem still the same. -
My laptop is Lenovo IdeaPad
-
@Mattiwatti The original author is in the group but not sure if he still checks his Telegram since he rarely uses this app.
-
Yeah, the last seen is long time ago
-
Is there's any other option to disable the PatchGaurd in my local machine
-
As long as I remember, you could boot EfiGuard from a USB.
-
BTW, why do you need to disable PatchGuard? The only command that is not PatchGuard compatible in HyperDbg is the '!syscall'. Are you going to intercepts system-calls?
-
Other commands are perfectly fine with PatchGuard.
-
No actually I'm going to use the !epthook command, but I faced a problem that the command cannot identify the system call function that I passed to it, so I thought it's a problem related to PatchGaurd
-
I'm using it in the VMI, with script of course
-
Not sure if I understand it correctly. Are you going to hook system-call handler using the '!epthook' command? 🤨
-
Oh, I feel very stupid right now 😶.
It's just I was going to apply your example that you did in this video about the epthook (that I'm mentioning) but in VMI mode. I thought that it would be ok 😶. -
As I understand, the epthook will remove the execute permission on that page that holds the code for hooked API, so whenever the caller calls it, it will cause a vm-exit, then the Hypervisor will take control then execute my script then cause vm-continue and continue the execution normally to the guest. I don't know if I understand it right 😶.
-
This example doesn't need patchguard to be disabled. It's works even if PatchGuard is running in both the 'Debugger Mode' and the 'VMI Mode'.
-
No, actually this behavior is not for the '!epthook'. The one you mentioned is the scenario where you use the '!monitor x' command. For the '!epthook', the execution bit is in effect while the 'read/write' bits are cleared. There is a hidden breakpoint there (int3 or 0xCC) which will be triggered and handled in the hypervisor whenever the target function is executed. Please take a look at these document pages for more information:
- https://docs.hyperdbg.org/design/features/vmm-module/design-of-epthook
- https://docs.hyperdbg.org/design/features/vmm-module/design-of-monitorDesign of !epthook | HyperDbg DocumentationDesign of !epthook command
-
Thanks, I'll fix it.
- 08 July 2024 (13 messages)
-
HyperDbg (@HyperDbg) on X
🔥 Summer's heating up, and so is the learning! VMware Workstation is now free, making it the perfect time to dive into hypervisor-based reverse engineering. Check out the free HyperDbg tutorial at @OpenSecTraining: https://t.co/I1n3ggYlU9 (preferred) https://t.co/119iZNhSsA
-
None
-
I was not able to reproduce the error using your scripts in the GitHub, but it was reproduced once using this script:
.sym reload pid 3024
.process pid 3024
g
.process
!monitor x ws2_32!send l 3 script {
printf("pre triggered\n");
}
--------------------------------------
g
event c all
g
.process pid 3024
g
.process
--------------------------------------
bp ws2_32!send
!monitor x ws2_32!send l 3 script {
printf("pre triggered\n");
}
.process -
But, only one time! Couldn't reproduce it again. It seems to be race condition but in order to investigate it, it needs to be deterministically reproduced.
-
I'll keep testing the same scripts to find a way for reproducing it, meanwhile if you find a reproduceable sequence of command, pls send it here.
-
Okay, I found a sequence that reproduces the error:
.sym reload pid 3024
.process pid 3024
g
.process
!monitor x ws2_32!send l 3 script {
printf("pre triggered\n");
}
!monitor x 00354b67 l 3 script {
printf("pre triggered\n");
} -
Fixed. Check the latest 'dev' branch.
- 10 July 2024 (5 messages)
-
Eduard I fixed this issue, but I'm not sure if I correctly fixed it and it didn't break anything. Once you have free time, please update your 'dev' branch and make a comprehensive test on both the step-over 'p' and the step-in 't', and let me know if you find any problems.
https://github.com/HyperDbg/HyperDbg/issues/406Step over hangs, if process terminates/excepts within call instruction. · Issue #406 · HyperDbg/HyperDbgStepOverTst.zip Steps to reproduce: .start path C:\dbg\StepOverTst.exe 2: kHyperDbg> bp 00007ff7`54c3156c 2: kHyperDbg> g debuggee is running... breakpoint 0x3 hit 00007ff7`54c3156c E8 37 03 ...
-
You did a great job. - 11 July 2024 (11 messages)
-
You mean the patch (last commit) should be reverted? 🤨
-
Or it just sometimes cause errors?
-
- 12 July 2024 (9 messages)
-
It's on the 'dev' branch now. Sure we won't release (merge it to the master) if the problem is not yet fixed.
-
I'll create a GitHub issue to further investigate it. Meanwhile, if you find a deterministic way of reproducing it, pls let me know.
-
hi guys, I'm trying to use visual studio kernel debug. But there is no current line shown (yellow arrow) in source code when hitting breakpoint
-
only show yellow arrow to the current line in asm
- 13 July 2024 (6 messages)
- 14 July 2024 (4 messages)
-
Ok, got it. I'll check it with these new details. Thanks 👍
-
This doesn't work as expected. You're trying to change @eip 5 times in one single execution. Doesn't make sense. 🤔
So, it probably needs to be changed to:
!monitor x 0D6A4D0 l 2 core 0 stage post script {
if ($context == 0D6A4D0){
@eip = 00D6A4D3;
printf("NOW WILL CALL %x\n",eip);
}
} -
But, that's definitely not a reason for the crash. Is it a crash of HyperDbg (BSOD)? or the target program crashes through SEH?
- 15 July 2024 (34 messages)
-
Starting from v0.10 (the next version), HyperDbg uses @keystone_engine as its assembler. ❤️
Thanks to our new team member @Reverser69 for adding it.
The following commands are added to assemble virtual and physical memory:
- https://docs.hyperdbg.org/commands/debugging-commands/a
- https://docs.hyperdbg.org/commands/extension-commands/aa (assemble virtual address) | HyperDbg DocumentationDescription of the 'a' command in HyperDbg.
-
None
-
No, actually if you wanna call something within an event, it'll be called from VMX root-mode. Though, not sure if it's because you're using it in the post stage or not.
Can you put the '!monitor' check into the next address (the address after the current @eip) and use it in the regular 'pre' stage? -
I was thinking about it. The thing is, after executing a call (pre stage), an MTF is set to bring the results back (post stage).
-
This MTF will be executed exactly after one instruction. It doesn't work like a step-over, it's like a step-in.
-
So, I don't have any idea what's going on inside HyperDbg with a post stage !monitor to a CALL instruction. 🤔
-
The thing that you wanna do, seems more reasonable to be done by using an !epthook. But as probably you're dealing with an executable with lots of anti debugging methods, maybe modifying the stack and putting the return address of a CALL gadget works for this case?
-
FYI, @Reverser69 is now working on bringing the support for assembly codes (keystone) within code {} statements, along with its classic hex format.
-
Don't have any idea how it's implemented in the OS-level functions or how we can implement it in VMX root-mode. 🤔
Does it need a timer configuration? 🤨 -
HyperDbg is in VMX root-mode, not user-mode 😕
-
There are tons of way to do this. Let me find an example from OST2 videos
-
Dbg3301: HyperDbg 10 08 Ignoring Events
View 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.
-
This one. You can use the short-circuiting mechanisom along with the !monitor's X attribute to pause the target process.
-
Another option is using the newly added !mode command+event_sc:
https://docs.hyperdbg.org/commands/extension-commands/mode!mode (detect kernel-to-user and user-to-kernel transitions) | HyperDbg DocumentationDescription of the '!mode' command in HyperDbg.
- 16 July 2024 (8 messages)
-
Only time in milis doesn't make sense since it will change each time you try to get it and it takes a long time to be ready (like some functions needed to be called) which makes it not a suitable case.
-
What about a function for RDTSC/P? 🤨
- 17 July 2024 (7 messages)
-
No, I mean a function in the script engine.
-
Oh, the problem is solved now?
-
No problem, I could implement that, but just to confirm it with you, do you expect to sleep() and halt the entire core for a couple of seconds or do you want to make sleep() only the target thread?
- 18 July 2024 (41 messages)
-
I think for the thread variant it's better to patch the execution flow (e.g. some assembly codes at @rip or somewhere else), but for the VMX-root variant, I'll try to see what's the best method of adding such a function.
-
? {
void Sleep(int milliseconds) {
.count = 0;
.delay = milliseconds * 1000; // Convert milliseconds to microseconds
while (.delay != 0) {
.delay--;
.count = 1000; // This constant can be adjusted based on the clock speed
while (.count != 0) {
.count--;
// Do nothing, just busy-wait
}
}
}
Sleep(10);
} -
Eduard What about this one? I test it an it works perfectly. You can adjust waiting time too.
-
Each core can run its script independently. Each core has its own stack and could run script simultaneously.
-
He uses global variables. Variables start with a '.' means global variables.
-
If you don't use '.' before name of each variable, it's considered as a local variable (local to each core).
-
So, I agree with @xmaple555, if your code is supposed to run simultaneously on multiple cores, you need to use local variables instead.
-
is the page faulted caused by accessing invalid memory ?
-
It should work on multi-core unless there is a error.
-
It needs to be investigated, if you have Windbg attached, you could comment this line:
-
-
Once you comment #pf line, all page-faults in the VMX root-mode will be passed to the Windows handler (which is WinDbg) and you could see the exact location of the crash.
-
Yes, the main debugger we used to debug HyperDbg is windbg+serial handler of HyperDbg itself. It works on all cases.
-
Just make sure to comment this line and !analyze -v in windbg will tell you where page-fault happens.
-
@HughEverett nice, it helps a lot for developing the hypervisor
-
but now I did it for dump crash analysis
-
Yes, it's not that straightforward. You can do single stepping but it takes a lot of time to get the execution cobtext again and sometimes it doesn't work (like after 4 or 5 single steppings).
-
I usually use our magical 'LogInfo' function which immediately sends the results over serial and it effectively works as the main printf-debugging function of the VMX root-mode.
-
'LogInfo' is guaranteed to send the results immediately without buffering them in the Debugger Mode. But, in the VMI Mode, it first buffers the logs and then sends them to the user-mode whenever it's possible.
-
You could run scripts within an event with a high rate of execution.
E.g.:
!epthook nt!ExAllocatePoolWithTag script { blah blah }
All cores definitely run your scripts simultaneously in this special case. -
Because the execution rate of 'nt!ExAllocatePoolWithTag' is high enough to make them run simultaneously.
- 19 July 2024 (17 messages)
-
Yes, the CPU clock speed is an important factor in this case.
-
Is the problem solved? Or it still freezes the debuggee? 🤨
-
Are you working on rewriting the parser of the script engine? Or the main parser of commands?
-
@Reverser69 finished rewriting the parser of commands yesterday.
-
Yes
-
-
But it's for command (libhyperdbg.dll), not the script engine.
-
Oh, okay, you're working on parser of script engine
-
It's okay, he was working on something else.
-
No collision
-
👍
- 20 July 2024 (10 messages)
-
So I assume that, this is not a problem with HyperDbg?
-
Since the interval depends on CPU clock speed
-
Also, we need to have a discussion about this one.
-
It's a new change proposed by @xmaple555.
I'm not sure if it's a good idea of having a limitation for the number of IRs that could be executed. -
What do you guys think ? Does anybody have any idea regarding this one?
-
🤔
- 21 July 2024 (26 messages)
-
I've looked into the sleep implementation in the OS, and it seems quite complex because it uses an external device timer. ☹️
-
VMware? 🤨
-
Exactly. In the VMX root-mode, interrupts are masked (RFLAG.IF is cleared).
-
This is exactly same as the function we used for the $time pseudo-register.
-
I think you can use this $time for this purpose too. By default, it returns a pointer to a string.
-
Also, dslang supports dereferencing (memory access) through & operator.
-
It would be great if we can have such a feature. You can use the Keystone disassembler that is recently added to the project.
-
You can add (+x) number to the time and read it using db, or dd. Like db($time+123)
-
Hi and welcome to the group. 🤗
Tomorrow, we'll release HyperDbg v0.10.
Along with that, I'll create a list of potential tasks that you (and anyone else) could add to the HyperDbg. I'll notify you when the list is ready (hopefully tomorrow). -
Eduard please don't forget to check this as well.
https://github.com/HyperDbg/HyperDbg/issues/417
If it's solved, please close this issue.Script with functions going crazy · Issue #417 · HyperDbg/HyperDbg!monitor x 00D6A712 l 2 script { void printMemDD(int addr){ dlen = 20; for (i = 0; i < dlen; i = i + 4){ printf("%x ", dd(addr + i)); } printf("\n"); return; } void printMemB...
- 22 July 2024 (24 messages)
-
Happy to announce @HyperDbg v0.10! 🎉🎊✨
This version comes with numerous bug fixes and stability improvements, plus new features like running assembly code directly in the events (VMX root-mode) and two new commands.
Check out the latest version: https://github.com/HyperDbg/HyperDbg/releases
For more information,
Assembly codes in conditions:
- https://docs.hyperdbg.org/using-hyperdbg/prerequisites/how-to-create-a-condition
Assembly codes in code sections:
- https://docs.hyperdbg.org/using-hyperdbg/prerequisites/how-to-create-an-action
Assemble virtual address:
- https://docs.hyperdbg.org/commands/debugging-commands/a
Assemble physical address:
- https://docs.hyperdbg.org/commands/extension-commands/aReleases · HyperDbg/HyperDbgState-of-the-art native debugging tools. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
-
# Changelog
## Added
- Support using assembly conditions and codes in all events
- Added the assembler command 'a' for virtual memory
- Added the assembler command '!a' for physical memory
- Providing a unified SDK API for reading memory in the VMI Mode and the Debugger Mode
- Export SDK APIs for reading/writing into registers in the Debugger Mode
- Export SDK API for writing memory in the VMI Mode and the Debugger Mode
- Export SDK API for getting kernel base address
- Export SDK API for connecting to the debugger and from debuggee in the Debugger Mode
- Export SDK API for starting a new process
- Add and export SDK API for unsetting message callback
- Event commands are coming with more examples regarding scripts and assembly codes
- Add message callback using shared memory
- Add maximum execution limitation to the script IRs (#435)
## Changed
- Fix clearing '!monitor' hooks on a different process or if the process is closed (#409)
- Fix triggering multiple '!monitor' hooks with different contexts (#415)
- Fix the problem of repeating commands once kHyperDbg is disconnected
- Fix step-over hangs if the process terminates/excepts within call instruction (#406)
- Fix crash on editing invalid physical addresses (#424)
- Fix exporting VMM module load and install it in the SDK
- Fix function interpretation issues and update the parser and the code execution (#435) -
Thanks to @xmaple555 and @Reverser69 for their great contributions in this release. ❤️
-
Right on
-
None
-
Here is an updated list of tasks that needs contributions from the community members:
https://github.com/HyperDbg/HyperDbg/blob/dev/CONTRIBUTING.mdHyperDbg/CONTRIBUTING.md at dev · HyperDbg/HyperDbgState-of-the-art native debugging tools. Contribute to HyperDbg/HyperDbg development by creating an account on GitHub.
-
cc @supermanfranky
-
I just wonder whether there is any plan for adding something like import or #include to the dslang scripts? -
This one is really something if it could be added! @xmaple555 🤔
-
My first idea is passing a pointer to a buffer where links for the buffers of scripts are stored.
-
This way, we could even pre-load a bunch of standard scripts.
-
No, I think he means include of .ds files.
-
C files needs compiler which is really hard to do.
-
But, .ds files might be good if we could implement functions in it and import it to other .ds files.
-
Not sure if it's possible 🤔
-
We could start implementing standard script functions.
-
I think some functionalities like Windows-specific routines (and in the future other functions) that needs interaction with symbols (structure offsets and function addresses) are better to be implemented in the script-engine.
-
This way, we could add lots of cool functions for modifying Windows as a standard library (say Windows.ds), and then import it and use it in the scripts.
-
This would be super cool! 👌🤔
- 23 July 2024 (6 messages)
-
Joined. -
Joined. -
Joined. -
Joined.
- 24 July 2024 (8 messages)
-
Joined. -
Joined. -
Joined. -
Joined. -
Joined. - 25 July 2024 (2 messages)
-
Joined. - 26 July 2024 (17 messages)
-
If you mean v0.10, then unfortunately no! ☹️
-
I spent time on finding the issue but it seems that it needs more investigation, I added it to the contributing list (to-do) list.
-
Is it deleted? 🤨
-
Forgot to say that #HyperDbg v0.10 also supports event forwarding to external binary (DLLs) modules.
- If you want to use HyperDbg events in your function, check out the guide:
https://docs.hyperdbg.org/tips-and-tricks/misc/event-forwarding
- Rust/C++ implementations are available here:
https://github.com/HyperDbg/event-forwarding-examplesEvent forwarding | HyperDbg DocumentationBrief explanation about Event Forwarding Mechanism
-
-
Ah, it seems to be deleted. 😔
-
What do you mean by return trap flag from cpuid? 🤨
-
In the Debugger Mode, if the debugee is paused, you could view/modify the trap flag using the 'r' command.
-
It's also accessible through the script engine using @rflag register.
- 27 July 2024 (2 messages)
-
Joined. -
@HughEverett ^^ - 28 July 2024 (4 messages)
-
Why are you everywhere @invlpg
-
It seems that it's deleted.
https://stackoverflow.com/questions/2613903/does-deleting-a-branch-in-git-remove-it-from-the-historyDoes deleting a branch in git remove it from the history?Coming from svn, just starting to become familiar with git. When a branch is deleted in git, is it removed from the history? In svn, you can easily recover a branch by reverting the delete opera...
-
I don't remember what I did on that branch, did you clone it somewhere in your computer?
- 29 July 2024 (10 messages)
-
Hi everyone!
We've updated the list of things for which we need contributions from the community in HyperDbg!
If you have some free time, you're more than welcome to join and contribute to the HyperDbg debugger. 😊✨
Check it out:
https://github.com/HyperDbg/HyperDbg/blob/dev/CONTRIBUTING.md -
None
-
[discord] <oi_its_me> Test -
What do you mean by inspecting kernel structures?
Is it anything other than the 'struct' command?
https://docs.hyperdbg.org/commands/debugging-commands/structstruct (make structures, enums, data types from symbols) | HyperDbg DocumentationDescription of the 'struct' command in HyperDbg.
-
Dump of all page tables?
HyperDbg already shows the page table entries, but won't dump them. You could use a combination of the '!pte' command + the '.dump' command to perform that.
https://docs.hyperdbg.org/commands/extension-commands/pte
https://docs.hyperdbg.org/commands/meta-commands/.dump!pte (display page-level address and entries) | HyperDbg DocumentationDescription of the '!pte' command in HyperDbg.
-
Joined. - 30 July 2024 (1 messages)
-
Joined.
@hyperdbg / Public archive of HyperDbg Telegram messages.
- 01 Jul 2024 (9)
- 02 Jul 2024 (11)
- 03 Jul 2024 (60)
- 04 Jul 2024 (7)
- 05 Jul 2024 (24)
- 06 Jul 2024 (8)
- 07 Jul 2024 (19)
- 08 Jul 2024 (13)
- 10 Jul 2024 (5)
- 11 Jul 2024 (11)
- 12 Jul 2024 (9)
- 13 Jul 2024 (6)
- 14 Jul 2024 (4)
- 15 Jul 2024 (34)
- 16 Jul 2024 (8)
- 17 Jul 2024 (7)
- 18 Jul 2024 (41)
- 19 Jul 2024 (17)
- 20 Jul 2024 (10)
- 21 Jul 2024 (26)
- 22 Jul 2024 (24)
- 23 Jul 2024 (6)
- 24 Jul 2024 (8)
- 25 Jul 2024 (2)
- 26 Jul 2024 (17)
- 27 Jul 2024 (2)
- 28 Jul 2024 (4)
- 29 Jul 2024 (10)
- 30 Jul 2024 (1)