GitBook: [#884] update 12

Author: SinaKarvandi

contribution/style-guide/coding-style.md

@@ -37,7 +37,7 @@ All global variables should start with `g_` for example `g_GuestState`.
 
 For drivers, file names start with a capital case character.
 
-For user-mode codes, file names start with lower case characters. 
+For user-mode codes, file names start with lower case characters.
 
 ### Directory Names
 
@@ -51,9 +51,6 @@ In HyperDbg, in most cases, if the printed message came from kernel-mode or vmx-
 
 Exactly, like the above conventions for "Printing Messages", errors follow the same rule.
 
-In HyperDbg, errors might come from either user-mode codes, kernel-mode, or vmx-root mode. Because we want to know the root cause of the error, we follow the rule of **"`Err,` "** and **"`err,` "**.
+In HyperDbg, errors might come from either user-mode codes, kernel-mode, or vmx-root mode. Because we want to know the root cause of the error, we follow the rule of "`Err,` " and "`err,` ".
 
 If the error starts with `err,` then, it means that the user-mode code generated this error. If the error started with `Err,` it means that it was either kernel-mode or vmx-root mode that encountered this error.
-
-
-

design/debugger-internals/ioctl-requests-for-events.md

@@ -100,15 +100,15 @@ typedef enum _DEBUGGER_EVENT_TYPE_ENUM {
 
 If you want to use the debugger features, you should connect the `CommandsEventList` to the list of user-mode commands.
 
-**OptionalParamX** is different in the case of each command. For example, in **!epthook2**, you should send the address of where you want to hook to the kernel as **OptionalParam1**. ****You have to check each command's manual to see what are its specific **OptionalParam**\(s\).
+**OptionalParamX** is different in the case of each command. For example, in **!epthook2**, you should send the address of where you want to hook to the kernel as **OptionalParam1**. You have to check each command's manual to see what are its specific **OptionalParam**(s).
 
-**Tag** is an ID that you can use later in action. 
+**Tag** is an ID that you can use later in action.
 
 **IsEnabled** has a user-mode usage to trace whether the event is enabled or not.
 
 **CommandStringBuffer** is the string of the command. You can ignore it.
 
-If your event contains a condition buffer \(`ConditionBufferSize != 0`\), you can use set the size if `ConditionBufferSize` and append the buffer to the end of the above structure, and when you send the buffer to the kernel, you should send the `sizeof(DEBUGGER_GENERAL_EVENT_DETAIL)+ ConditionBufferSize (if any)`.
+If your event contains a condition buffer (`ConditionBufferSize != 0`), you can use set the size if `ConditionBufferSize` and append the buffer to the end of the above structure, and when you send the buffer to the kernel, you should send the `sizeof(DEBUGGER_GENERAL_EVENT_DETAIL)+ ConditionBufferSize (if any)`.
 
 Finally, you can send it to the kernel by using the following function.
 
@@ -121,7 +121,7 @@ SendEventToKernel(PDEBUGGER_GENERAL_EVENT_DETAIL Event,
                   UINT32 EventBufferLength);
 ```
 
- If you want to send it directly using IOCTL, you can use the following IOCTL :
+If you want to send it directly using IOCTL, you can use the following IOCTL :
 
 ```c
 #define IOCTL_DEBUGGER_REGISTER_EVENT                                          \
@@ -132,7 +132,7 @@ After sending the above event to the kernel, you should chain an action or multi
 
 You should fill the following structure to send a "**Break**", "**Script**", and "**Custom Code**" to the kernel. For example, you can append the custom code buffer after this structure and send them together to the kernel.
 
-Also, **EventTag** is the unique ID that we sent previously in the event. 
+Also, **EventTag** is the unique ID that we sent previously in the event.
 
 ```c
 //
@@ -167,4 +167,3 @@ If you want to register the action to the event directly using `DeviceIoControl`
 #define IOCTL_DEBUGGER_ADD_ACTION_TO_EVENT                                     \
   CTL_CODE(FILE_DEVICE_UNKNOWN, 0x807, METHOD_BUFFERED, FILE_ANY_ACCESS)
 ```
-

tips-and-tricks/misc/customize-build.md

@@ -21,7 +21,7 @@ By default, **HyperDbg** sends the current time of the system with each message
 #define ShowSystemTimeOnDebugMessages TRUE
 ```
 
-If you want to use **WPP Tracing** instead of **HyperDbg'**s message tracing, then set `UseWPPTracing` to `TRUE`. After that, you no longer see any message in **HyperDbg**, and instead, you can see the messages in a **WPP Tracing** compatible app.
+If you want to use **WPP Tracing** instead of **HyperDbg**'s message tracing, then set `UseWPPTracing` to `TRUE`. After that, you no longer see any message in **HyperDbg**, and instead, you can see the messages in a **WPP Tracing** compatible app.
 
 ```c
 /**
@@ -65,7 +65,7 @@ This is one of the **important** options for **HyperDng**. By default, **HyperDb
 
 If you need to see messages immediately after each one message, then set this option to `TRUE`. However, it kills the performance as sending buffers to the user-mode involves various and heavy functions.
 
-If you set this option to `FALSE` \(**default**\), then **HyperDbg** accumulates \(**~5** or more\) messages, and when the buffer is full, it sends the buffer to the user-mode **CLI** or **GUI**.
+If you set this option to `FALSE` (**default**), then **HyperDbg** accumulates (**\~5** or more) messages, and when the buffer is full, it sends the buffer to the user-mode **CLI** or **GUI**.
 
 ```c
 /**
@@ -157,7 +157,7 @@ The seeds that user-mode codes use as the starter of their output source tag.
 #define DebuggerOutputSourceTagStartSeed 0x1
 ```
 
-The following option changes the maximum number of breakpoints \('[bp](https://docs.hyperdbg.org/commands/debugging-commands/bp)' command\) that the user can put into the entire system before continuing the debuggee. If you continue the debuggee and send an IOCTL, HyperDbg will reset this number.
+The following option changes the maximum number of breakpoints ('[bp](https://docs.hyperdbg.org/commands/debugging-commands/bp)' command) that the user can put into the entire system before continuing the debuggee. If you continue the debuggee and send an IOCTL, HyperDbg will reset this number.
 
 ```c
 #define MAXIMUM_BREAKPOINTS_WITHOUT_CONTINUE 50
@@ -174,4 +174,3 @@ The following option changes the speed at which HyperDbg reads kernel messages i
  */
 #define DefaultSpeedOfReadingKernelMessages 30
 ```
-

tips-and-tricks/misc/event-forwarding.md

@@ -4,7 +4,7 @@ description: Brief explanation about Event Forwarding Mechanism
 
 # Event Forwarding
 
-Event forwarding is a feature designed to make HyperDbg a tool for log gathering and analyzing system behavior. This way, you can use HyperDbg for [\#DFIR](https://twitter.com/search?q=%23dfir) purposes.
+Event forwarding is a feature designed to make HyperDbg a tool for log gathering and analyzing system behavior. This way, you can use HyperDbg for [#DFIR](https://twitter.com/search?q=%23dfir) purposes.
 
 You can use event forwarding to forward the event monitoring result from your internal system to an external source, e.g., **File**, **NamedPipe**, or **TCP Socket**.
 
@@ -38,23 +38,22 @@ Check the [output ](https://docs.hyperdbg.org/commands/debugging-commands/output
 
 Event forwarding is a one-way mechanism. This means you can just see the client's logs, and you cannot make changes to the logs or send commands to the target client. If you want t,o control the debugger from a remote system, you can use [.listen](https://docs.hyperdbg.org/commands/meta-commands/.listen) and [.connect](https://docs.hyperdbg.org/commands/meta-commands/.connect) commands.
 
-## Format \(plain-text and JSON\)
+## Format (plain-text and JSON)
 
-Event forwarding is only applied to the script, which means that you can use the [**print** ](https://docs.hyperdbg.org/commands/scripting-language/functions/exports/print)and the [**printf**](https://docs.hyperdbg.org/commands/scripting-language/functions/exports/printf) _\*\*_function to generate results that will be passed to the target output source.
+Event forwarding is only applied to the script, which means that you can use the [**print** ](https://docs.hyperdbg.org/commands/scripting-language/functions/exports/print)and the [**printf**](https://docs.hyperdbg.org/commands/scripting-language/functions/exports/printf) function to generate results that will be passed to the target output source.
 
-It's possible to create JSON results using the [**printf**](https://docs.hyperdbg.org/commands/scripting-language/functions/exports/printf) _\*\*_function.
+It's possible to create JSON results using the [**printf**](https://docs.hyperdbg.org/commands/scripting-language/functions/exports/printf) function.
 
 ### Examples
 
 The following repository contains some examples of listening on a named pipe as a server or listening on TCP sockets to use event forwarding.
 
-{% embed url="https://github.com/HyperDbg/event-forwarding-examples" caption="" %}
+{% embed url="https://github.com/HyperDbg/event-forwarding-examples" %}
 
-Assume that we want to send the results of syscall \(syscall numbers in `rax`\) to several sources. The following video shows how to redirect these events to the **file**, **TCP Socket**, **named pipe**.
+Assume that we want to send the results of syscall (syscall numbers in `rax`) to several sources. The following video shows how to redirect these events to the **file**, **TCP Socket**, **named pipe**.
 
 ## Demo
 
 Watch the video - How to use event forwarding.
 
-{% embed url="https://www.youtube.com/watch?v=tyapdCEZtic" caption="" %}
-
+{% embed url="https://www.youtube.com/watch?v=tyapdCEZtic" %}

tips-and-tricks/misc/message-overflow.md

@@ -4,17 +4,17 @@ description: Kernel Message Tracing Overflow
 
 # Message Overflow
 
-Kernel buffers for transferring data safely to the user-mode \(debugger\) can be filled. If the debugger doesn't find time to transfer all messages, then the new messages will replace the previous messages, and as a result, you lose your messages, which are not yet transferred to the user-mode.
+Kernel buffers for transferring data safely to the user-mode (debugger) can be filled. If the debugger doesn't find time to transfer all messages, then the new messages will replace the previous messages, and as a result, you lose your messages, which are not yet transferred to the user-mode.
 
 In the rest of this document, you will learn the important factors that can decrease such scenarios. Take a look at [Customize Build](https://docs.hyperdbg.org/tips-and-tricks/misc/customize-build) for more information.
 
 ## Use Conditions
 
-[Condition code](https://docs.hyperdbg.org/using-hyperdbg/prerequisites/how-to-create-a-condition) buffers are one of the most important parts of **HyperDbg**. You can use this feature to avoid triggering unnecessary events \(actions\) by creating conditions that filter the results for you in assembly form in both kernel-mode and vmx-root mode.
+[Condition code](https://docs.hyperdbg.org/using-hyperdbg/prerequisites/how-to-create-a-condition) buffers are one of the most important parts of **HyperDbg**. You can use this feature to avoid triggering unnecessary events (actions) by creating conditions that filter the results for you in assembly form in both kernel-mode and vmx-root mode.
 
 ## Change Reading Delay
 
-You can change `hprdbgctrl.cpp` file's **ReadIrpBasedBuffer\(\)** method to decrease the delay between reading each message from the kernel. You can change `Sleep(200);` to a lower time \(ms\), so you can read messages faster.
+You can change `hprdbgctrl.cpp` file's **ReadIrpBasedBuffer()** method to decrease the delay between reading each message from the kernel. You can change `Sleep(200);` to a lower time (ms), so you can read messages faster.
 
 ```c
 ...
@@ -46,7 +46,7 @@ You can change `hprdbgctrl.cpp` file's **ReadIrpBasedBuffer\(\)** method to decr
 
 If you need to see messages immediately after each one message, then set this option to `TRUE`. However, it kills the performance as sending buffers to the user-mode involves various and heavy functions.
 
-If you set this option to `FALSE`, **HyperDbg** accumulates \(**~5** or more based on message length and chunk size\) messages, and when the buffer is full, it sends the buffer to the user-mode **CLI** or **GUI**.
+If you set this option to `FALSE`, **HyperDbg** accumulates (**\~5** or more based on message length and chunk size) messages, and when the buffer is full, it sends the buffer to the user-mode **CLI** or **GUI**.
 
 You can change the following options in the **Configuration.h** file.
 
@@ -63,7 +63,7 @@ You can change the following options in the **Configuration.h** file.
 
 This is the most important factor in message tracing, if you increase the following value, then more messages will be stored in **HyperDbg** buffers; thus, they won't be replaced until the buffer is full, for example, if set this value to **1000**, then if you produce **1000** messages that are not delivered to the user-mode, **HyperDbg** replaces new messages with older messages, and in the case, if you set this value to **2000** then you have more capacity; thus, the buffers will have the capacity to hold twice more messages.
 
-However, keep in mind that **HyperDbg** occupies more non-paged pools \(RAM\) by increasing the following value, so you need to balance your message capacity with your memory \(RAM\).
+However, keep in mind that **HyperDbg** occupies more non-paged pools (RAM) by increasing the following value, so you need to balance your message capacity with your memory (RAM).
 
 ```c
 /* Default buffer size */
@@ -74,12 +74,9 @@ However, keep in mind that **HyperDbg** occupies more non-paged pools \(RAM\) by
 
 The following option shows the capacity of each packet in **HyperDbg**'s message tracing. If you have long messages or buffers, then you can increase this value.
 
-If you increased it, then **HyperDbg** accumulates more messages and won't send them immediately to the user-mode \(as described in **Not Use Immediate Messaging** above\). This will lead to better performance; however, messages will be delivered by a delay \(for accumulation\).
+If you increased it, then **HyperDbg** accumulates more messages and won't send them immediately to the user-mode (as described in **Not Use Immediate Messaging** above). This will lead to better performance; however, messages will be delivered by a delay (for accumulation).
 
 ```c
 #define PacketChunkSize                                                        \
   1000 // NOTE : REMEMBER TO CHANGE IT IN USER-MODE APP TOO
 ```
-
-\*\*\*\*
-

tips-and-tricks/nested-virtualization-environments/run-hyperdbg-on-hyper-v.md

@@ -10,7 +10,7 @@ Hyper-V has an unknown problem with HyperDbg and HyperDbg-style hypervisors. You
 
 In order to run HyperDbg on Hyper-V, you should enable nested-virtualization on it.
 
-For Hyper-V, we can enable nested-virtualization for the target virtual machine by running the following command on **Powershell** :
+For Hyper-V, we can enable nested-virtualization for the target virtual machine by running the following command on **Powershell**:
 
 ```
 Set-VMProcessor -VMName PutYourVmNameHere -ExposeVirtualizationExtensions $true
@@ -22,7 +22,6 @@ Note that instead of **PutYourVmNameHere**, put the name of your virtual machine
 
 And if you need to disable it, you can run:
 
-```text
+```
 Set-VMProcessor -VMName PutYourVmNameHere -ExposeVirtualizationExtensions $false
 ```
-