基于Cache的隐藏文件(和注册表)检测的一些思路pc软件 文章资讯 手机软件

您当前的位置→图文中心安全防范基于Cache的隐藏文件(和注册表)检测的一些思路

基于Cache的隐藏文件(和注册表)检测的一些思路


2009/3/28  编辑:佚名 来源:本站整理  关键词:

基于Cache的隐藏文件(和注册表)检测的一些思路

 

为了考研, 庸庸碌碌的过了半年。 现就在终于出头了, 现就在又忙于毕业设计design(软件界面美化和驱动文件程序加壳), 没空学习内核知识 。 就在今天特把以前的一些想法发出来, 大家讨论讨论。
就在网上找了一下, 谈文件程序隐藏的不少, 说怎么才能检测隐藏文件程序的好像不多。 这里说说我有关联于隐藏文件程序(和注册表)检测的一些思路, 错误和不足真的希望大牛们指出。
我们我自己知道现就在一般隐藏文件程序的检测方法有几种, 一种是文件程序系统system层即直接发irp到文件程序系统system来进行询问, 一种是直接对磁盘的数据信息来进行分析。 当之后者应该说是比前者更安全。 但相信您看过mj0011大牛的《基于IO Packet隐藏文件程序和注册表, 过磁盘解析和总线解析》(当然您用他公布的代码有可能不一定成功, 因为其中有些小bug), 其实这也不是安全的, 怎么办?前有azy大牛的ak922, 后有mj0011大牛的总线过滤。 那我们我自己只好夹缝中求生存了, 呵呵。
入正题, 我们我自己知道就windows ntfs系统system而言, 第一方法我自己构建的irp包其实走的线路是NtfsFsdDirectoryControl NtfsCommonDirectoryControl NtfsQueryDirectory就在后面就是走NtfsRestartIndexEnumeration和NtfsContinueIndexEnumeration等等到ReadIndexBuffer到NtfsMapStream到CcMapData, 可以通过CcMapData得到相应FileObject的Cache地址, 之后来进行解析。 其中Cache的具体地址为就在CcMapData最后一个参数里。


这是我用syser分析中的两分截图, 分析过NTFS文件程序系统system的话当您看到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》中提过。 我是有可以能够成功, 但系统system也就再也不能够定位到该文件程序来进行正常的工作, 还不如直接删除来隐藏来的好。 当然强大的LZ同学们肯定有您的好方法。

该方法的缺点:
同样这也要做文件程序系统system的解析, 很麻烦。 我用的是和我就在《NTFS文件程序解析系统system的不复杂分析》中提到的解析索引列表来读文件程序名一样的方法。 其实这样并不好, 应该索引列表中的文件程序名有时是短名, 有时甚至有些字符还很好误的。 这也是mj0011《基于IO Packet隐藏文件程序和注册表, 过磁盘解析和总线解析》代码中过滤不严导致隐藏失败的一个小bug。 所以用他来枚举文件程序不大准确。 真正准确的应该是就在MFT30属性中获得的文件程序名。
当然其实注册表的获取同样也是走CcMapData, 所以他能够检测基于ZZZEVAZZZ公布的注册表隐藏的方法。
文章就写到这里, 最后谢谢您的观看。

相关文章
  • 基于ARP欺骗的惩罚措施
  • 基于ARP欺骗的TCP伪连接DOS
  • 基于ARP欺骗的TCP伪连接DOS
  • 基于Cache的隐藏文件(和注册表)检测的一些思路
  • 基于Cache的隐藏文件(和注册表)检测的一些思路
  • 的R -基于网络攻击, ARP协议欺骗程序源代码BtNet.exe
  • 基于Linux/BSD 防止局域网内ARP欺骗
  • 基于ARP欺骗的网络攻击程序源码
  • 基于ARP欺骗的TCP伪连接D.o.S
  • 发表评论
    阅读排行
    相关热门
    网站帮助 - 广告合作 - 下载声明 - 网站地图