Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Com caller process

AlbertAlbert Member - All Emails Posts: 454
Scenario : out of proc com client calls into com server(we don't own the server code), as a kernel driver(,we own the code) is it possible to find out the calling process?

I know this is a bit of a generic problem description, but just trying to see if this can be done at all,?

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,760

    The short answer is "no". but I think you knew that. Even the COM server doesn't necessarily know that. It's just one endpoint of an RPC exchange.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • AlbertAlbert Member - All Emails Posts: 454
    Yes, I knew the short ans, but was hoping to get the long answer here I am sure someone has found a way..
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,760

    If you're not going to believe the answers, then I guess you shouldn't ask the question. As I said, even the COM server itself would not have access to this information. The RPC layer uses a network port or a service to marshal data back and forth. That's all hidden from the server, and the server even has access to symbols that you don't.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • MBond2MBond2 Member Posts: 233

    Are you asking if it is possible for a kernel driver to somehow spy on an RPC exchange?

    If so, the answer is surely yes. But I see no valid use for this kind of spying. Even if you are trying to fix some kind of security hole in software that you don't control, you have no valid way to interact with that software that you don't control. If you want help, i think you will have to explain more about what you are actually trying to achieve

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE