How to find destination PID / TID for an rpc call with only user mode mem dump and no rpcexts.dll
JR
destination PID/TID of the call?
0:000> kb
ChildEBP RetAddr Args to Child
00068928 77e7a33e 01c27848 00068948 77e7a36f RPCRT4!
LRPC_CCALL::SendReceive+0x22a
00068934 77e7a36f 00068964 76f22e68 00068d40 RPCRT4!I_RpcSendReceive
+0x24
00068948 77ef4675 00068990 01c27880 00000000 RPCRT4!NdrSendReceive
+0x2b
00068d24 76f235e7 76f22e68 76f22c70 00068d40 RPCRT4!
NdrClientCall2+0x222
00068d38 76f2357b 00000000 02372ba4 00000001 DNSAPI!R_ResolverQuery
+0x1b
00068d94 71a526c6 02372ba4 00000001 00000000 DNSAPI!DnsQuery_W+0x14f
00068dc8 71a5266f 02372ba4 00000001 00000000 mswsock!HostentBlob_Query
+0x29
00068df4 71a51b0a 02372b38 00396600 003965e8 mswsock!Rnr_DoDnsLookup
+0x7d
- clipped
There are a few msdn blogs and other pages that say this is done by
dumping the memory around the first param and looking for two dwords
in a fow that have the PID and TID as their value. (dpp 01c27848 in
this example) Right now when in user mode I use gpedit to turn on rpc
debug info and use rpcexts.dll. I'd like to not have to do that
though. Any advice would be greatly appreciated.
JR
Marc Sherman
"Debugging Local DCOM and MSRPC Communication". In this section the authors
walk through an example that does what you want with the user mode and
kernel mode debuggers. It doesn't look like they used rpc debug info for
this.
good luck,
Marc
"JR" <justin...@gmail.com> wrote in message
news:44278ee9-e4ec-490e...@f40g2000pri.googlegroups.com...
JR
> In Chapter 8 of "Advanced Windows Debugging" there's a section called
> "Debugging Local DCOM and MSRPC Communication". In this section the authors
> walk through an example that does what you want with the user mode and
> kernel mode debuggers. It doesn't look like they used rpc debug info for
> this.
>
> good luck,
> Marc
>
>
> - Show quoted text -
Thank you for the reply. I have the book you referenced and I have
read chapter 8. They have a kernel mode or complete memory dump for
those examples. It's rather easy when you have a kernel dump and can
use the !lpc command. I am trying to do it with a user mode memory
dump. That chapter also describes how to get the information with
rpcexts.dll commands. I'm looking for that PID/TID data in a structure
that is currently on the stack. Thanks again.
JR
I got this working I believe so I figured I would post a reply here so
others could see what I was talking about. Essentially I want to
profile a running process and determine what out of process com calls
it is making. I wanted to destination PID which can be related to a
com component using component services. After searching for some time
i found this blog which explained how top do this
http://blogs.technet.com/marcelofartura/archive/2007/07/13/how-to-identify-the-process-and-thread-being-called-in-a-com-call-from-a-thread-stack.aspx
So based on that article I use this breakpoint to dump the PID data
Bp ole32!CRpcChannelBuffer::SendReceive2 "r @$t0 = poi(poi(edi +
18)+8);? @$t0;g"
This works great. Now when I attach the debugger and set the bp I get
a list of the other PIDs that my exe calls in real time.
Is anyone else doing anything like this? I want to make sure I am
using the right function and that I won't be missing any out-of-
process com calls.
xiaopot...@gmail.com
xiaopot...@gmail.com
>
> "i found this blog which explained how top do this
> http://blogs.technet.com/marcelofartura/archive/2007/07/13/how-to-identify-the-process-and-thread-being-called-in-a-com-call-from-a-thread-stack.aspx"
Evaluate expression: 298812044 = 11cf828c
Evaluate expression: 298812044 = 11cf828c
Evaluate expression: 298812044 = 11cf828c
Evaluate expression: 0 = 00000000
Evaluate expression: 0 = 00000000
Evaluate expression: 1155524051 = 44dfe5d3
Evaluate expression: 298899562 = 11d0d86a
Evaluate expression: 298899562 = 11d0d86a
Evaluate expression: 0 = 00000000
Evaluate expression: 298812044 = 11cf828c
Evaluate expression: 298812044 = 11cf828c
Evaluate expression: 0 = 00000000
xiaopot...@gmail.com
test:
0:000> dt CRpcChannelBuffer 00568030
ole32!CRpcChannelBuffer
+0x000 lpVtbl : 0x76bd7c08 IRpcChannelBufferVtbl
+0x004 lpVtbl : 0x76bb92c0 IRpcChannelBufferVtbl
+0x008 _cRefs : 4
+0x00c state : 2
+0x010 _pRpcDefault : (null)
+0x014 _pRpcCustom : 0x0054e810 CChannelHandle
+0x018 _pOXIDEntry : 0x00559e68 OXIDEntry
+0x01c _pIPIDEntry : 0x0055b0e8 tagIPIDEntry
+0x020 _pInterfaceInfo : 0x00554780 Void
+0x024 _pStdId : 0x00568590 CStdIdentity
+0x028 _destObj : CDestObject
0:000> dt OXIDEntry 0x00559e68
ole32!OXIDEntry
+0x000 _pNext : 0x76cc68f8 OXIDEntry
+0x004 _pPrev : 0x00559de8 OXIDEntry
+0x008 _dwPid : 0x3e0
+0x00c _dwTid : 0
+0x010 _moxid : _GUID {629ccdea-5f91-1bc2-1fd7-85b418005454}
+0x020 _mid : 0x54540018`b485d71f
+0x028 _ipidRundown : _GUID {0000d800-03e0-0000-8ea9-5038c3148d7c}
+0x038 _dwFlags : 0x42
+0x03c _hServerSTA : (null)
+0x040 _pParentApt : (null)
+0x044 _pRpc : 0x0054e630 CChannelHandle
+0x048 _pAuthId : (null)
+0x04c _pBinding : 0x00522998 tagDUALSTRINGARRAY
+0x050 _dwAuthnHint : 4
+0x054 _dwAuthnSvc : 0xffffffff
+0x058 _pMIDEntry : 0x00559c40 MIDEntry
+0x05c _pRUSTA : 0x00563dac IRemUnknown
+0x060 _cRefs : 0n3
+0x064 _hComplete : (null)
+0x068 _cCalls : 0n0
+0x06c _cResolverRef : 0n7
+0x070 _dwExpiredTime : 0
+0x074 _version : tagCOMVERSION
+0x078 _ulMarshaledTargetInfoLength : 0
+0x07c _pMarshaledTargetInfo : (null)
=76cc7128 OXIDEntry::_palloc : CPageAllocator
0:000> ? 0x3e0
Evaluate expression: 992 = 000003e0
0:000> dd esp
002feb24 76bb9d01 00568030 002fec30 002fec18
now 992--->svchost /k netsvcs.exe
Abdullah Mushtaq
Identify RPC Call Context: Review the memory dump to identify the context of the RPC call. Look for any relevant call stacks or threads that might be involved in the RPC communication. Tools like WinDbg (Windows Debugger) or other memory analysis tools can help you analyze the call stacks.
Analyze Call Stacks: Use WinDbg or another debugging tool to analyze the call stacks of relevant threads. Look for any functions or modules that are indicative of RPC activity. This might involve functions related to networking, RPC runtime libraries, or other relevant APIs.
Look for RPC Context Data: Once you've identified potential call stacks related to RPC, search for any data structures or variables that might contain information about the RPC call context. This could include information about the source and destination PIDs or TIDs, as well as other relevant details.
Analyze Memory Content: If you suspect that the destination PID or TID is stored in memory, you can use the debugging tools to inspect the memory content at specific addresses. Look for any patterns or values that might correspond to PIDs or TIDs.
Manual Inspection: In the absence of specific debugging extensions, you might need to manually inspect memory regions, disassemble code, and analyze data structures to extract the required information.
Reverse Engineering: If necessary, you might need to reverse engineer the relevant portions of the application's code to understand how RPC calls are made and where the destination PID or TID is determined.
Please note that this process can be quite complex and time-consuming, especially without access to specialized debugging extensions like rpcexts.dll. If possible, consider obtaining the necessary debugging tools or extensions to make the analysis more efficient and accurate. Additionally, consulting with experienced reverse engineers or debugging experts might help you navigate through the challenges of extracting RPC call context information from a user-mode memory dump.
Posted by: https://habibicapcut.net