Anyone has any experience with application deployment through Mac App Store with 3rd party drivers? I have an application that is used to manage external device through usb port. It requires some drivers to be installed within. Any ideas how to deploy such application with Mac App Store so I don't have to bother user with any confusing messages about drivers? Is there any way to deploy such driver? Is there any way to load drivers only in userspace (sandbox?)
It's a virtual com port driver.
As far as I'm aware, you can use the user space I/O Kit framework from Mac App Store apps. So if your device can be driven entirely via that, go ahead. USB devices are usually good candidates for user space drivers, but it heavily depends on how the device will be used. If only your app is going to be accessing the device, you stand a very good chance. If you're intending to make it available to multiple applications, e.g. by creating a /dev node, you'll need to drop to the kernel.
You can't ship kernel extensions (kexts) with apps via the Mac App Store.
I don't know what the status is regarding MAS apps which require a specific device and kext to work, without shipping the kext together with the app. If the kext is optional, I suspect they'll allow it.
Related
I am developing a Win10 C# application dependent on a third party library, which enables me to control a USB3 device.
By trial and error, I found that I needed to run FTD3XXDriver_WHQLCertified_v1.3.0.4_Installer.exe, which in the end populated the SysWOW64 with FTD3XX.dll and System32\Drivers with FTDIBUS3.sys and the ancillary files and folder.
I would like to run my application from a USB thumb drive on different PC's in my organization without installing any of the drivers. Is there a way to do that?
Bad news: To the best of my knowledge you cannot address an FTDI device if the driver is not installed.
But windows normally install the driver automatically via the windows updater. At least, this is the case for the USB 2 devices of FTDI i.e. 232 family. I do not have a FT60X here to test if the windows updater has a driver ready for this as well.
If the driver is installed via the updater you have to bundle the FTD3XX.DLL with your application as it is not part of the "windows standard" driver. At least this was the case for the FTD2XX.DLL.
Long story short: connect your device to a computer without preinstalled driver. Check if the driver is installed via the windows updater. If this is the case, you mostlikely just need to bundle the FTD3XX.DLL with you application.
I am planning to write driver for USB or Bluetooth multi-touch device similar to Apple Magic Trackpad or Logitech trackpad for Mac.
The idea is that all macOS applications can use this multi-touch device. As the newly introduced DriverKit (or HIDDriverKit) is to be bundled with apps, should I still use IOKit or should I use DriverKit?
Thanks.
DriverKit is built around IOKit - it's just yet another interface to it. So I guess your question really is whether your driver should be implemented as:
A DriverKit System Extension (dext)
A kernel extension (kext)
Something else
You won't escape IOKit either way, because USB devices are only accessible via IOKit, and the HID stack is built on it too.
Bluetooth
As far as I'm aware, there aren't Bluetooth APIs for use with DriverKit, at least not yet. (As of macOS 10.15.4)
So if your device uses a custom Bluetooth protocol which needs to be turned into a HID event source from scratch, then I don't think you'll be able to use DriverKit, at least not exclusively.
If your device already appears to the system as a HID device but your driver needs to rewrite HID reports, then I think it might be possible to implement using DriverKit - at the very least it's worth researching.
Implementing it as a kext will definitely work for all cases, the trouble is any new kexts will have a very limited shelf life at this stage.
USB
For USB, it's more straightforward, there are direct DriverKit USB APIs. USB HID drivers are one of the well-supported scenarios by DriverKit. So you should definitely not use a kext to implement a USB HID driver targeting macOS 10.15+ at this point. In fact, if you did develop a USB HID kext, your users would periodically be presented with an awful warning popup.
"Something Else?"
That brings us to the "something else" category: you may be able to write the driver (almost) entirely in regular user space as a daemon using user space bluetooth and USB APIs, and then inject the HID events produced back into the system. The best way to do this might end up being via a DriverKit driver - so you'd have a user space daemon performing most of the driver logic, and a small DriverKit driver creating a "virtual" HID device which just ferries the events produced by the daemon into the HID stack. If you need to support older OS versions, the responsibility of the dext in this approach could be taken by a kext, with the daemon needing virtually no customisation to run on all OS versions.
If your driver will be doing a lot of complicated processing on the raw input data, this might be the way forward, as implementing such logic in a dext or kext isn't ideal.
To say which approach is best I'd really need to know a lot more about the device (and that might exceed the scope of a Stack Overflow question…).
I'm trying to understand if (and if so, how) it's possible to dedicate a HID (USB-card reader for NFC cards) to a specific application in macOS.
The card reader acts as a keyboard, sending the number of the card to whatever is open in macOS. I'm trying to get that USB-device locked to a specific application (e.g. firefox, chrome etc).
I really have no idea where to start looking for this. Hence I'm posting here for any help in the right direction.
Googling "Dedicate USB device to app" etc gave nothing useful.
macOS version 10.14.5 (18F132) (Mojave).
The way applications communicate to USB devices is IOKit framework. You could write it as service if you want to lock applications anywhere. And you need to know about launchd (Launch Daemon). It manages all your background service.
I'm very new to windows driver development.
I've written a KMDF windows driver and I'm able to test deploy it to my target machine using VS deploy. It worked fine and now I'd like to ship this driver with the application that uses this driver.
Here the problem comes... I couldn't find anything on Google that telling us how to distribute a KMDF driver(like making an installer). This driver is an upper class filter driver and it is only needed for my application so it should not be published to windows update.
My question is how to make something like an installer to distribute this driver? Thanks for any suggestion or tutorial.
EDIT 1
It is a fake device driver(meaning there is no physical device to drive)
Usually, device drivers for software won't be pushed out through Windows Update. There's exceptions for vendors like Intel, AMD, NVIDIA, but that is because of what those companies are and how popular/well-used they are (they will be working with Microsoft for such). You can't just have your driver pushed out via Windows Update.
You're going to need a digital signature to sign your kernel-mode software with as long as you're going to be distributing it onto machines using modern versions of Windows x64 (for the record, even Windows Vista x64 will enforce this requirement). This requirement will not be present on x86 versions of Windows as-of right now, but in all truth, it would be unethical to not sign your kernel-mode software anyway.
Starting on Windows 10 on a specific patch which was released really early-on, the requirement changed from having a normal digital signature which could work for signing kernel-mode binaries to it having to be an EV digital signature; to get your hands on an EV digital signature for kernel-mode software signing, you will undoubtedly need to be legally registered as a company (and likely require a company bank account as well).
See the following for more information about this.
https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/04/01/driver-signing-changes-in-windows-10/
Here's the twist though... For systems which are using Secure Boot (new modern systems tend to have it enabled by default now, it is a security feature), you will need to have your kernel-mode software co-signed by Microsoft themselves. This will require you to share your kernel-mode software with Microsoft by uploading it via an online portal, but you'll still need your EV digital signature before you can move to that stage.
See the following for more information regarding the Microsoft co-signing requirement (depending on the environment):
https://www.osr.com/blog/2017/07/06/attestation-signing-mystery/
Note: Please do not try to come up with ideas to circumvent this (e.g. enabling Test Mode on a clients system and then using a Test certificate for your driver, or disabling Secure Boot on a system which relies on it... such work-arounds come with a huge price of reducing the security on the system, and should never be applied as a solution to this problem in the real-world).
For actually installing the device driver, you could programmatically use the .INF file with the Win32 API and then use the StartService routine to start the service post-installation with the .INF. Also see: https://msdn.microsoft.com/en-us/library/aa376957%28v=vs.85%29.aspx
Alternatively, you can register the service yourself with the CreateService routine and then start it with the StartService routine (or reboot and have it load on start-up depending on the flags for the service creation).
Bear in mind, sometimes using the Service Manager, you'll miss important things in registration for some driver types (e.g. Filesystem Minifilter), and you'd need to handle this manually otherwise it won't work. Check the .INF and make sure anything that needs to be done as an requirement is done when you use the Service Manager for installation (if you decide not to rely on the .INF).
Hope this helps you get to where you need to be.
I have a crypto USB device which is used to store PKI certificates including the private key.
It can be read/written to using the Microsoft Crypto APIs. And it is protected by a PIN. I am investigating if the device is in fact secure.
In my opinion, the security of the device hinges on how the PIN is used/stored. This is related to a different question I posted on crypto.stackexchange - https://crypto.stackexchange.com/questions/5929/crypto-usb-devices-where-is-the-pin-password-stored
When I insert the device into my USB slot, it presents itself as a CD drive containing a setup program which installs the driver/CSP middleware/UI for the device. After the setup program is run and I store certificates in the device, I still see only the setup program in Windows Explorer when I look at the drive assigned for the device.
So in order to prove that the device is secure or not secure, I want to access the raw data on the device. And I want to know what APIs on Windows, I can use to access the device bypassing the Crypto APIs.
Alternately are there tools to do the same?
One idea would be to boot into a Linux Live CD and view the drive contents that way. You could, for example, try one of the latest Ubuntu builds, all of which can be run from the CD without installing the operating system onto your Windows machine.
My theory is that when your device is accessed from Linux, the raw data will be available. When it is accessed from Windows, I suspect some kind of clever AutoPlay comes into effect in order to present your device as a CD drive.