I'm trying to read out memory of another process via kernel mode driver. It is working and i'm injecting the driver into the space of another driver to make it work (or could just enable test mode).
However, it is working well, but when giving a wrong address, i result in a BSOD.
Here is information on one example BSOD:
SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: ffffe000d509c720, Address of the instruction which caused the bugcheck
Arg3: ffffd00026053db0, Address of the context record for the exception that
caused the bugcheck
Arg4: 0000000000000000, zero.
As I injected the driver into the other driver, the symbols etc cannot be resolved. There is some additional information:
ADDITIONAL_DEBUG_TEXT:
You can run '.symfix; .reload' to try to fix the symbol path and load symbols.
MODULE_NAME: nt
FAULTING_MODULE: fffff80043604000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 56cd4410
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced
memory at 0x%p. The memory could not be %s.
FAULTING_IP:
+8c0
ffffe000`d509c720 8a440aff mov al,byte ptr [rdx+rcx-1]
CONTEXT: ffffd00026053db0 -- (.cxr 0xffffd00026053db0;r)
rax=00000000df000008 rbx=00000000df000004 rcx=ffffe000d509e004
rdx=0000200009f62004 rsi=ffffe000d391c2a0 rdi=ffffe000d818f000
rip=ffffe000d509c720 rsp=ffffd000260547d8 rbp=ffffd00026054b80
r8=0000000000000004 r9=0000000000000000 r10=ffffe000d69eb8d8
r11=ffffe000d509e000 r12=00000000c0000900 r13=0000000000000000
r14=ffffe000d391c1d0 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010202
ffffe000`d509c720 8a440aff mov al,byte ptr [rdx+rcx-1]
ds:002b:00000000`df000007=??
Last set context:
rax=00000000df000008 rbx=00000000df000004 rcx=ffffe000d509e004
rdx=0000200009f62004 rsi=ffffe000d391c2a0 rdi=ffffe000d818f000
rip=ffffe000d509c720 rsp=ffffd000260547d8 rbp=ffffd00026054b80
r8=0000000000000004 r9=0000000000000000 r10=ffffe000d69eb8d8
r11=ffffe000d509e000 r12=00000000c0000900 r13=0000000000000000
r14=ffffe000d391c1d0 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010202
ffffe000`d509c720 8a440aff mov al,byte ptr [rdx+rcx-1]
ds:002b:00000000`df000007=??
Resetting default scope
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: 0x3B
CURRENT_IRQL: 0
ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre
LAST_CONTROL_TRANSFER: from ffffe000d509c233 to ffffe000d509c720
STACK_TEXT:
ffffd000`260547d8 ffffe000`d509c233 : ffffe000`d2b32700 00000000`df000004
ffffe000`d818f000 fffff800`43a167f5 : 0xffffe000`d509c720
ffffd000`260547e0 ffffe000`d2b32700 : 00000000`df000004 ffffe000`d818f000
fffff800`43a167f5 00000000`00000001 : 0xffffe000`d509c233
ffffd000`260547e8 00000000`df000004 : ffffe000`d818f000 fffff800`43a167f5
00000000`00000001 df000004`00000000 : 0xffffe000`d2b32700
ffffd000`260547f0 ffffe000`d818f000 : fffff800`43a167f5 00000000`00000001
df000004`00000000 ffffe000`d818f000 : 0xdf000004
ffffd000`260547f8 fffff800`43a167f5 : 00000000`00000001 df000004`00000000
ffffe000`d818f000 ffffe000`d818f000 : 0xffffe000`d818f000
ffffd000`26054800 fffff800`43a0eac2 : ffffe000`d2b327e0 ffffd000`26054b80
00000000`00000001 ffffe000`d65c0080 : nt!ObReferenceObjectByHandle+0x25
ffffd000`26054850 fffff800`43a0d956 : fffff800`21ef4020 00000000`00000000
00000000`00000000 00000000`00000000 : nt!NtDeviceIoControlFile+0x11c2
ffffd000`26054a20 fffff800`43750fa3 : ffffe000`d69eb840 00000000`00000000
00000000`00000000 00000000`00000000 : nt!NtDeviceIoControlFile+0x56
ffffd000`26054a90 00000000`587221bc : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : nt!setjmpex+0x3963
00000000`00bbf0f8 00000000`00000000 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : 0x587221bc
FOLLOWUP_IP:
nt!NtDeviceIoControlFile+11c2
fffff800`43a0eac2 448be0 mov r12d,eax
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: nt!NtDeviceIoControlFile+11c2
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: ntkrnlmp.exe
STACK_COMMAND: .cxr 0xffffd00026053db0 ; kb
BUCKET_ID: WRONG_SYMBOLS
FAILURE_BUCKET_ID: WRONG_SYMBOLS
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:wrong_symbols
FAILURE_ID_HASH: {70b057e8-2462-896f-28e7-ac72d4d365f8}
Now to what I am doing: I give the driver 4 values and have a global buffer to write read out values to:
char buf[5000]; NTSTATUS DevioctlDispatch( In struct _DEVICE_OBJECT *DeviceObject, Inout struct _IRP *Irp ) everything I am doing in the driver is in multiple __try __catch/__except/__finally blocks and I hoped i could just grab wrong read outs... I am getting the process handle and then pass it (after ProbeForRead) to RtlCopyMemory:
__try
{
KeAttachProcess(myprocess);
ProbeForRead((void*)address, len, 1);
RtlCopyMemory((void*)buf, (void*)address, len);
KeDetachProcess();
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
DbgPrint("Exception.\n");
status = STATUS_INVALID_PARAMETER;
KeDetachProcess();
return status;
}
I am doing this very often, but i made sure i Detach in any case.
Am I supposed to use KeStackAttachProcess? Where is the BSOD coming from? Am i catching errors wrong? Thanks! And yes, I am reading from a userspace application.
As I don't have a valid certificate yet, I am using an exploit in the vboxdrv to load my driver (in order to be not on a test system). But I just found out, that it does not support SEH. Therefore, my try/except doesn't to anything correct... Just have to wait for my cert or use test mode instead.