能力值：
( LV15，RANK：340 )
2 楼
这是注入CSRSS并且LoadLibraryA一个显示对话框的DLL引起的蓝屏截图，相关代码见此楼附件：
同样的使用WinDbg分析，可以得到如下信息：
!analyze -v PAGE_FAULT_IN_NONPAGED_AREA (50) Arg1: f0006c74, memory referenced. Arg3: bf838c27, If non-zero, the instruction address which referenced the bad memory address. READ_ADDRESS: f0006c74 FAULTING_IP: FAULTING_MODULE: bf800000 win32k PROCESS_NAME: csrss.exe ecx=f0006c6c edx=0055ee64 esi=0055ee70 edi=f9c7cd640008:bf838c27 8b7108 mov esi,dword ptr [ecx+8] ds:0023:f0006c74=???????? 0055fa34 7c801d6e 7ffdcc00 00000000 00000000 KERNEL32!LoadLibraryExW+0x18e lmvm win32k
可见这个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试
相关的程序源码都在里面，自己看吧。另外，建议先扫一遍毒再运行
上传的附件：
能力值：
( LV12，RANK：420 )
3 楼
第一个蓝屏是CRITICAL_OBJECT_TERMINATION~CRITICAL process退出~
能力值：
( LV15，RANK：340 )
4 楼
我那句“这也说明了利用APC可以执行任意地址的代码，而不是固定的在某个位置崩溃。”是复制出来的
，放这里确实点歧义 。
WinDbg不熟，不过这两个蓝屏大致还是知道原因：
第一个蓝屏说的 关键进程 就是CSRSS，因为插入了错误的APC回调地址到CSRSS中，导致CSRSS.exe执行非法操作被终止。（这个道理很简单，比如在CSRSS中创建一个远程线程，开始地址随便设个不能正确执行的地方，一样会引发这种蓝屏）
第二个蓝屏是向CSRSS中LoadLibraryA一个命令行Shell的DLL引发的（可以看堆栈中我加粗的三行，说明LoadLibrary执行过了），虽然不知道为什么会蓝，不过肯定不是0Day。这个代码我整理一下稍后上传，今天下午有点事出去了。
不知道这两点我说的对不？
关于第二个蓝屏，carsh dump分析中可以看到：0055fa34 7c801d6e 7ffdcc00 00000000 00000000 KERNEL32!LoadLibraryExW+0x18e
能力值：
( LV12，RANK：420 )
5 楼
csrss.exe是RING3进程，除非内核有漏洞，否则是不可能触发蓝屏的
能力值：
( LV15，RANK：340 )
6 楼
临界进程/线程没接触过，我内核这块只能算是触及了点皮毛。
csrss是ring3，不过当csrss被结束时，依然会蓝屏（也就是第一种蓝屏——关键进程被结束）。
这是今天早上对csrss的第二个线程插入APC引发蓝屏的dump分析，回调地址随便设的一个0x80008000，参数设的是0x0F0F0F0F。
!analyze -v CRITICAL_OBJECT_TERMINATION (f4) Arg1: 00000003, Process Arg2: 80d33da0, Terminating object PROCESS_NAME: csrss.exe ExceptionAddress: 80008000 READ_ADDRESS: 80008000 FAILED_INSTRUCTION_ADDRESS: lmvm csrss !process ffffffff80d33da0 3 !apc
这个蓝屏的原因没说错吧，CSRSS因为执行插入的APC回调地址0x80008000的全零地址，访问违规被OS给结束掉了。
对于第二个蓝屏，也就是我发这个报告的原因了。到底是什么引起的，不知道您能不能详细分析一下
为方便测试，传了一个测试包上来，具体见压缩包里的测试说明。
上传的附件：
能力值：
( LV12，RANK：420 )
7 楼
你这个也是因为csrss.exe被结束导致蓝屏的，只要将csrss.exe的临界进程标示去掉，就不会再蓝
能力值：
( LV9，RANK：180 )
8 楼
很认真的分析文章 学习
能力值：
( LV15，RANK：340 )
9 楼
你说的对。
第二个蓝屏我用的DLL好像不是cmdShell，刚才又试了一下，csrss中cmdShell也能加载成功。
根据2楼那个dump的堆栈情况看，应该是压缩包testdll目录下的那个MessageBox的，我再去仔细看看原因。
果然是MessageBox！换了个DLL，这次就不再是关键进程结束了
蓝屏和二楼相同：
PAGE_FAULT_IN_NONPAGED_AREA (50) Arg1: f000eefb, memory referenced. READ_ADDRESS: f000eefb FAULTING_IP: FAULTING_MODULE: bf800000 win32k PROCESS_NAME: csrss.exe ecx=f000eef3 edx=0055ee34 esi=0055ee40 edi=f8f8dd64f000eefb =????????f8f8dd50 804e006b 00000000 00000000 00000003 win32k!NtUserGetDCEx+0x2c 0055f2dc 77d50550 00000000 038b8734 038b8730 USER32!MessageBoxExA+0x1b 0055fa34 7c801d6e 7ffdbc00 00000000 00000000 KERNEL32!LoadLibraryExW+0x18e
那个r32.dll和源码见附件，就MessageBox然后ExitThread而已。
上传的附件：
能力值：
( LV2，RANK：10 )
10 楼
深刻的讨论，坐着学习
能力值：
( LV12，RANK：420 )
11 楼
总有一些发垃圾评论的，看着就恶心！
学习，学习，学习你做个什么声啊！
能力值：
( LV12，RANK：420 )
12 楼
第二个蓝屏貌似的确是win32k的BUG, csrss如果调messagebox就会挂掉~
能力值：
( LV15，RANK：340 )
13 楼
我觉得是因为CSRSS的线程不属于桌面，这里硬要显示个对话框才蓝掉的。先看堆栈：
STACK_TEXT: bf838c27 00000000 f000eefb 00000000 nt!KiTrap0E+0xccf8f8dd50 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
简单讲就是除了CSRSS的线程外都是桌面的一部分，CSRSS不会调用NtUserGetThreadState或者NtUserGetDCEx所以不会有问题
所以只要有线程在CSRSS里访问NtUserGetDCEx就挂了，第二个蓝屏估计是这个原因。
另外该文章的作者也提出了这种代码，我想效果应该差不多。
hCsrss = OpenProcess(PROCESS_ALL_ACCESS, FALSE, dwCsrssId);
CreateRemoteThread(hCsrss, NULL, 0, NtUserGetThreadState, 15, 0, NULL);
看来老外早就在做这方面的研究了啊
能力值：
( LV8，RANK：122 )
14 楼
不错, 学习了
能力值：
( LV3，RANK：20 )
15 楼
虽然看不懂。。但是收藏了。。以后学习
。
