首页
论坛
课程
招聘
[原创]用户模式APC蓝屏分析报告
2009-1-13 17:17 16309

[原创]用户模式APC蓝屏分析报告

2009-1-13 17:17
16309
关键词:APC,蓝屏,QueueUserAPC,ZwQueueApcThread,漏洞

曾在看雪上看到一篇 【囧】Ring3下把Windows XP SP2 弄蓝了…… 的帖子。
出于好奇,改了段QueueUserAPC的Delphi的代码(见该贴的5楼),结果SP3下也蓝屏了:



也许是太简单了,苦等不见高手回复。正好在学漏洞分析这门课,就拿这个问题来练手了
最后分析发现,其实这个蓝屏原因很简单——QueueUserAPC的调用上范了初级错误,APC插csrss后执行出错,导致csrss被OS中止掉了。

虽然简单,不过重要的是分析过程,所以在这里记录一下。分析中难免有错,高手飘过...

-------------------------------------------------------------------------------------------------

由于出问题的API是QueueUserAPC,于是尝试着用OllyDbg跟入检查原因。可以看到,QueueUserAPC实际是通过调用ntdll!ZwQueueApcThread实现的。不过ZwQueueApcThread没办法进一步跟进去:
7C92E23D >  B8 B4000000     MOV EAX,0B4             ; ZwQueueApcThread
7C92E242    BA 0003FE7F     MOV EDX,7FFE0300
7C92E247    FF12            CALL DWORD PTR DS:[EDX] ; ntdll.KiFastSystemCall
7C92E249    C2 1400         RETN 14
SS:
0012FF30   7C834174  返回到 kernel32.7C834174 来自 ntdll.ZwQueueApcThread

7C92EB8B >  8BD4            MOV EDX,ESP		        ; ntdll.KiFastSystemCall
7C92EB8D    0F34            SYSENTER

SYSENTER之后进入Ring0,OD是拿它没办法的。
好在实际测试发现,并不是SYSENTER进入后就马上蓝屏,也就是说出问题的地方并不是ntdll.KiFastSystemCall中。

由于不会SoftICE,所以没法进一步跟踪,看来只能从DUMP文件入手。
在“启动和故障恢复”选项卡中,选择核心内存转储方式(图2),然后运行引起蓝屏的程序,让Windows输出蓝屏时的内存DUMP:



这样,蓝屏后就会将高端内存输出到C:\WINDOWS\MEMORY.DMP中。用WinDBG打开DMP文件,!analyze -v进行分析(详细分析方法见二楼),发现该蓝屏的产生是系统关键进程CSRSS被意外终止所导致的。据此可以初步断定,由于ZwQueueApcThread插入APC队列使csrss.exe被终止,而不是最早插入APC的SYSTEM和SMSS.EXE这两个进程。

看来不了解APC的原理是无法继续分析了,我们先来看看什么是APC。APC即异步过程调用,是(Asynchronous Procedure Call)的缩写。这里直接引用《谈谈对APC的一点理解》中的原话:
1) APCs允许用户程序和系统元件在一个进程的地址空间内某个线程的上下文中执行代码。
2) I/O管理器使用APCs来完成一个线程发起的异步的I/O操作。
3) 使用APC可以得到或者设置一个线程的上下文和挂起线程的执行。

在NT中,有两种类型的APCs:用户模式和内核模式。……用户模式的APCs需要目标线程处在Alertable等待状态才能被成功的调度执行。对于用户模式下,可以调用SleepEx, WaitForSingleObjectEx等API使目标线程处于Alertable等待状态,从而让用户模式APCs执行。当一个用户模式APC被投递到一个线程,调用上面的等待函数,如果返回等待状态STATUS_USER_APC,在返回用户模式时,内核转去控制APC例程,当APC例程完成后,再继续线程的执行。


简单来说,APC通过 Alertable I/O 提供更有效的异步通知形式,当IO请求完成后,一旦线程进入可告警状态(Alertable),我们在APC队列中设置的回调函数将会执行,此时我们将获得目标线程的控制权直至返回。

APC在Windows系统中应用相当广泛,实际上TerminateThread就是利用APC实现的。使用TerminateThread可以在任何时候结束指定线程。查阅微软支持库Q254956(http://support.microsoft.com/kb/254956/en-us/)可知,调用TerminateThread会在目标进程中产生一个APC队列,然后强制所有线程进入等待状态,用于执行APC队列中的ExitThread函数,从而结束目标进程。这是一种典型的APC应用,由于使用APC来执行退出进程操作,这就导致了被TerminateThread结束的线程不能回到自身的清理函数中,这也是APC的一个特性。[/url]
APC方式执行的回调函数,实际上是中断目标进程转入指定回调程序执行。这样的好处在于不会有新的线程产生,而且可以控制目标线程的执行流程。返回目标进程领空也比较简单,由于APC调用前已经把返回地址压入堆栈中,只需适时的执行一条ret指令便可以返回,而无需像挂钩子函数或者远程线程中,执行繁琐的清理操作。

这么一来就清楚了。一旦我们劫持csrss.exe中的某个线程,让他去执行一些非法操作,于是csrss.exe就壮烈牺牲了。

有人说了,将CallBack地址赋值LoadLibraryA也会引起蓝屏?首先我要说的是,表1中那段APC代码实际是错的,光调用一个QueueUserAPC函数就错了两个参数,也正是因为写得有问题才引起的目标程序访问违规:

完整代码点这里
pStrDll := PAnsiChar(dllName);
QueueUserAPC(@LoadLibraryA, hThread, DWORD(pStrDll));

由Delphi的调用规范可知,参数1(@LoadLibraryA)是取LoadLibraryA的地址。然而,这里取得的并非LoadLibraryA的真正地址,而是一个JMP指令(不清楚的可以用OD跟踪一下程序中的API调用)。正确方法应该是通过GetProcAddress取得LoadLibraryA函数入口,这样才能继续。当然,参数3(DWORD(pStrDll))是另一个错误所在,将pStrDll这个DLL名字指针强制转成DWORD型是没有错误,问题在于这个pStrDll所指内容是在本地进程中的,要是在其他进程里访问这个地址,内容肯定不一样。
是不是很熟悉,QueueUserAPC这个API调用其实和CreateRemoteThread很像,只不过其根本不同在于CreateRemoteThread要创建新的线程用于执行我们的目标代码,而QueueUserAPC不用。

-------------------------------------------------------------------------------------------------

另外说说网上一些关于APC注入的误区。APC注入参数1不一定非要是LoadLibraryA,其他API也是可行的(网上教程都用LoadLibrary是因为载入DLL实现起来比较简单而且通用)。APC的可以帮助我们执行指定位置的任意代码,只要把QueueUserAPC参数1的指针指向要执行的ShellCode,然后等待系统处理这个用户模式APC就行了。

当然,搬网上某些APC注入教程的原话,“有时你等得花儿都谢了APC还没有执行”。确实如此,只有当目标线程调用了SleepEx、WaitForSingleObjectEx、WaitForMultipleObjectsEx等API时,用户模式APC才能执行,这也是大多数线程插入APC后没有反应的原因。就目前来看,公认的方法是通过暴力注入explorer.exe的所有线程来达到目标效果。实际explorer中,通常都会有这样两个线程等着你去插入:
ntdll!RtlQueueWorkItem+0x2b5
ntdll!RtlDowncaseUnicodeString+0x75

这两个进程可以通过Sysinternals的Process Explorer的线程列表进行查看,他们会不断的进入Alertable等待状态,所以可以顺利执行ShellCode。

[看雪官方培训] Unicorn Trace还原Ollvm算法!《安卓高级研修班》2021年6月班火热招生!!

上传的附件:
收藏
点赞0
打赏
分享
最新回复 (14)
雪    币: 248
活跃值: 活跃值 (27)
能力值: ( LV15,RANK:340 )
在线值:
发帖
回帖
粉丝
木桩 活跃值 8 2009-1-13 17:18
2
0
这是注入CSRSS并且LoadLibraryA一个显示对话框的DLL引起的蓝屏截图,相关代码见此楼附件:



同样的使用WinDbg分析,可以得到如下信息:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 50, {f0006c74, 0, bf838c27, 0}

Probably caused by : memory_corruption

Followup: memory_corruption
---------
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: f0006c74, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: bf838c27, If non-zero, the instruction address which referenced the bad memory address.
Arg4: 00000000, (reserved)

Debugging Details:
------------------
READ_ADDRESS: f0006c74

FAULTING_IP:
win32k!NtUserGetDCEx+2c
bf838c27 8b7108 mov esi,dword ptr [ecx+8]

MM_INTERNAL_CODE: 0
DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAULTING_MODULE: bf800000 win32k

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0x50

PROCESS_NAME: csrss.exe

TRAP_FRAME: f9c7ccd8 -- (.trap 0xfffffffff9c7ccd8)
ErrCode = 00000000
eax=e14254c0 ebx=bf838c46 ecx=f0006c6c edx=0055ee64 esi=0055ee70 edi=f9c7cd64
eip=bf838c27 esp=f9c7cd4c ebp=f9c7cd50 iopl=0 vif nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00090246
win32k!NtUserGetDCEx+0x2c:
0008:bf838c27 8b7108 mov esi,dword ptr [ecx+8] ds:0023:f0006c74=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from 805256fb to 805349ae

STACK_TEXT:
f9c7cc74 805256fb 00000050 f0006c74 00000000 nt!KeBugCheckEx+0x1b
f9c7ccc0 804e2ff1 00000000 f0006c74 00000000 nt!MmAccessFault+0x6f5
f9c7ccc0 bf838c27 00000000 f0006c74 00000000 nt!KiTrap0E+0xcc
f9c7cd50 804e006b 00000000 00000000 00000003 win32k!NtUserGetDCEx+0x2c
f9c7cd50 7c92eb94 00000000 00000000 00000003 nt!KiFastCallEntry+0xf8
0055ee58 77d1f229 77d3b22a 00000000 00000000 ntdll!KiFastSystemCallRet
0055f110 77d3b12b 0055f26c 0055f340 0174fb14 USER32!NtUserGetDCEx+0xc
0055f260 77d65fdf 0055f26c 00000028 00000000 USER32!MessageBoxWorker+0x2ba
0055f2b8 77d50574 00000000 0174a1ac 0174a1a8 USER32!MessageBoxTimeoutW+0x7a
0055f2d8 77d6615b 00000000 0174a1ac 0174a1a8 USER32!MessageBoxExW+0x1b
0055f2f4 0174a19f 00000000 0174a1ac 0174a1a8 USER32!MessageBoxW+0x45
WARNING: Stack unwind information not available. Following frames may be wrong.
0055f350 7c9211a7 01740000 00000001 00000000 32+0xa19f
0055f370 7c93cbab 0174b158 01740000 00000001 ntdll!LdrpCallInitRoutine+0x14
0055f478 7c936178 00000000 c0150008 00000000 ntdll!LdrpRunInitializeRoutines+0x344
0055f724 7c9362da 00000000 00163910 0055fa18 ntdll!LdrpLoadDll+0x3e5
0055f9cc 7c801bb9 00163910 0055fa18 0055f9f8 ntdll!LdrLoadDll+0x230
0055fa34 7c801d6e 7ffdcc00 00000000 00000000 KERNEL32!LoadLibraryExW+0x18e
0055fa48 7c801da4 016e0000 00000000 00000000 KERNEL32!LoadLibraryExA+0x1f
0055fa64 7c8341cc 016e0000 0055fac0 00000000 KERNEL32!LoadLibraryA+0x94

0055faac 7c92eac7 7c801d77 016e0000 00000000 KERNEL32!BaseDispatchAPC+0x50
0055fff4 00000000 00000000 000000c8 0000012a ntdll!KiUserApcDispatcher+0x7


STACK_COMMAND: kb

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

MEMORY_CORRUPTOR: LARGE

FAILURE_BUCKET_ID: MEMORY_CORRUPTION_LARGE

BUCKET_ID: MEMORY_CORRUPTION_LARGE

Followup: memory_corruption
---------

kd> lmvm win32k
start end module name
bf800000 bf9c0200 win32k (pdb symbols) D:\Program Files\Symbols\win32k.pdb\D48935A134F249CDA985C45051FBF0462\win32k.pdb
Loaded symbol image file: win32k.sys
Image path: \SystemRoot\System32\win32k.sys
Image name: win32k.sys
Timestamp: Wed Aug 04 14:17:30 2004 (41107F7A)
CheckSum: 001C663B
ImageSize: 001C0200
File version: 5.1.2600.2180
Product version: 5.1.2600.2180
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 3.7 Driver
File date: 00000000.00000000
Translations: 0804.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft(R) Windows(R) Operating System
InternalName: win32k.sys
OriginalFilename: win32k.sys
ProductVersion: 5.1.2600.2180
FileVersion: 5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)
FileDescription: Multi-User Win32 Driver
LegalCopyright: (C) Microsoft Corporation. All rights reserved.


