search

himselfv / viper

Enhanced Windows Service manager application
35 stars 2 forks source link

Triggers: Study if we can resolve RPC source GUIDs to names #18

Closed himselfv closed 7 years ago

himselfv commented 7 years ago

Original report by me.

Network Event -type triggers with RPC sources form a large share of all triggers on Windows 10. All RPC sources are GUIDs. Perhaps it's possible to resolve these GUIDs to more readable names?

If not, maybe it's viable to keep a manual Guid dictionary like with Device Interface Classes? Are there any lists of these Guids?

Document the findings here.

himselfv commented 7 years ago

Correction: Docs say: The event is triggered when an endpoint resolution request arrives for the RPC interface GUID specified by pDataItems.

So this is an RPC interface GUID. not "source GUID" (whatever I meant by that).

himselfv commented 7 years ago

Findings:

  1. There is a lot of RPC interfaces out there. There are sources which document many (such as this excellent handbook by Jean-Baptiste Machand), but that doesn't cover most of modern ones, and they would further change with next versions.

  2. You can query open endpoints on your local PC for supported interfaces. These are often annotated, meaning you get some kind of power-user friendly name. But you only get the interfaces for the currently running services.

  3. I haven't yet found a way to query for interfaces which are currently stopped but known to RPC. This might still be possible (some hints to this here and there), or it might not be (it's not obvious where this persistent registry could be stored, given that most of these IIDS don't seem to appear in registry). More likely not.

  4. Viper now queries local IDs as described, which resolves many IDs. It also contains a well-known ID list which I populated with all IDs that I could resolve + lots of IDs from the handbook above, leaving the dynamic loading as a fallback.

Drawbacks and potential improvements:

  1. Not all IDs are resolved, even if the service in question is started. Notably, all Broker IDs (== root Broker ID) cannot be. Broker IDs are IDs in the form "GUID1:GUID2". GUID1 is always the same and GUID2 is one of the guids in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BackgroundModel\Brokers\ subkey.

  2. The dynamic list is constructed just once. Whatever services are running at the time, that's the IDs that will be dynamically resolved. Starting the service later will not resolve its IDs until restart. This might be improved, though I wouldn't rely on dynamic loading too much.

himselfv commented 7 years ago

Resolving as I did what I could for now.