为了考验，庸庸碌碌的过了半年。现在终于出头了，现在又忙于毕业设计（软件界面美化和驱动文件加壳），没空学习内核知识 。今天特把以前的一些想法发出来，大家讨论讨论。
在网上找了一下，谈文件隐藏的不少，说如何检测隐藏文件的好像不多。这里说说我关于隐藏文件（和注册表）检测的一些思路，错误和不足希望大牛们指出。
我们知道现在一般隐藏文件的检测方法有几种，一种是文件系统层即直接发irp到文件系统进行询问，一种是直接对磁盘的数据进行分析。当然后者应该说是比前者更安全。但相信你看过mj0011大牛的《基于IO Packet隐藏文件和注册表，过磁盘解析和总线解析》(当然你用他公布的代码可能不一定成功，因为其中有些小bug)，其实这也不是安全的，怎么办？前有azy大牛的ak922，后有mj0011大牛的总线过滤。那我们只好夹缝中求生存了，呵呵。
入正题，我们知道就windows ntfs系统而言，第一方法自己构建的irp包其实走的线路是NtfsFsdDirectoryControl NtfsCommonDirectoryControl NtfsQueryDirectory在后面就是走NtfsRestartIndexEnumeration和NtfsContinueIndexEnumeration等等到ReadIndexBuffer到NtfsMapStream到CcMapData，通过CcMapData得到相应FileObject的Cache地址，然后进行解析。其中Cache的具体地址为在CcMapData最后一个参数里。
这是我用syser分析中的两分截图，分析过NTFS文件系统的话当你看到FILE0和INDX字样的时候一定很是熟悉，文件的解析就从这里开始了。其实在这做分析，比直接读磁盘数据分析要简单点，代码如下：
复制内容到剪贴板
代码:
VOID ListDir (LPBYTE pDir, UINT uAlcSize)
{
LPINDX pIndx;
LPINDXATTR pIndxAttr;
DWORD dwRes;
BYTE pRuns[0x200];
pIndx = ( LPINDX ) pDir;
pIndxAttr = (LPINDXATTR)( pDir + ( 0x18 + pIndx->wHeadSize ) );
if ( 'I' != pIndx->bDirID [0] ||'N' != pIndx->bDirID [1] ||'D' != pIndx->bDirID [2] ||'X' != pIndx->bDirID [3] )
{
return ;
}
while ( TRUE )
{
if ( ( (ULONG)( pIndxAttr ) - (ULONG)(pIndx) ) >= pIndx->dwUseSize )
{
if ( 0 == uAlcSize - ( pIndx->dwAllocSize + 0x18 ) )
break;
else
{
uAlcSize -= ( pIndx->dwAllocSize + 0x18 );
pIndx = ( LPINDX )( (LPSTR)pIndx + ( pIndx->dwAllocSize+ 0x18 ) );
if ( 'I' != pIndx->bDirID [0] ||
'N' != pIndx->bDirID [1] ||
'D' != pIndx->bDirID [2] ||
'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公布的注册表隐藏的方法。
文章就写到这里，最后谢谢你的观看。