可见这个BSOD是由于内存访问违规引起的。由于win32k.sys中的这条指令,读取了0xf0006c74的内容,而0xf0006c74不再内存中,于是引起了蓝屏。
0008:bf838c27 8b7108   mov esi,dword ptr [ecx+8]      ; ds:0023:f0006c74=????????

回想这个蓝屏发生的原因,由于LoadLibrary了一个cmdShell到csrss.exe的第二个线程中,结果就出现了这个蓝屏。查看蓝屏前的堆栈,可以看到这样三行:
0055fa34 7c801d6e 7ffdcc00 00000000 00000000 KERNEL32!LoadLibraryExW+0x18e
0055fa48 7c801da4 016e0000 00000000 00000000 KERNEL32!LoadLibraryExA+0x1f
0055fa64 7c8341cc 016e0000 0055fac0 00000000 KERNEL32!LoadLibraryA+0x94
这说明了LoadLibraryA确实被执行了。也就是说如果我们写一段ShellCode到CSRSS中,就可以利用CSRSS的权限作我们想做的事情。至于注入CSRSS所需要的权限,例如管理员、SeDebugPrivilege等,参见其他注入教程中关于OpenThread和OpenProcess的部分。

---------------------------------------------------------------------------------------

附件 APC_src.rar 说明
\APC注入_D2009\AnyAPC_Boom.rar              里面是APC注入的主程序,用法见源码目录下的readme.txt
\注射用DLL\多线程cmdshell\s32.dll           改成32.dll丢到Windows安装目录中,注入后监听3820端口,可以Telnet试

相关的程序源码都在里面,自己看吧。另外,建议先扫一遍毒再运行
上传的附件:
雪    币: 459
活跃值: 活跃值 (43)
能力值: ( LV12,RANK:420 )
在线值:
发帖
回帖
粉丝
qihoocom 活跃值 9 2009-1-13 18:09
3
0
第一个蓝屏是CRITICAL_OBJECT_TERMINATION~CRITICAL process退出~

第二个蓝屏除非你触发了0DAY~
什么叫“这也说明了利用APC可以执行任意地址的代码,而不是固定的在某个位置崩溃。“
这纯粹是搞笑嘛
雪    币: 248
活跃值: 活跃值 (27)
能力值: ( LV15,RANK:340 )
在线值:
发帖
回帖
粉丝
木桩 活跃值 8 2009-1-13 22:39
4
0
我那句“这也说明了利用APC可以执行任意地址的代码,而不是固定的在某个位置崩溃。”是复制出来的,放这里确实点歧义 。

WinDbg不熟,不过这两个蓝屏大致还是知道原因:
第一个蓝屏说的 关键进程 就是CSRSS,因为插入了错误的APC回调地址到CSRSS中,导致CSRSS.exe执行非法操作被终止。(这个道理很简单,比如在CSRSS中创建一个远程线程,开始地址随便设个不能正确执行的地方,一样会引发这种蓝屏)
第二个蓝屏是向CSRSS中LoadLibraryA一个命令行Shell的DLL引发的(可以看堆栈中我加粗的三行,说明LoadLibrary执行过了),虽然不知道为什么会蓝,不过肯定不是0Day。这个代码我整理一下稍后上传,今天下午有点事出去了。

不知道这两点我说的对不?

