呵，两份资料说的不一样，被搞晕了～哪位高人来确定一下子。

  http://www.xfocus.net/articles/200602/848.html
Windows平台内核级文件访问中是这样说的：

“我们可以用IoGetRelatedDeviceObject这个函数来获得一个FileObject对应的最底层的那个功能驱动对象(FDO)。但是这样虽然绕过了那些过滤驱动，却同时也绕过了正常的FSD如Ntfs/Fastfat，因为正常的FSD也是作为一个过滤驱动存在的。磁盘文件对象的对应的最底层的FDO是Ftdisk.sys，它已经因为过于底层而不能处理我们投递的IRP请求。”

上面说要取得正确的底层文件驱动应该用：IoGetBaseFileSystemDeviceObject

而在“WindowsNT系统文件内幕”驱网的中文翻译版，中说，“IO管理器使用IoGetRelatedDeviceObject得到可能已经附加到了目标设备对象的最高层的设备对像指针。”


我实际在虚拟机上测试，用IoGetBaseFileSystemDeviceObject 与 IoGetRelatedDeviceObject返回的都是 “\FileSystem\Ntfs”。
我想请教，返回这个正确么？到底用IoGetRelatedDeviceObject取得的是最底层的还是最高层的？正确的取得最高层的和最底层的应该用哪两个啊？

还有，我按书上说的用IoGetDeviceObjectPointer打开“\Device\C:”来得到文件对像与设备对像是得到的总是不能用，用WinDbg查看取得的地址，里面全是“？？？？？”，是不是我哪时做的不对了？

请各位高人指点迷津，谢谢～

 

IoGetRelatedDeviceObject应该获得顶层对象,因为你自己没有过滤对象,所以获得的就是本身.
IoGetBaseFileSystemDeviceObject是获得底层文件对象的.

IoGetBaseFileSystemDeviceObject : 得到与文件对象相关的卷设备对象(是由文件系统在打开卷时创建的).
IoGetRelatedDeviceObject              : 得到与文件对象相关的存储设备栈上(与上面的卷设备对象同在一栈上)最高层的设备对像指针.
见下代码:
//////////////////////////////////////////////////////////////////////////
//
//Routine Description:
//
//    This routine returns a pointer to the actual device object than an I/O Request Packet (IRP) should be given to based on
//    the specified file object.
//
//    N.B. - Callers of this function must ensure no device object is attaching or detaching from this stack for the duration
//    of this call. This is because the database lock is *not* held!
//
//Arguments:
//
//    FileObject - Pointer to the file object representing the open file.
//
//Return Value:
//
//    The return value is a pointer to the device object for the driver to whom the request is to be given.
//////////////////////////////////////////////////////////////////////////
PDEVICE_OBJECT IoGetRelatedDeviceObject(IN PFILE_OBJECT FileObject)
{
    PDEVICE_OBJECT deviceObject;
    // If the file object was taken out against the mounted file system, it will have a Vpb.
    // Traverse it to get to the DeviceObject. Note that in this case we should never follow FileObject->DeviceObject,
    // as that mapping may be invalid after a forced dismount.
    if(FileObject->Vpb != NULL && FileObject->Vpb->DeviceObject != NULL)
    {
        ASSERT(!(FileObject->Flags & FO_DIRECT_DEVICE_OPEN));
        deviceObject = FileObject->Vpb->DeviceObject;
        // If a driver opened a disk device using direct device open and later on it uses IoGetRelatedTargetDeviceObject to find
        // the device object it wants to send an IRP then it should not get the filesystem device object.
        // This is so that if the device object is in the process of being mounted then vpb is not stable.
    }
    else if(
    !(FileObject->Flags & FO_DIRECT_DEVICE_OPEN)
    &&
    FileObject->DeviceObject->Vpb != NULL
    &&
    FileObject->DeviceObject->Vpb->DeviceObject != NULL
    )
    {
        deviceObject = FileObject->DeviceObject->Vpb->DeviceObject;
        // This is a direct open against the device stack (and there is no mounted file system to strain the IRPs through).
    }
    else
    {
        deviceObject = FileObject->DeviceObject;
    }
    ASSERT(deviceObject != NULL);
    // Check to see whether or not the device has any associated devices. If so, return the highest level device;
    // otherwise, return a pointer to the device object itself.
    if(deviceObject->AttachedDevice != NULL)
    {
        deviceObject = IoGetAttachedDevice(deviceObject);
    }
    return deviceObject;
}

//////////////////////////////////////////////////////////////////////////
//
//Routine Description:
//
//    This routine returns the base (lowest-level) file system volume device object associated with a file.
//        I.e., it locates the file system w/o walking the attached device object list.
//
//Arguments:
//
//    FileObject - Supplies a pointer to the file object for which the base file system device object is to be returned.
//
//Return Value:
//
//    The function value is the lowest level volume device object associated w/the file.
//////////////////////////////////////////////////////////////////////////
PDEVICE_OBJECT IoGetBaseFileSystemDeviceObject(IN PFILE_OBJECT FileObject)
{
    PDEVICE_OBJECT deviceObject;
    // If the file object has a mounted Vpb, use its DeviceObject.
    if(FileObject->Vpb != NULL && FileObject->Vpb->DeviceObject != NULL)
    {
        deviceObject = FileObject->Vpb->DeviceObject;
        // Otherwise, if the real device has a VPB that indicates that it is mounted,
        // then use the file system device object associated with the VPB.
    }
    else if
        (
        !(FileObject->Flags & FO_DIRECT_DEVICE_OPEN)
    &&
        FileObject->DeviceObject->Vpb != NULL
    &&
        FileObject->DeviceObject->Vpb->DeviceObject != NULL
        )
    {
        deviceObject = FileObject->DeviceObject->Vpb->DeviceObject;
        // Otherwise, just return the real device object.
    }
    else
    {
        deviceObject = FileObject->DeviceObject;
    }
    ASSERT(deviceObject != NULL);
    // Simply return the resultant file object.
    return deviceObject;
}

明白了，谢谢两位～

引用第0楼MuseHero于2007-02-12 19:50发表的“呵，两份资料说的不一样，被搞晕了～哪位高人来确定一下子。”:
  http://www.xfocus.net/articles/200602/848.html
...
却同时也绕过了正常的FSD如Ntfs/Fastfat，因为正常的FSD也是作为一个过滤驱动存在的.......

从来没有听说过FSD是过滤驱动的说法。而且后面说的ftdisk.sys和FSD根本就不在一个device stack中。任何PDO, FDO, Filter DO，都是要对在同一个device stack来说才存在，对于2个不同的device stack中的DO根本没有谁比谁低的问题。如果按照他这种说法，去研究一下Daemon Tools这种虚拟光驱的driver，岂不是要得出“自己比自己低”这样莫名其妙的句子出来？

引用第4楼rayyang2000于2007-02-13 13:28发表的“”:



从来没有听说过FSD是过滤驱动的说法。而且后面说的ftdisk.sys和FSD根本就不在一个device stack中。任何PDO, FDO, Filter DO，都是要对在同一个device stack来说才存在，对于2个不同的device stack中的DO根本没有谁比谁低的问题。如果按照他这种说法，去研究一下Daemon Tools这种虚拟光驱的driver，岂不是要得出“自己比自己低”这样莫名其妙的句子出来？

老大,DT 最近版本的是不是使用了SPTD 这样的第3方的SCSIPORT了？

sptd那个驱动太恶心，把所有的disk drivers的dispatch routine全部hook到一个xxx的内存处，然后再从那里跳到自己的驱动

引用第4楼rayyang2000于2007-02-13 13:28发表的“”:



从来没有听说过FSD是过滤驱动的说法。而且后面说的ftdisk.sys和FSD根本就不在一个device stack中。任何PDO, FDO, Filter DO，都是要对在同一个device stack来说才存在，对于2个不同的device stack中的DO根本没有谁比谁低的问题。如果按照他这种说法，去研究一下Daemon Tools这种虚拟光驱的driver，岂不是要得出“自己比自己低”这样莫名其妙的句子出来？

