[原创]驱动蓝屏后调试DUMP文件-软件逆向-看雪-安全社区|安全招聘|kanxue.com

[原创]驱动蓝屏后调试DUMP文件

发表于: 2011-2-20 17:52 14209

[原创]驱动蓝屏后调试DUMP文件

无泪城

2011-2-20 17:52

14209

关于分析DUMP文件的一些想法：
在分析一个驱动蓝屏的时候，如果有驱动的PDB文件就很容易找到出错的地方，然是如果没有PDB文件，往往比较麻烦，只能给出个大题的东西，今天调试了一下DUMP文件，有点感触，先来分析一下，（ProbeForWrite(bb,10,10);bb为NULL指针）
双机调试的方法不说了，直接开始调试：加载驱动文件，直接蓝屏了，这个时候WINDBG给出了一下提示：
FOLLOWUP_IP:
HelloDDK+5ae
f7c455ae 8be5            mov     esp,ebp

BUGCHECK_STR:  0x7E

DEFAULT_BUCKET_ID:  NULL_DEREFERENCE

LAST_CONTROL_TRANSFER:  from f7c455ae to 8060d589

STACK_TEXT:
f7a01c54 f7c455ae 00000000 0000000a 0000000a nt!ProbeForWrite+0x39
WARNING: Stack unwind information not available. Following frames may be wrong.
f7a01c74 f7c45504 f7a01d4c 805777f1 864d2b10 HelloDDK+0x5ae
f7a01c7c 805777f1 864d2b10 860cd000 00000000 HelloDDK+0x504
f7a01d4c 80577901 800008a8 00000001 00000000 nt!IopLoadDriver+0x66d
f7a01d74 80535c32 800008a8 00000000 865b4020 nt!IopLoadUnloadDriver+0x45
f7a01dac 805c71e0 f7a69cf4 00000000 00000000 nt!ExpWorkerThread+0x100
f7a01ddc 80542e12 80535b32 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  HelloDDK+5ae

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: HelloDDK

IMAGE_NAME:  HelloDDK.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4d60d8a6

STACK_COMMAND:  .cxr 0xfffffffff7a01880 ; kb

FAILURE_BUCKET_ID:  0x7E_HelloDDK+5ae

BUCKET_ID:  0x7E_HelloDDK+5ae

这里我只给出其中的一部分代码。
其中有用的信息大家可以自己分析，今天主要想找找出错位置，看其中的一部分
HelloDDK+5ae
f7c455ae 8be5            mov     esp,ebp

主要看HelloDDK+5ae，也就是出错在加载地址的5ae偏移处。
然后从新打开虚拟机，挂上调试，这个时候先加载驱动，（先别启动驱动，也就是别让你的驱动蓝），然后再WINDBG中BREAK一下，然后下bp          nt!IopLoadDriver+0x66a，这个是SP3的（P2的为bp          nt!IopLoadDriver+0x669），然后再启动驱动，这个时候断下来了，如果所示：

然后单布进入（F11）
得到如下图：

这个时候就能得到HelloDDK的基址为f7c0d000然后加上5ae得到f7c0d5ae
然后反汇编f7c0d5ae得到

看到没有事这个地方或者上面出错了，然后咱往上面看得到

这里就能判断出来时这个CALL出问题了，实际上是第三个push 0的问题
在分析一下

这里就知道是ProbeForWrite出了问题了，可以用IDA在分析一下，然后用二进制工具改，也可以直接用WINDBG修改
如下eb f7c0d5a0 90 90 90 90 90 90 90 90 90 90 90 90 90 90
然后再反汇编看一下

确定好后运行即可
当然，这里是最简单的东西，实际上好多NOP掉了也会出错，不过嘛，往往很多只需要改成JMP 或直接JZ或JNZ就能实现你想要的东西，希望对你有帮助。

登录后可查看完整内容

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课

上传的附件：

1.jpg （13.48kb，674次下载）
2.jpg （21.71kb，671次下载）
3.jpg （15.53kb，671次下载）
4.jpg （25.56kb，673次下载）
5.jpg （16.63kb，672次下载）
6.jpg （32.55kb，671次下载）

收藏・15

免费・7

支持

赞赏记录

参与人

雪币

留言

时间

Youlor

为你点赞~

2024-5-31 05:46

伟叔叔

为你点赞~

2024-3-18 01:59

心游尘世外

为你点赞~

2024-1-31 00:04

QinBeast

为你点赞~

2024-1-22 02:41

飘零丶

为你点赞~

2024-1-19 00:36

shinratensei

为你点赞~

2024-1-17 04:01

PLEBFE

为你点赞~

2023-3-11 04:08

最新回复 (15)

雪yaojun

雪币： 120

活跃值： (160)

能力值：

( LV2，RANK：10 )

在线值：

发帖

回帖

593

粉丝

关注

私信

