在内核转储中解释Section对象

我试图追踪3thParty应用程序的问题。当前正在调查的路径是查看每个进程中创建的Section对象：rpsPdf10.mutex。在内核转储中解释Section对象

_{如果对象的名称是它的预期用法的任何指示，我不知道他们为什么选择一个Section对象并将其用作Mutex，但这很可能无关紧要。}

使用LiveKd我发出以下命令的试图让节对象

0: kd>!process 0 0 3thParty.exe 
... 
PROCESS fffffa800ea80060 
    SessionId: 0 Cid: 0a00 Peb: fffdf000 ParentCid: 014c 
    DirBase: 99349000 ObjectTable: fffff8a004448bf0 HandleCount: 338. 
    Image: 3thParty.exe 
...  

0: kd> !handle 0 7 fffffa800ea80060 
     ... 
     08 fffff8a012e26710 Section     rpsPdf10.mutex 
     ... 

0: kd> !object fffff8a012e26710 
Object: fffff8a012e26710 Type: (fffffa800cd7cea0) Section 
    ObjectHeader: fffff8a012e266e0 (new version) 
    HandleCount: 38 PointerCount: 39 
    Directory Object: fffff8a00a980080 Name: rpsPdf10.mutex 

0: kd> dt nt!_FILE_OBJECT fffff8a012e26710 
    +0x000 Type    : 0n256 
    +0x002 Size    : 0n0 
    +0x008 DeviceObject  : 0x000000000008dfb0 _DEVICE_OBJECT 
    +0x010 Vpb    : 0xfffffa80c0000001 _VPB 
    +0x018 FsContext  : (null) 
    +0x020 FsContext2  : 0xfffffa8000000034 Void 
    +0x028 SectionObjectPointer : 0xfffff8a0102d7820 _SECTION_OBJECT_POINTERS 
    +0x030 PrivateCacheMap : 0x0000000000001000 Void 
    +0x038 FinalStatus  : 0n73728 
    +0x040 RelatedFileObject : 0x63536153030a040c _FILE_OBJECT 
    +0x048 LockOperation : 0x74 't' 
    +0x049 DeletePending : 0 '' 
    +0x04a ReadAccess  : 0x65 'e' 
    +0x04b WriteAccess  : 0 '' 
    +0x04c DeleteAccess  : 0x73 's' 
    +0x04d SharedRead  : 0 '' 
    +0x04e SharedWrite  : 0x74 't'

输出字符串't' 'e' 's' 't'肯定伸出所以

无论是我的详细信息沿着错误的路径 - >tx到Blabb，这是确定的。这不是一个文件对象，但问题仍然是如何找到关于Section对象的更多信息。它仍然是好奇的和/或一个相当不幸的巧合，遵循从文件对象信息派生的部分和控制区指针似乎是正确的？！
或有什么毛病节对象
还是...？

tldr;

继上述_FILE_OBJECT结构的_SECTION_OBJECT_POINTERS，我在

的0x26_{NumberOfMappedViews到达（= HandleCount：38）}
0x27_{的NumberOfUserReferences（= PointerCount：39）}

因此对于女性我假设我遵循的道路是正确的。

0: kd> dt nt!_SECTION_OBJECT_POINTERS 0xfffff8a0102d7820 
    +0x000 DataSectionObject : 0xfffffa800fbed900 Void 
    +0x008 SharedCacheMap : 0x0008000000000001 Void 
    +0x010 ImageSectionObject : 0x0000000000000001 Void 

0: kd> dt nt!_CONTROL_AREA 0xfffffa800fbed900 
    +0x000 Segment   : 0xfffff8a0102d7820 _SEGMENT 
    +0x008 DereferenceList : _LIST_ENTRY [ 0x0000000000000000 - 0x0000000000000000 ] 
    +0x018 NumberOfSectionReferences : 1 
    +0x020 NumberOfPfnReferences : 0 
    +0x028 NumberOfMappedViews : 0x26 
    +0x030 NumberOfUserReferences : 0x27

编辑

对象头看起来像这样

0: kd> dt nt!_OBJECT_HEADER fffff8a012e266e0 

    +0x000 PointerCount  : 0n39 
    +0x008 HandleCount  : 0n38 
    +0x008 NextToFree  : 0x00000000`00000026 Void 
    +0x010 Lock    : _EX_PUSH_LOCK 
    +0x018 TypeIndex  : 0x21 '!' 
    +0x019 TraceFlags  : 0 '' 
    +0x01a InfoMask   : 0xa '' 
    +0x01b Flags   : 0 '' 
    +0x020 ObjectCreateInfo : 0xfffffa80`0e505140 _OBJECT_CREATE_INFORMATION 
    +0x020 QuotaBlockCharged : 0xfffffa80`0e505140 Void 
    +0x028 SecurityDescriptor : 0xfffff8a0`1ba076a8 Void 
    +0x030 Body    : _QUAD

