无忧启动论坛

标题: 在低配置系统上重现高速机蓝屏故障的方法 [打印本页]

作者: asbai 时间: 2006-10-21 21:02
标题: 在低配置系统上重现高速机蓝屏故障的方法
发现很多兄台对这个问题很有兴趣，想重现这个问题来自己研究。

之前提到过此问题是由于 xpelogon 完成初始化的速度超过 smss 和 winlogon，导致 kill 这两个进程的时机太靠前而产生的。所以重现这个故障的方法很简单，只要提高 xpelogon 完成初始化任务的速度就可以了：
1. 删除 PE 注册表中调用 xpehelp 的启动项，这同时跳过了 peconfig.ini 里定义的 2 秒时延。
2. 删除设置输入法等其它启动项。
3. 如果你已经删除了xpeinit -9 项，现在为了重现故障请恢复它。
4. 重新制作 PE 映像，刻盘或替换硬盘上的版本。
5. 重启机器。

以上方法在 AMD AthlonXP2600+ 上测试通过。:)

作者: lxl1638 时间: 2006-10-22 00:30
呵呵，想看蓝屏的来吧。
正是因为这个，120M的IMG版很少出现蓝屏，因为它执行的启动项比较多，XPELogon完成任务时，WinLogon也完成了它的任务，这时Kill掉WinLogon没事了。但在那个超级微型版中，启动项比较少，XPELogon完成任务时，WinLogon还没完成它的任务，此时Kill掉WinLogon就蓝屏。

[ 本帖最后由 lxl1638 于 2006-10-22 01:06 AM 编辑 ]

作者: Rinrin 时间: 2006-10-22 10:13
按照asbai的方法做了试验
随后找到了产生0x71的地方
给ntoskrnl.exe打了一个补丁(其实就是把jz指令改为nop) :)
结果setupldr.bin似乎有校验的
无法加载
我倒～～～

作者: asbai 时间: 2006-10-22 15:34

原帖由 Rinrin 于 2006-10-22 10:13 AM 发表
按照asbai的方法做了试验
随后找到了产生0x71的地方
给ntoskrnl.exe打了一个补丁(其实就是把jz指令改为nop) :)
结果setupldr.bin似乎有校验的
无法加载
我倒～～～

呵呵，兄台果然乃执着的技术高人。不过小弟拜读以后觉得有几处不妥:L：

1. 毛桃兄的 setupldr.bin 来自 2k3 sp1，而 nt kernel 则出自 xp sp2。据此推测 ntoskrnl.exe 是使用了某种方式的自校验，校验工作不似出自 setupldr.bin。

2. 阅读兄台高论，猜测兄是改了 kernel 里的错误处理代码，让 kernel 对 smss 等系统关键进程的出错视而不见。窃以为此举大大不妥。明知道关键进程出错了却视而不见很有点掩耳盗铃的味道:P。带着关键错误运行的系统可能比蓝屏产生更恶劣的后果:)。

3. 微软对 PE 本身的版权许可较为宽松，只在应用场合方面做了些限制。但是被反向工程并 crack 后的内核显然属于非法版本了，在中国的著作权保护法下，出于个人学习和研究目的这样做问题不大。但是这种打着补丁的 PE 一旦流入到国外或企事业机构、盈利组织里就惨了。 ;P

[ 本帖最后由 asbai 于 2006-10-22 03:37 PM 编辑 ]

作者: lxl1638 时间: 2006-10-22 17:21
这些本人是文盲啦，不过总觉得给nt kernel打补丁不是很好的方法，除非对它完全了解(如有它的源码)，asbai 兄提出延迟Kill掉smss是很稳妥的办法，因为XPEinit -9也是这个操作，只不过是它早了些，我们把它延迟去做。

作者: Rinrin 时间: 2006-10-22 17:43

原帖由 asbai 于 2006-10-22 03:34 PM 发表

呵呵，兄台果然乃执着的技术高人。不过小弟拜读以后觉得有几处不妥:L：

1. 毛桃兄的 setupldr.bin 来自 2k3 sp1，而 nt kernel 则出自 xp sp2。据此推测 ntoskrnl.exe 是使用了某种方式的自校验，校验工作 ...

呵呵
娱乐一下嘛:)

其实我猜测xpeinit运行时，所有的初始化工作已经做完了，出现0x71错误只是因为内核线程顽固地等待了5秒

经过分析，仅有下面一处：

_Phase1Initialization@4 proc near
..............
or    [ebp+Timeout.HighPart], 0FFFFFFFFh
lea    eax, [ebp+Timeout]
push eax          ; Timeout
push ebx          ; Alertable
push dword ptr [ebp-554h] ; Handle
mov    [ebp+Timeout.LowPart], 0FD050F80h
call _ZwWaitForSingleObject@12 ; ZwWaitForSingleObject(x,x,x)
test eax, eax
jz    loc_5C7AB4

..................
loc_5C7AB4:          ; BugCheckCode
push 71h
jmp    loc_5C7AB6
loc_5C7AB6:          ; KeBugCheck(x)
call _KeBugCheck@4
mov    ecx, [ebp+var_4]
pop    esi
pop    ebx
call @xHalReferenceHandler@4 ; xHalReferenceHandler(x)
leave
retn 4

