'X' != pIndx->bDirID [3] )
{
return;
}
pIndxAttr = (LPINDXATTR)( (LPSTR)( pIndx ) + ( 0x18 + pIndx->wHeadSize ) );
}
}
if ( 12 > pIndxAttr->dwMFTIndx )
{
pIndxAttr = (LPINDXATTR)( (LPSTR)( pIndxAttr ) + pIndxAttr->wcbSize );
}
else
{
if ( FALSE == (0x01 & pIndxAttr->bFileNSpace ) )
{
pIndxAttr = (LPINDXATTR)( (LPSTR)( pIndxAttr ) + pIndxAttr->wcbSize );
continue;
}
KdPrint(("File Name is:%ls\n",pIndxAttr->wzFileName));
pIndxAttr = (LPINDXATTR)( (LPSTR)( pIndxAttr ) + pIndxAttr->wcbSize );
}
}
return;
}
当然这段代码只是求个验证， 并不完善。 因为其实直接读取内存数据， 我测试了能检测出AK922了， 另外mj0011的总线过滤没有做Cache的工作， 当然也能检测到。
下面说说怎么获得Cache地址， 两种方法。 一是你自己得到FileObject然后用CcMapData去获得， 做过文件过滤驱动的话这应该比较简单。 另一种就是做Hook， 从中获得。 既然是做检测文件隐藏， 那么你可以先正常的枚举， 然后根据获得的Cache地址读取数据分析和开始的进行对比。
该方法的优点：
这种方法是直接读取Cache中的数据， 不走IofCompleteRequest， 得到的数据比直接Irp来的安全。 你可能要说我不能对Cache中的数据进行修改来进行隐藏吗？其实这在AZY的另一篇文章《挂接缓存管理器CcMapData（）实现文件XXX》中提过。 我是有可以成功， 但系统也就无法定位到该文件进行正常的工作， 还不如直接删除来隐藏来的好。 当然强大的LZ同学们肯定有你的好方法。
该方法的缺点：
同样这也要做文件系统的解析， 很麻烦。 我用的是和我在《NTFS文件解析系统的简单分析》中提到的解析索引列表来读文件名一样的方法。 其实这样并不好， 应该索引列表中的文件名有时是短名， 有时甚至有些字符还不错误的。 这也是mj0011《基于IO Packet隐藏文件和注册表， 过磁盘解析和总线解析》代码中过滤不严导致隐藏失败的一个小bug。 所以用他来枚举文件不大准确。 真正准确的应该是在MFT30属性中获得的文件名。
当然其实注册表的获取同样也是走CcMapData， 所以他能够检测基于ZZZEVAZZZ公布的注册表隐藏的方法。
文章就写到这里， 最后谢谢你的观看。
……