Just after a bit of confirmation really:
Does XP SP3 implement the User Interface Privilege Isolation (UIPI) mechanism found in Vista?
Back story for human interest :)
I've recently been handed the C++ source to a fairly large application. Sadly the sole developer of this application, since its inception back in the mid 90's, passed away recently leaving us in a pretty tight spot until we can hire a new developer.
Recently users have reported that the application has randomly stopped working and/or certain features that previously worked don't seem to fire at all "although nothing has changed my end!". The "nothing changed" turned out to be SP3 :)
Knowing this, and although I'm not a C/C++ guy, I thought I'd take a look at the source to see if I could find out anything (having spent a great deal of time looking at firewalls, virus scanners and other external factors).
I traced one error to a call to an Api function, SendMessage, and went to the MSDN docs to take a look. It clearly states "Microsoft Windows Vista and later. Message sending is subject to User Interface Privilege Isolation (UIPI). The thread of a process can send messages only to message queues of threads in processes of lesser or equal integrity level." Whilst I'm not 100% sure, this does seem to be a probable cause.
Cheers!
Lenny.
No, XP SP3 doesn't implement any of the Vista security changes, at least not any related to the window manager. You don't really give much background to help, but what sort of error do you get that's associated with SendMessage()?
SendMessage() is a very widely used routine that simply dispatches a Windows message to a window, so I'd expect that the error is associated with how the recipient window handles the incoming message (or not) rather than with SendMessage() itself. Rather than thinking of SendMessage() as being just a Windows function, you've got to think of it as a function that will end up calling further application code in whatever application owns the window that you sent the message to - in particular, the return code from SendMessage() tells you how the window's application got on trying to process the message.
UIPI doesn't report errors on SendMessage - if you're getting an error returned, then it's something else. And the other commenters are right, UIPI is on Vista only, and you wouldn't get bit by this anyways unless you were trying to send a message to a service, for example.
Related
This touches on some already-answered questions, so feel free to duplicate away, but chances are I've already read them and am not satisfied.
There are 2 drivers on my system (located in C:\Windows\System32\drivers) called pefndis.sys and wfpcapture.sys. I am 100% sure pefndis.sys is a kernel driver and 99.9% sure wfpcature.sys is as well. These are 3rd party drivers installed by Mircosoft's Message Analyzer. I have discovered pefndis.sys is used to capture data on the wire and wfpcapture.sys is used to capture data above the network layer (ie, this will capture loopback traffic). I have no documentation, header files, etc, for these drivers as there was no intention of Microsoft for these drivers to be used for custom solutions as I would like to do. It just so happens I've identified wfpcapture.sys as performing the exact tasks I want, and I'd love to tap into what it can do; this seems so much more reasonable than spending the time and pain of implementing my own driver. However, my efforts have failed.
This is what I've done: I have some simple c++ code here:
void Provider::InitDriver()
{
HANDLE wfpHandle = NULL;
DWORD lastError = 0;
LPCTSTR wfpName = L"\\\\.\\wfpcapture";
LPCTSTR pefName = L"\\\\.\\pefndis";
wfpHandle = CreateFile(
wfpName,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
lastError = GetLastError();
CloseHandle(wfpHandle);
}
When I run CreateFile with wfpName, I get an invalid handle and lastError==2 meaning the file cannot be found. When I run CreateFile with pefName, I get a valid handle and lastError==0. Upon further investigation, most of my randomly-picked .sys files from the drivers folder produce invalid handles with error codes of 2. Occasionally I'd get an error code of 5 (Access Denied, which also seems odd since I'm running everything as administrator). Does anyone have an explanation why I cannot get a handle to wfpcapture.sys? I brought up the pefndis.sys driver because it was installed by the same program as wfpcapture.sys, and I can clearly get a handle to that, so all my strings are formatted correctly, and both files are in the same directory. I came across this post yesterday which told me IoCreateSymbolicLink can be used in the driver code to give the driver another alias. If I'm using the wrong alias, does that explain why so many .sys files return FILE_NOT_FOUND errors when I try to get handles to them?
I've tried to do some more research on the file using IL DASM (no luck, this is native code), DUMPBIN, WinObj, and DependencyWalker.
DUMPBIN /EXPORTS [...]wfpcapture.sys returns no exports. I find this extremely odd. These answers suggest .DLLs without exports are simply resources or the code is obfuscated. I am almost certain wfpcapture.sys does not just contain resources. Is obfuscation the most reasonable explanation.. any other ideas why it doesn't have any exports?
I could not find wfpcapture in WinObj anywhere. I located pefndis in Device\. Where is wfpcapture? It doesn't actually talk to a device, so that makes sense, but it is still a driver, correct? Do drivers need to register with Windows in some way before CreateFile can find them?
DependencyWalker verified what DUMPBIN told me, I think .. no exports. I have no idea how Message Analyzer (or anything else down its dependency stack) is actually talking to it.
Just a bit more background for a complete picture... wfpcapture.sys is an ETW Provider that taps into Microsoft's WFP architecture (used for firewall and IDS applications) to sniff packets above the network layer. I want code that "activates" wfpcapture.sys and then sits back and collects the events (packet captures) that wfpcapture publishes. It's this activation part that I can't figure out. If I setup Message Analyzer to start capturing localhost traffic, then turn on the part of my code that captures the events (using StartTrace(...) and EnableTraceEx2(...)), that works just fine. I am just dying to know how Message Analyzer is talking to wfpcapture.sys and what it's saying in order to get it to cooperate and start publishing events. Another fun fact: When I start a trace in Message Analyzer and do sc query wfpcapture, it tells me the service (here it is identified as a kernel driver) is running. When I stop the trace, the query tells me the service is stopped. If I manually sc start wfpcapture and verify the service is running,, and then run my event capturing code, I get nothing. This tells me Message Analyzer must be sending something to wfpcapture.sys to get it activated and publishing. My plan that spawned this whole thing was to get a handle to driver and start sending it control codes via DeviceIoControl to glean some knowledge on how it worked. I have also seen some very strong evidence that Message Analyzer is passing filter masks to the driver.
Am I completely wasting my time here? That driver is not meant for my consumption, and poking and prodding it to learn about it may be a long shot, but I'm certain it does exactly what I need and I've never written a driver in my life; trying to do that seems foolish when this is sitting right here. Message Analyzer is free, I'm not trying to steal software. Could there possibly be some DRM associated with the driver that's boxing me out? I'd love to hear the thoughts of anyone out there who has Windows driver experience.
Ok, lot of questions there, hope this doesn't get flagged as too broad.
I've been asked by a client to solve the following pesky issue. They have a custom software that has a tendency of displaying message boxes "left and right" without any apparent reason. For instance, the software itself is an accounting program, and when they take a customer's payment, the message box may be displayed about 3 or 4 times in a row. Each message box plays Windows default sound. Unfortunately the way this software was programmed, the type of sounds it plays is completely wrong. For instance, it may display a warning message box and play the warning system sound when the message itself is just an information. All this is quite annoying for the staff who uses the software.
I tried to contact the vendor who distributes the software, but I hit a deadend with them. So now I am looking for ways to mitigate this issue.
My easiest solution was to suggest to mute the speakers, but unfortunately, they require sound to be present to be able to hear incoming emails, and most importantly, be able to play voice mail from them later. So my solution was to somehow mute message box sounds just for a single process.
From my experience, I know that there're two APIs that may be producing these sounds: MessageBeep and an older Beep.
I also found this article that explains how to use AppInit_DLLs to hook to system APIs. It works great, except that both of the APIs that I need to hook to come from User32.dll and not from kernel32.dll like the author suggests.
There's also this post in the questions section that kinda gives approximate steps to hooking to an API from User32.dll, but when I tried to implement them, there's not enough information (for my knowledge to do it.)
So my questions is, does anyone know how to hook to an API in the User32.dll module?
EDIT: PS. Forgot to mention. This software is installed on Windows 7 Professional, with UAC disabled -- because it is not compatible with UAC :)
As an alternative you can patch you application. Find calls to MessageBeep and overwrite them with nop.
This is the hard way of doing it: if your app is supposed to be running as Administrator on a pre-Vista Windows, you could get the address of the API via ::GetProcAddress(), give yourself privileges to write to its memory page, and overwrite the beginning of the API's code with a "jmp" assembly instruction jumping into the address of your override function. Make sure your overwrite function takes the same arguments and is declared as __cdecl.
Expanded answer follows.
The "standard" technique for API hooking involves the following steps:
1: Inject your DLL into the target process
This is usually accomplished by first allocating memory in the target process for a string containing the name/path of your DLL (e.g. "MyHook.dll"), and then creating a remote thread in the target process whose entry point is kernel32::LoadLibraryA() passing the name of your DLL as argument. This page has an implementation of this technique. You'll have to wrestle a bit with privileges, but it's guaranteed to work 100% on Windows XP and earlier OSes. I'm not sure about Vista and post-Vista, Address Space Layout Randomization might make this tricky.
2. Hook the API
Once your DLL is loaded into the target process, its DllMain() will be executed automatically, giving you a chance to run anything you want in the target process. From within your DllMain, use ::LoadLibraryA() to get the HMODULE of the library containing the API you want to hook (e.g. "user32.dll") and pass it to ::GetProcAddress() together with the name of the API you want to hook (e.g. "MessageBeep") to get the address of the API itself. Eventaully give yourself privileges to write to that address' page, and overwrite the beginning of the API with a jmp instruction jumping into your detour (i.e. into your "version" of the API to hook). Note that your detour needs to have the same signature and calling convention (usually _cdecl) as the API you want to hook, or else monsters will be awakened.
As described here, this technique is somewhat destructive: you can't call back into the original API from the detour, as the original API has been modified to jump into yours and you'll end up with a very tight and nice infinite loop. There are many different techniques that would allow you to preserve and/or call back into the original API, one of which is hooking the ...A() versions of the API and then calling into the ...W() versions (most if not all of the ...A() Windows API's convert ASCII strings into UNICODE strings and end up calling into their ...W() counterparts).
No need to spend time on a custom program to do this.
You can mute a particular application when it's running, and that setting will be remembered the next time you open the application. See https://superuser.com/questions/37281/how-to-disable-sound-of-certain-applications.
There's also the Windows Sound Sentry that will turn off most system sounds, although I'm not aware of any per-application settings for Sound Sentry.
You can use Deviare API hook and solve the hook in a couple of C# lines. Or you can use EasyHook that is a bit more difficult and less stable.
I'm quite confused as to what should and should not be done in QApplication::commitData. The name implies that I should just store the state, and the docs say it should not close the application. However, the default implementation indeed closes all windows thereby closing the application. Also, if this is not the way to detect windows shutdown, I don't see any other way to tell that windows is indeed being shutdown.
There is also the related saveState. The function name means about the same and the documentation is also quite similar.
How am I supposed to properly detect when the system is being shutdown and both save my state and close my application? Is commitData indeed the correct way and just suffering from a very poor name and bad documentation?
In my practice to detect an application shutdown I usually connect to the slot void QCoreApplication::aboutToQuit (). As it says in the docu:
The signal is particularly useful if your application has to do some last-second cleanup. Note that no user interaction is possible in this state.
So far so good this has worked for me properly
commitData() and saveState() may seem redundant.
But the documentation
says
Futhermore, most session managers will very likely request a saved state immediately after the application has been started. This permits the session manager to learn about the application's restart policy.
Maybe that explains why the notion of 'data' and 'state' are separated. During that initial call, it would not be user friendly to interact with the user.
The default response to shutdown the application seems like a good design, because if you don't reimplement, then the safest thing to do is to close the app (as if the user had chosen the Quit action), which should also save the user's data.
Is the OS shutting down, or only the session? As far as your app should be concerned, it is only the session (since technically, the user could be logging off and the OS continues to run.) And the user might consider the app to be not 'shut down', just 'paused with data safed.'
Also consider mobile platforms like iOS, where an application seeming runs forever.
I am having a problem with the program I am currently working on. It is caused by the increased security in vista/Windows 7, specifically the UIPI which prevents a window with a lower integrity level 'talking' to a higher one.
In my case, i am wanting to tell the window with a high Integrity level to move into our application, It works flawlessly on XP or windows 7 with the security off.
I have tried setting the HWND of the higher IL window directly, rather than using the findwindow() function, this works fine but the program then fails when trying to move it or generally interact with it. The windowhandle is saved by the app to be embedded and read by the app running at a lower IL.
I have also tried setting UIaccess in the manifest to TRUE and digitally signing the program but no luck.
Any ideas on how to solve this problem?
thanks.
Just thought i would follow this up for anyone who also struggled as I have finally found a way to do this.
IL = Integrity Level.
I had 2 apps, highIL.exe and lowIL.exe, the highIL wanted to find the lowIL.exe window, set it as a child window and move it into a zone created for it on the highIL.exe. This was blocked by the UIPI in vista+.
In the end i used the ChangeWindowMessageFilter method in vista and the ChangeWindowMessageFilterEx in Windows7, both found in the user32.dll. These functions allow you to poke a hole in the UIPI to allow messages that you want through.
I created a few custom messages using RegisterWindowMessage function, I used this function to register the method in both highIL and lowIL applications, the line looked a little like this:
const UINT MY_MOVEINTWINDOW_MSG = RegisterWindowMessage(_T("MyMsg.MoveWindow"));
The lowIL.exe is then able to send these messages to the highIL.exe window without them being blocked. Then it was a case of just simply adding and writing message handlers.
This method will only work if you have access to both the high and low IL.
The MSDN also has a working example of the ChangeWindowMessageFilterEx function on there Website
On Vista using IE8, I have an instance of IWebBrowser2, which I am using to obtain the current HTML document:
IWebBrowser2* browser;
CComPtr<IDispatch> disp;
HRESULT hr = browser->get_Document(&disp);
When this is executed by an Administrator, the call succeeds. However, when called by a regular user, the call returns an error code of "800706B5" ("The interface is unknown") despite the page being on a "Trusted Site" and "Protected Mode" being off.
This same code worked without problems on IE7 on Vista, and with IE8 on XP.
Does anyone know why this error might be occurring, and what I can do to resolve the issue? Running as administrator is less than ideal, and Jon Skeet is stumped by this one too :)
Update: the question seems to revolve around UAC: turning off UAC completely allows things to work for a regular user (though it's distinctly unsafe)
The error is occurring because on Vista, IE 8 runs in "low integrity" mode, whereas my test code, running as a normal user, runs at "medium integrity". The security model is designed so that code can send instructions to lower integrity components, but data cannot be read from "lower" to "higher" components by default.
More information is available in this document about How the Integrity Mechanism Is Implemented in Windows Vista
Was IE8 installed by the Administrator "For this user only"? I don't know why or if that would give this error, just a hunch.