因为是在加载阶段提示ntoskrnl.exe无法加载，错误代码为4
这时候完全由setupldr.bin主导引导过程，因此有了上述看法

作者: Rinrin 时间: 2006-10-22 17:44

原帖由 lxl1638 于 2006-10-22 05:21 PM 发表
这些本人是文盲啦，不过总觉得给nt kernel打补丁不是很好的方法，除非对它完全了解(如有它的源码)，asbai 兄提出延迟Kill掉smss是很稳妥的办法，因为XPEinit -9也是这个操作，只不过是它早了些，我们把它延迟去做。

是滴
偶同意:lol

作者: asbai 时间: 2006-10-22 18:29

原帖由 Rinrin 于 2006-10-22 05:43 PM 发表

呵呵
娱乐一下嘛:)

其实我猜测xpeinit运行时，所有的初始化工作已经做完了，出现0x71错误只是因为内核线程顽固地等待了5秒

经过分析，仅有下面一处：

因为是在加载阶段提示ntoskrnl.exe无法加载，错误 ...

呵呵，娱乐一下确实无妨的说。:)

关于 ntoskrnl.exe 无法加载应该是其装载时进行自校验的结果。刚看了毛桃兄关于换 xp boot logo 的大作，也是改完了 ntoskrnl.exe 以后要用 modifyPE update 其 crc 校验和的。不过俺试了试好像光 update 校验和也没用。可能新版的 kernel 直接验证数字签名了～

作者: Rinrin 时间: 2006-10-22 18:50

原帖由 asbai 于 2006-10-22 06:29 PM 发表

呵呵，娱乐一下确实无妨的说。:)

关于 ntoskrnl.exe 无法加载应该是其装载时进行自校验的结果。刚看了毛桃兄关于换 xp boot logo 的大作，也是改完了 ntoskrnl.exe 以后要用 modifyPE update 其 crc 校验和 ...

多谢提醒！
下面是修改过的NTOSKRNL.EXE
大家测试一下有没有什么问题
我自己测试很正常:lol

用法：
替换掉asbai兄所做PE里的同名文件即可
rinrin.ys168.com
Cracked NTOS Kernel下

作者: lxl1638 时间: 2006-10-22 19:11
高手出场，果然不同，希望大家测试，是给NT Kernel打补丁好还是PeWaitKill好。

作者: lxl1638 时间: 2006-10-22 19:33

原帖由 Rinrin 于 2006-10-22 05:43 PM 发表

呵呵
娱乐一下嘛:)

其实我猜测xpeinit运行时，所有的初始化工作已经做完了，出现0x71错误只是因为内核线程顽固地等待了5秒

经过分析，仅有下面一处：

因为是在加载阶段提示ntoskrnl.exe无法加载，错误 ...

有一点不明，内核线程顽固地等待了5秒，按理说，这5秒后再执行XPEinit -9应该不会出现蓝屏了，但有些机子要延时7秒或更多。

作者: Rinrin 时间: 2006-10-22 21:29

原帖由 lxl1638 于 2006-10-22 07:33 PM 发表

有一点不明，内核线程顽固地等待了5秒，按理说，这5秒后再执行XPEinit -9应该不会出现蓝屏了，但有些机子要延时7秒或更多。

这个。。。
我也不知道如何解释:P

作者: asbai 时间: 2006-10-22 21:39

原帖由 lxl1638 于 2006-10-22 07:33 PM 发表

有一点不明，内核线程顽固地等待了5秒，按理说，这5秒后再执行XPEinit -9应该不会出现蓝屏了，但有些机子要延时7秒或更多。

我想 Rinrin 兄的意思是这样的：在开始 5 秒等待之前，smss 还有很多服务要启。假如启服务花了 6 秒，之后又等了 5 秒，那 smss 进程就至少要生存 11s。

Rinrin 兄认为 smss 被 kill 的时候正好在那后 5 秒之间。不过俺觉得这种估计有点危险：
1. 如果机器足够高速，xpelogon 完成过快，smss 很可能在前面的阶段就被 kill。
2. 这段 nt kernel 的出错处理代码有可能是几种导致 0x71 的错误公用的（虽然可能性不大，但没有源码还是有点难说，呵呵），简单的跳过可能发生非预期的后果。
3. 微软要 “顽固地” 等 5s 我觉得想必有他的道理，他们有庞大的测试环境和广泛的用户反馈，猜想不这样做可能在某些机型上发生问题。直接跳过恐怕影响兼容性。
4. 现在超线程技术和双核、四核处理器正在迅速普及。XP 的 kernel 也有不同的对应版本。兄台要一个一个 crack 过来貌似太辛苦了 :lol。何况从操作系统原理上讲 SMP Kernel 比单 CPU Kernel 在同步问题上又要复杂很多，crack 起来也更具风险。

:)

[ 本帖最后由 asbai 于 2006-10-22 09:41 PM 编辑 ]

作者: asbai 时间: 2006-10-22 21:43

原帖由 Rinrin 于 2006-10-22 09:29 PM 发表

这个。。。
我也不知道如何解释:P

我晕，老兄竟然这么回法。。。。可怜我还搜肠刮肚地揣摩兄台的意思 :L:P

欢迎光临无忧启动论坛 (http://bbs.wuyou.net/)