2

I have a Windows service running in the background and I want at some point to tell him to get objects from the Running Object Table.

The problem is that it seems impossible to achieve, whatever I try.

It always fails at the GetObject method from the Windows API, failing with code 0x‭800401E3‬ (Operation unavailable) as if the object did not exist.

  • The same code sample that fails in the service does work fine in a regular executable therefore a typo or a logical error is quite unlikely.

  • I tried running the service the following ways :

    • On local system account
    • On admin user account
    • On local system account impersonating admin user (using ImpersonateLoggedOnUser)
      • They all failed the same way (as described above, on GetObject method)

So I am wondering whether there are limitations I am not aware regarding the Running Object Table and Windows services (for possible security issues ?).

And well, if it is suppose to work, what could I be missing ? Is there something else than user privileges that could tamper with the ability of my service to see/retrieve data from the Running Object Table ?

Norgannon
  • 487
  • 4
  • 16
  • A [MCVE] would be helpful. – Lightness Races in Orbit Dec 24 '18 at 13:51
  • Well if I still have no clue tomorrow I will try to make one but it might be a pain to use with the exe recording in the ROT and the service to deploy – Norgannon Dec 24 '18 at 13:58
  • 1
    I understand. That's kind of the point, though, isn't it? So many moving parts, how can we know what's at fault without seeing 'em? FWIW I had a quick glance at the docs and nothing obvious popped out. Good luck! – Lightness Races in Orbit Dec 24 '18 at 14:07
  • I understand and it annoys me not to provide one. I usually do but this time I hoped I could avoid it given the nature of the problem. I was kind of hoping that someone would have had the same issue in the past and find the obvious problem that went straight above my head. A kind of christmas miracle I guess :> – Norgannon Dec 24 '18 at 14:21
  • 1
    ROT object access is by default restricted to the Windows Station (check the doc here: https://learn.microsoft.com/en-us/windows/desktop/api/objidl/nf-objidl-irunningobjecttable-register). Are you trying to get your own objects or other objects? Like if you're running a service an try to get Office objects, it won't work. – Simon Mourier Dec 24 '18 at 14:27
  • They are my own objects. I don't really know what a "Windows Station" refers to. That's a terminology I don't know. That might just be the right track. I'll try to modify the way they are registered. – Norgannon Dec 24 '18 at 14:38
  • @SimonMourier Well the registration was done using the ROTFLAGS_REGISTRATIONKEEPSALIVE flag. I tried putting both ROTFLAGS_REGISTRATIONKEEPSALIVE & ROTFLAGS_ALLOWANYCLIENT and also ROTFLAGS_ALLOWANYCLIENT alone. I did not see any change in the bahavior when trying to retrieve the object. – Norgannon Dec 24 '18 at 14:50
  • 1
    see https://learn.microsoft.com/en-us/windows/desktop/winstation/window-stations if the code that calls register doesn't live in the same window station than the code that calls GetObject, you'll probably have problems, not only with the ROT (monikers), but also with the object references. Services typically live in a specific non-interactive window station – Simon Mourier Dec 24 '18 at 14:52
  • 2
    Read the full doc about Register, you must also add keys in the registry, AppID, etc. https://learn.microsoft.com/en-us/windows/desktop/com/installing-as-a-service-application https://learn.microsoft.com/en-us/windows/desktop/com/rotflags https://learn.microsoft.com/en-us/windows/desktop/api/shobjidl_core/nn-shobjidl_core-ifileisinuse – Simon Mourier Dec 24 '18 at 14:56
  • I see... That does make sense and would explain the issue. Your last link seems to provide the answers. I'll try to closely follow it. Thanks a lot :D – Norgannon Dec 24 '18 at 15:02

0 Answers0