关于第二个蓝屏,carsh dump分析中可以看到:
STACK_TEXT:
f9c7cc74 805256fb 00000050 f0006c74 00000000 nt!KeBugCheckEx+0x1b
f9c7ccc0 804e2ff1 00000000 f0006c74 00000000 nt!MmAccessFault+0x6f5
f9c7ccc0 bf838c27 00000000 f0006c74 00000000 nt!KiTrap0E+0xcc
f9c7cd50 804e006b 00000000 00000000 00000003 win32k!NtUserGetDCEx+0x2c
f9c7cd50 7c92eb94 00000000 00000000 00000003 nt!KiFastCallEntry+0xf8
0055ee58 77d1f229 77d3b22a 00000000 00000000 ntdll!KiFastSystemCallRet
0055f110 77d3b12b 0055f26c 0055f340 0174fb14 USER32!NtUserGetDCEx+0xc
0055f260 77d65fdf 0055f26c 00000028 00000000 USER32!MessageBoxWorker+0x2ba
0055f2b8 77d50574 00000000 0174a1ac 0174a1a8 USER32!MessageBoxTimeoutW+0x7a
0055f2d8 77d6615b 00000000 0174a1ac 0174a1a8 USER32!MessageBoxExW+0x1b
0055f2f4 0174a19f 00000000 0174a1ac 0174a1a8 USER32!MessageBoxW+0x45
WARNING: Stack unwind information not available. Following frames may be wrong.
0055f350 7c9211a7 01740000 00000001 00000000 32+0xa19f
0055f370 7c93cbab 0174b158 01740000 00000001 ntdll!LdrpCallInitRoutine+0x14
0055f478 7c936178 00000000 c0150008 00000000 ntdll!LdrpRunInitializeRoutines+0x344
0055f724 7c9362da 00000000 00163910 0055fa18 ntdll!LdrpLoadDll+0x3e5
0055f9cc 7c801bb9 00163910 0055fa18 0055f9f8 ntdll!LdrLoadDll+0x230
0055fa34 7c801d6e 7ffdcc00 00000000 00000000 KERNEL32!LoadLibraryExW+0x18e
0055fa48 7c801da4 016e0000 00000000 00000000 KERNEL32!LoadLibraryExA+0x1f
0055fa64 7c8341cc 016e0000 0055fac0 00000000 KERNEL32!LoadLibraryA+0x94

0055faac 7c92eac7 7c801d77 016e0000 00000000 KERNEL32!BaseDispatchAPC+0x50
0055fff4 00000000 00000000 000000c8 0000012a ntdll!KiUserApcDispatcher+0x7

可以看出APC是这样执行的:
KiUserApcDispatcher -> 处理APC队列(由于回调地址设的是LoadLibraryA,所以接着是LoadLibraryA)
LoadLibraryA -> 加载DLL名字是就是32.dll,看到这个也不要奇怪 0055f350 7c9211a7 01740000 00000001 00000000 32+0xa19f
MessageBoxW -> 暂时没找出调用这个的原因,不过由于DLL是Delphi 2009写的,应该是自动调用的什么提示功能,反正没有正确执行DLL_Main
NtUserGetDCEx -> (这里就是纯猜测了)像是为了取DC然后绘制对话框,用于显示MessageBox
雪    币: 459
活跃值: 活跃值 (43)
能力值: ( LV12,RANK:420 )
在线值:
发帖
回帖
粉丝
qihoocom 活跃值 9 2009-1-13 23:41
5
0
csrss.exe是RING3进程,除非内核有漏洞,否则是不可能触发蓝屏的

常识啊!

临界进程/线程是一个例外,这是系统主动蓝的,也不可能是CSRSS调用引发的
雪    币: 248
活跃值: 活跃值 (27)
能力值: ( LV15,RANK:340 )
在线值:
发帖
回帖
粉丝
木桩 活跃值 8 2009-1-14 10:00
6
0
临界进程/线程没接触过,我内核这块只能算是触及了点皮毛。
csrss是ring3,不过当csrss被结束时,依然会蓝屏(也就是第一种蓝屏——关键进程被结束)。

这是今天早上对csrss的第二个线程插入APC引发蓝屏的dump分析,回调地址随便设的一个0x80008000,参数设的是0x0F0F0F0F。

符号库有些不全,将就看看吧
Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [D:\Program Files\Debugging Tools for Windows\MEMORY.DMP]
Kernel Complete Dump File: Full address space is available

Symbol search path is: SRV*C:\MaxDOS\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_rtm.040803-2158
Kernel base = 0x804d8000 PsLoadedModuleList = 0x8055bb20
Debug session time: Wed Jan 14 09:44:26.114 2009 (GMT+8)
System Uptime: 2 days 22:34:08.298
Loading Kernel Symbols
.....................................................................................................
Loading User Symbols
..............
Loading unloaded module list
..................................................*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck F4, {3, 80d33da0, 80d33f14, 805fb7a8}

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
Probably caused by : memory_corruption

Followup: memory_corruption
---------

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

CRITICAL_OBJECT_TERMINATION (f4)
A process or thread crucial to system operation has unexpectedly exited or been
terminated.
Several processes and threads are necessary for the operation of the
system; when they are terminated (for any reason), the system can no
longer function.
Arguments:
Arg1: 00000003, Process
Arg2: 80d33da0, Terminating object
Arg3: 80d33f14, Process image file name
Arg4: 805fb7a8, Explanatory message (ascii)

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

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************

PROCESS_OBJECT: 80d33da0

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAULTING_MODULE: 4a680000 csrss

PROCESS_NAME: csrss.exe

EXCEPTION_RECORD: f8a3d9d8 -- (.exr 0xfffffffff8a3d9d8)
ExceptionAddress: 80008000
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 80008000
Attempt to read from address 80008000

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx"

