Comments on: Associating LPC clients and servers http://kobyk.wordpress.com/2008/04/12/associating-lpc-clients-and-servers/ I don't have to put up with this shit... Fri, 09 Oct 2009 20:15:04 +0000 http://wordpress.com/ hourly 1 By: Remote Procedure Call debugging « KK’s Blog http://kobyk.wordpress.com/2008/04/12/associating-lpc-clients-and-servers/#comment-151 Remote Procedure Call debugging « KK’s Blog Sat, 07 Jun 2008 12:22:16 +0000 http://kobyk.wordpress.com/?p=19#comment-151 [...] Procedure Call debugging Recently, I discussed how one would go about finding the other end of an LPC (Local inter-Process Communication, rather [...] [...] Procedure Call debugging Recently, I discussed how one would go about finding the other end of an LPC (Local inter-Process Communication, rather [...]

]]> By: Shay Barak http://kobyk.wordpress.com/2008/04/12/associating-lpc-clients-and-servers/#comment-119 Shay Barak Fri, 18 Apr 2008 19:28:20 +0000 http://kobyk.wordpress.com/?p=19#comment-119 Brilliant! My methods usually rely on guesswork, spraying a bunch of breakpoints in the context of the assumed server process at key locations where I'm guessing it might hit and then tracing back with the stack. Once I've found the relevant code I either resolve to static means or debug dynamically at the handler of the LPC call. Needless to say, your tactics are much more refined. Usually when it comes to Windows, the general under-the-hood know-how is enough to make a solid guess of where to look and pretty soon you can finger the culprit. However in the case of 3rd party software that uses system mechanisms such as LPC the intuitive approach can fail and so methodological analysis is a must. Now I wonder if I can make a monitor application for catching invocation through LPC/RPC so that I can set it to record, trigger an application's response to an event and instantly get a narrowed-down list of where to look. Anyway, thank you for another great post. Brilliant!
My methods usually rely on guesswork, spraying a bunch of breakpoints in the context of the assumed server process at key locations where I’m guessing it might hit and then tracing back with the stack. Once I’ve found the relevant code I either resolve to static means or debug dynamically at the handler of the LPC call.
Needless to say, your tactics are much more refined.
Usually when it comes to Windows, the general under-the-hood know-how is enough to make a solid guess of where to look and pretty soon you can finger the culprit. However in the case of 3rd party software that uses system mechanisms such as LPC the intuitive approach can fail and so methodological analysis is a must.
Now I wonder if I can make a monitor application for catching invocation through LPC/RPC so that I can set it to record, trigger an application’s response to an event and instantly get a narrowed-down list of where to look.

Anyway, thank you for another great post.

]]>