雪yaojun: 2 楼

今天刚想过如何去调试蓝屏后的dump文件，楼主就发贴了。学习一下。

2011-2-20 21:54

Mx￠Xgt

雪币： 656

活跃值： (448)

能力值：

( LV12，RANK：360 )

在线值：

发帖

回帖

583

粉丝

关注

私信

Mx￠Xgt 7: 3 楼

收藏备用~~~~~

2011-2-20 22:18

prince

雪币： 603

活跃值： (617)

能力值：

( LV12，RANK：660 )

在线值：

发帖

回帖

1874

粉丝

关注

私信

prince 16: 4 楼

可以更简单一点:

1. Load symbol
2. kp

2011-2-21 01:38

jerrynpc

雪币： 284

活跃值： (16)

能力值：

( LV2，RANK：10 )

在线值：

发帖

回帖

695

粉丝

关注

私信

jerrynpc: 5 楼

不给力吖，求无dump蓝屏分析办法

2011-2-21 09:07

无泪城

雪币： 193

活跃值： (64)

能力值：

( LV3，RANK：30 )

在线值：

发帖

回帖

246

粉丝

关注

私信

无泪城: 6 楼

能更加详细一些吗？分析一个未知的驱动，啥都没有，就一个驱动，咋样才能快速找到蓝屏的代码及原因啊？
1. Load symbol
2. kp
咋搞啊？我也感觉我那听繁琐！

2011-2-21 10:27

prince

雪币： 603

活跃值： (617)

能力值：

( LV12，RANK：660 )

在线值：

发帖

回帖

1874

粉丝

关注

私信

prince 16: 7 楼

蓝屏代码在你用WinDbg加载dump文件的时候，一般就会显示出来，每个蓝屏代码所代表的意义在WinDbg的help文件中会有所介绍。但是并不是这些蓝屏代码就能够直接给出真正的原因。像类似“Bug Check 0xC000021A: STATUS_SYSTEM_PROCESS_TERMINATED”这种蓝屏代码我们一看就知道是什么原因引起的；但是类似像“Bug Check 0xC5: DRIVER_CORRUPTED_EXPOOL”这样的蓝屏代码，我们只能够看到蓝屏的直接原因，而为什么memory 或者 system pool会corrupted，还是要具体问题具体分析，很可能这个pool或者memory早就被某个driver给破坏掉了，但是过了N久系统才touch到这个损坏的pool，这种问题，基本除了排除法，没有什么好的办法能够直接找到root cause。

对于lz上面提到的情况，配置好系统symbol之后，直接kp命令就可以看到详细的调用堆栈信息，包括传入的参数，一目了然。

The k* commands display the stack frame of the given thread, together with related information..
 
 
p 
Displays all of the parameters for each function that is called in the stack trace. The parameter list includes each parameter's data type, name, and value. The p option is case sensitive. This parameter requires full symbol information. 

2011-2-21 11:04

无泪城

雪币： 193

活跃值： (64)

能力值：

( LV3，RANK：30 )

在线值：

发帖

回帖

246

粉丝

关注

私信

无泪城: 8 楼

恩，我这电脑没有双机调试，回去测试一下，顺便问一个问题，蓝屏的时候给出了一系列代码，其中有一项是STACK_TEXT：里面罗列了蓝屏的时候堆栈调用情况，不知道用Kp命令得到的是不是和这个一致？例如：
/////////////////////////
////////////////////////
STACK_TEXT: //反映了错误前堆栈中函数调用情况，最下面的0x7c801671处函数调用ntdll中的ZwDeviceIoControlFile，接着调用了ntdll中的KiFastSystemCallRet，再接着调用了nt（这里的nt指Ntoskrnl）中的KiFastCallEntry，一直到myfault+0x403，发生异常。
f9357734 804f880d 00000003 f9357a90 00000000 nt!RtlpBreakWithStatusInstruction
f9357780 804f93fa 00000003 e1147008 fbe93403 nt!KiBugCheckDebugBreak+0x19
f9357b60 80540853 0000000a e1147008 0000001c nt!KeBugCheck2+0x574
f9357b60 fbe93403 0000000a e1147008 0000001c nt!KiTrap0E+0x233
WARNING: Stack unwind information not available. Following frames may be wrong.
f9357c58 805759d1 ffb5c3b0 8111f318 811d9130 myfault+0x403
f9357d00 8056e33c 00000090 00000000 00000000 nt!IopXxxControlFile+0x5e7
f9357d34 8053d808 00000090 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
f9357d34 7c92eb94 00000090 00000000 00000000 nt!KiFastCallEntry+0xf8
0012f9f0 7c92d8ef 7c801671 00000090 00000000 ntdll!KiFastSystemCallRet
0012f9f4 7c801671 00000090 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
0012fa54 004018c2 00000090 83360018 00000000 0x7c801671

2011-2-21 11:43