1

I am in an interesting situation. I have very limited Windows kernel experience, so I just don't know what data structure to look for in order to find what I need to know.

There is a driver that is crashing Windows on my host machine. I know this much from examining the memory dump from the driver. 

For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff807`4cdc14e0 48894c2408      mov     qword ptr [rsp+8],rcx ss:0018:fffff389`040e6990=00000000000000f7
3: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_OVERRAN_STACK_BUFFER (f7)
A driver has overrun a stack-based buffer.  This overrun could potentially
allow a malicious user to gain control of this machine.
DESCRIPTION
A driver overran a stack-based buffer (or local variable) in a way that would
have overwritten the function's return address and jumped back to an arbitrary
address when the function returned.  This is the classic "buffer overrun"
hacking attack and the system has been brought down to prevent a malicious user
from gaining complete control of it.
Do a kb to get a stack backtrace -- the last routine on the stack before the
buffer overrun handlers and bugcheck call is the one that overran its local
variable(s).
Arguments:
Arg1: fffff389040e69d0, Actual security check cookie from the stack
Arg2: 000041be41f88edc, Expected security check cookie
Arg3: ffffbe41be077123, Complement of the expected security check cookie
Arg4: 0000000000000000, zero

Debugging Details:
------------------


KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.Sec
    Value: 1

    Key  : Analysis.DebugAnalysisProvider.CPP
    Value: Create: 8007007e on DESKTOP-GS87ORM

    Key  : Analysis.DebugData
    Value: CreateObject

    Key  : Analysis.DebugModel
    Value: CreateObject

    Key  : Analysis.Elapsed.Sec
    Value: 9

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 64

    Key  : Analysis.System
    Value: CreateObject


BUGCHECK_CODE:  f7

BUGCHECK_P1: fffff389040e69d0

BUGCHECK_P2: 41be41f88edc

BUGCHECK_P3: ffffbe41be077123

BUGCHECK_P4: 0

SECURITY_COOKIE:  Expected 000041be41f88edc found fffff389040e69d0

STACK_TEXT:  
fffff389`040e6988 fffff807`4ce7c485 : 00000000`000000f7 fffff389`040e69d0 000041be`41f88edc ffffbe41`be077123 : nt!KeBugCheckEx
fffff389`040e6990 fffff807`4cc4066c : 00000000`00000000 fffff807`4d21a91b 00000000`00000000 fffff389`040e74c0 : nt!_report_gsfailure+0x25
fffff389`040e69d0 fffff389`040e6960 : fffff389`040e6970 fffff389`040e6980 fffff389`040e6990 fffff389`040e69a0 : nt!NtSetInformationWorkerFactory+0x35c
fffff389`040e6b30 fffff389`040e6970 : fffff389`040e6980 fffff389`040e6990 fffff389`040e69a0 00000000`00000000 : 0xfffff389`040e6960
fffff389`040e6b38 fffff389`040e6980 : fffff389`040e6990 fffff389`040e69a0 00000000`00000000 00000000`00000000 : 0xfffff389`040e6970
fffff389`040e6b40 fffff389`040e6990 : fffff389`040e69a0 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffff389`040e6980
fffff389`040e6b48 fffff389`040e69a0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffff389`040e6990
fffff389`040e6b50 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffff389`040e69a0


SYMBOL_NAME:  nt!_report_gsfailure+25

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

STACK_COMMAND:  .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET:  25

FAILURE_BUCKET_ID:  0xF7_MISSING_GSFRAME_nt!_report_gsfailure

OS_VERSION:  10.0.18362.1

BUILDLAB_STR:  19h1_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {82d2c1b5-b0cb-60a5-9a5d-78c8c4284f84}

Followup:     MachineOwner

Main Question: Is it possible to directly extract the name of the crashing driver from a windows (kernel only) memory dump file?

If not, is it possible to extract that information by enabling user mode crash dumps (by this I mean the "active" crash dump with by user and kernel space)?

If it is possible, where should I look for the data structure to find this information? Is there a convenient Wdbg command that will get me close?

My main goal is to examine the root cause of the driver's crashing behavior and possibly recreate the crash myself.

Improve this question
0

1 Answer 1

Reset to default
2

It is possible. Take a minute to read the output from analyze. There's a few fields that will tell you what driver faulted like "FAULTING_MODULE", "IMAGE_NAME", and "MODULE_NAME".

It will give you the state of the registers as well and specifically what instruction that caused the crash so you'll see something like 

driver + offset:
addresss: instruction

Then below that, you'll see the stack context which is pretty useful to see what's going on. If I remember correctly, the command for that it uses is "kb"

If you use the .trap command for the field "TRAP_FRAME", you will go to the context of where it crashed too which is pretty sick.

Anyhow, all that will give you everything you need to finish your exploit. Happy hacking!

Improve this answer
3
  • Thanks for replying! I've updated the question with the full analyze output. It says it crashed in the nt image, which sadly doesn't help much. Any other tips to tease out the faulting module?
    – MrSynAckSter
    Nov 25, 2019 at 8:08
  • 1
    If you look into STACK TEXT, you'll see that there's a call stack. And before OS crashed somewhere within kernel image, which is called nt, it was executing some other code. So it's not the kernel which crashed, it's some driver which called the kernel API with the wrong parameters, which made kernel panic. Thus you need to analyze the call stack to see who it was. There are addresses of the code which was executed before hitting the kernel: 0xfffff389040e6960, 0xfffff389040e6970, etc. You need to find out which driver was at those addresses.
    – Anton Kukoba
    Nov 25, 2019 at 9:52
  • While you can do this the hard way, there are also pretty good tools like BlueScreenView or WhoCrashed that generally do a pretty good job of identifying the probable faulting module. The information is in the dump file, of course, but decoding it for the specific system that faulted is a somewhat tedious exercise.
    – J...
    Nov 25, 2019 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.