|
| 1 | +--- |
| 2 | +description: Description of the '.pagein' command in HyperDbg. |
| 3 | +--- |
| 4 | + |
| 5 | +# .pagein (bring the page into the RAM) |
| 6 | + |
| 7 | +### Command |
| 8 | + |
| 9 | +> .pagein |
| 10 | +
|
| 11 | +### Syntax |
| 12 | + |
| 13 | +> .pagein \[Mode (string)] \[VirtualAddress (hex)] |
| 14 | +> |
| 15 | +> .pagein \[Mode (string)] \[VirtualAddress (hex)] \[l Length (hex)] |
| 16 | +
|
| 17 | +### Description |
| 18 | + |
| 19 | +Injects a page-fault and brings the target page (or a range of pages) into the memory. |
| 20 | + |
| 21 | +### Parameters |
| 22 | + |
| 23 | +**\[Mode (string)] (optional)** |
| 24 | + |
| 25 | +The page-fault error code that needs to be injected. The error code can be one of these values, or a combination of these values: |
| 26 | + |
| 27 | +**p**: present  |
| 28 | + |
| 29 | +**w**: write  |
| 30 | + |
| 31 | +**u**: user  |
| 32 | + |
| 33 | +**f**: fetch  |
| 34 | + |
| 35 | +**k**: protection key  |
| 36 | + |
| 37 | +**s**: shadow stack  |
| 38 | + |
| 39 | +**h**: hlat  |
| 40 | + |
| 41 | +**g**: sgx |
| 42 | + |
| 43 | +**\[VirtualAddress (hex)]** |
| 44 | + |
| 45 | +The **virtual** address or the start address of a range of addresses where we want to bring its entry into the RAM. |
| 46 | + |
| 47 | +**\[l Length (hex)] (optional)** |
| 48 | + |
| 49 | +The **length** of the memory (range) in bytes. |
| 50 | + |
| 51 | +{% hint style="warning" %} |
| 52 | +Currently, this command is only supported in the [Debugger Mode](https://docs.hyperdbg.org/using-hyperdbg/prerequisites/operation-modes#debugger-mode). |
| 53 | +{% endhint %} |
| 54 | + |
| 55 | +### Page-Fault Error Codes |
| 56 | + |
| 57 | +The following table is derived from [Exceptions](https://wiki.osdev.org/Exceptions) with some modifications, which explains the meaning of each bit in the **Mode** string. |
| 58 | + |
| 59 | +<table><thead><tr><th width="93">Bit</th><th width="79">Mode</th><th width="107">Length</th><th width="123">Name</th><th>Description</th></tr></thead><tbody><tr><td>P</td><td>p</td><td>1 bit</td><td>Present</td><td>When set, the page fault was caused by a page-protection violation. When not set, it was caused by a non-present page.</td></tr><tr><td>W</td><td>w</td><td>1 bit</td><td>Write</td><td>When set, the page fault was caused by a write access. When not set, it was caused by a read access.</td></tr><tr><td>U</td><td>u</td><td>1 bit</td><td>User</td><td>When set, the page fault was caused while CPL = 3. This does not necessarily mean that the page fault was a privilege violation.</td></tr><tr><td>RSVD</td><td></td><td>1 bit</td><td>Reserved write</td><td>When set, one or more page directory entries contain reserved bits which are set to 1. This only applies when the PSE or PAE flags in CR4 are set to 1.</td></tr><tr><td>I</td><td>f</td><td>1 bit</td><td>Instruction Fetch</td><td>When set, the page fault was caused by an instruction fetch. This only applies when the No-Execute bit is supported and enabled.</td></tr><tr><td>PK</td><td>k</td><td>1 bit</td><td>Protection key</td><td>When set, the page fault was caused by a protection-key violation. The PKRU register (for user-mode accesses) or PKRS MSR (for supervisor-mode accesses) specifies the protection key rights.</td></tr><tr><td>SS</td><td>s</td><td>1 bit</td><td>Shadow stack</td><td>When set, the page fault was caused by a shadow stack access.</td></tr><tr><td>HLAT</td><td>h</td><td>1 bit</td><td>HLAT</td><td>When set, there is no translation for the linear address using HLAT paging.</td></tr><tr><td>SGX</td><td>g</td><td>1 bit</td><td>Software Guard Extensions</td><td>When set, the fault was due to an <a href="https://en.wikipedia.org/wiki/Software_Guard_Extensions">SGX violation</a>. The fault is unrelated to ordinary paging.</td></tr></tbody></table> |
| 60 | + |
| 61 | +This is a list of common page-fault error codes: |
| 62 | + |
| 63 | +| Error Code | Mode | Description | |
| 64 | +| ---------- | --------- | --------------------------------- | |
| 65 | +| 0x0 | (default) | page not-found | |
| 66 | +| 0x2 | w | write access fault | |
| 67 | +| 0x3 | pw | present, write access fault | |
| 68 | +| 0x4 | u | user access fault | |
| 69 | +| 0x6 | wu | write, user access fault | |
| 70 | +| 0x7 | pwu | present, write, user access fault | |
| 71 | +| 0x10 | f | fetch instruction fault | |
| 72 | +| 0x11 | pf | present, fetch instruction fault | |
| 73 | +| 0x14 | uf | user, fetch instruction fault | |
| 74 | + |
| 75 | +In most cases, using a value of **0x0** (default page-fault error code) is the safest option. |
| 76 | + |
| 77 | +{% hint style="danger" %} |
| 78 | +Using this command with incorrect mode strings or virtual addresses that are not meant to be accessible is like delivering an exception to the target process. In the case of a thread operating in kernel-mode, the exception is directed towards the kernel. If the target process handles these exceptions appropriately, the Structured Exception Handling (SEH) handlers will be invoked. However, if the target fails to handle the exceptions properly, it may result in a crash of the target process. In the case of a kernel-mode thread, it can lead to a Blue Screen of Death (BSOD) for the entire system. Therefore, it is crucial to ensure that the necessary pages are brought in for the addresses intended to be accessible, and that the appropriate access page-fault error code is chosen. |
| 79 | +{% endhint %} |
| 80 | + |
| 81 | +### Examples |
| 82 | + |
| 83 | +The following command injects a page-fault with the error code equal to `zero` and the **CR2** register is configured to `00007ff8349f2224`. |
| 84 | + |
| 85 | +```diff |
| 86 | +0: kHyperDbg> .pagein 00007ff8349f2224 |
| 87 | +the page-fault is delivered to the target thread |
| 88 | +press 'g' to continue debuggee (the current thread will execute ONLY one instruction and will be halted again)... |
| 89 | +``` |
| 90 | + |
| 91 | +The following command injects a page-fault with the error code equal to `zero` and starting from the a range where its **CR2** register is configured to `00007ff8349f2224`. and the last address is `00007ff8349f2224+(4*0x1000)` which means it brings **5** pages into the memory or the length is `0x4000` bytes. |
| 92 | + |
| 93 | +```diff |
| 94 | +0: kHyperDbg> .pagein 00007ff8349f2224 l 4000 |
| 95 | +the page-fault is delivered to the target thread |
| 96 | +press 'g' to continue debuggee (the current thread will execute ONLY one instruction and will be halted again)... |
| 97 | +``` |
| 98 | + |
| 99 | +The following command injects a page-fault with the error code equal to `0x4` and the **CR2** register is configured to `00007ff8349f2224`. |
| 100 | + |
| 101 | +```diff |
| 102 | +0: kHyperDbg> .pagein u 00007ff8349f2224 |
| 103 | +the page-fault is delivered to the target thread |
| 104 | +press 'g' to continue debuggee (the current thread will execute ONLY one instruction and will be halted again)... |
| 105 | +``` |
| 106 | + |
| 107 | +### IOCTL |
| 108 | + |
| 109 | +This command works over serial by sending the serial packets to the remote computer. |
| 110 | + |
| 111 | +First of all, you should fill in the following structure, set the `VirtualAddressFrom` to your target virtual address that you want to put a breakpoint on and `VirtualAddressTo` to the end of the range of addresses, and fill `PageFaultErrorCode` to your target page-fault error code. Note that, if you want to bring only one page, then you can set both `VirtualAddressFrom` and `VirtualAddressTo` to the same value. |
| 112 | + |
| 113 | +```c |
| 114 | +typedef struct _DEBUGGER_PAGE_IN_REQUEST |
| 115 | +{ |
| 116 | + UINT64 VirtualAddressFrom; |
| 117 | + UINT64 VirtualAddressTo; |
| 118 | + UINT32 ProcessId; |
| 119 | + UINT32 PageFaultErrorCode; |
| 120 | + UINT32 KernelStatus; |
| 121 | + |
| 122 | +} DEBUGGER_PAGE_IN_REQUEST, *PDEBUGGER_PAGE_IN_REQUEST; |
| 123 | +``` |
| 124 | + |
| 125 | +The next step is sending the above structure to the debuggee when debuggee is paused and waiting for new command on **vmx-root** mode. |
| 126 | + |
| 127 | +You should send the above structure with `DEBUGGER_REMOTE_PACKET_REQUESTED_ACTION_ON_VMX_ROOT_INJECT_PAGE_FAULT` as `RequestedAction` and `DEBUGGER_REMOTE_PACKET_TYPE_DEBUGGER_TO_DEBUGGEE_EXECUTE_ON_VMX_ROOT` as `PacketType`. |
| 128 | + |
| 129 | +In return, the debuggee sends the above structure with the following type. |
| 130 | + |
| 131 | +```c |
| 132 | +DEBUGGER_REMOTE_PACKET_REQUESTED_ACTION_DEBUGGEE_RESULT_OF_BRINGING_PAGES_IN |
| 133 | +``` |
| 134 | + |
| 135 | +In the returned structure, the `KernelStatus` is filled by the kernel. |
| 136 | + |
| 137 | +If the `KernelStatus` is `DEBUGEER_OPERATION_WAS_SUCCESSFULL`, then the operation was successful. Otherwise, the returned result is an error. |
| 138 | + |
| 139 | +The following function is responsible for sending page-in requests to the debugger. |
| 140 | + |
| 141 | +```c |
| 142 | +BOOLEAN KdSendPageinPacketToDebuggee(PDEBUGGER_PAGE_IN_REQUEST PageinPacket); |
| 143 | +``` |
| 144 | +
|
| 145 | +### Remarks |
| 146 | +
|
| 147 | +Starting from **v0.4**, this command was added to the HyperDbg debugger and starting from **v0.7** it supports a range of addresses. |
| 148 | +
|
| 149 | +This command is mainly designed to be used with the '[.start](https://docs.hyperdbg.org/commands/meta-commands/.start)' command. Certain pages (virtual addresses) may have been paged-out or are not currently present in the memory (RAM). Without these pages being stored in the physical RAM, it is not possible to utilize EPT hooks, such as the '[!monitor](https://docs.hyperdbg.org/commands/extension-commands/monitor)' command, on those particular addresses. Therefore, executing this command will tell the operating system to retrieve the page and ensure the availability of the virtual address. Consequently, you will be able to utilize EPT hooks commands on those addresses. |
| 150 | +
|
| 151 | +This command is guaranteed to keep debuggee in a halt state (in Debugger Mode); thus, nothing will change during its execution. But after, running it, HyperDbg asks to continue the debuggee using the '[g](https://docs.hyperdbg.org/commands/debugging-commands/g)' command. Subsequently, all processes will resume their execution, while the specific target (current) thread will execute a single instruction due to the Trap Flag being set. However, it will once again pause after handling the page fault and executing that one instruction. |
| 152 | +
|
| 153 | +### Requirements |
| 154 | +
|
| 155 | +None |
| 156 | +
|
| 157 | +### Related |
| 158 | +
|
| 159 | +[.start (start a new process)](https://docs.hyperdbg.org/commands/meta-commands/.start) |
0 commit comments