ObReferenceObjectByHandle的ObjectType参数是OPTIONAL的，可以为NULL。

可以直接使用MmSectionObjectType,这个是导出的，声明一下即可

感谢mj大牛的提示，昨天回去又翻了一下wrk中ntoskrnl的导出声明，的确有好多ObjectType的声明。
于是乎，我试了一下，FileMapping句柄传入驱动后经ObReferenceObjectByHandle获取成功可以得到PSECTION的值，但是查看((PSECTION)Section)->Segment->ControlArea->FilePointer的许多成员均为无效,用ObQueryNameString获取文件名就崩溃了，访问地址无效。
难道要预先调用一些函数此结构成员才会有效还是其他什么原因呢？

经过google一番后，发现mj回复的一个帖子http://www.whitecell.org/forums/viewthread.php?tid=711&highlight=ZwQueryInformationProcess上说_EPROCESS结构在没有调用过ZwQueryInformationProcess(ProcessImageFileInformation)前， 是空的只有调用过一次该函数，系统才会获得镜象文件并放到这个成员中。是不是这里也有类似问题呢？

感谢mj大牛的提示，昨天回去又翻了一下wrk中ntoskrnl的导出声明，的确有好多ObjectType的声明。
于是乎，我试了一下，FileMapping句柄传入驱动后经ObReferenceObjectByHandle获取成功可以得到PSECTION的值，但是查看((PSECTION)Section)->Segment->ControlArea->FilePointer的许多成员均为无效,用ObQueryNameString获取文件名就崩溃了，访问地址无效。

另外还试了一种方法，在win32下用ZwQueryObject先获取到FileMapping的对象名，然后传入驱动用ObOpenObjectByName打开后，情况和之前一样。

难道要预先调用一些函数此结构成员才会有效还是其他什么原因呢？

经过google一番后，发现mj回复的一个帖子http://www.whitecell.org/forums/viewthread.php?tid=711&highlight=ZwQueryInformationProcess上说_EPROCESS结构在没有调用过ZwQueryInformationProcess(ProcessImageFileInformation)前， 是空的只有调用过一次该函数，系统才会获得镜象文件并放到这个成员中。是不是这里也有类似问题呢？

论坛提示提交失败，发了两次。

刚刚又试了一下，居然可以正常获取了。

看来你误解了某些文章对这个过程的描述。
看到

SectionObject->Segment->ControlArea->FilePointer

你可能觉得ControlArea就是指Segment的ControlArea成员：

nt!_SEGMENT_OBJECT
   +0x000 BaseAddress      : Ptr32 Void
   +0x004 TotalNumberOfPtes : Uint4B
   +0x008 SizeOfSegment    : _LARGE_INTEGER
   +0x010 NonExtendedPtes  : Uint4B
   +0x014 ImageCommitment  : Uint4B
   +0x018 ControlArea      : Ptr32 _CONTROL_AREA
   +0x01c Subsection       : Ptr32 _SUBSECTION
   +0x020 LargeControlArea : Ptr32 _LARGE_CONTROL_AREA
   +0x024 MmSectionFlags   : Ptr32 _MMSECTION_FLAGS
   +0x028 MmSubSectionFlags : Ptr32 _MMSUBSECTION_FLAGS

其实不对，这里的ControlArea，其实指的是_SEGMENT_OBJECT的BaseAddress成员，这个成员指向一个_CONTROL_AREA结构，这个结构的FilePointer成员才是FILE_OBJECT的指针。

我也随便贴点东西~~

kd> dt _SECTION_OBJECT e1471548
nt!_SECTION_OBJECT
   +0x000 StartingVa       : (null)
   +0x004 EndingVa         : 0x0100003e
   +0x008 Parent           : 0xf8a8f5bc
   +0x00c LeftChild        : 0x00001000
   +0x010 RightChild       : 0xffffffff
   +0x014 Segment          : 0xe1013f18 _SEGMENT_OBJECT
