Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CoGetServerPid may fail for high PIDs #2

Open
jogerh opened this issue Jun 7, 2017 · 6 comments
Open

CoGetServerPid may fail for high PIDs #2

jogerh opened this issue Jun 7, 2017 · 6 comments

Comments

@jogerh
Copy link

jogerh commented Jun 7, 2017

Thank you for a nice contribution with CoGetServerPid.

While investigating the code, I found that if the process ID is greater than what can be represented by an USHORT, an invalid process ID is returned (max USHORT).

If you happen to know about a solution to this problem, it would be highly appreciated.

Best regards,
Jøger

@kimgr
Copy link
Owner

kimgr commented Jul 5, 2017

Thank you for the report, and sorry for the very late response.

I suspect I've misinterpreted the wire layout -- could it be that the PID is not an USHORT in the (made-up) OBJREF struct, but rather a DWORD?

If you could catch this in a debugger, you should be able to look at the stream data and see where the "rest" of the DWORD is (look out for byte-order issues). If you can find a new correct offset, we can update CoGetServerPID to do the right thing.

@forderud
Copy link

CoGetServerPid seem to always return 65535 for process IDs above 65k. This therefore doesn't appear to be a straight-forward "wire layout" misinterpretation issue...

@kimgr
Copy link
Owner

kimgr commented Jun 16, 2019

Since the time CoGetServerPID was written, Microsoft appear to have added documentation for the OBJREF format: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dcom/fe6c5e46-adf8-4e34-a8de-3f756c875f31

Not that it's actually giving away very much (the location of the PID is a mystery to me in this one).

I'm not sure what it can be, besides a wire layout misinterpretation; that's basically all CoGetServerPID does :).

Anyway, patches welcome for this, I don't have access to a Windows environment anymore and my mind is elsewhere.

@forderud
Copy link

forderud commented Sep 2, 2021

Just stumbled across a 3 Ways to Get a COM Server Process ID blog post that seem relevant for this particular problem. The proposed OXID Resolver and ALPC port approaches seem a bit convoluted though.

@kimgr
Copy link
Owner

kimgr commented Sep 6, 2021

@forderud Thanks for the link, that covers way more ground than CoGetServerPID ever did. If someone is interested in augmenting CoGetServerPID with a second phase to inspect the OXID resolver that would be cool. But it does look pretty convoluted.

@forderud
Copy link

Side note: It's also possible to determine PID from a window handle (HWND) using GetWindowThreadProcessId. This can be used as alternative approach when dealing with OLE controls that expose a window handle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants