SendInput fail

  • Thread starter Thread starter Kid
  • Start date Start date
K

Kid

Hi

I am trying to write auto test tool for some program, but it did not recieve
key and mouse event by SendInput . How can it do that , can I overcome this
protection?

I found this program only protect SendInput on Vista but not WinXP .

I have tested my code for other app ok on Vista by SnedInput function .

Thank for your teaching.
 
Maybe something is wrong with your code. I don't think anyone here has seen
your code?

Are you sending keyboard input? Did you ensure the correct window has the
focus?
 
I don't think you really understand what I said .

I use the same code to control with the same program on WinXP and it's work
fine.

For other app like notepad or office on Vista, my function can do mouse and
key actions by SendInput too.

When I SetForegroundWindow that program windowon Vista , it will eat any
following SendInput that's why I ask here.
 
Here are a couple of lines from MSDN
Microsoft Windows Vista. This function fails when it is blocked by User
Interface Privilege Isolation (UIPI). Note that neither GetLastError nor the
return value will indicate the failure was caused by UIPI blocking.

Microsoft Windows Vista. This function is subject to UIPI. Applications are
permitted to inject input only into applications that are at an equal or
lesser integrity level.

I think if you disable UAC on the test machine then it should work fine.
(Otherwise I haven't found a workaround solution, it wouldn't make any sense
to have a workaround since this is a security restriction)

AliR.
 
AliR (VC++ MVP) said:
Here are a couple of lines from MSDN
Microsoft Windows Vista. This function fails when it is blocked by User
Interface Privilege Isolation (UIPI). Note that neither GetLastError nor
the return value will indicate the failure was caused by UIPI blocking.

Microsoft Windows Vista. This function is subject to UIPI. Applications
are permitted to inject input only into applications that are at an equal
or lesser integrity level.

I think if you disable UAC on the test machine then it should work fine.
(Otherwise I haven't found a workaround solution, it wouldn't make any
sense to have a workaround since this is a security restriction)
Click to expand...

Yes, and another less invasive workaround is to simply run the OP's app (the
one that calls SendInput) As Administrator. To force this to happen, embed
a manifest in it that has:

<?xml version="1.0" encoding="utf-8" ?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0"
processorArchitecture="X86"
name="AppName"
type="win32" />

<description>App Description</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator"
uiAccess="true"/>

<!-- level=”asInvoker” or level=”requireAdministrator” or level=”highestAvailable”-->

</requestedPrivileges>
</security>
</trustInfo>
</assembly>


For more info, see
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1180962&SiteID=1

-- David
 
David Ching said:
Yes, and another less invasive workaround is to simply run the OP's app
(the one that calls SendInput) As Administrator.
Click to expand...

Which is a violation of the security policy of use of least privileges.
Developers often use Administrator privileges, making systems more
vulnerable to malicious attacks. The policy of use of least privileges means
that Administrator privileges should not be granted if the requirements can
be satisfied using lesser privileges.
 
Sam Hobbs said:
Which is a violation of the security policy of use of least privileges.
Developers often use Administrator privileges, making systems more
vulnerable to malicious attacks. The policy of use of least privileges
means that Administrator privileges should not be granted if the
requirements can be satisfied using lesser privileges.
Click to expand...

I don't see how it is a violation. The app to which the SendInput is
directed is running as Administrator, which means that the app generating
the SendInput must also be running as Administrator. So the least
priviledges required here is as Administrator. If anything is violating, it
is the app receiving the SendInput; if that does need to be run as
Administrator, then it should not be. Then the app generating the SendInput
doesn't need to be either. But that was not the situation as it was
described.

-- David
 
David Ching said:
I don't see how it is a violation. The app to which the SendInput is
directed is running as Administrator, which means that the app generating
the SendInput must also be running as Administrator. So the least
priviledges required here is as Administrator. If anything is violating,
it is the app receiving the SendInput; if that does need to be run as
Administrator, then it should not be. Then the app generating the
SendInput doesn't need to be either. But that was not the situation as it
was described.

-- David
Click to expand...


It is logic such as that that makes systems more vulnerable.
 
Sam Hobbs said:
It is logic such as that that makes systems more vulnerable.
Click to expand...

Instead of criticizing working solutions to the OP's problem, please suggest
one yourself.

-- David
 
I am not criticizing; I am providing answers. I am sorry if you feel
criticized but my intent is to ensure that developers are provided relevant
additional guidance. For more about least privileges, see "Spot the Bug! :
Writing Secure Applications using Least Privileges" at:

http://blogs.msdn.com/rsamona/archive/2005/01/06/348168.aspx

That article refers to the book "Writing Secure Code" which many people
consider to be an excellent book; I don't consider it to be excellent except
for the security information that should be available from Microsoft but is
not.

If you search the MSDN for "least privileges" (with quotes) you will get
hundreds of results.
 
Sam Hobbs said:
I am not criticizing; I am providing answers. I am sorry if you feel
criticized but my intent is to ensure that developers are provided relevant
additional guidance.
Click to expand...

Sure, all that advice is helpful but IT CANNOT BE USED IN THIS CASE.

-- David
 
Back
Top