在內核轉儲中解釋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對象

回答

相關問題