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
Related
I'm working in C++ in Windows and I need to deal with an input device with force feedback. I found out that one solution could be to use DirectInput and so I start looking at that.
FIRST QUESTION: any suggestions on other ways for dealing with force feedback devices? (Win32 app, not UWP)
Coming back to DirectInput
The reference starting point I have got in my mind is the DirectInput Samples, in particular the FFconst example where a constant feedback force is applied to the first device axis according to a value grabbed from a simple GUI. In my case what I want to achieve is having a simple console application where I set a constant force according to a value grabbed from the standard input.
The basic steps for using the DirectInput API, according to the samples and the documentation, are:
create direct input device calling DirectInput8Create;
look for devices calling EnumDevices filtering devices and limiting scope to the enumeration according to what you are looking for (in my case I'm filtering for looking only in DI8DEVCLASS_GAMECTRL devices and limiting the scope to DIEDFL_ATTACHEDONLY | DIEDFL_FORCEFEEDBACK);
set data format for the selected device(s) calling SetDataFormat in order to be able to acquire the device;
set the cooperative level for the device(s) calling SetCooperativeLevel once again in order to acquire the device;
use the device...
Now, all goes well until we encounter the SetCooperativeLevel mehtod since it needs as input a HWND window handle "to be associate to the device" and which "must be a valid top-level window handle that belongs to the process". Since I'm writing a console application I need to find a valid HWND pointer: I sorted the problem out following this suggestion. Anyway, the HWND pointer I get in that way seems not to be a valid window handle since I get a E_HANDLE error, as I would specify nullptr as argument. I found out that specifying the argument through the call of GetTopWindow allows not to get the invalid handle error. However I'm not able to acquire the device and I get the DIERR_OTHERAPPHASPRIO error, which is nothing more than E_ACCESSDENIED. I found that it seems someone use to treat that error in the same way the DIERR_INPUTLOST error is treated, i.e. re-acquiring the device in a while loop as shown in the Joystick direct input sample in the UpdateInputState function. Anyway trying this I'm not able to exit that loop, i.e. the device device keep being denied.
That said I end up with the
SECOND QUESTION: how to use the DirectInput API in a console application or inside a DLL? (Win32) In case of a console application I'd like to understand why the steps I've done don't work, and in case of a DLL I'd like to know if anyone has an idea on which HWND pointer could be used.
Microsoft provides a function to get a console application's window for uses like this.
HWND WINAPI GetConsoleWindow(void);
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 trying to simulate the keypress events for Win+X on Windows 8 which should pop up a small menu, but I have been unable to get this to work by using SendInput. For any other combination of keys (e.g. Win+R, Win+E, Win+D) it works but not for Win+X. I've noticed that Synergy+ has the same problem, but the Windows on-screen keyboard doesn't. I have also looked at the parameters for SendInput that the on-screen keyboard uses but if I use exactly the same parameters in my application I still don't get the menu.
So my question, how do I get this to work? Or is there an alternative way to display this menu?
I've recently added support for this to our application. Glad we beat our competitor to it!
There are new UIPI restrictions in Windows 8. The most-used blocked shortcut is Alt+Tab, so you're going to want to do the workaround.
You have to mark your binaries with uiAccess="true" in the manifest. (For more detail on how to do this, google.) This manifest prevents binaries from being launched unless signed with a Microsoft-approved code signing certificate and installed in a "secure location" (system32 or Program Files/Program Files (x86)).
If you lanch your program from any helpers: The uiAccess binary can't be launched with CreateProcess from a medium integrity process (the manifest marks it as requiring "high" integrity). Instead, it's easiest to launch it using ShellExecute "open" to get the shell to elevate it. If using CreateProcessAsUser, you have to set TokenUIAccess to 1 using SetTokenInformation, or launching will fail.
Final provisos: note that uiAccess quite heavily restricts what a process can do. You can't receive UI input from normal (medium integrity) processes, so other applications can't interact with your windows. If you don't already follow good practices in separating your UI into a separate process, this would therefore be a good reason to do that. Alternatively, the tasks requiring uiAccess could be put into a small, self-contained helper binary and entirely separated from the non-UI process too. Your main app can run it as a high-integrity helper process that is sent instructions as required to perform those specific tasks (such as SendInput).
Finally, SendInput will work.
I want to monitor when a key is changed/added/deleted to the registry whenever application is being installed or removed. I have tested the sample code from the msdn(link) and it works fine.
But the problem is that it does not tell me which key has actually been modified/added/deleted. How can i retrieve this information using c++?
There are only 3 ways, none of which is both easy and adequate:
RegNotifyChangeKeyValue:
Doesn't give you the info you need, but is very easy to use.
EVENT_TRACE_FLAG_REGISTRY which is part of Event Tracing for Windows
which is what ProcMon uses. It works well, but it's quite difficult to use.
I'm not sure exactly how to use it myself, but if I figure it out I'll post it here.
CmRegisterCallback:
Requires kernel-mode driver, which is a pain in 64-bit.
But it's the most perfect solution otherwise.
Unfortunately Event Tracing for Windows (EWT) does not allow to see full key path in the event. You get only a partial key name and a strange handle with is actually a key control block. It's not so simple to get information from this block.
Yes the process monitor uses EWT, but it does not use Windows Kernel Trace as a provider.
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.