终于有人发现那篇文章的这个Bug了，恭喜恭喜~有时间我请客喝酒~

引用第6楼WQXNETQIQI于2007-02-13 18:39发表的“”:
sptd那个驱动太恶心，把所有的disk drivers的dispatch routine全部hook到一个xxx的内存处，然后再从那里跳到自己的驱动

没啥的，为了防止MJ的WS行为就这么干了~

跟我有什么关系。。。。

引用第9楼WQXNETQIQI于2007-02-13 19:47发表的“”:
跟我有什么关系。。。。

我猜测得阿~~DT的虚拟光驱还是不能骗过startForce

引用第5楼liuyan1于2007-02-13 16:01发表的“”:


老大,DT 最近版本的是不是使用了SPTD 这样的第3方的SCSIPORT了？

DT是我这几年研究最多的一个软件，可惜没有什么心思在crack上，有几个版本的解密总是搞不定，也懒得去解了。不过还是很佩服它的作者，确实功力很深，有很多思路非常有启发，我从他那里真的是学到了不少东西。

4.x开始的几个版本用的那个sptd我怀疑其实还是他们自己做的，只不过是另外开了个公司以避过法律责任，就像以前的CloneDVD一样，在欧盟的法律出来以后跑到一个小岛上注册个公司照样卖。

至于架构，当时看过4.03的，但确实忘记了，不好妄加评论

引用第7楼killvxk于2007-02-13 20:49发表的“”:


终于有人发现那篇文章的这个Bug了，恭喜恭喜~有时间我请客喝酒~

其实我还是很理解作者的，这里指出这些问题也不是专门针对作者提出。

Windows Kernel里面的很多概念、架构确实很难理解，而且还要从英文去理解意思，真的很头疼。N年前我刚开始学的时候，也是对这些Device Stack搞不懂，常常都搞不清楚在说什么。记得当时最麻烦的是理解Physical Device Object，完全就觉得是莫名其妙，感觉那个PDO就好像凭空出来的。而且当时手头的资料和代码又是PCI/ISA居多，那时候又没有便宜的开发板之类的东东卖，作为个人也不可能花个几千美金去买，所以当时只能死读资料，都不知道看了多少代码，多少遍资料，才慢慢有些理解。

说起来也蛮悲哀的，当时连驱网都没有，网络也才流行，OSR更是听都没有听说（也许在DDK或者MS的那个地方有留地址，可是当时看到大段的英文立马就头疼 ），身边更是没有人对这个感兴趣了，只能一个人瞎琢磨。说起来还真的不好意思，我真正入门大概花了差不多1年多的时间，而真正能写一个BSOD不太多的driver，大概已经是2年后的事情了 呵呵   我想这里像我这么后知后觉的人大概已经绝种了吧？嘎嘎。。。

引用第6楼WQXNETQIQI于2007-02-13 18:39发表的“”:
sptd那个驱动太恶心，把所有的disk drivers的dispatch routine全部hook到一个xxx的内存处，然后再从那里跳到自己的驱动

不这样做如何能对付StarForce呢,以其说DT恶心,还不如说,StarForce 更BT,大家都在抢谁能先掌握HardDrive 把，呵呵，都玩的比较无耻．

引用第11楼rayyang2000于2007-02-14 07:10发表的“”:


DT是我这几年研究最多的一个软件，可惜没有什么心思在crack上，有几个版本的解密总是搞不定，也懒得去解了。不过还是很佩服它的作者，确实功力很深，有很多思路非常有启发，我从他那里真的是学到了不少东西。

4.x开始的几个版本用的那个sptd我怀疑其实还是他们自己做的，只不过是另外开了个公司以避过法律责任，就像以前的CloneDVD一样，在欧盟的法律出来以后跑到一个小岛上注册个公司照样卖。
.......

老大,偶都不敢看DT了,最新也只看过ALCOHOL 120% 的1.43版.DT写的确实非常有水准,呵呵现在都不知道它是如何实现的了,听说有一段它们在搞虚拟IDE?