编辑2

以下@ blabb的回答调整结构

0: kd> ? @$proc 
Evaluate expression: -6047068061600 = fffffa80`0ea80060 

0: kd> dx (char *)@$proc->ImageFileName 
(char *)@$proc->ImageFileName : 0xfffffa800ea80340 : [Type: char *] : "3thParty.exe" 

0: kd> !handle 0 0 @$proc section 
... 
0474: Object: fffff8a012e26710 GrantedAccess: 000f0007 
... 

0: kd> !object fffff8a012e26710 
Object: fffff8a012e26710 Type: (fffffa800cd7cea0) Section 
    ObjectHeader: fffff8a012e266e0 (new version) 
    HandleCount: 38 PointerCount: 39 
    Directory Object: fffff8a00a980080 Name: rpsPdf10.mutex 

0: kd> ?? (unsigned long) (#FIELD_OFFSET(nt!_OBJECT_HEADER, Body)) 
unsigned long 0x30 

0: kd> dt nt!_object_header 0xfffff8a012e26710-0x30 
    +0x000 PointerCount  : 0n39 
    +0x008 HandleCount  : 0n38 
    +0x008 NextToFree  : 0x00000000`00000026 Void 
    +0x010 Lock    : _EX_PUSH_LOCK 
    +0x018 TypeIndex  : 0x21 '!' 
    +0x019 TraceFlags  : 0 '' 
    +0x01a InfoMask   : 0xa '' 
    +0x01b Flags   : 0 '' 
    +0x020 ObjectCreateInfo : 0xfffffa80`0e505140 _OBJECT_CREATE_INFORMATION 
    +0x020 QuotaBlockCharged : 0xfffffa80`0e505140 Void 
    +0x028 SecurityDescriptor : 0xfffff8a0`1ba076a8 Void 
    +0x030 Body    : _QUAD 

0: kd> x nt!ObTypeIndexTable 
fffff800`01a70c00 nt!ObTypeIndexTable = <no type information> 

0: kd> dt -r1 nt!_SECTION_OBJECT 0xfffff8a012e26710 
    +0x000 StartingVa  : 0x00000022`00000100 Void 
    +0x008 EndingVa   : 0x00000000`0008dfb0 Void 
    +0x010 Parent   : 0xfffffa80`c0000001 Void 
    +0x018 LeftChild  : (null) 
    +0x020 RightChild  : 0xfffffa80`00000034 Void 
    +0x028 Segment   : 0xfffff8a0`102d7820 _SEGMENT_OBJECT 
     +0x000 BaseAddress  : 0xfffffa80`0fbed900 Void 
     +0x008 TotalNumberOfPtes : 1 
     +0x010 SizeOfSegment : _LARGE_INTEGER 0x1 
     +0x018 NonExtendedPtes : 0x1000 
     +0x01c ImageCommitment : 0 
     +0x020 ControlArea  : (null) 
     +0x028 Subsection  : (null) 
     +0x030 MmSectionFlags : 0xfffffa80`10987b10 _MMSECTION_FLAGS 
     +0x038 MmSubSectionFlags : 0x00000000`03400000 _MMSUBSECTION_FLAGS 

0: kd> dc 0xfffff8a012e26710-0x30-0x50 
fffff8a0`12e26690 030c0408 f4636553 0e1a02e0 fffffa80 ....Sec......... 
fffff8a0`12e266a0 00000048 000000b8 0000001c fffffa80 H............... 
fffff8a0`12e266b0 0e505140 fffffa80 00000000 00000000 @QP............. 
fffff8a0`12e266c0 0a980080 fffff8a0 001c001c 00000000 ................ 
fffff8a0`12e266d0 10eb8770 fffff8a0 00000000 00000008 p............... 
fffff8a0`12e266e0 00000027 00000000 00000026 00000000 '.......&....... 
fffff8a0`12e266f0 00000000 00000000 000a0021 fffff8a0 ........!....... 
fffff8a0`12e26700 0e505140 fffffa80 1ba076a8 fffff8a0 @QP......v...... 

