-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iOS 7 Compatibility / Trust Dialog handling #20
Comments
Thanks, we already have this done in the "trustdialog" branch which adds iOS 7 compatibility. In addition to what you describe there is also logic which starts an untrusted notification proxy service and listens for a "com.apple.mobile.lockdown.request_pair" notification expecting the host to initiate a pairing. However, the last problem we are facing is that the trust dialog appears to be triggered by more than just the pairing step over the usbmux connection and reappears again despite us having paired fine already. Apparently, especially on Linux, other "processes" (like talking to the PTP interface) appear to trigger a new trust dialog repeatingly despite an already trusted pairing exists and all libimobiledevice tools working fine while the dialog shows. This behavior does not exist on OS X where the trust dialog does not reappear once the pairing is done. If you have any details to add that would help fixing that... Btw. I hope any of your "other project" changes to this library are public, still? |
Hello, Also i didn't know, you managed to do the pairing (also ifnormation regarding com.apple.mobile.lockdown.request_pair), just wanted to share piece of information, since i got some usefull info from this project ..... regarding this "dual" trust dialog. on windows this is done by apple driver. Please note, that there are 2 apple services related to mobile devices
following is my observation of apple device behaviour - initial state - apple mobile service disabled, ipod service stopped
Our project can connect to device either in step 1, or step 3 I'm not sure, if this info will be usefull to you, but i hope so. When watching USB communication with apple device, i noticed following. So to resolve your problem on linux. I think, the order of pair and validate requests matters, if you will be succesfull to pair with device, then send your validate requrest, prior MTP driver hits the device, there will be no secondary truship request. i have no idea, how to it on linux tho', unless mtp driver is proxied by usbmuxd. |
Hello, i've just checked your code in trustdialog branch, and i must say, it's much more refined than mine, which is mostly based on watching usb communication, and also itunes. also i wonder where you got information about "untrustedbuid", this string cannot be found in my itunes communication capture. |
Thanks for the information, it boils down to what we already concluded as well. Thus the "non usbmux" connections are the cause to trigger a new trust dialog if the host was unable to "validate" it's trust status to the device upfront. The UntrustedSystemBUID is visible in USB dumps. I think we'll be able to come up with a solution now. Asides, we use the whole libimobiledevice stack on Win32/64, OS X, Linux (and Raspberry Pi, iOS, ...) already for a quite a while perfectly fine so you might want to have a look into using it in your project instead of having to replicating code and increasing maintenance work on both ends. :) |
Unfortunately project is closed source, that's why i must to not use GPL solutions. That was also one of reasons, why we did not use libimobile in start (gnutls is also gpl) and made own implementation using openssl, also it's little easier on windows, since we can directly connect to provided endpoints, without need of usbmux. Did your capture come from communication with OSX iTunes? my capture was from different versions of itunes on Windows 7 as well as Windows 8, and there was no UntrustedSystemBUID - for capture we use hardware monitor from TotalPhase (and i'm quite happy with it ;o) Also good to know, that libimobile works on Pi, i planed to do something on it in future. |
Not captured Windows yet, only OS X and Linux. |
OK, that might change situation - although most likely noone will want now to change project code. Still i remember, at time, when we started project and transition from using apple itunes DLL functions, to direct communication with apple devices, GnuTLS was under GPLv2, while OpenSSL had been useable in cs projects. I might upload capture from windows iTunes to paste.bin or elsewhere, if you are interested. You will need software to view it, but it's free for download and available for win,linux and osx. Regarding that UntrustedSystemBUID, i have not tested it yet, but has it any "visible" effect on device? What i mean is something similar to Android debug channel access authorization (android os 4.2.3 and higher), when device display RSA fingerprint upon confirmation see http://oi44.tinypic.com/33y3tvo.jpg , or is it just used internally? |
How could you capture anything on Windows when there is no updated iTunes release available yet? |
iOS7 beta 6 developer preview was working with itunes 11.0.5, version beta 3/4 was working even with 11.0.1 Currently with latest release pairing seems to be working properly, although itunes are complaining, that you need version 11.1 to synchronize iPhone with computer (which is not released yet for windows) i have implemented UntrustedSystemBUID, just in case. in manner you use it in libimobile. Still have no idea what it does tho (since windows itunes doesn't use it, maybe when 11.1 comes out, we will see). I will most likely need to ask our ios developer to bring his mac in office, so we can check osX itunes communication, if windows version is not released soon. |
i forgot to mention 1 thing, in my first post i stated you can read DeviceUniqueID without pairing, after many tests, we came to conclusion, this is only working for iPhone, on iPad and iPod Touch you get error GetProhibited, at least with ios 5 and 6. |
Reading the UDID from the device directly is not allowed without being in trusted state (having started a session or done a validate pair). However, as you say, the USB serial will still be available... I think we have succeeded now with proper iOS 7 compatibility support for libimobiledevice, just need some cleanup and a proper release. Will update the ticket accordingly. |
I have test trustdialog branch on my OS. I plug IOS7 iphone after run usbmuxd & .Iphone show me "Trust This Computer "dialog .I clik it ,but it show me again after a while.So I ignore this dialog,then run idevicepair pair , console show "ERROR: Pairing with device 956b4a506543901924bfa229297c8baa300113bf failed with unhandled error code -20" . |
I have complete this branch test.execute these steps to activate tethering. User must reopen "Personal Hospot" to Let the iphone pops tethering enable dialog if it is on Originally. log: idevicepair pairERROR: Pairing with device 956b4a506543901924bfa229297c8baa300113bf failed with unhandled error code -20 |
Merged trustdialog branch to master, still the usbmuxd/split HEAD branch is required but will soon be merged to master, too. |
Just wanted to mention here that I have opened the following bug report: |
imo change that will be required is same, that will be needed for ptp driver. as i stated in my post regarding iOS7 compatibility which (problem on which martin was already working, when i posted here). Every call to pair operation raises trust dialog on device, and disables trustship, therefore unless you not need to setup new trusthip (or fix existing) do not call pair at all. old comon uses order of operation (pre OS7) new order of operation (which is also working with pre OS 7 devices) pairing can return different errors |
Hi mexmer and many thanks for your comment. Well, frankly I hope that a |
just question, did you try to start ethernet driver mentioned stellincwei few posts above? i'm not sure, how exactly linux driver for iphone ethernet works, but starting usbmuxd prior iphone ethernet driver and pairing device might be worth a shot. if driver itself doesn't do explicit pairing, then if it's done by usbmuxd, it should be enough. |
Tethering still works already if one uses the "new" usbmuxd which automatically takes care of the trust handling. Asides, I think the tethering protocol in use was extended (if not changed) a bit, too. Another ticket exists for GNOME to return the current signal strength and radio type during tethering to Network Manager. Overall, this needs someone to look into bringing the driver up to date... |
Dear Martin, Many thanks for your response, was helpful!!
What exactly do you mean by "new"? I checked and on my Debian unstable This package depends on libusbmuxd2 whose installed version is also
Well, the driver still tries to do something so I assume things are
ONe point that remains unclear to me is: between libimobiledevice and |
Dear Martin, br0: port 2(ipeth0) entering learning state usbmuxd_send: Error -1 when sending: Broken pipe At 2013-10-28 03:57:35,hinderer notifications@github.com wrote: Many thanks for your response, was helpful!!
What exactly do you mean by "new"? I checked and on my Debian unstable This package depends on libusbmuxd2 whose installed version is also
Well, the driver still tries to do something so I assume things are
ONe point that remains unclear to me is: between libimobiledevice and ¡ª |
What do you mean, the "new" usbmuxd? What version works, and what version of libimobiledevice has the trustdialog work merged in? Thanks in advance, glad to see progress in this area :) |
programmin1 (2014/01/02 19:59 -0800):
It would be great to have these software taking care of the trust dialog herab. |
I have an iPhone 4s, jailbroken (evasion) on iOS 7.0.4, trying to connect to an raspberry pi running Xbian - "trust dialog" a problem. On the rpi, I run the commands as above, and get Error -20, unable to write to usbmuxd. Thx for your help and work! Sorry, I am a total noob (first git post), so pls forgive if this is the wrong place to post such. |
I experience the same thing. Please let me know if there is anything I can On Wednesday, January 15, 2014, btafssp notifications@github.com wrote:
Per-Mattias Nordkvist |
Where is the 'trustdialog' branch? I can only see one branch called 'master'. |
Looks like it was merged into master, and the branch was deleted. Maybe this is the change? |
Hi, i just wanted to drop you note, since for other project i'm working on, i finally managed to finish correct handling of device trusthip.
first, there is little difference in pairing plist
you need to add 2 fields
at end of pair record dictionary
SystemBUID - plString - it's 26 numbers (at least, that is sent by itunes), or might be 10-16 (eg 27. characters, still 26 numbers split by dash) - this value must be persistent (like HostID)
Pair request (as well as validate request), need to have
ProtocolVersion - plString - value is 2
difference is also in pairing itself
first you call VerifyPairing - if it's first time, you will receive invalid HostID error and then call Pair method
if you receive password protected error, check for ProductVersion, if it's 7 (eg. ios 7), you send Pair request - if it fails, with password protected error - retry (in my app, i'm doing 5 retries with 5 sec pause between - device disconnects lockdown service after 30 sec automaticaly)
after users confirms trust on device, device automatically resets USB after user confirms trust.
next time verifypairing should go without issues.
Please note, that if you disconnect lockdown link after verify, prior succesfull pairing, you need to start whole process again.
If you start with Pair request, after initializiing lockdown, device will show "trust this connection" dialog. that's why you need to start with Verify operation.
following values are for sure available regardless trustship status
DeviceUniqueID
ProductType
ProductClass
ProductVersion
DeviceName - James' iphone
changing order of operation (verify then pair) works with ios 4 devices also (iphone 3g was available for my test), SystemBUID and ProtocolVersion is either ignore, or understood by ios 4 devices, so there is no need to make extra chane in pair record for devices running ios4, i had no ios 3 device at hand, so can't say, if they work.
The text was updated successfully, but these errors were encountered: