I have a system-wide keyboard hook DLL that I have created that has been working successfully for years in Windows XP.
However, it appears that in certain later versions of Windows (Vista Home Premium, and Windows 7, to name a couple), the hook either does not work at all, or it simply works only locally within the application that installed it.
I have seen it suggested in a couple of places on the internet to change the WH-KEYBOARD to WH-KEYBOARD-LL in the call to SetWindowsHookEx, but this doesn't appear to help when I tried it. Is there something else I need to change in addition to changing the hook type to WH-KEYBOARD-LL?
(P.S.: I had to define WH-KEYBOARD-LL as 13, since it not defined in Delphi. I'm assuming this is accurate.)
Make sure the process hosting the hook is at the same privilege level of the application you intend to hook. Keyboard and other hooks are a high security risk, so Vista and later was changed to only allow system-wide hooks in processes within a common certain security context. In other words, if you start the hook host process with user rights, it will only hook processes that are at the same privilege level. If you think about it, this make sense because you would not want a user-level process being able to inject code into an admin-level process. That is bad on so many levels.
Related
I know that ntdll is always present in the running process but is there a way (not necessarily supported/stable/guaranteed to work) to create a file/key without ever invoking ntdll functions?
NTDLL is at the bottom of the user-mode hierarchy, some of its functions switch to kernel mode to perform their tasks. If you want to duplicate its code then I suppose there is nothing stopping you from decompiling NtCreateFile to figure out how it works. Keep in mind that on 32-bit Windows there are 3 different instructions used to enter kernel mode (depending on the CPU type), the exact way and where the transition code lives changes between versions and the system call ids change between versions (and even service packs). You can find a list of system call ids here.
I assume you are doing this to avoid people hooking your calls? Detecting your calls? Either way, I can't recommend that you try to do this. Having to test on a huge set of different Windows versions is unmanageable and your software might break on a simple Windows update at any point.
You could create a custom kernel driver that does the work for you but then you are on the hook for getting all the security correct. At least you would have documented functions to call in the kernel.
Technically, registry is stored in %WINDIR%\System32\config / %WINDIR%\SysWOW64\config, excepted your own user's registry which is stored in your own profile, in %USERPROFILE%\NTUSER.DAT.
And now, the problems...
You don't normally have even a read access to this folder, and this is true even from an elevated process. You'll need to change (and mess up a lot...) the permissions to simply read it.
Even for your own registry, you can't open the binary file - "Sharing violation"... So, for system/local machine registries... You can't in fact open ANY registry file for the current machine/session. You would need to shut down your Windows and mount its system drive in another machine/OS to be able to open - and maybe edit - registry files.
Real registry isn't a simple file like the .reg files. It's a database (you can look here for some elements on its structure). Even when having a full access to the binary files, it won't be fun to add something inside "from scratch", without any sotware support.
So, it's technically possible - after all, Windows does it, right? But I doubt that it can be done in a reasonable amount of time, and I simply can't see any benefit from doing that since, as you said, ntdll is ALWAYS present, loaded and available to be used.
If the purpose is to hack the current machine and/or bypass some lack of privileges, it's a hopeless approach, since you'll need even more privileges to do it - like being able to open your case and extract the system drive or being able to boot on another operating system on the same machine... If it's possible, then there is already tools to access the offline Windows, found on a well-known "Boot CD", so still no need to write in registry without any Windows support.
I'm trying to develop a dual purpose driver that performs certain tasks at boot time, and other unrelated tasks after Windows has already started. It's developed as a boot start driver. I understand that the proper way to do this may be to develop 2 separate drivers, but I'd prefer to only go through the WinQual process once. There's also the added benefit of performing only one driver install in my app versus two. It needs to work on Vista through Win8 x86 & 64.
So what I'm really looking for is a safe way to determine in DriverInit if the system is in the process of booting, or if it's already up and running. The driver will initially be utilized when Windows has already started, then enabled at boot time after the next reboot. The DriverInit code needs to be different for both scenarios.
Is there a registry key that is or is not present?
Can I determine if a user is logged-in in DriverInit?
Is there a call I can make that will determine if Windows is booting?
I'm not an expert at driver writing, so thanks in advance for any advice.
Technically, glagolig's answer is probably the correct way to solve this.
The solution for my particular issue was a little different. There are 2 mutually exclusive use cases were the driver is either needed as a SERVICE_DEMAND_START driver after Windows is up and running, or as a SERVICE_BOOT_START driver with boot time functionality. The situation never arises were I need the functionality of both cases at the same time in the same Windows session.
The driver is initially installed as a SERVICE_DEMAND_START driver (this is the one that is going to WinQual). It is then changed to SERVICE_BOOT_START in the registry on the new drive that will be booted. All the driver entry points (DriverEntry, AddDevice, etc) that are different for each use case read the 'Start' value in the driver's service registry key to determine how it needs to operate.
It hasn't passed yet, but I'm fairly certain that I can change the start type of the driver in the registry without affecting Window's digital signature enforcement.
At the time boot-start drivers are loaded Windows has not created any user-mode processes yet. Try to acquire a handle to some process that is supposed to be created later on during Windows startup. For example, smss.exe, csrss.exe or wininit.exe . (Processes with these names existed for many years, it is very unlikely that Microdoft abandons them in the future while still allowing existing kernel mode modules to run.) Use ZwOpenProcess with POBJECT_ATTRIBUTES pointing to one of those process' names. If the call fails you are at boot time.
Also you may study Windows startup described in "Windows Internals" by Russinovich and Solomon. Most likely you will get a number of other ideas.
I've answered a similar question elsewhere on SO. The short version is that what you're asking is not normal driver behavior, so no API exists to support this. You can add in heuristics to tell you this, but they'll remain heuristics.
You can use IoGetBootDiskInformation to check if you are loaded post or, during boot. It will return STATUS_TOO_LATE if this API is called post reboot.
Is there any bottleneck above the physical the cpu and HAL? Or are there multiple ways a process could start under Windows XP, Vista, or 7, that don't invovle CreateProcess at some point?
Given the comment on your question:
Building an Anti-Executable driver, just planning, wondering if controlling createprocess would be enough.
No it wouldn't be enough if security is your concern. There is NtCreateProcess below that one for example. And those aren't the only ones.
The best way provided by the system is a file system filter driver. In fact the WDK comes with samples that require only a moderate amount of change to do what you're asking. Since you asked about XP you can use a minifilter if you can get away with support for XP SP1 and later.
PsSetLoadImageNotifyRoutine and PsSetCreateProcessNotifyRoutine are unfortunately only notifications. So they don't allow to do anything about the event that they notify about. And you really shouldn't attempt to work around this.
In the old times I have seen some clever implementations using SSDT hooks on ZwCreateSection that would exchange the returned handle with one to an executable that shows an error message. Since the executable itself sees the original command line, it can then show a nice error message informing the user that the command has been banned for reasons xyz. However, with Vista and later and even on XP and 2003 64bit (x64), it's going to be harder to write the SSDT hooks. Not to mention that everyone would frown upon it, that it requires quite extensive experience to get it right (and even then it often has flaws that can cause havoc) and that you can forget any certifications you may be aspiring for in the Windows Logo process.
Conclusion: use a file system filter driver to deny access to unwanted executables. With a minifilter the learning curve will be moderate, with a legacy filter I'll recommend you take a few courses first and then start your first attempts.
Looking through a quick disassembly of CreateProcess, it appears that the two main things it does are:
Call NtCreateUserProcess (this is syscall 0xAA) to actually create the process structures in the kernel (PEB, etc.)
Start the new process with a call to NtResumeThread (syscall 0x4F).
The Windows Internals books certainly detail this process very well.
I'm not sure if there are designated hooks in the kernel which would allow you to create your anti-executable driver. It used to be that you could hook the "System Service Dispatch Table" to change how these system calls behaved. But now, technologies like PatchGuard prevent a driver from doing this (and allowing the system to run).
I've written a program with a manifest that includes requireAdministrator. On Windows 7 systems with UAC enabled, Windows pops up a dialog asking for permissions, as it should. Works great.
If a user starts my program by right-clicking it and choosing "Run as administrator", then Windows 7 also pops up a dialog asking for permissions. However, there are some slight differences in how my program operates in some of the more esoteric parts of my program.
So what are the differences between "Run as administrator" and a manifest with requireAdministrator? Any links to documentation that describe differences would be appreciated.
Edit: This is with UAC enabled.
Edit: As promised below is the full explanation of the difference I'm seeing.
I'm using the EasyHook library to inject a DLL into another process. When my application is run with "Run as administrator", the injected process crashes and EasyHook returns the error "Unknown error in injected assembler code". None of the code in my DLL gets a chance to execute; the crash occurs before then. (Moreover, the crash occurs even if I strip the DLL down to nothing)
If I run my program normally (i.e., elevated via requireAdministrator), everything works fine.
My application is composed of a few different executables. The process that the user launches is not the same process that performs the injection.
With the information given there would be no differences in the permissions between the two processes.
If you request an execution level of "requireAdministrator" via the applications manifest your application will either be launched with the full access token of an administrator or not at all if the user denies consent (see Create and Embed an Application Manifest (UAC) for further information).
The same will happen when a user chooses Run as Administrator.
The only difference is the way that the process is started. When you start an executable from the shell, e.g. by double-clicking in Explorer or by selecting Run as Administrator from the context menu, the shell will call ShellExecute to actually start process execution. The whole process of elevation is hidden inside this function. Kenny Kerr describes this process in more details in Windows Vista for Developers – Part 4 – User Account Control:
ShellExecute first calls CreateProcess to attempt to create the new process. CreateProcess does all the work of checking application compatibility settings, application manifests, runtime loaders, etc. If it determines that the application requires elevation but the calling process is not elevated then CreateProcess fails with ERROR_ELEVATION_REQUIRED. ShellExecute then calls the Application Information service to handle the elevation prompt and creation of the elevated process since the calling process obviously doesn’t have the necessary permissions to perform such a task. The Application Information service ultimately calls CreateProcessAsUser with an unrestricted administrator token.
If on the other hand you want to create an elevated process regardless of what application information is available then you can specify the little-known “runas” verb with ShellExecute. This has the effect of requesting elevation regardless of what an application’s manifest and compatibility information might prescribe. The runas verb is not actually new to Windows Vista. It was available on Windows XP and Windows 2003 and was often used to create a restricted token directly from the shell. This behavior has however changed. Here is a simple example:
::ShellExecute(0, // owner window
L"runas",
L"C:\\Windows\\Notepad.exe",
0, // params
0, // directory
SW_SHOWNORMAL);
So essentially starting an executable using the Run as Administrator option means that ShellExecute bypasses the checks for compatibility settings, application manifests etc and directly requests elevation.
Kenny Kerr's article also has sample code to query the current process' token for its permission using the OpenProcessToken function. Possibly you can use the example to identify that there are no differences in the way your process is elevated.
I'm definitely curious to know which differences you are observing as I strongly doubt they are related to elevation.
As a last thing: Can you double check that you really request a level of requireAdministrator and not by mistake only a level of highestAvailable?
One possible difference might be the rarely used/understood/deliberately-chosen uiAccess attribute. Can you create two manifests, one with uiAccess=false and one with uiAccess=true, then tell us whether one of them gives the same behaviour as you see with right-click-run-as-admin?
The EasyHook documentation for the RemoteHooking class' IsAdministrator property mentions:
Due to UAC on Windows Vista, this property in general will be false even if the user is in the builtin-admin group. As you can't hook without administrator privileges you should just set the UAC level of your application to requireAdministrator.
It's hard to imagine why this is happening, but it is conceivable (especially as you are seeing it happen!) that assets, processes, assemblies, &c, with possibly different trust levels and so forth, will not inherit the elevation of your main app. Setting the requireAdministrator flag may handle/enforce this globally across the entire scope of resources and dependencies. Would love to know how this turns out.
I thought I was seeing a difference between these as well. However, it turned out that in my case the issue was this:
When I click "Run as Administrator" from my file browser (Q-Dir), the working directory is different than when I try simply double clicking an application with requireAdministrator set in the manifest. This changed the behavior of some buggy DLLs I had received. In fact, it turned out that 100% of the differences I saw were due to running from different working directories (specifically, it mattered whether I was on C: drive or a different drive letter) and that the method of getting the program to run as administrator had nothing to do with it.
It's an issue that is specific to my computer's exact configuration, but it is a possible clue into the type of thing that might be happening (or might have happened 7 years ago . . . )
I need to monitor and, if it is needed, decline process start in the Windows XP and Vista OS?
What are known/documented/undocmented methods? What about known hacks of this methods?
(It will be used for the shareware firewall/security software).
Be very careful with any code that thinks it knows enough about what a user is doing to know whether or not to allow a process to start. It's a great way to find out how much you don't know about your users, but only if you provide an email address for the users to send complaints to.
An example was some VPN software I worked with that hooked into the Windows system to be notified whenever a DLL was loaded. It actually caused BSOD when running a very common application - Visual Studio. The manufacturer wasn't aware of how modular VS is, and that starting it loads many DLLs, and sometimes even more during execution, as new features are loaded.
When you put yourself in the position to do things for your users, you have the responsibility to know enough to do them correctly.
For monitoring you can use WMI events.
There is no[1] method to decide whether to allow the start or not. If you are on Pro/Biz/Ent/Ultimate editions group policy can be used to block specified executables from being launched, or limit to a specified list.
[1] As far as I am aware.