interception_create_context detects no devices

[ZimM-LostPolygon]

interception_create_context behaves incorrectly for some reason. To be exact, line 59

device_array[i].handle = CreateFile(device_name, GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL);

always returns INVALID_HANDLE_VALUE, so no devices are detected. I've installed the Interception driver. Windows 10 x64. Also tried on Windows 8 x64 virtual machine, no luck as well.

Am I missing something obvious?

[oblitum]

Am I missing something obvious?

Yes, quite probably. Your error is generally a sign that the drivers were not correctly installed or you have not reboot the machine.

The installer displays a message in the console when it's able to correctly install the drivers. If you didn't see it then there was no installation.

[ZimM-LostPolygon]

The installer displays a message in the console when it's able to correctly install the drivers. If you didn't see it then there was no installation.

First time I've tried to install the driver, the installer has printed a message about driver being successfully installed and that a reboot is required. After rebooting, still no devices are detected. If I try to install the drivers now, I get

h:\Download\Interception\Interception\command line installer>install-interception.exe /install

Interception command line installation tool
Copyright (C) 2008-2014 Francisco Lopes da Silva

Could not write to \system32\drivers

Attempting to uninstall the driver fails as well:

h:\Download\Interception\Interception\command line installer>install-interception.exe /uninstall

Interception command line installation tool
Copyright (C) 2008-2014 Francisco Lopes da Silva

Error deleting \system32\drivers\keyboard.sys

This is on Windows 10 x64. I don't have any antivirus or any similar software (except the built-in Windows Defender, but it doesn't throws any alarms, and disabling it didn't helped either), and I am definitely running an administrator console. mouse.sys and keyboard.sys files are present in "c:\Windows\System32\drivers\", so I guess the initial installation went fine?.. Not sure if there is any way to check if they are actually loaded.

On Windows 8.1 x64 virtual machine, installing and uninstalling works as expected (judging by the installer messages), but even after multiple reboots, interception_create_context detects no devices.

[oblitum]

Are you always using an administrator command prompt to install and uninstall? Simply launching cmd will not work, it must be executed as administrator.

[oblitum]

You said you are definitely using an administrator prompt. I just want to confirm it's always. I'm sorry but such basic issues is not common, not sure what's happening on your side.

[oblitum]

driverquery.exe is a tool that will list installed drivers.

[oblitum]

Also, just recalled, sometimes, I guess if I recall correctly, the installer may fail removing/changing files because you have some explorer window open at the driver's folder and it locks the file somehow. This is generally fixed by rebooting and just after login, launching the command prompt to call the installation tool, avoiding navigating and opening the driver files through explorer.

[ZimM-LostPolygon]

Yes, I know that it must be launched as administrator. I'm sure I'm running the administrator console:

In any case, on Windows 8.1 x64 virtual machine, install/uninstall works fine, but the sample isn't working. Which is quite strange, I agree.

I've just tested on a physical Windows 8.1 x64 machine, the installation went fine, but the sample I've compiled still won't run.

driverquery.exe lists these drivers on all 3 test systems

keyboard     Keyboard Upper Filter  Kernel        16.02.2012 0:40:16    
mouse        Mouse Upper Filter Dri Kernel        16.02.2012 0:40:56 

I guess this means that the driver install was indeed successful?

[ZimM-LostPolygon]

I've restarted my Win10 machine and immediately started the (re)installation, and this time it was successful again, so thank you for this suggestion. However, after reboot, nothing has changed.

I've did some debugging, and GetLastError() after the CreateFile in interception_create_context returns "The system cannot find the file specified.", which kind of suggests that the driver isn't actually loaded, but at this point I don't know what else I can try. Though I'd be happy to help with any debugging, if that would be required.

[ZimM-LostPolygon]

Screenshots from DeviceTree, showing that the driver actually seems to be loaded:

Still, the sample doesn't works.

[oblitum]

It's difficult to realize what's the issue... since the devices have been actually created by the driver, which shows it's alive, and the devices are there to be open...

[oblitum]

After you have now verified the drivers are loaded. Have you tried to link against the already compiled libraries that are provided instead of the ones you're compiling yourself? This is just in case to avoid any possible mistakes regarding your compilation configuration, like use of Windows wide character API and what not.

