cawan's blog: How To Build A Kernel Shellcode Design and Testing Platform For Windows 8 By Using Windbg

How To Build A Kernel Shellcode Design and Testing Platform For Windows 8 By Using Windbg

by cawan (cawan[at]ieee.org or chuiyewleong[at]hotmail.com)

on 5/11/2012

For windows kernel shellcoder, it is very important to has a testing platform in

evaluating and verifying the shellcode at instruction level in runtime. So, windbg

should be the ideal tool to do the job. In order to build a testing platform, we

need 2 pieces of memory areas, one with write and execute (WE) permission, and

another one with write (W) permission. The one with WE permission is to let us put

our shellcode inside, and run it there. On the other hand, the one with W permission

is for temporary storage, so, we can store our variable or output there. A good

example is sgdt command. The command will read the gdt register and store the content

into a memory area that we specified. Now, we need to search memory pages to find

one with WE permission and another one with W permission. Let's start now.

8 files are generated, which the file names from 80000000.txt to f0000000.txt.

The processes will take quite a while in scanning the kernel space page by page.

Based on the log files, quite a number of memory areas are found which can meet the

requirement. However, most of them are protected by integrity check of the kernel.

In other words, when some bytes on those memory areas are modified, and let the

kernel run again, the system will crash immediately. Fortunately, after several

tries, a piece of memory area which has WE permission and out of the control of

integrity check by the kernel has been found.

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

VA 811fc000

PDE at C0602040 PTE at C0408FE0

contains 0000000002A07063 contains 00000000025FC963

pfn 2a07 ---DA--KWEV pfn 25fc -G-DA--KWEV

(811fb480) nt!HvlpLogicalProcessorRegions+0xb80 | (81206480) nt!HvlpNodes

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

The memory area is known as HvlpLogicalProcessorRegions and it is started from

0x811fb480 and end at 0x81206480. Please note that the memory addresses will be

different in your machine because the kernel base is always ASLRed. Now we need to

make sure the HvlpLogicalProcessorRegions is included in the nt kernel export list

or not.

There is nothing in the export list that match "HvlpLogicalProcessorRegions", and even

with prefix "Hvlp". If search for those with prefix "Hvl", then there are some, but

nothing related to the "HvlpLogicalProcessorRegions". So, from the angle of kernel

shellcode design, we can only get the base of "HvlpLogicalProcessorRegions" by using

offset comparison technique as discussed in previous paper - "How to Defeat Windows 8

ASLR in Getting the Address of KPCR". Anyway, since we are using windbg with symbol

files now, we no need to consider this first. But now, how about the memory area with

W permission ? Again, after several tries, a fixed address is very suitable to do the

job, and it is located at 0xffdf0000.

///////////////////////////////////////////////////////////////////////////////////

VA ffdf0000

PDE at C0603FF0 PTE at C07FEF80

contains 0000000002A96063 contains 8000000002A58163

pfn 2a96 ---DA--KWEV pfn 2a58 -G-DA--KW-V

///////////////////////////////////////////////////////////////////////////////////

Nice, let's try with some instructions. First, check for any content in

HvlpLogicalProcessorRegions.

kd> dd HvlpLogicalProcessorRegions

811fb480 00000000 00000000 00000000 00000000

811fb490 00000000 00000000 00000000 00000000

811fb4a0 00000000 00000000 00000000 00000000

811fb4b0 00000000 00000000 00000000 00000000

811fb4c0 00000000 00000000 00000000 00000000

811fb4d0 00000000 00000000 00000000 00000000

811fb4e0 00000000 00000000 00000000 00000000

811fb4f0 00000000 00000000 00000000 00000000

Full with zero...Fine, we start to put some instructions there.

kd> a HvlpLogicalProcessorRegions

811fb480 nop

nop

811fb481 nop

nop

811fb482 sgdt [0xffdf0000]

sgdt [0xffdf0000]

811fb489 nop

nop

811fb48a nop

nop

811fb48b

The instruction "sgdt [0xffdf0000]" will write the content of gdt register into

0xffdf0000. Let's check the memory of HvlpLogicalProcessorRegions again.

kd> dd HvlpLogicalProcessorRegions

811fb480 010f9090 df000005 009090ff 00000000

811fb490 00000000 00000000 00000000 00000000

811fb4a0 00000000 00000000 00000000 00000000

811fb4b0 00000000 00000000 00000000 00000000

811fb4c0 00000000 00000000 00000000 00000000

811fb4d0 00000000 00000000 00000000 00000000

811fb4e0 00000000 00000000 00000000 00000000

811fb4f0 00000000 00000000 00000000 00000000

It is easier to check it in bytes...

kd> db HvlpLogicalProcessorRegions

811fb480 90 90 0f 01 05 00 00 df-ff 90 90 00 00 00 00 00 ................

811fb490 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

811fb4a0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

811fb4b0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

811fb4c0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

811fb4d0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

811fb4e0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

811fb4f0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................

Good, the instructions already there. Let the kernel run again to ensure the system

will not hang due to our modification to the kernel memory. Issue command 'g' and

do something such as open windows explorer at windows 8, it should work properly.

Now, break the system again and check our instructions are still there or not.