-
-
[原创] 续上篇，Win 7 64 位下遍历对象目录方法探究。
-
发表于: 2018-4-2 10:55
-
1.原因，解决因设备被占用是IoGetDeviceObjectPointer 获取不到设备指针的问题。
对比发现，除了基本类型长度的变化，其他的结构上没有发生变化，也就说，由编译版本的变化就可以兼容基本类型长度的变化，所以，32位下的那一份源码可用。故此结帖。
2.本文为大白兔一手手打，如果有和大佬侵权的部分，请留言指正，即刻修改，有严重影响则即刻删除。您可以共享此文，请注明出处爱上看雪的只为共享的大白兔声明敬上。
3.思路来源和上文相似，一个套路，写这篇意为给此系列一个完整版方便您的资料需求。
4.读此文之前您需要一个Win7 64位版本的操作系统，下面开启我的探寻之旅：
kd> !object \
Object: fffff8a000004640（64位操作系统下对象地址是8字节的） Type: (fffffa8018d41b50 对象的类型对象地址) Directory（对象的类型名称）
ObjectHeader: fffff8a000004610 (new version，看来新版本的意思是XP和Win 7的区别呢 )
HandleCount: 0 PointerCount: 41
Directory Object: 00000000（上一级的目录对象） Name: \
不明白，再来一次。
看到这样，又是一波满满的感动呢，对象的地址，对象的类型，对象的名字，3大重要的信息都可以查询到，根据对象头的新版本，我先猜一下应该和Win 7 32位版本没有多大的区别呢？我们验证看看咯。
对比于Win7 32位来说，结构真的是一样的呢，只不过因为存储的长度问题，Win7 64位加长了他们的类型而已，尽管这个区别导致我们不得不需要另写一个结构来做区分，当然，也可以选择做兼容使用类如ULONG_PTR 这类型来做兼容，不过我不是很喜欢这种方式，出了问题不是很好查。所以在本文的代码demo中，我都加以Win7_64后缀来表示此类结构用于Win7 64位系统。
哈哈哈哈。
哈哈哈。
哈哈。
哈
楼主已疯。为什么呢？
大家先看我的结果把。这是直接从Win7 32 位 的那份枚举源码中编译成64位驱动的，至于64位驱动加载的部分我这里不细讲，相信能看此实现的同仁应该都知道64位驱动加载方法的。
惊了，正常来说不应该32位到64位版本会有一些版本迁移带来的变化吗？
确实是会有的，但您需要对比32位的版本，下面是64位下各个结果版本图。
对比发现，除了基本类型长度的变化，其他的结构上没有发生变化，也就说，由编译版本的变化就可以兼容基本类型长度的变化，所以，32位下的那一份源码可用。故此结帖。哈哈哈哈！！
拜拜。
[培训]《安卓高级研修班(网课)》月薪三万计划，掌握调试、分析还原ollvm、vmp的方法，定制art虚拟机自动化脱壳的方法
最后于 2018-4-4 10:19
被wo爱吃大白兔编辑
，原因：
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
是的，确实是通用的，所以前面32位版本可以编译直接运行成功，但出于演示的目的，我特意指出了32位和64位ULONG 长度的不统一部分，这样可能来的更直观，代码上确实会冗杂，如果没有使用合适的内存对齐策略，我想还是不能通用的，所以为了直观，共享，我特意对3大系统板块都做了分析，然后定义出来。 |
|
|
32、64不同的长度可以用ULONG_PTR或者PVOID，在32下是4字节、64下是8字节，定义一个结构就可以通吃所有系统的。而且实际上微软也是用ULONG_PTR/PVOID的。 ps:：再提一下，遍历Directory的时候没加锁，虽然无伤大雅一般情况下不会出什么问题。
最后于 2018-4-4 10:20
被hzqst编辑
，原因：
|
|
|
感谢您的批评，很乐意接受您的指正，您的观点我很认同。 |
|
|
感谢楼主分享自己的学习经历和成果！
|
|
|
嗯嗯，您说的ULONG_PTR方式用于编写自定义结构很有效果，但是针对本次的演示，我想请同仁注意，此次64位下逆向出来的结构中含有整型大多都是4字节的，只有头对象那一结构中有两个是8字节的，这些细节就产生一个做法：要做32位和64位结构兼容时，除了对象头结构那两个PointerCount 和HandleCount应该使用ULONG_PTR方式兼容，其他的整型数据都应该使用ULONG来做或者ULONG32。哈哈，您提倡加锁的观点非常好，这个部分应该要加上，补足代码的缺点呢。
最后于 2018-4-4 10:42
被wo爱吃大白兔编辑
，原因：
|
|
|
哈哈，谢谢版主。 |
|
|
|
|
|
|
hzqst
KevinsBobo