0: kd> !pool 0xfffff8a012e26710-0x30-0x50 2 
Pool page fffff8a012e26690 region is Paged pool 
*fffff8a012e26690 size: c0 previous size: 80 (Allocated) *Sect (Protected) 
    Pooltag Sect : Section objects

来源

2017-10-13 Lieven Keersmaekers

@blabb - *旁注：它看起来像使用7作为KMFlags， Windbg完全忽略了TypeName。使用0作为KMFlags，它确实区分大小写。* –

我收到了供应商的反馈，Section对象的意图被用作信号量。少量的内存是保留的，将被用作布尔值，所以它绝对不是文件对象。也就是说，我仍然很想深入挖掘，所以任何帮助都是值得欢迎的。 –

我添加了一个答案，并删除了评论看看 – blabb

这是运行Windows 7
命令一个32位的机使用的是结构无关，但指针运算是拱依赖

当前过程

kd> ? @$proc 

Evaluate expression: -2061895528 = 8519f898

进程名称从EPROCESS->映像文件名称

kd> dx (char *)@$proc->ImageFileName 

(char *)@$proc->ImageFileName   : 0xffffffff8519fa04 : "windbg.exe" [Type: char *]

让我们搜索这个过程中的一些部分把手
的类型名是大小写敏感的

kd> !handle 0 3 @$proc Section 

Searching for handles of type Section 

PROCESS 8519f898 SessionId: 1 Cid: 0138 Peb: 7ffd8000 ParentCid: 0d04 
    DirBase: 7e257560 ObjectTable: b91a3520 HandleCount: 254. 
    Image: windbg.exe 

Handle table at b91a3520 with 254 entries in use 

00c0: Object: 9a10bc58 GrantedAccess: 00000004 Entry: 9945b180 
Object: 9a10bc58 Type: (84eb6040) Section 
    ObjectHeader: 9a10bc40 (new version) 
     HandleCount: 6 PointerCount: 6

！处理0 3标志转储对象可使用！对象{对象地址}被重新验证的具体信息

kd> !object 9a10bc58 
Object: 9a10bc58 Type: (84eb6040) Section 
    ObjectHeader: 9a10bc40 (new version) 
    HandleCount: 6 PointerCount: 6

每个对象具有32的objectheader它在sizeof（nt！）对象地址之前是18个字节。_OBJECT_HEADER-的sizeof（obheader->车身））体被嵌入在HEADER作为最后成员，并且是可变尺寸的

