by tiamo
目标有2个
第一.加载未签名的驱动.当然本来32位vista就能加载的
第二.安装驱动的时候关掉那个提示窗口
解决方法:
首先我的驱动是签名过的.而且是一个信任的root机构发布的证书.但是并不是微软要求的那8个root机构发布的证书
然后通过patch让windows接受任何信任root机构的证书
先从第二个目标开始.
这安装驱动的时候setupapi.dll会调用wintrustverify函数来验证你的驱动是否经过了签名.如果没签名或者签名了但是root却不是微软要求的那8个root机构的话.就会弹出框了..
如果你的驱动是签过名的.但是不是微软要求的8个root机构的话.wintrustverify返回的错误代码是800b0109.也就是"未信任的root机构".稍微跟踪一下就知道这个是这crypt32.dll里面返回的.一共有4个地方.找个hex编辑工具查找替换一下.把800b010b替换成0.然后为你的驱动签个名.随便找一个受信任的root机构(比如我用的就是我的网上银行的证书).或者自己架设一个证书服务.自己给自己发一个证书.然后把证书加到你的受信任的store里面.签名以后再看.安装的时候就不跳框了...
第二个目标很容易就作到了...但是.即便是在32位下面也必须要patch内核的.因为crypt32.dll是一个很关键的文件.他也是经过签名的.vista要求那些被加载到关键进程里面全部文件都必须要签名.
一个很直观的结果就是.虽然驱动安装不弹框了.但是你的声卡不响了.所以的PlaySound啊sndOpen啊全部返回失败了.这是因为这个crypt32.dll会被加载到audiodg.exe这个进程里面.而这个进程要求加载到里面全部dll,exe都必须签名.显然改过crypt32.dll以后.他的签名就给破坏掉了.
第一个目标稍微比较麻烦.因为内核的签名验证是一层一层的.
电脑在引导的时候.首先mbr里面的代码会加载vista安装盘下面的bootmgr这个文件到内存.然后把执行权交给bootmgr.然后bootmgr会加载system32/winload.exe.然后winload.exe会加载ntoskrnl.exe.
这个加载过程一步一步都有签名判断.
1.mbr加载bootmgr这一步可以不管他.我的系统比较多.我用了grub作为引导程序.而没有使用vista的.
2.bootmgr加载winload.exe.这个地方要求winload.exe是签过名的.
3.winload.exe负责加载ntoskrnl.exe,hal.exe还有全部的boot start的驱动.当然还有这些驱动以及内核需要使用的一些dll.还有一些数据文件.这些文件也都是要求签名的.签名判断是由winload.exe来完成的.
4.ntoskrnl会加载剩下的system start,auto start的这些驱动.以及以后的manual start的驱动,用户层的dll.exe等等.这些文件的签名判断是由ntoskrnl通过一个ci.dll来完成的.ci.dll是ntoskrnl.exe的一个import
运行在内核态的.
所以.patch工作很明确
1.bootmgr需要patch.因为他要判断winload.exe
2.winload.exe需要patch.因为全部的boot start的驱动都是由他判断的.ci.dll也是他判断的
3.ci.dll也需要patch.离开了load过程以后的签名判断就都是他来负责了
bootmgr是一个16位的com程序跟一个32位的pe文件拼接起来的.用个hex编辑工具搜索一下"MZ"也就是dos文件头就能看到一个很明显的标记.把从MZ的地方开始一直到bootmgr的结尾的数据保存下来成一个新文件起名叫bootmgr.dll.用ida打开.ida提示他有调试符号文件.问你要不要加载.你就加载吧..微软很厚道.提供了这个文件的pdb的..哈哈....
16位的那个com不用管他..着重看这个32位的dll吧
BmMain是他的入口函数..这个函数里面一直往下..有个调用BlImgQueryCodeIntegrityBootOptions的调用.根据这个调用的结果来确定是否执行BmFwVerifySelfIntegrity函数.好.把这个地方的代码改成jmp吧.跳过这个BmFwVerifySelfIntegrity函数的调用.
接着到BlImgLoadBootApplication这个函数里面.同样这个地方有个BlImgQueryCodeIntegrityBootOptions函数调用.调用完了就是ImgArchPcatLoadBootApplication.进入这个ArchPcat这个函数可以看到他是通过BlImgLoadPEImageEx函数来加载的.同时能看到签名判断也是这LoadPEimageEx这个函数里面完成的.当BlImgLoadPEImageEx的第6个参数arg6 & 0x10的结果不是0的时候就会进行签名判断.否则跳过这个签名判断.只是判断pe头的checksum.所以如果这调用这个函数的时候不要设置第6个参数的第4位就行了.回到ImgArchPcatLoadBootApplication函数.可以看到他使用进入时候的eax值加上自己的一些判断来生成BlImgLoadPEImageEx第6个参数.再仔细看看就可以发现只是需要清掉BlImgLoadBootApplication调用ImgArchPcatLoadBootApplication之前的eax的第4位就行了.因为ImgArchPcatLoadBootApplication并不去修改这个第4位.所以简单了..清除掉原来设置eax的代码.直接放一个xor eax,eax就行了..
保存一下这个dll,给他checksum一下..然后copy /b + /b一下跟刚刚剥离出来的16位com程序合并起来.命名成bootmgr2.这个bootmgr就算是破解完了.
你要么替换掉原来的bootmgr.要么使用个别的比如grub一类的引导工具试试看.你的系统应该能正常引导起来.接下来破解winload.exe
一样的ida打开winload.exe.加载他的pdb(有了pdb确实省心省力).顺便说一句.从winload开始就支持kernel debug了..你可以用windbg来调试winload了.
winload.exe更简单了.你稍微看看就知道他重用了很多bootmgr的代码.比如是否进行签名判断的地方也是看那第7个参数arg7 & 0x10的值.然后一路track back就能看到如果LoadIntegrityCheckPolicy是0的话.就整个的关掉了winload的签名判断了.所以找到初始化LoadIntegrityCheckPolicy的地方.把他设置层0,这个在OsInitializeCodeIntegrity函数里面.整个函数里面的东西都是不需要的.你直接在函数的开头把LoadIntegrityCheckPolicy设置成0然后ret就行了..
保存这个winload2.exe.checksum一下..
然后用bcdedit添加一个新的{boot loader}.使用这个新的winload2.exe试试看..你的系统应该能引导起来.
到此你的boot start的驱动就能顺利加载了(32位下面当然本来就可以加载).如果你用64位的话.你可以在这里放一个boot start的驱动.然后干掉patch guard.
接下来是ci.dll.这个就麻烦多了..不比得启动过程的判断那么简单.我试过像winload啊bootmgr那样直接跳过全部的签名判断.不过很不幸的是..不行..Spsys.sys文件会bugcheck.这是微软的software license 驱动..很不幸的是他不但没有pdb.而且还充满了花指令.尝试过动态跟踪.经历过n次bugcheck.我放弃了要直接跳过全部的签名判断的方法.而采用现在这种迂回的办法.
ci.dll比较复杂.总体的来说他有两种判断.第一是整个文件的判断.第二是page判断也就是基于内存页的.
第一.ci.dll会去读取system32/catroot/{fxxxxxxx}目录下面的cat文件.然后把这些文件解析完成.以后凡是要判断是否文件有签名的时候只是做一个二叉搜索.这parse这些cat文件的时候为他们设置一个标记来表示这个cat是否通过了微软的8个root机构签名.所以.我们的目标就是让我们自己的cat文件也打上微软认证的标记就行了.跟踪一下就知道.如果我们的cat没有通过微软的认证,那么那个标记位就是1.而通过了的就是2.所以.把那个or byte prt [esi + 44h],1的指令里面的1改成2就行了.具体的位置在MinCryptVerifyCertificateWithPolicy函数.关于ebp-34的操作里面.有or 上1的地方可以都把1修改成2.
这样一来整个文件相关的签名判断的修改就完成了..
第二.基于memory page的判断的.这个比上一个简单.在CiValidateImageData函数的结尾有个mov [ebp-20],0c00000428h的地方.把这个0c0000428给改成0.
保存这个ci.dll.checksum一下.这次就只能覆盖掉了.
好了..全部改完了..引导你的系统吧...
==================================================
vista为这些文件设置了很高的权限.即使是system帐号也只能读取不能修改
你需要把这些文件的所有者都修改成Administrator一类的才能修改这些文件.当然修改完了记得把他的权限还原成原来的样子..那个所有者你需要打"NT Service/TrustedInstaller"
当然有些文件在vista运行中你是没有办法替换的.你可以双系统或者用vista的光盘上的winpe启动你的电脑然后来替换他们...
==================================================
所有的修改都是基于32位vista的...我这里也没有64位的安装盘.
但是64位下的修改也是一样的.不用害怕patch guard.这个不属于patch guard管辖范围.
你的boot start的驱动能加载了.然后再慢慢修理这个patch guard吧...
送上这本理论基础支持....这个pdf相信大家都看过了吧?
虽然32位的跟他说的有些不一样..不过这个有很好的指导意义...
另外还有几张图..破解以后的图
第一.加载未签名的驱动.当然本来32位vista就能加载的
第二.安装驱动的时候关掉那个提示窗口
解决方法:
首先我的驱动是签名过的.而且是一个信任的root机构发布的证书.但是并不是微软要求的那8个root机构发布的证书
然后通过patch让windows接受任何信任root机构的证书
先从第二个目标开始.
这安装驱动的时候setupapi.dll会调用wintrustverify函数来验证你的驱动是否经过了签名.如果没签名或者签名了但是root却不是微软要求的那8个root机构的话.就会弹出框了..
如果你的驱动是签过名的.但是不是微软要求的8个root机构的话.wintrustverify返回的错误代码是800b0109.也就是"未信任的root机构".稍微跟踪一下就知道这个是这crypt32.dll里面返回的.一共有4个地方.找个hex编辑工具查找替换一下.把800b010b替换成0.然后为你的驱动签个名.随便找一个受信任的root机构(比如我用的就是我的网上银行的证书).或者自己架设一个证书服务.自己给自己发一个证书.然后把证书加到你的受信任的store里面.签名以后再看.安装的时候就不跳框了...
第二个目标很容易就作到了...但是.即便是在32位下面也必须要patch内核的.因为crypt32.dll是一个很关键的文件.他也是经过签名的.vista要求那些被加载到关键进程里面全部文件都必须要签名.
一个很直观的结果就是.虽然驱动安装不弹框了.但是你的声卡不响了.所以的PlaySound啊sndOpen啊全部返回失败了.这是因为这个crypt32.dll会被加载到audiodg.exe这个进程里面.而这个进程要求加载到里面全部dll,exe都必须签名.显然改过crypt32.dll以后.他的签名就给破坏掉了.
第一个目标稍微比较麻烦.因为内核的签名验证是一层一层的.
电脑在引导的时候.首先mbr里面的代码会加载vista安装盘下面的bootmgr这个文件到内存.然后把执行权交给bootmgr.然后bootmgr会加载system32/winload.exe.然后winload.exe会加载ntoskrnl.exe.
这个加载过程一步一步都有签名判断.
1.mbr加载bootmgr这一步可以不管他.我的系统比较多.我用了grub作为引导程序.而没有使用vista的.
2.bootmgr加载winload.exe.这个地方要求winload.exe是签过名的.
3.winload.exe负责加载ntoskrnl.exe,hal.exe还有全部的boot start的驱动.当然还有这些驱动以及内核需要使用的一些dll.还有一些数据文件.这些文件也都是要求签名的.签名判断是由winload.exe来完成的.
4.ntoskrnl会加载剩下的system start,auto start的这些驱动.以及以后的manual start的驱动,用户层的dll.exe等等.这些文件的签名判断是由ntoskrnl通过一个ci.dll来完成的.ci.dll是ntoskrnl.exe的一个import
运行在内核态的.
所以.patch工作很明确
1.bootmgr需要patch.因为他要判断winload.exe
2.winload.exe需要patch.因为全部的boot start的驱动都是由他判断的.ci.dll也是他判断的
3.ci.dll也需要patch.离开了load过程以后的签名判断就都是他来负责了
bootmgr是一个16位的com程序跟一个32位的pe文件拼接起来的.用个hex编辑工具搜索一下"MZ"也就是dos文件头就能看到一个很明显的标记.把从MZ的地方开始一直到bootmgr的结尾的数据保存下来成一个新文件起名叫bootmgr.dll.用ida打开.ida提示他有调试符号文件.问你要不要加载.你就加载吧..微软很厚道.提供了这个文件的pdb的..哈哈....
16位的那个com不用管他..着重看这个32位的dll吧
BmMain是他的入口函数..这个函数里面一直往下..有个调用BlImgQueryCodeIntegrityBootOptions的调用.根据这个调用的结果来确定是否执行BmFwVerifySelfIntegrity函数.好.把这个地方的代码改成jmp吧.跳过这个BmFwVerifySelfIntegrity函数的调用.
接着到BlImgLoadBootApplication这个函数里面.同样这个地方有个BlImgQueryCodeIntegrityBootOptions函数调用.调用完了就是ImgArchPcatLoadBootApplication.进入这个ArchPcat这个函数可以看到他是通过BlImgLoadPEImageEx函数来加载的.同时能看到签名判断也是这LoadPEimageEx这个函数里面完成的.当BlImgLoadPEImageEx的第6个参数arg6 & 0x10的结果不是0的时候就会进行签名判断.否则跳过这个签名判断.只是判断pe头的checksum.所以如果这调用这个函数的时候不要设置第6个参数的第4位就行了.回到ImgArchPcatLoadBootApplication函数.可以看到他使用进入时候的eax值加上自己的一些判断来生成BlImgLoadPEImageEx第6个参数.再仔细看看就可以发现只是需要清掉BlImgLoadBootApplication调用ImgArchPcatLoadBootApplication之前的eax的第4位就行了.因为ImgArchPcatLoadBootApplication并不去修改这个第4位.所以简单了..清除掉原来设置eax的代码.直接放一个xor eax,eax就行了..
保存一下这个dll,给他checksum一下..然后copy /b + /b一下跟刚刚剥离出来的16位com程序合并起来.命名成bootmgr2.这个bootmgr就算是破解完了.
你要么替换掉原来的bootmgr.要么使用个别的比如grub一类的引导工具试试看.你的系统应该能正常引导起来.接下来破解winload.exe
一样的ida打开winload.exe.加载他的pdb(有了pdb确实省心省力).顺便说一句.从winload开始就支持kernel debug了..你可以用windbg来调试winload了.
winload.exe更简单了.你稍微看看就知道他重用了很多bootmgr的代码.比如是否进行签名判断的地方也是看那第7个参数arg7 & 0x10的值.然后一路track back就能看到如果LoadIntegrityCheckPolicy是0的话.就整个的关掉了winload的签名判断了.所以找到初始化LoadIntegrityCheckPolicy的地方.把他设置层0,这个在OsInitializeCodeIntegrity函数里面.整个函数里面的东西都是不需要的.你直接在函数的开头把LoadIntegrityCheckPolicy设置成0然后ret就行了..
保存这个winload2.exe.checksum一下..
然后用bcdedit添加一个新的{boot loader}.使用这个新的winload2.exe试试看..你的系统应该能引导起来.
到此你的boot start的驱动就能顺利加载了(32位下面当然本来就可以加载).如果你用64位的话.你可以在这里放一个boot start的驱动.然后干掉patch guard.
接下来是ci.dll.这个就麻烦多了..不比得启动过程的判断那么简单.我试过像winload啊bootmgr那样直接跳过全部的签名判断.不过很不幸的是..不行..Spsys.sys文件会bugcheck.这是微软的software license 驱动..很不幸的是他不但没有pdb.而且还充满了花指令.尝试过动态跟踪.经历过n次bugcheck.我放弃了要直接跳过全部的签名判断的方法.而采用现在这种迂回的办法.
ci.dll比较复杂.总体的来说他有两种判断.第一是整个文件的判断.第二是page判断也就是基于内存页的.
第一.ci.dll会去读取system32/catroot/{fxxxxxxx}目录下面的cat文件.然后把这些文件解析完成.以后凡是要判断是否文件有签名的时候只是做一个二叉搜索.这parse这些cat文件的时候为他们设置一个标记来表示这个cat是否通过了微软的8个root机构签名.所以.我们的目标就是让我们自己的cat文件也打上微软认证的标记就行了.跟踪一下就知道.如果我们的cat没有通过微软的认证,那么那个标记位就是1.而通过了的就是2.所以.把那个or byte prt [esi + 44h],1的指令里面的1改成2就行了.具体的位置在MinCryptVerifyCertificateWithPolicy函数.关于ebp-34的操作里面.有or 上1的地方可以都把1修改成2.
这样一来整个文件相关的签名判断的修改就完成了..
第二.基于memory page的判断的.这个比上一个简单.在CiValidateImageData函数的结尾有个mov [ebp-20],0c00000428h的地方.把这个0c0000428给改成0.
保存这个ci.dll.checksum一下.这次就只能覆盖掉了.
好了..全部改完了..引导你的系统吧...
==================================================
vista为这些文件设置了很高的权限.即使是system帐号也只能读取不能修改
你需要把这些文件的所有者都修改成Administrator一类的才能修改这些文件.当然修改完了记得把他的权限还原成原来的样子..那个所有者你需要打"NT Service/TrustedInstaller"
当然有些文件在vista运行中你是没有办法替换的.你可以双系统或者用vista的光盘上的winpe启动你的电脑然后来替换他们...
==================================================
所有的修改都是基于32位vista的...我这里也没有64位的安装盘.
但是64位下的修改也是一样的.不用害怕patch guard.这个不属于patch guard管辖范围.
你的boot start的驱动能加载了.然后再慢慢修理这个patch guard吧...
送上这本理论基础支持....这个pdf相信大家都看过了吧?
虽然32位的跟他说的有些不一样..不过这个有很好的指导意义...
另外还有几张图..破解以后的图