A forum for reverse engineering, OS internals and malware analysis 

Ask your beginner questions here.
 #5848  by abhishekb
 Thu Apr 07, 2011 10:51 am
Hi
I am working on Windows XP SP2. I am trying to acquire the list of processes using lists of threads in the scheduler.
I have got the values of KiWaitListHead and KiDispatcherReadyListHead.
I thought of traversing the KiWaitListHead in Windbg but got stucked.
I am posting my results.
Code: Select all
lkd> dd KiWaitListHead
805632e8  85e2cad8 85fc2918 00000011 00000000
805632f8  e57a42bd d6bf94d5 01000013 ffdff980
80563308  ffdff980 804e25f1 00000000 000ed3f4
80563318  00000000 00000000 80563320 80563320
80563328  00000000 00000000 80563330 80563330
80563338  00000000 00000000 00000000 85fbab30
80563348  00000000 00000000 00040001 00000000
80563358  85fbaba0 85fbaba0 00000003 00000000
lkd> dt _LIST_ENTRY 805632e8  
nt!_LIST_ENTRY
 [ 0x85c4d988 - 0x85fc2918 ]
   +0x000 Flink            : 0x85c4d988 _LIST_ENTRY [ 0x85cddd70 - 0x805632e8 ]
   +0x004 Blink            : 0x85fc2918 _LIST_ENTRY [ 0x805632e8 - 0x85c5f918 ]
lkd> dt _LIST_ENTRY 85c4d988 
nt!_LIST_ENTRY
 [ 0x0 - 0x805632e8 ]
   +0x000 Flink            : (null) 
   +0x004 Blink            : 0x805632e8 _LIST_ENTRY [ 0x85292e08 - 0x85fc2918 ]
The first dt command shows that the value of LIST_ENTRY at 0x85c4d988 is [ 0x85cddd70 - 0x805632e8 ]
but with the next dt command it shows that Flink is null [ 0x0 - 0x805632e8 ].
Why so?
And also when I issued the command with 'recursive' option i got the following result which seems to be okay.
Code: Select all
lkd> dt _LIST_ENTRY 805632e8 -r2
nt!_LIST_ENTRY
 [ 0x853734a8 - 0x852a9a48 ]
   +0x000 Flink            : 0x853734a8 _LIST_ENTRY [ 0x85e36e08 - 0x805632e8 ]
      +0x000 Flink            : 0x85e36e08 _LIST_ENTRY [ 0x85e05080 - 0x853734a8 ]
         +0x000 Flink            : 0x85e05080 _LIST_ENTRY [ 0x853094a8 - 0x85e36e08 ]
         +0x004 Blink            : 0x853734a8 _LIST_ENTRY [ 0x85e36e08 - 0x805632e8 ]
      +0x004 Blink            : 0x805632e8 _LIST_ENTRY [ 0x853734a8 - 0x852a9a48 ]
         +0x000 Flink            : 0x853734a8 _LIST_ENTRY [ 0x85e36e08 - 0x805632e8 ]
         +0x004 Blink            : 0x852a9a48 _LIST_ENTRY [ 0x805632e8 - 0x85fc2918 ]
   +0x004 Blink            : 0x852a9a48 _LIST_ENTRY [ 0x805632e8 - 0x85fc2918 ]
      +0x000 Flink            : 0x805632e8 _LIST_ENTRY [ 0x853734a8 - 0x852a9a48 ]
         +0x000 Flink            : 0x853734a8 _LIST_ENTRY [ 0x85e36e08 - 0x805632e8 ]
         +0x004 Blink            : 0x852a9a48 _LIST_ENTRY [ 0x805632e8 - 0x85fc2918 ]
      +0x004 Blink            : 0x85fc2918 _LIST_ENTRY [ 0x852a9a48 - 0x85301e08 ]
         +0x000 Flink            : 0x852a9a48 _LIST_ENTRY [ 0x805632e8 - 0x85fc2918 ]
         +0x004 Blink            : 0x85301e08 _LIST_ENTRY [ 0x85fc2918 - 0x852bc870 ]
I am sorry if this is a very silly question. I just want all the EPROCESS structures using these ETHREAD structures.
 #5849  by r2nwcnydc
 Thu Apr 07, 2011 11:26 am
It looks like a process was being started or killed. If you had reissued the second command you probably would have gotton different results.
 #5850  by abhishekb
 Thu Apr 07, 2011 11:36 am
Yes I am getting a different result most of the time. My question is how can I be sure that I have covered all the ETHREAD structures from my 'driver code' as the Flink of the second LIST_ENTRY might be null.
 #5852  by r2nwcnydc
 Thu Apr 07, 2011 12:38 pm
You can raise the IRQL on all the processors which will guarantee you are the only thing that is able to run. I would recommend you pick up the book, "The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System."

I don't think I can post the full example from the book, but here are some of the functions you should look into.

KeGetCurrentIrql
KeRaiseIrql
KeGetCurrentProcessorNumber
KeIni tializeDpc
KeSetTargetProcessorDpc
KeInsertQueueDpc
KeLowerlrql
 #5859  by Vrtule
 Thu Apr 07, 2011 7:08 pm
The most clear way would probably be to use same locking mechanism as the kernel does when it operates with the lists. I think it uses dispatcher lock in this case.