kd> ?? (unsigned long) (#FIELD_OFFSET(nt!_OBJECT_HEADER , Body)) 
unsigned long 0x18

_OBJECT_HEADER如下（虽然尺寸没有改变有新版本标题和旧之间的差异版本报头）

kd> dt nt!_object_header 9a10bc58-0x18 
    +0x000 PointerCount  : 0n6 
    +0x004 HandleCount  : 0n6 
    +0x004 NextToFree  : 0x00000006 Void 
    +0x008 Lock    : _EX_PUSH_LOCK 
    +0x00c TypeIndex  : 0x21 '!' 
    +0x00d TraceFlags  : 0 '' 
    +0x00e InfoMask   : 0x8 '' 
    +0x00f Flags   : 0 '' 
    +0x010 ObjectCreateInfo : 0x82f7aa00 _OBJECT_CREATE_INFORMATION 
    +0x010 QuotaBlockCharged : 0x82f7aa00 Void 
    +0x014 SecurityDescriptor : (null) 
    +0x018 Body    : _QUAD

旧版本头在头直接有_OBJECT_TYPE 新版本的索引到一个数组

这里的类型的索引是0×21

类型的数组是

kd> x nt!ObTypeIndexTable 
82f88580   nt!ObTypeIndexTable = <no type information>

你可以写这样一个脚本来转储所有类型

function log(instr) 
{ 
    host.diagnostics.debugLog(instr + "\n"); 
} 
function exec (cmdstr) 
{ 
    return host.namespace.Debugger.Utility.Control.ExecuteCommand(cmdstr); 
} 
function dumptypeindex() 
{ 
    var cpob = host.createPointerObject 
    var titab = exec("x nt!ObTypeIndexTable").First().substr(0,8) 
    var obtype = cpob(host.parseInt64(titab , 16),"nt","_OBJECT_TYPE **") 
    var i = 2 
    while(obtype[i] !=0) 
    { 
     log("index = "+i+"\t"+ host.memory.readWideString(obtype[i].Name.Buffer)) 
     i++ 
    } 
}

执行这个脚本如下

kd> .scriptload c:\wdscr\dumptypeindex.js 
JavaScript script successfully loaded from 'c:\dumptypeindex.js' 
kd> dx @$scriptContents.dumptypeindex() 
index = 2 Type 
index = 3 Directory 
index = 4 SymbolicLink 
index = 5 Token 
index = 6 Job 
index = 7 Process 
index = 8 Thread 
index = 9 UserApcReserve 
index = 10 IoCompletionReserve 
index = 11 DebugObject 
index = 12 Event 
index = 13 EventPair 
index = 14 Mutant 
index = 15 Callback 
index = 16 Semaphore 
index = 17 Timer 
index = 18 Profile 
index = 19 KeyedEvent 
index = 20 WindowStation 
index = 21 Desktop 
index = 22 TpWorkerFactory 
index = 23 Adapter 
index = 24 Controller 
index = 25 Device 
index = 26 Driver 
index = 27 IoCompletion 
index = 28 File 
index = 29 TmTm 
index = 30 TmTxȂ؃扏楄 
index = 31 TmRm 
index = 32 TmEn 
index = 33 Section 
index = 34 Session 
index = 35 Key 
index = 36 ALPC Port 
index = 37 PowerRequest 
index = 38 WmiGuid 
index = 39 EtwRegistration 
index = 40 EtwConsumer 
index = 41 FilterConnectionPort 
index = 42 FilterCommunicationPort 
index = 43 PcwObject

将产生的类型

通知0x21 = 0n33 =第

号

因为我们有一个节

我们可以转储段对象

kd> dt -r1 nt!_SECTION_OBJECT 9a10bc58 
    +0x000 StartingVa  : 0x90f87b44 Void 
    +0x004 EndingVa   : 0x82efb58a Void 
    +0x008 Parent   : 0xc0802000 Void 
    +0x00c LeftChild  : (null) 
    +0x010 RightChild  : 0xc0c0a280 Void 
    +0x014 Segment   : 0x995ed8d8 _SEGMENT_OBJECT 
     +0x000 BaseAddress  : 0x86b65740 Void 
     +0x004 TotalNumberOfPtes : 0xdf 
     +0x008 SizeOfSegment : _LARGE_INTEGER 0x000000df`00080000 
     +0x010 NonExtendedPtes : 0xdf000 
     +0x014 ImageCommitment : 0 
     +0x018 ControlArea  : (null) 
     +0x01c Subsection  : (null) 
     +0x020 MmSectionFlags : 0x869f52a8 _MMSECTION_FLAGS 
     +0x024 MmSubSectionFlags : 0x02ea0000 _MMSUBSECTION_FLAGS

一个目的是通过由所述pool_header

kd> dc 9a10bc58-0x18-0x18 
9a10bc28 060b0204 f4636553 00000720 00000070 ....Sec. ...p... 
9a10bc38 00000000 00000000 00000006 00000006 ................ 
9a10bc48 00000000 00080021 82f7aa00 00000000 ....!........... 
9a10bc58 90f87b44 82efb58a c0802000 00000000 D{....... ...... 
9a10bc68 c0c0a280 995ed8d8 000df000 00000000 ......^......... 
9a10bc78 00012000 00000004 0670020b 6666744e . ........p.Ntff 
9a10bc88 00f00702 00000a48 0000c0fe 00020000 ....H........... 
9a10bc98 00000000 00000002 00000000 00000000 ................

通知上述Sec标签教是前面对象首标之后使用SectionObjects

d> !pool 9a10bc58-0x18-0x18 2 
Pool page 9a10bc28 region is Paged pool 
*9a10bc28 size: 58 previous size: 20 (Allocated) *Sect (Protected) 
     Pooltag Sect : Section objects

来源

2017-10-13 20:32:24 blabb

* fwiw - 我正在从内核转储和使用Windbg 10.0.10240.9。 '！handle 0 3 @ $ proc Section'返回所有内容并忽略类型。 '！handle 0 0 @ $ proc Section'只返回部分*（仍在翻阅你的答案） –

我使用@ $ proc作为例子，如果你当前的进程不是你有可能需要改变上下文的进程.process/p/r {EPROCESS的addr（从@ process 0返回的exeofinterest返回）}演练是从内部预览中完成的windbg 16278 – blabb

不，'@ $ proc'是正确的，只是指出一些关于Windbg *知道后受到轰炸的东西*我*不知道;） –

在内核转储中解释Section对象

回答

相关问题