I am developing a kernel-mode driver and I 'd like it to be able to run on all Windows platforms (including Windows 10). I have read the driver signing policy in Win10 from http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver-signing-changes-in-windows-10.aspx. I don't know if I am understanding it right, does it mean that if I buy a non-EV cert before Win10 release (AKA 2015/7/29), I can still use the cert to sign a driver to any platform including Win10 until the cert expires. For example, I can just buy a 3-year long cert before 7/29 and use it to sign any drivers for these 3 years (the longest period for a cert seems to be 3 years). 3 years later, I have no other choice but to buy an EV cert, is this understanding right? Thanks.
You're basically asking if you can slip a driver that wasn't signed with Extended Validation ("EV") certificate through the door before Windows 10 release.
The salient point is this:
http://blogs.msdn.com/b/windows_hardware_certification/archive/2015/04/01/driver-signing-changes-in-windows-10.aspx
Beginning with the release of Windows 10, all new Windows 10 kernel
mode drivers must be submitted to and digitally signed by the Windows
Hardware Developer Center Dashboard portal. Windows 10 will not load
new kernel mode drivers which are not signed by the portal.
My guess is "maybe".
But you'd better hurry.
And you'd better have a Plan B if your Windows 10 customers discover that your driver won't work.
Related
This question already has answers here:
How can I stop my installer from triggering Windows 10's "This app has been blocked for your protection" error?
(2 answers)
Closed 3 years ago.
I am new to windows development. I packed my project into a msi setup to install on other systems but when I open the msi in any system it shows a warning as attached . How can I remove this warning?
Note: Be sure to check if your organization already has an EV-level certificate? Just a few emails or phone calls might be wise before trying to research the purchase process?
Trust & Reputation: What you really need is an EV code-signing certificate. Microsoft's SmartScreen feature
in Windows (which is what you see with that blue prompt) is a
reputation-based system where unknown binaries are flagged as unsafe until they are validated safe by users in actual use.
Virustotal.com: An EV code-signing certificate "buys trust outright" - interesting concept - and should allow your users to not see such a prompt even for brand new binaries. Make sure to check all your binaries using virustotal.com though, as many malware-scanner detections can trigger a resurged smartscreen warning for any binary - which is what it is for (signed malware is still malware).
False Positives: False positives for malware is a huge problem since you have to deal with it and solve it, and you can't just tell your users to rebuild their PC and try again.
Moral: The moral of the story is to use Virustotal.com to test for both malware and false positives in your binaries and files for distribution, and to use an EV-level certificate for serious software distribution to get trust for your binaries outright (without delay). An EV-level certificate is not a silver bullet. Problems can still be seen. Trust can be lost too, not just gained (trust... hard to earn, easy to lose).
Tip: A properly signed MSI will also show up with the correct name in the UAC prompt: Installshield Custom Dialogue Installer (see screen shot and then the answer a bit down the page).
The Far Side Perspective: "Be sure that your setup is malware free or an applied digital certificate is proof positive that you delivered the malware" (until that is hackable too) :-)
We do our best.
Link:
How to protect MSI against modification (on malware and false positives - recommended)
How to add publisher in Installshield 2018
How to pass the Windows Defender SmartScreen Protection?
I've written a C program in Windows that uses some precompiled files from WinDivert. My program uses a .dll from WinDivert and some of the functions in the .dll install the WinDivert.sys driver. There are also a few more files from WinDivert that are a part of this (a .lib, a .inf, and another .dll).
The problem is that on one of my computers (Windows 8.1 64 bit), everything works perfectly. But, when I try to use the program on my laptop (Windows 8.1 64), my friend's laptop (Windows 7 64), or another Windows 7 64 desktop, something blocks the installation of the driver. I'm unsure what is blocking it or how to stop it from being blocked because on all computers:
+I'm running on an admin profile
+Running the program in admin command prompt
+Tried disabling firewall, anti virus, etc (although it runs fine with these on for the computer that works)
+As far as I can tell, all my security settings are the same
+Note: the driver does have a valid signature.
Why does the driver install perfectly on one computer, but not on the other three? What could be issue?
The main causes for 1275 errors are documented on the WinDivert FAQ. However, there may be other causes that I'm unaware of (perhaps some experts out there can help?)
Another thing to try is the following commands:
sc stop WinDivert1.1
sc delete WinDivert1.1
I have a big problem.
I wrote an app for Windows Phone 7.1+, and it's also published on Windows Phone Store:
this app works well for Windows Phone 7.1 and also for Windows Phone 8, and there were no problems during app submission process (who also declares that my app is fully compatible with any OS since Windows Phone 7.5).
The problem is related only to my Scheduled Agent, which runs perfectly on Windows Phone Mango (7.1), but it is not firing at all on Windows Phone 8 (I've also tested my app on real devices, with both the OS').
When I upgraded to Visual Studio 2012 (Express for Windows Phone), I've noticed that it is possibile to add two different types of ScheduledTaskAgent project: one for Windows Phone 7.5 and one for Windows Phone 8 (obviously it wasn't so in Visual Studio 2010...and I used the only one available = the first) !
Dou you think this can be the reason while the scheduled agent is not working in WP8?
What's the difference between the two projects types?
How to manage (in code I mean) two projects of that type? Is it possible?
How can I choose which task I have to register (see code below)?
Will the submission process fail with two ScheduledTaskAgent projects (I think so)?
This is the critical part of the code, when I'm registering my task at startup:
PeriodicTask newTask = new PeriodicTask("MyTaskID");
newTask.Description = "my Description";
ScheduledActionService.Add(newTask);
#if DEBUG
Microsoft.Phone.Scheduler.ScheduledActionService.LaunchForTest("MyTaskID", TimeSpan.FromSeconds(5));
#endif
Thank you in advance.
The only difference between the two project types is (1) the Windows Phone 8 one targets Windows Phone 8 instead of 7.1 and (2) it references the Windows Phone 8 SDK instead of the Windows Phone 7 dlls.
I have an application where I have two projects (7.1 and 8.0). I also have two background agent projects (7.1 and 8.0) and I share code between them using linked files. I reference the 8.0 agent from the 8.0 project and the 7.1 agent from the 7.1 project. I used this example as a best practice for having the two versions of code.
You do not want to reference two agents since that will not work.
If you remove the #if DEBUG does your agent get called when you're debugging?
First make sure you got the proper reference in app manifest file.
<ExtendedTask Name="BackgroundTask">
<BackgroundServiceAgent Specifier="ScheduledTaskAgent" Name="MyApp.Agent" Source="MyApp.Agent" Type="MyApp.Agent.ScheduledAgent" />
</ExtendedTask>
Second the Agent library must be referenced in the main app project.
Third, make sure you are not exceeding the allowed running time or memory allocation. In WP8 the cap for background agent was raised to 11MB. Also there is a limit of app with registered background tasks, so it might be possible that there was no free slot for your task with bg agent.
How do I determine the Remote Desktop Protocol version supported by a particular client?
Note that I am NOT asking for the ActiveX control version but the underlying protocol version. As examples from two machines I checked using Help->About (or just About in the case of Windows XP):
On Windows 8, I do NOT want 6.2.9200, I want 8.0.
On Windows XP, I do NOT want 6.0.6001, I want 6.1.
And I am not asking for the protocol version in use in a given session (which is what Determine Remote Desktop Protocol version programatically? is referring to) because we're not in a session, we are validating a client's configuration.
Thanks!
I eventually contact Microsoft about this question and the (somewhat amazing) answer I got back is as follows:
That string is hard-coded and not retrieved from the server or AX (in
fact mstsc.exe checks the build number of mstsax.dll before loading it
to make sure it is consistent with its own build number).
So I guess I will need to fall back on hard-coded OS version information - perhaps the mstsc.exe version. That's yucky but I don't see what choice I have.
I have a Program.exe that I need to intercept. That specific program uses CreateFile & ReadFile, however I need to intercept ReadFile function.
I thought about writing my own File System Filter MiniDriver.
I found this link by Googling: http://msdn.microsoft.com/en-us/library/ff551862(v=vs.85)
It seems that is the correct way to do this. However last time I did any driver development, I remember that >= VISTA did not allow drivers to be installed easily. You needed to acquire "Signed" priviledge from Microsoft(you had to pay).
My question is that, can I create Simple File System Filter Driver for my USB stick and intercept any readings from ReadFile()? All I want to do is to allow ReadFile by a specific process.
1) I need this legally
2) I need to avoid unsigned drivers, so the driver would always work.
Will one minifilter driver work for every OS starting from XP?!
Prohibit of loading unsigned drivers is exist only on x64 versions of windows >= vista
On x64 versions you can
1) Switch to test mode to turm off this restriction
2) Add test sertificate as root to certificate storage
But if you want distribute this driver you must bay certificate.
Yes, minifilter is the preferred way for this. You can intercept system calls/IRPs and allow-deny any of them depending upon your criteria.
Also, same driver code can be used for multiple OSes, however you need to build for specific Os.
WDK 7 can be used to build drivers from XP to Windows 7.
Also, as izlesa suggested, you need to sign for x64 windows higher than vista.