DEFAULT_BUCKET_ID: CODE_CORRUPTION

ERROR_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx"

READ_ADDRESS: 80008000

FAILED_INSTRUCTION_ADDRESS:
+ffffffff80008000
80008000 0000 add byte ptr [eax],al


BUGCHECK_STR: 0xF4_C0000005

STACK_TEXT:
f8a3d520 8062da73 000000f4 00000003 80d33da0 nt!KeBugCheckEx+0x1b
f8a3d544 805fb766 805fb7a8 80d33da0 80d33f14 nt!PspCatchCriticalBreak+0x75
f8a3d574 804e006b 80d33fe8 c0000005 f8a3d9b0 nt!NtTerminateProcess+0x7d
f8a3d574 804df310 80d33fe8 c0000005 f8a3d9b0 nt!KiFastCallEntry+0xf8
f8a3d5f4 8051ee95 ffffffff c0000005 f8a3d9f4 nt!ZwTerminateProcess+0x11
f8a3d9b0 804fdbfe f8a3d9d8 00000000 f8a3dd64 nt!KiDispatchException+0x3a0
f8a3dd34 804e397d 0055f780 0055f79c 00000000 nt!KiRaiseException+0x175
f8a3dd50 804e006b 0055f780 0055f79c 00000000 nt!NtRaiseException+0x31
f8a3dd50 80008000 0055f780 0055f79c 00000000 nt!KiFastCallEntry+0xf8
WARNING: Frame IP not in any known module. Following frames may be wrong.
0055fa64 7c8341cc 0f0f0f0f 0055fac0 00000000 0x80008000
0055faac 7c92eac7 80008000 0f0f0f0f 00000000 KERNEL32!BaseDispatchAPC+0x50
0055fff4 00000000 00000000 00000000 00000000 ntdll!KiUserApcDispatcher+0x7


STACK_COMMAND: kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
804da0c9-804da0cd 5 bytes - nt!KiXMMIZeroPage+30
[ fa f7 80 0c 02:e9 71 b3 65 7f ]
804da10c - nt!KiXMMIZeroPage+73 (+0x43)
[ fb:90 ]
804da112-804da115 4 bytes - nt!KiXMMIZeroPage+79 (+0x06)
[ 57 ff ff ff:c5 cd 69 7f ]
804da545-804da54a 6 bytes - nt!ExAcquireResourceSharedLite+10 (+0x433)
[ fa 8b 75 08 33 db:e9 fb c9 69 7f cc ]
804da564 - nt!ExAcquireResourceSharedLite+98 (+0x1f)
[ fb:90 ]
804da569-804da570 8 bytes - nt!ExAcquireResourceSharedLite+b8 (+0x05)
[ c2 08 00 90 90 90 90 90:e9 21 ac 65 7f c2 08 00 ]
804dcb82 - nt!ExReleaseResourceLite+ba (+0x2619)
[ 99:3f ]
804dcb94 - nt!ExReleaseResourceLite+c8 (+0x12)
[ 87:2d ]
804dcba0 - nt!ExReleaseResourceLite+d0 (+0x0c)
[ 7e:24 ]
804dcbc5-804dcbcd 9 bytes - nt!ExReleaseResourceLite+f5 (+0x25)
[ 90 90 90 90 90 90 90 90:e9 24 86 65 7f 5f 5e 5b ]
804dcbd5-804dcbda 6 bytes - nt!ExReleaseResourceLite+5 (+0x10)
[ 64 a1 24 01 00 00:e9 4c a3 69 7f cc ]
804dcbe8 - nt!ExReleaseResourceLite+18 (+0x13)
[ 36:dc ]
804dcbf9 - nt!ExReleaseResourceLite+29 (+0x11)
[ 25:cb ]
804dcc16-804dcc1a 5 bytes - nt!ExReleaseResourceLite+75 (+0x1d)
[ 66 81 e2 7f ff:e9 f9 a2 69 7f ]
804dfff2-804dfff8 7 bytes - nt!KiFastCallEntry+7f (+0x33dc)
[ c7 45 08 00 0d db ba:e9 ee 6e 69 7f cc cc ]
804e007c-804e0080 5 bytes - nt!KiServiceExit (+0x8a)
[ fa f7 45 70 00:e9 24 51 65 7f ]
804e016b-804e016d 3 bytes - nt!KiSystemCallExitBranch+2 (+0xef)
[ 5a 59 9d:c8 02 04 ]
804e08fb-804e08ff 5 bytes - nt!KiExceptionExit (+0x790)
[ fa f7 45 70 00:e9 04 49 65 7f ]
804e2fc9-804e2fce 6 bytes - nt!KiTrap0E+a4 (+0x26ce)
[ fb f7 45 70 00 02:90 e9 68 22 65 7f ]
804e44b4-804e44b8 5 bytes - nt!ExfInterlockedInsertHeadList+1 (+0x14eb)
[ fa 8b 01 89 02:e9 db 29 69 7f ]
804e44d1-804e44d6 6 bytes - nt!ExfInterlockedInsertTailList+1 (+0x1d)
[ fa 8b 41 04 89 0a:e9 e1 29 69 7f cc ]
804e44f2-804e44f6 5 bytes - nt!ExfInterlockedRemoveHeadList+1 (+0x21)
[ fa 8b 01 3b c1:e9 75 29 69 7f ]
804e4874-804e4878 5 bytes - nt!KeUpdateSystemTime+137 (+0x382)
[ fa ff 15 dc 85:e9 b0 0a 65 7f ]
804e4886-804e488a 5 bytes - nt!KeUpdateSystemTime+149 (+0x12)
[ fa ff 15 dc 85:e9 98 0b 65 7f ]
804e4b4c-804e4b50 5 bytes - nt!ExAcquireResourceExclusiveLite+7 (+0x2c6)
[ 64 a1 24 01 00:e9 03 06 65 7f ]
804e4b6d-804e4b71 5 bytes - nt!ExAcquireResourceExclusiveLite+47 (+0x21)
[ 89 46 1c 66 89:e9 00 06 65 7f ]
804ea175-804ea17a 6 bytes - nt!ExAcquireSharedWaitForExclusive+10 (+0x5608)
[ fa 8b 75 08 33 db:e9 bc cd 68 7f cc ]
804ea194 - nt!ExAcquireSharedWaitForExclusive+ae (+0x1f)
[ fb:90 ]
804ea199-804ea1a0 8 bytes - nt!ExAcquireSharedWaitForExclusive+ef (+0x05)
[ c2 08 00 90 90 90 90 90:0f c7 c8 02 03 c2 08 00 ]
804ee809-804ee80f 7 bytes - nt!CcGetActiveVacb+5 (+0x4670)
[ fa 8b 45 08 8b 48 48:e9 46 87 68 7f cc cc ]
804f01dc-804f01e3 8 bytes - nt!CcSetActiveVacb+7 (+0x19d3)
[ fa 8b 45 08 83 78 48 00:e9 c8 6d 68 7f cc cc cc ]
804f01ff-804f020c 14 bytes - nt!CcSetActiveVacb+a3 (+0x23)
[ 8b 0a 89 48 48 89 58 50:e9 95 6d 68 7f e9 84 6d ]
804f1c70-804f1c74 5 bytes - nt!ExAcquireSharedStarveExclusive+7 (+0x1a71)
[ 64 a1 24 01 00:e9 4e 36 64 7f ]
161 errors : !nt (804da0c9-804f1c74)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

MEMORY_CORRUPTOR: LARGE

FAILURE_BUCKET_ID: MEMORY_CORRUPTION_LARGE

BUCKET_ID: MEMORY_CORRUPTION_LARGE

Followup: memory_corruption
---------

kd> lmvm csrss
start end module name
4a680000 4a685000 csrss (pdb symbols) C:\MaxDOS\Symbols\csrss.pdb\D71FC46DDC57401BBA700BD8668D35CC1\csrss.pdb
Loaded symbol image file: csrss.exe
Mapped memory image file: C:\MaxDOS\Symbols\csrss.exe\41107C1F5000\csrss.exe
Image path: \??\C:\WINDOWS\system32\csrss.exe
Image name: csrss.exe
Timestamp: Wed Aug 04 14:03:11 2004 (41107C1F)
CheckSum: 00010CBF
ImageSize: 00005000
Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0
kd> !process ffffffff80d33da0 3
PROCESS 80d33da0 SessionId: 0 Cid: 017c Peb: 7ffd8000 ParentCid: 0140
DirBase: 06a2e000 ObjectTable: e14da530 HandleCount: 323.
Image: csrss.exe
VadRoot ffaa2e20 Vads 105 Clone 0 Private 382. Modified 2317. Locked 0.
DeviceMap e1004940
Token e14da600
ElapsedTime 23 Days 21:52:37.557
UserTime 00:00:04.476
KernelTime 01:19:13.094
QuotaPoolUsage[PagedPool] 79504
QuotaPoolUsage[NonPagedPool] 5112
Working Set Sizes (now,min,max) (1116, 50, 345) (4464KB, 200KB, 1380KB)
PeakWorkingSetSize 1421
VirtualSize 64 Mb
PeakVirtualSize 65 Mb
PageFaultCount 3623369
MemoryPriority BACKGROUND
BasePriority 13
CommitCharge 572

THREAD 80cf0da8 Cid 017c.018c Teb: 7ffde000 Win32Thread: e1c84598 WAIT: (WrLpcReply) UserMode Non-Alertable
80cf0f9c Semaphore Limit 0x1

THREAD 80cde5b0 Cid 017c.0190 Teb: 7ffdd000 Win32Thread: e1b10008 RUNNING on processor 0
THREAD 80d38da8 Cid 017c.0194 Teb: 7ffdc000 Win32Thread: e15323e0 WAIT: (WrLpcReceive) UserMode Non-Alertable
80da06f0 Semaphore Limit 0x7fffffff

THREAD 80d22da8 Cid 017c.0198 Teb: 7ffdb000 Win32Thread: 00000000 WAIT: (WrLpcReceive) UserMode Non-Alertable
80da2238 Semaphore Limit 0x7fffffff

THREAD 80d32258 Cid 017c.01a4 Teb: 7ffda000 Win32Thread: e1660398 WAIT: (WrLpcReceive) UserMode Non-Alertable
80da06f0 Semaphore Limit 0x7fffffff

THREAD 80d10da8 Cid 017c.01a8 Teb: 7ffd9000 Win32Thread: e15bf618 WAIT: (WrUserRequest) KernelMode Alertable
ffbae888 SynchronizationEvent
80cc5e50 SynchronizationEvent
80daa078 NotificationTimer
80ce6cb8 SynchronizationEvent
80561a40 NotificationEvent
80d25bc0 SynchronizationEvent
80daa048 SynchronizationTimer

THREAD 80db2508 Cid 017c.01ac Teb: 7ffd7000 Win32Thread: e15c1658 WAIT: (WrUserRequest) UserMode Non-Alertable
80ce56f8 SynchronizationEvent
80cf43c8 SynchronizationEvent
ffb9fcd0 SynchronizationEvent