kd> dt _SEGMENT_OBJECT 0xe1013f18
nt!_SEGMENT_OBJECT
   +0x000 BaseAddress      : 0x8225bba8
   +0x004 TotalNumberOfPtes : 0xf
   +0x008 SizeOfSegment    : _LARGE_INTEGER 0xf
   +0x010 NonExtendedPtes  : 0xf000
   +0x014 ImageCommitment  : 0
   +0x018 ControlArea      : 0x00000420 _CONTROL_AREA
   +0x01c Subsection       : 0x8225bc58 _SUBSECTION
   +0x020 LargeControlArea : (null)
   +0x024 MmSectionFlags   : (null)
   +0x028 MmSubSectionFlags : (null)
kd> dt _CONTROL_AREA 0x8225bba8
nt!_CONTROL_AREA
   +0x000 Segment          : 0xe1013f18 _SEGMENT
   +0x004 DereferenceList  : _LIST_ENTRY [ 0x0 - 0x0 ]
   +0x00c NumberOfSectionReferences : 1
   +0x010 NumberOfPfnReferences : 1
   +0x014 NumberOfMappedViews : 0
   +0x018 NumberOfSubsections : 5
   +0x01a FlushInProgressCount : 0
   +0x01c NumberOfUserReferences : 1
   +0x020 u                : __unnamed
   +0x024 FilePointer      : 0x8237d3a0 _FILE_OBJECT
   +0x028 WaitingForDeletion : (null)
   +0x02c ModifiedWriteCount : 0
   +0x02e NumberOfSystemCacheViews : 0
kd> !fileobj 0x8237d3a0

\WINDOWS\system32\smss.exe

Device Object: 0x82356c08   \Driver\Ftdisk
Vpb: 0x823ab930
Access: Read SharedRead SharedDelete

Flags:  0x44040
        Cache Supported
        Cleanup Complete
        Handle Created

FsContext: 0xe1478d90        FsContext2: 0xe1478ee8
CurrentByteOffset: 0
Cache Data:
  Section Object Pointers: 8224a014
  Shared Cache Map: 00000000

问题总算是搞清楚了，是SECTION的第一个成员的类型写错了，导致后边的偏移出错。之前也是读取的!_SEGMENT_OBJECT的第一个成员的，现在可以正常读取了。

顺便我也看了下输出，发现跟大家的有点不同，BasedAddress 和 ControlArea的成员刚好相反，难道我的系统特别？我发现WRK中的_SEGMENT定义也是如此.

kd> dt _section_object 0xe1c1a908
nt!_SECTION_OBJECT
   +0x000 StartingVa       : (null)
   +0x004 EndingVa         : 0x0007dbc0
   +0x008 Parent           : (null)
   +0x00c LeftChild        : 0x000e7258
   +0x010 RightChild       : 0x0007dbb0
   +0x014 Segment          : 0xe1b3b298 _SEGMENT_OBJECT

kd> dt _segment 0xe1b3b298
nt!_SEGMENT
   +0x000 ControlArea      : 0x8211f610 _CONTROL_AREA
   +0x004 TotalNumberOfPtes : 6
   +0x008 NonExtendedPtes  : 6
   +0x00c WritableUserReferences : 1
   +0x010 SizeOfSegment    : 0x5e00
   +0x018 SegmentPteTemplate : _MMPTE
   +0x020 NumberOfCommittedPages : 0
   +0x024 ExtendInfo       : (null)
   +0x028 SystemImageBase  : (null)
   +0x02c BasedAddress     : (null)    +0x030 u1               : __unnamed
   +0x034 u2               : __unnamed
   +0x038 PrototypePte     : 0x00010208 _MMPTE
   +0x040 ThePtes          : [1] _MMPTE