[ZimM-LostPolygon]

I've tried linking against the .dll and .lib files, but failed with "unresolved external symbol" errors similarly to this issue: https://github.com/oblitum/Interception/issues/14 What version of Visual Studio did you used to compile those? Compatibility of .lib files between different versions of CRT is not guaranteed: http://stackoverflow.com/questions/8439595/are-compiled-lib-files-interchangeable-for-different-versions-of-microsoft-visu I am using Visual Studio Update 3, so if the .lib was produced by an earlier version, then it might not work.

Perhaps, if possible, you might build any of the samples against those libraries and upload it here? Just so we can verify that this is indeed a problem with the compiler configuration.

[ZimM-LostPolygon]

OK, so after trying some more to link against the compiled libraries, I've succeeded, and it actually works! Now to find out what's causing the library to build incorrectly..

[oblitum]

Regarding your first concern, I've produced binaries using the WDK. The WDK tries to be compatible as much as possible, even using some unknown tricks, to maintain compatibility. As you have checked, this is not the culprit.

You should check whether you're compiling the library correctly, defining expected flags in static compilations if needed, and check usage of chars vs wide chars by default in your build.

[ZimM-LostPolygon]

Yeap, that was it. I think this is an error in the library, though.

char device_name[] = "\\\\.\\interception00";
...
device_array[i].handle = CreateFile(device_name, GENERIC_READ, 0, NULL, OPEN_EXISTING, 0, NULL);

device_name is char[], and char is always 1 byte, but CreateFile is a macro that is substituted by CreateFileW or CreateFileA depending on configuration. In this case, this resulted into trying to put a 1-byte string into CreateFileW. The easy fix is to just replace CreateFile with CreateFileA. After making this one-symbol change, the library I've built on my own worked great.

Thank you!

[oblitum]

Yeap, that was exactly what I suspected, in truth after demonstrating the devices were being created, the only option left was name mismatch. Sorry about that, it's a known issue for some time but I didn't got the time to review the header implementation to fix that.

[oblitum]

I didn't review it about whether there are other API calls in other places that would need the same fix, so, better just use it as provided and use a char build configuration, not wide char.

[oblitum]

Or review all of the implementation making sure no Windows API call is left without being specific.

[filippobottega]

Hello, I have the same issue with install-interception.exe (Last change date: 25/07/2015 18:50) on Windows 10. In Administrative CMD:

1. install-interception.exe /install OK
2. Reboot OK (Driver works well)
3. install-interception.exe /uninstall FAIL with Error deleting \system32\drivers\keyboard.sys
4. Reboot OK
5. install-interception.exe /uninstall OK

6. Reboot OK (Driver is uninstalled)

   Do you have a new version that solves this issue?

   Thank you, Filippo Bottega.

[oblitum]

@filippobottega Hi. No I don't have a new version because I was unable to reproduce this consistently, it has rarely happened to me and has been generally an issue with the way Windows somehow lock files out of a sudden. This happened long time ago when I was with the system drivers folder open on Explorer while executing the installer and have avoided it by rebooting so that any Windows locks over the driver files get closed so that the installer can operate correctly. Files that, for any reason are locked by Windows, AV software, etc, can't really be removed gracefully and my best bet is that is what can happen for some people, hence it's resolved by rebooting, because system locks are cleared up.

[ZimM-LostPolygon]

@oblitum What about the API charset issue when building from source?

[oblitum]

@ZimM-LostPolygon this is going to be fixed shortly as I'm preparing a release to address these minor issues (notice that this is easily avoidable using the correct charset while building, as advised).

[filippobottega]

@oblitum Hi, thank you for your explanation and for your support. If can help, I have tested the installer on Windows 10 Enterprise edition 64 bit. The test fails on my machine and on a clear installation on a virtual machine. I have found that keyboard.sys is loaded by System process (PID:4). I think that is not possible to solve this issue. I think your solution is the best but I suggest you to add an error message to inform the user that a reboot is required and, if needed, that a new run of the installer is needed. Please don't change the exit codes of install-interception.exe because they are correct.

Best regards, Filippo Bottega.

[oblitum]

Just updated the last release with an installer that just corrects the issue with /uninstall.

@filippobottega if you're interested in getting the installer DLLs with the fix as well, feel free to mail me.