THREAD 80d341b8 Cid 017c.0224 Teb: 7ffd6000 Win32Thread: e16747b0 WAIT: (WrUserRequest) UserMode Non-Alertable
ffb7b128 SynchronizationEvent
80d23190 SynchronizationEvent

THREAD ffa57020 Cid 017c.00b4 Teb: 7ffd5000 Win32Thread: 00000000 WAIT: (UserRequest) UserMode Non-Alertable
ffa57bc4 NotificationEvent

THREAD 80cda588 Cid 017c.00e0 Teb: 7ffd4000 Win32Thread: e1483870 WAIT: (WrLpcReceive) UserMode Non-Alertable
80da06f0 Semaphore Limit 0x7fffffff

THREAD 80cd2370 Cid 017c.046c Teb: 7ffd3000 Win32Thread: e106e008 WAIT: (WrUserRequest) UserMode Non-Alertable
80ddd1c0 SynchronizationEvent

THREAD 80cd47c8 Cid 017c.01d4 Teb: 7ff9f000 Win32Thread: e1976d28 WAIT: (WrLpcReceive) UserMode Non-Alertable
80da06f0 Semaphore Limit 0x7fffffff


kd> !apc
*** Enumerating APCs in all processes
Process 80e82830 System
Process 80ce3c08 smss.exe
Process 80d33da0 csrss.exe
Thread 80cf0da8 ApcStateIndex 0 ApcListHead 80cf0de4 [USER]
KAPC @ 80e031c8
Type 12
KernelRoutine 80577b96 nt!PspQueueApcSpecialApc+0
RundownRoutine 00000000 +0
Process 80d0dda0 winlogon.exe
Process 80d07a50 services.exe
Process 80d36a58 lsass.exe
Process ffb57440 svchost.exe
Process 80d22488 svchost.exe
Process ffb5b020 svchost.exe
Process ffb8b750 svchost.exe
Process 80cf6020 svchost.exe
Process 80d3f550 explorer.exe
Process ffb596e0 spoolsv.exe
Process ffaa2a30 vmusrvc.exe
Process ffaa04a0 ctfmon.exe
Process ffa97638 vmsrvc.exe
Process ffa88700 vpcmap.exe
Process ffa4f020 alg.exe
Process 80cd9be8 wuauclt.exe
Process 80ded870 wuauclt.exe
Process 80cc9798 AnyAPC_Boom.exe


这个蓝屏的原因没说错吧,CSRSS因为执行插入的APC回调地址0x80008000的全零地址,访问违规被OS给结束掉了。

对于第二个蓝屏,也就是我发这个报告的原因了。到底是什么引起的,不知道您能不能详细分析一下
为方便测试,传了一个测试包上来,具体见压缩包里的测试说明。
上传的附件:
雪    币: 459
活跃值: 活跃值 (43)
能力值: ( LV12,RANK:420 )
在线值:
发帖
回帖
粉丝
qihoocom 活跃值 9 2009-1-14 11:57
7
0
你这个也是因为csrss.exe被结束导致蓝屏的,只要将csrss.exe的临界进程标示去掉,就不会再蓝
但你第二个蓝屏就和临界进程无关了
雪    币: 212
活跃值: 活跃值 (22)
能力值: ( LV9,RANK:180 )
在线值:
发帖
回帖
粉丝
ppanger 活跃值 4 2009-1-14 12:10
8
0
很认真的分析文章 学习
雪    币: 248
活跃值: 活跃值 (27)
能力值: ( LV15,RANK:340 )
在线值:
发帖
回帖
粉丝
木桩 活跃值 8 2009-1-14 12:59
9
0
你说的对。
第二个蓝屏我用的DLL好像不是cmdShell,刚才又试了一下,csrss中cmdShell也能加载成功。
根据2楼那个dump的堆栈情况看,应该是压缩包testdll目录下的那个MessageBox的,我再去仔细看看原因。

果然是MessageBox!换了个DLL,这次就不再是关键进程结束了


蓝屏和二楼相同:




PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: f000eefb, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: bf838c27, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)

READ_ADDRESS: f000eefb

FAULTING_IP:
win32k!NtUserGetDCEx+2c
bf838c27 8b7108 mov esi,dword ptr [ecx+8]


MM_INTERNAL_CODE: 0

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAULTING_MODULE: bf800000 win32k

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0x50

PROCESS_NAME: csrss.exe

TRAP_FRAME: f8f8dcd8 -- (.trap 0xfffffffff8f8dcd8)
ErrCode = 00000000
eax=e1c3cd18 ebx=bf838c46 ecx=f000eef3 edx=0055ee34 esi=0055ee40 edi=f8f8dd64
eip=bf838c27 esp=f8f8dd4c ebp=f8f8dd50 iopl=0 vif nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00090246
win32k!NtUserGetDCEx+0x2c:
0008:bf838c27 8b7108 mov esi,dword ptr [ecx+8] ds:0023:f000eefb=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from 805256fb to 805349ae

