创建c:\con.txt吗？windows文件系统漏洞
作者：
创建c:\con.txt吗？windows文件系统漏洞
你会建立c:\con.txt吗？--windows文件系统漏洞
唉，写完了前面的废话头都昏了，有错误及时告诉我哦。
----------------------------
如果你在想con.txt不是很正常吗？那好，你先去创建下，只要带有独立的con字样的文件就好，然后悟出什么了再看这篇文章（如果你用linux或者mac或者unix那就算了）。
呵呵，正常来说带有con、prn、com1这样字眼的文件或目录是不能创建的(原因自己找)，但我想到了以前在安全焦点的一篇文章，是教你创建带"\"的文件夹的。当时的方法是用控制台命令（如果你叫dos命令那是不标准的）mkdir csk..\这样的语法创建的。看来这是windows一个文件系统的漏洞了，没错……
我后来就在想其中的原理，可能你会发现像上面的csk..\在创建后是csk.，而他实际被windows解释为访问mkdir csk.\的目录。看来有字符在创建时被略去了。而一次偶然机会我发现mkdir C:\con\是成功的，在c下面出现了c:\con文件夹，而且删不掉……呵呵，有一个bug……
我这时突然想到了可能的原因：首先创建目录时肯定要验证正确性，而像这种C:\dir\肯定是先将\符号略去了，但后面的内容呢？看来windows似乎不去检查了……否则mkdir c:\con\就应该失败了，而mkdir c:\con肯定是无效的。
所以我在想是否创建的文件也能利用这个漏洞夺过windows文件系统的一些检查呢？正如你看到的，我成功了^-^
呵呵，这可不是画出来的哦，是货真价实的con.txt。其实原理和我上面的猜测差不多，但由于时间有限，我的分析不一定正确，下面给出具体破解过程：
2005.8.1：23:00
首先我要知道mkdir造成漏洞的原因，于是拿出ollydbg去调试cmd.exe(mkdir是内部命令嘛，不知他找谁？）。接着对KERNEL32.CreateDirectoryW设断点，果然在输入了mkdir c:\con\后中断了。自然单步跟入CreateDirectoryW：
----------------------------------------------------------------
7C81E97F 50 push eax
7C81E980 57 push edi
7C81E981 FF15 3C11807C call dword ptr ds:[<&ntdll.RtlDosPathNameToNtPathName_U>>
; ntdll.RtlDosPathNameToNtPathName_U
7C81E987 84C0 test al,al
7C81E989 0F84 8ACA0100 je kernel32.7C83B419
7C81E98F 66:817D F4 F001 cmp word ptr ss:[ebp-C],1F0
7C81E995 0F87 8CCA0100 ja kernel32.7C83B427
7C81E99B 8B45 F8 mov eax,dword ptr ss:[ebp-8]
----------------------------------------------------------------
注意上面的API:RtlDosPathNameToNtPathName_U,在执行完了以后，ss:[ebp-8]指向的位置存放着:\??\c:\con\(unicode)。
然后程序执行到:
7C81E9FE FF15 0810807C call dword ptr ds:[<&ntdll.NtCreateFile>]
呵呵，Native的创建文件，到此为止C:\con已经在你硬盘上了，由此可推测那个\??\c:\con\(unicode)便是最终的生成路径了。
你必须用rd c:\con\才能删除那个目录！
然后再试mkdir c:\con：继续跟踪，虽然也到了ntdll.NtCreateFile，但很明显函数执行失败了……不过可以明确一点CreateDirectoryW似乎不检查文件合法性……
不过我不服气，想到那个\??\c:\con\(unicode)总该起点作用吧，于是又用了这段mkdir c:\coo。
然后再运行到ntdll.RtlDosPathNameToNtPathName_U以后找到了那段unicode的地址:dword ptr ss:[ebp-8],当时是0x001581E8，
于是打开了内存修改：
先找到那个地址：
001581E0 47 00 45 00 0F 07 1E 00 5C 00 3F 00 3F 00 5C 00 G.E. .\.?.?.\.
001581F0 63 00 3A 00 5C 00 63 00 6F 00 6F 00 00 00 AD BA c.:.\.c.o.o...
然后手动改为\??\c:\con\（注意是unicode，这里多加了个\，为了绕过验证）：
001581E0 47 00 45 00 0F 07 1E 00 5C 00 3F 00 3F 00 5C 00 G.E. .\.?.?.\.
001581F0 63 00 3A 00 5C 00 63 00 6F 00 6E 00 5C 00 00 00 c.:.\.c.o.n.\...
然后就按F9让他去吧，呵呵，成功了，虽然打了mkdir c:\coo，但在c:\出现了con文件夹！
到目前为止已经搞一段落了，我先来总结下：
1.原先的文件名漏洞并不是出现在mkdir和rmdir这两个命令中，而是ntdll.NtCreateFile，换句话说你编写程序调用CreateDirectoryW(L"C:\\con\\",NULL);也会有同样效果。
2.加了\后可以成功创建文件原因不明，但的确可以绕过一些检查。
3.虽然原先的路径字符串对是否创建文件成功（ntdll.NtCreateFile）有作用，但似乎最终文件名是由那段unicode定的。
好了，现在心里已经有点头绪了，那我们来试下CreateFileW吧，也就是要创建一个文件，比如con.txt。
想到控制台中>>这个重定向命令。比如help >>c:\aa.txt可以将help命令的内容输入到aa.txt里面，那肯定是要调用CreateFileW了，但先不管这个，先试验下这个:
help >>c:\con.txt\(呵呵，多加一个\,企图绕过验证)
结果:
C:\WINDOWS\system32>help >>c:\con.txt\
文件名、目录名或卷标语法不正确。
呵呵，看来CreateFileW与CreateDirectoryW不同了，然后又试了C:\WINDOWS\system32>help >>c:\con.txt，这回更搞笑，唉都忘了con含义了（自己试试看）。
看来命令行里靠不住了，于是自己编了个小程序:
HANDLE pfile=CreateFile("C:\con.txt",FILE_GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,0,0);
if (pfile!=INVALID_HANDLE_VALUE)
{
MessageBox(NULL,L"OK!",NULL,MB_OK);
}
当然运行这个肯定是失败的，不过还是先用ollydbg看下：
跟进CreateFileW后，首先执行API的是:ntdll.RtlInitUnicodeString，呵呵，看名字就知道含义了~
同时前面的ntdll.RtlDosPathNameToNtPathName_U又出现了:
7C8109E9 50 push eax
7C8109EA 56 push esi
7C8109EB FF15 3C11807C call dword ptr ds:[<&ntdll.RtlDosPathNameToNtPathName_U>>;
7C8109F1 84C0 test al,al
7C8109F3 0F84 408E0200 je kernel32.7C839839
呵呵，看来又会是老样子吗？先终止吧，把代码改称
HANDLE pfile=CreateFile("C:\co.txt",FILE_GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,0,0);
然后用老办法，到了ntdll.RtlDosPathNameToNtPathName_U以后找到unicode对应内存，然后修改！
00142AA0 5C 00 3F 00 3F 00 5C 00 63 00 3A 00 5C 00 63 00 \.?.?.\.c.:.\.c.
00142AB0 6F 00 6E 00 2E 00 74 00 78 00 74 00 5C 00 00 00 o.n...t.x.t.\...
按下F9，向上帝祈祷……，结果……
虽然出现了带con的文件名，但好像有问题……C:下出现的是con.tx……
不过问题一想就明白。strlen("con.tx")==strlen("con.tx")
看来原先的字符串还控制这文件名长度……第二次使用
HANDLE pfile=CreateFile("C:\coo.txt",FILE_GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,0,0);
然后进Olly用相同方法，呵呵，欢呼吧，成功了！！
好了，到此为止你知道怎么创建了。呵呵，道理永远是浅显的，上面的过程无非是修改了下内存，但到底是为什么会造成这个问题的呢？希望大家考虑下，我这里就卖个关子。
最后别忘了把那些垃圾删掉吧，你可以用del命令或者自己编程，然后拦截DeleteFileW，当然程序要是unicode版的，文件名先伪造一个合法的，然后用相同方法去修改就好了。
在这里我想说些有趣的事：
1.前面mkdir con\建立的文件夹可以访问，能防止文件，但无法删除
2.那些带有con\prn的文件打不开也删不掉，而且系统无法确定其时间。
不过上面仅供学习娱乐，创建带con可能意义不大，不过你可以先CreateFileW一个这样的文件，通过破解让他顺利创建后利用返回的合法HANDLE再使用WriteFile也许允许你用里面读写数据哦……这样里面得内容就100%安全了，除非format。
不过世上还有无聊的人会编病毒……所以我就不公开提供生成这种文件的代码了。需要的自己找我吧
最后附上能自动创建、删除这类文件的程序：
WinFileKiller
点击下载：[url]ftp://FTP_visitor:visitor@ftp.csksoft.net/Public/Products/Crack/WinFileKiller.rar[/url]
陈士凯版权所有，转载请标明作者与出处。
唉，写完了前面的废话头都昏了，有错误及时告诉我哦。
----------------------------
如果你在想con.txt不是很正常吗？那好，你先去创建下，只要带有独立的con字样的文件就好，然后悟出什么了再看这篇文章（如果你用linux或者mac或者unix那就算了）。
呵呵，正常来说带有con、prn、com1这样字眼的文件或目录是不能创建的(原因自己找)，但我想到了以前在安全焦点的一篇文章，是教你创建带"\"的文件夹的。当时的方法是用控制台命令（如果你叫dos命令那是不标准的）mkdir csk..\这样的语法创建的。看来这是windows一个文件系统的漏洞了，没错……
我后来就在想其中的原理，可能你会发现像上面的csk..\在创建后是csk.，而他实际被windows解释为访问mkdir csk.\的目录。看来有字符在创建时被略去了。而一次偶然机会我发现mkdir C:\con\是成功的，在c下面出现了c:\con文件夹，而且删不掉……呵呵，有一个bug……
我这时突然想到了可能的原因：首先创建目录时肯定要验证正确性，而像这种C:\dir\肯定是先将\符号略去了，但后面的内容呢？看来windows似乎不去检查了……否则mkdir c:\con\就应该失败了，而mkdir c:\con肯定是无效的。
所以我在想是否创建的文件也能利用这个漏洞夺过windows文件系统的一些检查呢？正如你看到的，我成功了^-^
呵呵，这可不是画出来的哦，是货真价实的con.txt。其实原理和我上面的猜测差不多，但由于时间有限，我的分析不一定正确，下面给出具体破解过程：
2005.8.1：23:00
首先我要知道mkdir造成漏洞的原因，于是拿出ollydbg去调试cmd.exe(mkdir是内部命令嘛，不知他找谁？）。接着对KERNEL32.CreateDirectoryW设断点，果然在输入了mkdir c:\con\后中断了。自然单步跟入CreateDirectoryW：
----------------------------------------------------------------
7C81E97F 50 push eax
7C81E980 57 push edi
7C81E981 FF15 3C11807C call dword ptr ds:[<&ntdll.RtlDosPathNameToNtPathName_U>>
; ntdll.RtlDosPathNameToNtPathName_U
7C81E987 84C0 test al,al
7C81E989 0F84 8ACA0100 je kernel32.7C83B419
7C81E98F 66:817D F4 F001 cmp word ptr ss:[ebp-C],1F0
7C81E995 0F87 8CCA0100 ja kernel32.7C83B427
7C81E99B 8B45 F8 mov eax,dword ptr ss:[ebp-8]
----------------------------------------------------------------
注意上面的API:RtlDosPathNameToNtPathName_U,在执行完了以后，ss:[ebp-8]指向的位置存放着:\??\c:\con\(unicode)。
然后程序执行到:
7C81E9FE FF15 0810807C call dword ptr ds:[<&ntdll.NtCreateFile>]
呵呵，Native的创建文件，到此为止C:\con已经在你硬盘上了，由此可推测那个\??\c:\con\(unicode)便是最终的生成路径了。
你必须用rd c:\con\才能删除那个目录！
然后再试mkdir c:\con：继续跟踪，虽然也到了ntdll.NtCreateFile，但很明显函数执行失败了……不过可以明确一点CreateDirectoryW似乎不检查文件合法性……
不过我不服气，想到那个\??\c:\con\(unicode)总该起点作用吧，于是又用了这段mkdir c:\coo。
然后再运行到ntdll.RtlDosPathNameToNtPathName_U以后找到了那段unicode的地址:dword ptr ss:[ebp-8],当时是0x001581E8，
于是打开了内存修改：
先找到那个地址：
001581E0 47 00 45 00 0F 07 1E 00 5C 00 3F 00 3F 00 5C 00 G.E. .\.?.?.\.
001581F0 63 00 3A 00 5C 00 63 00 6F 00 6F 00 00 00 AD BA c.:.\.c.o.o...
然后手动改为\??\c:\con\（注意是unicode，这里多加了个\，为了绕过验证）：
001581E0 47 00 45 00 0F 07 1E 00 5C 00 3F 00 3F 00 5C 00 G.E. .\.?.?.\.
001581F0 63 00 3A 00 5C 00 63 00 6F 00 6E 00 5C 00 00 00 c.:.\.c.o.n.\...
然后就按F9让他去吧，呵呵，成功了，虽然打了mkdir c:\coo，但在c:\出现了con文件夹！
到目前为止已经搞一段落了，我先来总结下：
1.原先的文件名漏洞并不是出现在mkdir和rmdir这两个命令中，而是ntdll.NtCreateFile，换句话说你编写程序调用CreateDirectoryW(L"C:\\con\\",NULL);也会有同样效果。
2.加了\后可以成功创建文件原因不明，但的确可以绕过一些检查。
3.虽然原先的路径字符串对是否创建文件成功（ntdll.NtCreateFile）有作用，但似乎最终文件名是由那段unicode定的。
好了，现在心里已经有点头绪了，那我们来试下CreateFileW吧，也就是要创建一个文件，比如con.txt。
想到控制台中>>这个重定向命令。比如help >>c:\aa.txt可以将help命令的内容输入到aa.txt里面，那肯定是要调用CreateFileW了，但先不管这个，先试验下这个:
help >>c:\con.txt\(呵呵，多加一个\,企图绕过验证)
结果:
C:\WINDOWS\system32>help >>c:\con.txt\
文件名、目录名或卷标语法不正确。
呵呵，看来CreateFileW与CreateDirectoryW不同了，然后又试了C:\WINDOWS\system32>help >>c:\con.txt，这回更搞笑，唉都忘了con含义了（自己试试看）。
看来命令行里靠不住了，于是自己编了个小程序:
HANDLE pfile=CreateFile("C:\con.txt",FILE_GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,0,0);
if (pfile!=INVALID_HANDLE_VALUE)
{
MessageBox(NULL,L"OK!",NULL,MB_OK);
}
当然运行这个肯定是失败的，不过还是先用ollydbg看下：
跟进CreateFileW后，首先执行API的是:ntdll.RtlInitUnicodeString，呵呵，看名字就知道含义了~
同时前面的ntdll.RtlDosPathNameToNtPathName_U又出现了:
7C8109E9 50 push eax
7C8109EA 56 push esi
7C8109EB FF15 3C11807C call dword ptr ds:[<&ntdll.RtlDosPathNameToNtPathName_U>>;
7C8109F1 84C0 test al,al
7C8109F3 0F84 408E0200 je kernel32.7C839839
呵呵，看来又会是老样子吗？先终止吧，把代码改称
HANDLE pfile=CreateFile("C:\co.txt",FILE_GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,0,0);
然后用老办法，到了ntdll.RtlDosPathNameToNtPathName_U以后找到unicode对应内存，然后修改！
00142AA0 5C 00 3F 00 3F 00 5C 00 63 00 3A 00 5C 00 63 00 \.?.?.\.c.:.\.c.
00142AB0 6F 00 6E 00 2E 00 74 00 78 00 74 00 5C 00 00 00 o.n...t.x.t.\...
按下F9，向上帝祈祷……，结果……
虽然出现了带con的文件名，但好像有问题……C:下出现的是con.tx……
不过问题一想就明白。strlen("con.tx")==strlen("con.tx")
看来原先的字符串还控制这文件名长度……第二次使用
HANDLE pfile=CreateFile("C:\coo.txt",FILE_GENERIC_WRITE,FILE_SHARE_WRITE,NULL,CREATE_ALWAYS,0,0);
然后进Olly用相同方法，呵呵，欢呼吧，成功了！！
好了，到此为止你知道怎么创建了。呵呵，道理永远是浅显的，上面的过程无非是修改了下内存，但到底是为什么会造成这个问题的呢？希望大家考虑下，我这里就卖个关子。
最后别忘了把那些垃圾删掉吧，你可以用del命令或者自己编程，然后拦截DeleteFileW，当然程序要是unicode版的，文件名先伪造一个合法的，然后用相同方法去修改就好了。
在这里我想说些有趣的事：
1.前面mkdir con\建立的文件夹可以访问，能防止文件，但无法删除
2.那些带有con\prn的文件打不开也删不掉，而且系统无法确定其时间。
不过上面仅供学习娱乐，创建带con可能意义不大，不过你可以先CreateFileW一个这样的文件，通过破解让他顺利创建后利用返回的合法HANDLE再使用WriteFile也许允许你用里面读写数据哦……这样里面得内容就100%安全了，除非format。
不过世上还有无聊的人会编病毒……所以我就不公开提供生成这种文件的代码了。需要的自己找我吧
最后附上能自动创建、删除这类文件的程序：
WinFileKiller
点击下载：[url]ftp://FTP_visitor:visitor@ftp.csksoft.net/Public/Products/Crack/WinFileKiller.rar[/url]
陈士凯版权所有，转载请标明作者与出处。