-
-
[原创]吾爱破解2016安全挑战赛第二题Windows驱动
-
发表于: 2016-4-7 15:51
-
这道题目当时没有太多时间做，只做到了题目的前2个要求就提交了，想着看能不能混个52pojie论坛帐号。前几天去腾讯面试，刚好和面试官讨论到这个题目，面试官给了些新思路，这几天有点时间就做了下。水平有限，文中若有错误，欢迎大家指出。
1.题目详情
编写一个适用于Windows XP及更高版本系统的驱动，要求对于所有A目录下形如A\B\C.exe的程序在运行时，每1秒钟正确输出一次其包括程序名在内的进程完整路径。
其中A代表一或多级的根目录，B代表一级子目录，C.exe为程序完整文件名。
测试步骤及结果：
1、首先手动启动A\B\C.exe，正确输出进程的完整路径。
2、保持进程运行，然后手动将程序名C.exe修改为任意D.exe后，可正确输出改名后的进程完整路径A\B\D.exe。
3.、手动结束进程，并尽快手动将程序所在的目录名B修改为任意E后再启动该进程，可正确输出改名后的进程完整路径A\E\D.exe。
要求以上步骤中驱动均使用同一种方法获取进程路径信息，且除监控A目录下的进程启动外，驱动不可动态监控以上步骤中的任何手动操作或系统行为。
2.关于进程路径
应用层可以调用GetProcessImageFileName这个API来获取路径。这个API的内部实际调用的是功能号为0x1b的NtQueryInformationProcess，NtQueryInformationProcess会查看进程的
EPROCESS->SE_AUDIT_PROCESS_CREATION_INFO->OBJECT_NAME_INFORMATION
，如果有值，那么直接拷贝过去，如果没有值，那么会调用ObQueryNameString查询EPROCESS->SECTION_OBJECT->SEGMENT_OBJECT->CONTROL_AREA->FILE_OBJECT，查询到后会存放在这里供后续的请求。
很明显，要达到题目要求的第2点，我们不能直接调用ZwQueryInformationProcess，因为EPROCESS里存放的路径并不会随着文件重命名而更新。那么我们能不能每次自己调用ObQueryNameString来查询EPROCESS里存放的FILE_OBJECT呢？这样就可以绕过EPROCESS缓存进程路径了，毕竟文件改名，文件系统是一定知道的。题目不会那么简单，重点在于题目的第3个要求。
3.哪里出现问题了
先上一张图：
可以看到PCHunter也有这个问题，也就是说EXE运行一遍后，关闭EXE，把EXE所在目录改个名字再启动EXE，PCHunter获取到的路径会是重命名之前的路径(已经刷新进程列表)。如果你ObQueryNameString查询进程的EPROCESS里存放的FILE_OBJECT就会出现跟PCHunter一样的情况，文件名会跟着变化，但是文件路径却还是原来的。那么难道是ObQueryNameString出现了问题？
实际上，一个EXE关闭后再启动，虽然进程的EPROCESS的地址变了，但是EPROCESS里存放的FILE_OBJECT却还是原来的。系统并不会因为EXE关闭就马上释放掉EPROCESS里存放的FILE_OBJECT，系统会缓存这个FileObject，下次进程启动，它还会把这个FileObject放在这个进程的EPROCESS里。翻了翻WRK的代码，ObQueryNameString内部实际是从FileObject对象头里存放的查询函数指针来查询的，而这个查询函数最终还是会发送IRP给文件系统驱动去查询。那么是文件系统的原因吗，给定FileObject查询出来的文件名路径会是错的？
4.文件名在哪里
FILE_OBJECT有2个重要的域，FsContext和FsContext2，FsContext实际是FCB/SCB(文件控制块/流控制块，分别对应于FAT文件系统和NTFS文件系统)，同一个文件/文件流，可以有多个FileObject，但是这些FileObject指向的的FCB/SCB都是同一个。FCB/SCB里存放的是特定于这个文件/文件流的一些信息。另一个域FsContext2实际是CCB(ContextControlBlock)，这个是特定于FileObject的，也即是每个FileObject都有属于自己的CCB。为了弄清楚到底是哪里出了问题，特意下载了一份泄漏的ntfs文件系统代码。翻了下，发现文件流的文件名是存放在CCB里的。如下图：
调试发现，启动EXE再关闭，然后改掉EXE所在的目录名再启动EXE后，2个EPROCESS里存放的FileObject是同一个。而这个FileObject的CCB里存放的文件全路径并不会更新路径而只会更新文件的名字。那么问题就清楚了。对于FAT32文件系统，它的文件名是存放在FCB(FileObject->FsContext)里的，同一文件的不同FileObject是共享FCB的，这里面存放的文件名是即时更新的。也就是说对于FAT32文件系统，只要查询EPROCESS里存放的FileObject就可以达到题目的3个要求。那么对于NTFS文件系统，该怎么解决这个问题呢。因为系统会缓存EXE的FileObject，而且这个FileObject的CCB里存放的全路径不更新路径名怎么办呢，能不能自己再创建一个FileObject呢？可是要FileObject得知道进程文件路径，然后ZwOpenFile才可以。这貌似成了一个鸡生蛋的问题了。去北京腾讯面试，面试官恰好给了我一点新思路，那就是文件ID。
5.文件ID
文件ID这个在MSDN里面并没有太多资料，只是在介绍ZwCreateFile的CreateOptions参数的时候提及了一个FILE_OPEN_BY_FILE_ID标记，而且说了FAT文件系统并不支持这个标记。文件ID是一个8个字节的整数，可以唯一的索引到这个文件。文件ID不会随着文件改名而变化，它会一直不变直到文件被删除。那么问题的解决思路就来了，首先通过EPROCESS里存放的FileObject来查询这个文件的文件ID，再根据文件ID来打开这个文件拿到一个新的FileObject，这个FileObject的CCB里的文件名肯定是最新的，调用ObQueryNameString就可以查询到了。
6.文件ID的获取
status = IoQueryFileInformation(FilePointer, FileInternalInformation, FileIdLen, &FileIdInfo, &FileIdLen);
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
|
|
|
哈哈，对啊，提交了代码又给邮箱发个隐藏要求，我知道文件ID这个玩意，但是当时还没搞明白整个流程是哪里出问题了，还以为是ObQueryNameString出问题了。
|
|
|
 你没有用文件ID之前有别的办法满足第三个要求么……就是满足第三个要求但是不满足隐藏要求的……
|
|
|
|
|
|
|
|
|
|
|
|
这题比较有意思 如果没有限制必须使用同一种方法 第三个路径直接从PEB里拿
|
|
|
那题PEB里我测试成功了，但是为了要监视那个目录，又不能用minifilter等一些监控技术，我开的是系统线程，这样就会崩溃了，然后我还是没做第三题，也是上交了2个要求，感谢楼主分享，学习了
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
前排膜拜MJ，还有没有别的思路呢~
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
好好搜索论坛 http://bbs.pediy.com/showthread.php?t=90393 |