STACK_TEXT:
f8f8dc74 805256fb 00000050 f000eefb 00000000 nt!KeBugCheckEx+0x1b
f8f8dcc0 804e2ff1 00000000 f000eefb 00000000 nt!MmAccessFault+0x6f5
f8f8dcc0 bf838c27 00000000 f000eefb 00000000 nt!KiTrap0E+0xcc
f8f8dd50 804e006b 00000000 00000000 00000003 win32k!NtUserGetDCEx+0x2c
f8f8dd50 7c92eb94 00000000 00000000 00000003 nt!KiFastCallEntry+0xf8
WARNING: Stack unwind information not available. Following frames may be wrong.
0055f0e0 77d3b12b 0055f23c 00000000 ffffffff ntdll!KiFastSystemCallRet
0055f230 77d65fdf 0055f23c 00000028 00000000 USER32!MessageBoxWorker+0x2ba
0055f288 77d66084 00000000 0016ada8 0017b2e8 USER32!MessageBoxTimeoutW+0x7a
0055f2bc 77d50598 00000000 038b8734 038b8730 USER32!MessageBoxTimeoutA+0x9c
0055f2dc 77d50550 00000000 038b8734 038b8730 USER32!MessageBoxExA+0x1b
0055f2f8 038b8727 00000000 038b8734 038b8730 USER32!MessageBoxA+0x45
0055f350 7c9211a7 038b0000 00000001 00000000 r32+0x8727

0055f370 7c93cbab 038b9134 038b0000 00000001 ntdll!LdrInitializeThunk+0x29
0055f478 7c936178 00000000 c0150008 00000000 ntdll!LdrFindResourceDirectory_U+0x276
0055f724 7c9362da 00000000 00163910 0055fa18 ntdll!RtlValidateUnicodeString+0x506
0055f9cc 7c801bb9 00163910 0055fa18 0055f9f8 ntdll!LdrLoadDll+0x110
0055fa34 7c801d6e 7ffdbc00 00000000 00000000 KERNEL32!LoadLibraryExW+0x18e
0055fa48 7c801da4 038a0000 00000000 00000000 KERNEL32!LoadLibraryExA+0x1f
0055fa64 7c8341cc 038a0000 0055fac0 00000000 KERNEL32!LoadLibraryA+0x94

0055faac 7c92eac7 7c801d77 038a0000 00000000 KERNEL32!BaseDispatchAPC+0x50
0055fff4 00000000 00000000 000000c8 00000110 ntdll!KiUserApcDispatcher+0x7

这样看来,是调用MessageBox导致的,错误位置一样。原因未知


那个r32.dll和源码见附件,就MessageBox然后ExitThread而已。
上传的附件:
雪    币: 201
活跃值: 活跃值 (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
robar 活跃值 2009-1-14 14:30
10
0
深刻的讨论,坐着学习
雪    币: 459
活跃值: 活跃值 (43)
能力值: ( LV12,RANK:420 )
在线值:
发帖
回帖
粉丝
qihoocom 活跃值 9 2009-1-14 16:29
11
0
总有一些发垃圾评论的,看着就恶心!
学习,学习,学习你做个什么声啊!
雪    币: 459
活跃值: 活跃值 (43)
能力值: ( LV12,RANK:420 )
在线值:
发帖
回帖
粉丝
qihoocom 活跃值 9 2009-1-14 16:35
12
0
第二个蓝屏貌似的确是win32k的BUG, csrss如果调messagebox就会挂掉~
雪    币: 248
活跃值: 活跃值 (27)
能力值: ( LV15,RANK:340 )
在线值:
发帖
回帖
粉丝
木桩 活跃值 8 2009-1-15 09:03
13
0
我觉得是因为CSRSS的线程不属于桌面,这里硬要显示个对话框才蓝掉的。先看堆栈:
STACK_TEXT:
f8f8dc74 805256fb 00000050 f000eefb 00000000 nt!KeBugCheckEx+0x1b
f8f8dcc0 804e2ff1 00000000 f000eefb 00000000 nt!MmAccessFault+0x6f5
f8f8dcc0 bf838c27 00000000 f000eefb 00000000 nt!KiTrap0E+0xcc
f8f8dd50 804e006b 00000000 00000000 00000003 win32k!NtUserGetDCEx+0x2c


加粗的 win32k!NtUserGetDCEx+0x2c 说明了0x804e006b前面的一个Call跳到了NtUserGetDCEx。接着看蓝色部分0xbf838c27,这就是出错位置,所以转到了nt!KiTrap0E进行错误处理。所以大致可以确定是在 NtUserGetDCEx 里出的问题。
看到一篇叫“A Story of Unchecked Assumptions in the Windows Kernel”的文章,里面的第28页说了个有趣的特性:
All threads are part of a desktop Except CSRSS-owned threads
but Microsoft owns that code, and it never calls NtUserGetThreadState or NtUserGetDCEx.

简单讲就是除了CSRSS的线程外都是桌面的一部分,CSRSS不会调用NtUserGetThreadState或者NtUserGetDCEx所以不会有问题
所以只要有线程在CSRSS里访问NtUserGetDCEx就挂了,第二个蓝屏估计是这个原因。

另外该文章的作者也提出了这种代码,我想效果应该差不多。
hCsrss = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwCsrssId);
CreateRemoteThread(hCsrss, NULL, 0, NtUserGetThreadState, 15, 0, NULL);

看来老外早就在做这方面的研究了啊
雪    币: 6235
活跃值: 活跃值 (417)
能力值: ( LV7,RANK:112 )
在线值:
发帖
回帖
粉丝
SnowFox 活跃值 2009-1-15 17:54
14
0
不错, 学习了
雪    币: 232
活跃值: 活跃值 (12)
能力值: ( LV3,RANK:20 )
在线值:
发帖
回帖
粉丝
edison黄 活跃值 2009-1-15 23:28
15
0
虽然看不懂。。但是收藏了。。以后学习
谢谢楼主分享
游客
登录 | 注册 方可回帖
返回