|
分享源码
界面截图: |
- |
是否带模块: |
纯源码 |
备注说明: |
- |
' 1、这段代码本身没有攻击性,就是个单纯的写出文件。
' 2、除非打了最新微软补丁,否则屏幕会反复重启,电脑将会无法正常使用。
' 3、电脑重启后此BUG依旧存在,电脑依旧无法正常使用!
' 4、BUG影响到win7、win10、win11系统。
' --------------BUG分析--------------
' 1、首先我们查看崩溃堆栈,可以看到加载额外图标资源崩溃,其实问题不出在图标资源本身而是另有玄机,我这里写出的就是易语言的默认图标。
' 2、windows有两套文件名管理逻辑,一个是长文件名,一个是短文件名。
' 3、windows下的短文件名其实是dos+fat12/fat16时代的产物,又称为8.3命名法,其中的8是指文件名或目录名的主体部分小于等于8个字符,其中的3是指文件名或目录名的扩展部分小于等于3个字符。
' 4、长文件名转短文件名都会包含一个~符号,问题就出在这里。
' 5、正常逻辑,如果文件名包含~符号,先判断是不是8.3格式,如果不是8.3格式则不处理,而判断是不是8.3格式第一步是判断文件名的长度。
' 6、我们逆向系统代码可以看到当判断文件名中包含~符号时,会调用LdrpCnvrtShortToLongFileName函数进行转换,转换过程中我们可以看到里面调用了NtQueryDirectoryFile函数来获取文件基本信息,其中就有文件名长度信息。
' 7、微软帮助文档中有写到,第六个参数和第八个参数代码传入了Heap和3,Heap是一段内存缓冲区,指向的是FileInformation指针,而FileInformation并不是一个固定的结构体,而是由第八个参数决定的,第八个参数转入的是3,对应的是FileBothDirectoryInformation,是一个结构体,我们通过计算,可以看到Heap+60,偏移60对应的值是FileNameLength,这个值就是文件名的长度,单位是byte!!!
' 8、if(v8<=0x104)看到这句条件判断没?0x104不就是260嘛,MAX_PATH啊!但是它的单位可不是字节啊!而是字符啊!我们这里写出的问题大于了130个字符,以UNICODE方式保存的文件名实际占用字节数要乘以2!显然大于了260这个逻辑!但问题是微软在这个if底下没有else!也就是说文件名超过了130个字符就没做任何处理就返回了!并且没有做任何事!引用返回结果的代码没有判断值的合法性,所以导致空指针异常,程序就崩溃了。这个低级的问题很神奇地出现在windows的内核ntdll的dll中。
' 9、直到10月8日的win11补丁KB5044284才对代码进行了修改,看起来是修复了,我们看看微软是咋修复的:
' 10、微软增加了一个else { v6=0xC0000106 },并没有解决byte和字符之间的关系,目前这个在问题上还有BUG可以利用,也许以后还会修复吧。
|
评分
-
查看全部评分
|