I am trying to figure out what the best way to communicate between a GUI and a Windows system service is. Named pipe seems to be a good option because it has built-in access control mechanism to protect the channel. I found that VPN apps actually use named pipe for communicating between their GUI with system services, such as ExpressVPN and NordVPN.
It seems that these VPN apps don't use basic Windows APIs for creating named pipes (i.e. CreateNamedPipe) but some other libraries or APIs because the behavior of these apps is almost the same: The system service, which is installed by the app, creates a named pipe with a name in this format: (app_id)(username):SingleInstanceIPCChannel or a random GUID string (e.g. 64de4b4e-96e2-4444-8946-f96888f5f3bd)
Anyone knows which library or APIs have this behavior?
Related
I have a Windows Service running on a (large) customer's network. There is a Windows Application that runs on the same host that interacts with the Service to control/configure it. The communications from Application to Service is via named pipes. I've had this working with no problems in my lab or in production service on the customer's network for two years.
I installed the Service and the UI application at a different customer for testing and many of the UI functions do not work. Circumstances and tests point to the named pipe mechanism as a likely culprit.
Is it possible that one EXE or the other could be restricted from creating / using this named pipe?
If there are security concerns/restrictions with named pipes in general I will have to consider using some other means for these applications to talk, but that will involve a lot of engineering time, so I'm still trying to resolve the issue as it stands.
I want to Convert my existing app code which interact with Kernel mode driver(WDM driver). For IOCTL i’m using DeviceIoControl APIs.
For porting my app to UWP i’m using this link : https://learn.microsoft.com/en-us/cpp/porting/how-to-use-existing-cpp-code-in-a-universal-windows-platform-app?view=vs-2017 .
After applying changes in project properties as mentioned in link, i’m getting error as DeviceIoControl identifier not found. That’s issue i’m facing. Is there any sample app/API available instead of DeviceIoControl?
Actually, we added DeviceIoControl to the allow list in RS5. You need to get a HANDLE to the device first, and that will require two changes
Call CreateFileFromApp instead of CreateFile
The device being opened needs to grant access to app container. If
you own the driver and it is a custom device interface, you can use
a custom cap.
If you are accessing an in box defined device interface, you can’t get a direct HANDLE to the device. If your MSR access driver is a pnp driver you can use the guidance above.
You can't use DeviceIOControl from UWP apps. You can see the list of supported Win32 and COM APIs and this is not one of them. UWP apps have a more restricted security model to make it harder to use as a malware vector, so you can't interact with arbitrary kernel mode drivers.
There is a specific scenario where you can enable a custom capability and use Windows.Devices.Custom APIs. See CustomCapability sample. This is intended for hardware support aps generally. See Hardware Support App (HSA): Steps for Driver Developers.
As mentioned by #Xavier Xie, CreateFileFromApp and CreateFile2FromApp are available in later Win10 releases to get brokered device handles from app container. This is probably the easiest approach if you already have a lot of Win32 code that you want to port.
Device access also has UWP version in Windows.Devices.Custom. This also brokers the device handle but encapsulates it into a CustomDevice object which you can use to do IO control to your device.
Note: in both cases, the device handle gets brokered (ie. created in the runtime broker in medium IL, and marshaled into the app container) if the app its self doesn't have permissions to directly open the device. What this means is that the device interface will still need to be ACL'ed or otherwise granted access such that the app can open it.
The most current best way to grant access to an app to access your device is through a custom capability. The Device Access Broker will check the interface's DEVPKEY_DeviceInterface_UnrestrictedAppCapabilities key for the app's PFN. In the legacy flow, Device Access will check DEVPKEY_DeviceContainer_PrivilegedPackageFamilyNames.
How can I send and retrieve messages in Windows without the MSMQ feature?
MSMQ is a network protocol so as long as you can write the data onto the wire in the right format, you'd be able to avoid installing MSMQ but normally you would make use of the installed MSMQ feature to handle all the messaging, handshaking, storage, etc.
In theory you could write your own queue manager application to replace what Windows installs for the MSMQ feature. For example, you may want to do that on a non-Windows platform.
As writing your own queue manager is a significant development project, most people don't bother and instead use what's there already.
I apologize for the bad phrasing in the title, but here's a little more context.
I recently bought a Windows 8 laptop and noticed that Norton was pre-installed and running with SYSTEM level privileges. Thus, it occurred to me that there must be some way for third-party applications to run with SYSTEM privileges.
However, after much googling, I could not figure out whether it was an API call or a registry setting or something else entirely that enabled Norton to do this, so I decided to ask the SO community. How can I write an application that runs with SYSTEM privileges?
Services can be configured to run as several different accounts, including LOCAL SERVICE, NETWORK SERVICE, SYSTEM, or any user's account.
Using SYSTEM isn't recommended, because any security problem can lead to complete compromise of the machine, but it is available.
This is configured by the lpServiceStartName parameter of CreateService and/or ChangeServiceConfig. Pass a NULL pointer as this parameter of CreateService, or ".\\LocalSystem" to ChangeServiceConfig, to use the local system account.
It's a bad idea to run a GUI application as local system. The best approach is to have both a GUI application (running as the logged-on user) and a service (running as SYSTEM) and have them communicate as needed using any suitable IPC method. This is probably what Norton is actually doing.
However, it is possible to get a system service to launch an application as SYSTEM in the user's session. To do this, duplicate the processes security token with DuplicateTokenEx and then use SetTokenInformation with the TokenSessionId option. This will give you a token in SYSTEM context but in the user's session which you can use to launch an executable. (There may be additional issues; for example, you might also need to change the permissions on the workstation and desktop.)
I am working on a product for Windows 8 that needs to perform some low-level tasks, display some UI, and communicate with an external server. I definitely need a Windows service to accomplish the low-level tasks. At the same time, I would like to use the cool features of Windows App Store apps, like push notifications, live tiles etc... for the UI. In this design, both my service and my app would communicate with my external server.
The flow would be something like: my Windows service sends some information to my server, which then sends a push notification to my App Store app.
I understand that deployment is not pretty in this scenario, but let's put that aside for now. My problem: How does the server know that the service and the app are on the same machine, and consequently linked together? i.e. When my Windows service sends information to the server, how does the server know where to send the push notification? I need is some sort of shared, unique, identifying information.
I have seen lots of discussion (usually frustrated in nature) about the lack of inter-process communication between App Store apps and desktop apps. In my case, I have two options:
Generate the exact same unique identifier in the service and in the app. This seems unlikely because apps don't seem to be able to access very much system-specific information. I'd love to be shown that I am wrong about this.
Generate a unique identifier in the server OR in the app and communicate it to the other component. Potential ways to do this:
Create the identifier in the app, save it to a file, and then access the file from the service.
Some sort of local socket solution (I've read this doesn't work, but have not tried)
Of course, option 2 seems likely to violate the Windows 8 app Certification Requirements, notably:
Windows Store apps must not communicate with local desktop
applications or services via local mechanisms, including via files and
registry keys.
Any advice would be most appreciated.
I'm not a lawyer, but if it says "via local mechanisms" then you could still possibly communicate via a cloud service as long as having both apps installed isn't necessary to have some features in the app or if you don't mean to publish the app in the store.
You could save some sort of a token in the documents folder or if your desktop app can run with appropriate permissions - it could access the local data folder of the Windows Store app to synchronize the token for use in communication with the web service.
Perhaps the user could just be asked to copy and paste a token between the two apps?