kd> dt _control_area 0x8211f610
nt!_CONTROL_AREA
   +0x000 Segment          : 0xe1b3b298 _SEGMENT
   +0x004 DereferenceList  : _LIST_ENTRY [ 0x0 - 0x0 ]
   +0x00c NumberOfSectionReferences : 1
   +0x010 NumberOfPfnReferences : 0
   +0x014 NumberOfMappedViews : 0
   +0x018 NumberOfSubsections : 1
   +0x01a FlushInProgressCount : 0
   +0x01c NumberOfUserReferences : 1
   +0x020 u                : __unnamed
   +0x024 FilePointer      : 0x820b4658 _FILE_OBJECT
   +0x028 WaitingForDeletion : (null)
   +0x02c ModifiedWriteCount : 0
   +0x02e NumberOfSystemCacheViews : 0

kd> dt _file_object 0x820b4658
ntdll!_FILE_OBJECT
   +0x000 Type             : 5
   +0x002 Size             : 112
   +0x004 DeviceObject     : 0x81bf2c08 _DEVICE_OBJECT
   +0x008 Vpb              : 0x81fe6d80 _VPB
   +0x00c FsContext        : 0xe1e8c990
   +0x010 FsContext2       : 0xe1e8cae8
   +0x014 SectionObjectPointer : 0x820fa144 _SECTION_OBJECT_POINTERS
   +0x018 PrivateCacheMap  : (null)
   +0x01c FinalStatus      : 0
   +0x020 RelatedFileObject : (null)
   +0x024 LockOperation    : 0 ''
   +0x025 DeletePending    : 0 ''
   +0x026 ReadAccess       : 0x1 ''
   +0x027 WriteAccess      : 0x1 ''
   +0x028 DeleteAccess     : 0 ''
   +0x029 SharedRead       : 0x1 ''
   +0x02a SharedWrite      : 0 ''
   +0x02b SharedDelete     : 0 ''
   +0x02c Flags            : 0x40042
   +0x030 FileName         : _UNICODE_STRING "\test.doc"
   +0x038 CurrentByteOffset : _LARGE_INTEGER 0x0
   +0x040 Waiters          : 0
   +0x044 Busy             : 0
   +0x048 LastLock         : (null)
   +0x04c Lock             : _KEVENT
   +0x05c Event            : _KEVENT
   +0x06c CompletionContext : (null)

kd> !fileobj 0x820b4658

\test.doc

Device Object: 0x81bf2c08   \Driver\Ftdisk
Vpb: 0x81fe6d80
Event signalled
Access: Read Write SharedRead

Flags:  0x40042
        Synchronous IO
        Cache Supported
        Handle Created

FsContext: 0xe1e8c990        FsContext2: 0xe1e8cae8
CurrentByteOffset: 0
Cache Data:
  Section Object Pointers: 820fa144
  Shared Cache Map: 00000000

还是要谢谢楼上两位的讲解。

貌似还真应该是_SEGMENT（根据_CONTROL_DATA的Segment成员会指回之前的Segment）不是_SEGMENT_OBJECT，难道是微软符号里_SECTION_OBJECT这个Segment的类型写错了？

好神奇~应该不会那么晦涩吧

那怎么看，Setcion_object的segment当_SEGMENT_OBJECT还是_SEGMENT，

不过楼主的那样弄还不算和大伙理解的有冲突，你们都只是当第一个成员当做control_area。所以偏移还不会出错

有没权威点的来验证下用哪个结构解析啊？

typedef struct _SECTION_OBJECT
{
        PVOID StartingVa;
        PVOID EndingVa;

        struct _SECTION_OBJECT *Parent;
        struct _SECTION_OBJECT *LeftChild;
        struct _SECTION_OBJECT *RightChild;

        PSEGMENT Segment;
//        PSEGMENT_OBJECT Segment; 错误的!!!!!!

} SECTION_OBJECT, *PSECTION_OBJECT;

MS的符号文件有误：
+0x014 Segment         : Ptr32 _SEGMENT_OBJECT
应该是：
+0x014 Segment         : Ptr32 _SEGMENT

这算不上MS符号有误吧，又没有人说nt!_SECTION_OBJECT等同于nt!_SECTION，
非要用nt!_SECTION_OBJECT结构去解释EPROCESS中的Section成员，那微软也
没招啊。nt!_SEGMENT_OBJECT与nt!_SEGMENT还是两个不同的结构呢。

achillis 很犀利