libimobiledevice
Not possible to use on ARM64 Windows
As far as I understand on Windows this uses AppleMobileDeviceSupport, of which no arm64 build exists, making it impossible to use there. Would be nice to state that in the README, and maybe eventually offer the libusb backend for Windows too? Sorry if I'm wrong about any of this.
yes, Apple didn't release driver for arm based windows, so even if you connect device, it will not be avalaible under itunes, afaik it only works as WPD/mtp for photo access, but that's about it.
considering, arm based windows are available for more than 5 years already, it's quite shame, but apple never bothered to support arm based windows.
just sidenote, first arm based windows, were actually windows RT (those were running on microsoft surface RT powered by nvidia tegra CPU), but first "real" arm based windows computer was 1st gen of surface X with snapdragon SQ1 running Windows 10 Arm edition in 2019.
as long, as apple doens't make proper build for arm (only binary available is for x86/64, that runs in emulation on arm), then it will not work.
I don't see an immediate reason it wouldn't work if we use the libusb backend on windows. but in the meantime, mentioning it in the README (here and in the other repos) would save frustration to some
for windows you need driver, and there is none. as long as apple does not release drivers for their devices under arm, then nothing we can do, libusb will not communicate with device on windows without driver intalled either.
when itunes start working properly on ARM64 windows, and you will be able to access your device from it (eg. sync music/videos), then libimobile will work with it too.
last time i checkd, itunes on Surface Pro X didn't see my iphone, i was not even able to read photos from it, because without apple service running, trust between computer and device cannot be established.
Looks like libusbk has support for ARM64: https://github.com/mcuee/libusbk/pull/52
yes but there are 2 caveats,
-
you need properly signed driver, otherwise it will not load under 64bit windows, tht means you need codesign certificate ... or you can put your windows into driver testing mode and testsign your driver, there are articles how testsigning works, but it's not something that regular user will do.
-
you will need to implement usbmuxd to be fully functional on arm windows, since you will not have apple mobile service. (for this, i have not really tested usbmuxd under windows, i always use apple service, so no idea if it's not done already).
I can make usbmuxd compile under Windows against libusb. Only issue is the driver problem as mentioned.
if you don't have windows codesign certificate to sign compiled driver, then this is the thing i mentioned https://learn.microsoft.com/en-us/windows-hardware/drivers/install/test-signing
we did that in past for windows phones, since we are not manufacturer, we can't submit driver for WHQL validation, so we selfsigned driver that was based on winusb.sys from wdk.
I am not by any means a Windows user, but yes when I mentioned libusb I meant using it with WinUSB. My understanding is that WinUSB is signed by Microsoft already, and as a user you just need to associate it to your USB device using Device Manager. A custom .inf (which would require WHQL or test-signing) is only required if you want to avoid that step, i.e. have your driver automatically bind the USB function(s). I guess I'm mistaken?
yes, it's more complicated, driver package on windows consist from
- inf file (which contains description of driver, list of files that driver uses, identifiers of devices that it can handle, in past you could make driver for whole device class, but microsoft removed that option, because it was misused by malicious drivers),
- optional binary driver files (if those are already part of windows distribution, like winusb.sys, serial,sys, and so on, you don't need to bundle them), all of these needs to be digitaly signed
- signed catalog file, that contains hashes of all driver binaries, hash of inf file, and is digitaly signed by driver maker, and crossigned by microsoft certification lab (WHQL signature)
in driver testing mode you can also load drivers, that are not crossigned by microsft, and are only selfsigned by certificate you created by yourself, you need to add your selsigned certificate to machine storage as trusted certificate
also mind, when you are communicating with device, that is only exposed by WinUSB interface or libusb interface, you need to implement communication at usb protocol level.
as for libusb, while there were some attempts to port and adopt winusb, i don't know about any stable working fork, libusb uses USBDK and libusbk (which is linked here), uses libusb.sys which is kmdf based IOCTL driver, that is not compatible with winusb, it's different driver, different API.
32bit window didn't have much restriction regarding loading usigned kernel mode drivers, but loading driver on 64bit has requirements that must be met.
yes, it's more complicated, driver package on windows consist from
I understand, but Windows ships with a Winusb.inf that declares the Winusb.sys driver/service, and it will even load it automatically if the USB device implements a certain OS descriptor. And if you don't control the USB device descriptors, Microsoft also says you can manually associate your device to the driver (the link I posted above). This is so that you don't have to sign your own INF. So my question is, why won't that work here? Is it because the device falls under a class that isn't USBDevice, or?
also mind, when you are communicating with device, that is only exposed by WinUSB interface or libusb interface, you need to implement communication at usb protocol level.
I think me and @nikias are well aware of this, don't worry :) I occasionally work on libusb bindings and libraries using libusb.
as for libusb, while there were some attempts to port and adopt winusb, i don't know about any stable working fork, libusb uses USBDK and libusbk (which is linked here), uses libusb.sys which is kmdf based IOCTL driver, that is not compatible with winusb, it's different driver, different API.
libusb's official wiki recommends using it with WinUSB: https://github.com/libusb/libusb/wiki/Windows#user-content-How_to_use_libusb_on_Windows. the other backends are only recommended if WinUSB cannot be used for some reason.
Just had a look at Zadig, the GUI tool recommended by libusb to install the driver, and to my (pleasant) surprise it claims to work on ARM64 too :) This tool can supposedly create the .inf and binary catalog, sign it with a certificate created on the fly, and install it into the OS. If we want to provide an even more seamless experience, we can call libwdi directly. But I haven't yet tested any of this since I don't have Windows.
Guys, maybe you can take a look at the application: TikTok Live Studio, which uses Zadig to install a libusb-win32 driver for iPhone devices, and implements its own usbmuxd to communicate with iPhones on Windows!
I think me and @nikias are well aware of this, don't worry :) I occasionally work on libusb bindings and libraries using libusb.
as for libusb, while there were some attempts to port and adopt winusb, i don't know about any stable working fork, libusb uses USBDK and libusbk (which is linked here), uses libusb.sys which is kmdf based IOCTL driver, that is not compatible with winusb, it's different driver, different API.
libusb's official wiki recommends using it with WinUSB: https://github.com/libusb/libusb/wiki/Windows#user-content-How_to_use_libusb_on_Windows. the other backends are only recommended if WinUSB cannot be used for some reason.
i see they made lot of progress, when comes to winusb, which is great, but when you scroll to list of know limitations, there might be issues when it comes to usbmuxd. probly main limitation is absence of reset and inabilitity to alter interface configuration.
still definetly worth a shot, including zadig, as tool for autoinstalling/configuring driver.
ah good point, I don't think usbmuxd is ever resetting devices but not being able to set configurations is a huge PITA, hopefully doesn't affect us here..
I posted a patch for Windows here, but it doesn't run yet because of Windows-specific things regarding libusb: https://github.com/libimobiledevice/usbmuxd/issues/263#issuecomment-3361165546
did you use Zadig to load the driver? does it show up as using WinUSB.sys in device manager? I skimmed the documentation a while ago and from my understanding libusb should be able to find the driver without having the interface UUID, so unsure what's going on there. if I get access to a windows machine I'll try to test
@nikias Which commit is the patch based on? I'm getting some compile errors based on some Apple code in utils.c. I can fix those errors but since the fix wasn't in the patch, I'm assuming that I'm working from a different source. Working off the same foundation will make it easier to problem solve and share any potential fixes.
@NumberOneGit latest master but let me check again in my VM if I missed something