iOS 7 Compatibility / Trust Dialog handling about libimobiledevice

[FunkyM]

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?

[mexmer]

Hello,
first, the "other" project i was mentioning is on windows platform, not linux. While i admit, base of iphone communication framework is derived from libimobile (in principle), it was writen using openssl (while libimobile used gnutls, when we started it), although i was using libimobile sometimes as reference, libimobile code is not part of project.

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.
i fear this will require changes of ptp/mtp driver.

on windows this is done by apple driver.
you connect apple device to computer, and then apple service does "initial" pairing with so called "chaperone" certificate - i think, this certificate is hardcoded in service (i'm not sure about that, it's just guess,. it might also be temporary created certificate, that is valid only trough lifetime of service).

Please note, that there are 2 apple services related to mobile devices

1. Apple Device Mobile Service - this service automaticaly, and is used by iTunes, and we have it turned off (otherwise we cannot communicate directly with apple device)
   2)iPod Helper Service - this service is started on demand, when apple device is plugged to computer (i think, it's started by apple driver, and most likely this service supplies same functionality as usbmuxd)

following is my observation of apple device behaviour - initial state - apple mobile service disabled, ipod service stopped

1. connect apple device (iphone)
2. apple device (no MTP) is connected to windows, and trusthip dialog appears
3. confirm trusthip - device resets usb connection and in device tree is replaced with another "apple device", that has as slave device MTP apple iphone (you can acquire photos using this)

Our project can connect to device either in step 1, or step 3
When we connect in step 1, after successfull pairing, device switches to mode described in step 3 - i think, in this situation pairing request cancels previous trust dialog, and new one appears
When we connect in step 3, after pair request device switches to mode in step 1 (mtp disapears), and trusthip dialog on device appears, after pairing device is in mode described by 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.
When device is connected there is always pair request incoming from computer, but if Apple Mobile Device service is running (eg. itunes service), it most likely intercepts usb arival and sends own pairing record (which is also what our software does), before ipod service sends one.

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.

[mexmer]

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.

[FunkyM]

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.
I am still wondering how exactly this works on Windows and will need to look at that, too.

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. :)

[mexmer]

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.

[FunkyM]

Not captured Windows yet, only OS X and Linux.
Your license assumption is very wrong. The libimobiledevice stack (including it's related libraries and even GnuTLS) are all LGPL, not GPL. Thus with that license, it is fine to distribute a binary library even within proprietary solutions (I know of a couple of closed source projects using libimobiledevice). On Windows we don't even need usbmuxd either, you only need libusbmuxd and can safely use the native Apple drivers.

[mexmer]

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?

[FunkyM]

How could you capture anything on Windows when there is no updated iTunes release available yet?
The underlying "drivers" (usbmuxd and alike) on OS X have been updated to work with iOS 7, I assume the Windows one's will be updated, too. Using the new device firmware will force users to do an iTunes update aswell.
The UntrustedSystemBUID handling is now a more important part of the whole connection workflow, you'll probably see that in a capture once the Windows drivers are released.

[mexmer]

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.

[mexmer]

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.
Though UDID can be obtained by other means (it's reported as device serial number trough USB), which seems to be also way libimobile reads it.

[FunkyM]

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.

[stellincwei]

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" .

[stellincwei]

I have complete this branch test.execute these steps to activate tethering.
usbmuxd &
-------plug iphone
idevicepair validate
idevicepair pair
-------close and open tethering / open tethering
-------iphone show BlueTooth and USB ONLY dialog.... tethering enable

User must reopen "Personal Hospot" to Let the iphone pops tethering enable dialog if it is on Originally.
many users may not do this. how to solve this.

log:
idevicepair validate
SUCCESS: Validated pairing with device 956b4a506543901924bfa229297c8baa300113bf

idevicepair pair

ERROR: Pairing with device 956b4a506543901924bfa229297c8baa300113bf failed with unhandled error code -20

[FunkyM]

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:
https://bugzilla.kernel.org/show_bug.cgi?id=63771
I hope that was the correct thing to do...

[mexmer]

imo change that will be required is same, that will be needed for ptp driver.
driver will need to properly call validate_pairing, and then (in case of error) pair afterwards.

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)
you get device public certificate
load or generate matching computer certificates (if you loading cached data, you need to make sure, that device public certificate is same, and that you use same systemudid)
call pair - device normally accept this (unless it has passcode enabled)
if pair returns OK continue, otherwise handle error
call validate pair
if validatepair returns OK, device is connected and you work as normal

new order of operation (which is also working with pre OS 7 devices)
you get device public certificate
load or generate matching computer certificates (if you loading cached data, you need to make sure, that device public certificate is same, and that you use same systemudid)
call validate pair (with untrustedbuid set to systembuid - new iOS7 key)
if validate pair returns OK, device is connected and you work as normal
call pair - device displays "trust this computer" dialog - always, regadless you are paired already or not
if pair returns OK continue, otherwise handle error
at this moment device resets, and you start again with validate pair

pairing can return different errors
you can distinguish either device is waiting for user input (trust dialog confirmation), or it's different error.
if device is waiting for user confirmation, you just repeat pair operation, until it succeeds (it will succeed when user confirms trust)
you can also see device locked error for devices with passcode lock,again you just call pair operation until it succeed (it will succeed when user enter passcode on display)

Hi mexmer and many thanks for your comment. Well, frankly I hope that a
dev kwill pick it up because I'm far from being a kernel developer.

[mexmer]

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.

[FunkyM]

Tethering still works already if one uses the "new" usbmuxd which automatically takes care of the trust handling.
Nevertheless, the driver might require a few new USB ids for latest devices and there is a udev rule installed which is supposed to run the idevicepair tool which is pretty much obsolete now.

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!!

Tethering still works already if one uses the "new" usbmuxd which
automatically takes care of the trust handling.

What exactly do you mean by "new"? I checked and on my Debian unstable
the version of usbmuxd which is installed is 1.0.8-2 which as far as I
could see seems to be the last available version.

This package depends on libusbmuxd2 whose installed version is also
1.0.8-2. I was not able to find any more recent package. Did I miss
something?

Nevertheless, the driver might require a few new USB ids for latest
devices and there is a udev rule installed which is supposed to run
the idevicepair tool which is pretty much obsolete now.

Well, the driver still tries to do something so I assume things are
correct at that level, although I understand there may be stuff that
could be removed because it has become useless.

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...

ONe point that remains unclear to me is: between libimobiledevice and
usbmuxd who does the pairing? Fromyour mail Iunderstood that it is
usbmuxd which is supposed to do that but before I thought it was rather
libimobiledevice. Or am I misunderstanding things completely here?

[stellincwei]

Dear Martin,
I have used the "new" usbmuxd to take over the trust dialog box and ran ipheth.ko to communicate with iphone (IOS7.04).
But I often find these log to prevent the pair successfully.

br0: port 2(ipeth0) entering learning state
br0: topology change detected, propagating
br0: port 2(ipeth0) entering forwarding state
usbmuxd_send: Error -1 when sending: Broken pipe
usbmuxd_send: Error -1 when sending: Broken pipe
usbmuxd_send: Error -1 when sending: Broken pipe
usbmuxd_send: Error -1 when sending: Broken pipe

---

usbmuxd_send: Error -1 when sending: Broken pipe
GnuTLS error: Error in the push function.
usbmuxd_send: Error -1 when sending: Broken pipe
usbmuxd_send: Error -1 when sending: Broken pipe
usbmuxd_get_result: Received packet is too small!
usbmuxd_connect: Connect failed, Error code=-1

At 2013-10-28 03:57:35,hinderer [email protected] wrote:
Dear Martin,

Many thanks for your response, was helpful!!

Tethering still works already if one uses the "new" usbmuxd which
automatically takes care of the trust handling.

What exactly do you mean by "new"? I checked and on my Debian unstable
the version of usbmuxd which is installed is 1.0.8-2 which as far as I
could see seems to be the last available version.

This package depends on libusbmuxd2 whose installed version is also
1.0.8-2. I was not able to find any more recent package. Did I miss
something?

Nevertheless, the driver might require a few new USB ids for latest
devices and there is a udev rule installed which is supposed to run
the idevicepair tool which is pretty much obsolete now.

Well, the driver still tries to do something so I assume things are
correct at that level, although I understand there may be stuff that
could be removed because it has become useless.

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...

ONe point that remains unclear to me is: between libimobiledevice and
usbmuxd who does the pairing? Fromyour mail Iunderstood that it is
usbmuxd which is supposed to do that but before I thought it was rather
libimobiledevice. Or am I misunderstanding things completely here?

¡ª
Reply to this email directly or view it on GitHub.

[programmin1]

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):

What do you mean, the "new" usbmuxd? What version works, and what
version of libimobiledevice has the trustdialog work merged in?

It would be great to have these software taking care of the trust dialog
released so that they can be packaged for the Linux distributions.

herab.

[btafssp]

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.

[pmnordkvist]

I experience the same thing. Please let me know if there is anything I can
do to help sort this out. Keep up the good work.

On Wednesday, January 15, 2014, btafssp [email protected] wrote:

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.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-32411457
.

Per-Mattias Nordkvist
Mobil [phone]
www.twitter.com/pmnordkvist
www.improove.se

[themaddoctor]

Where is the 'trustdialog' branch? I can only see one branch called 'master'.
Thank you.

[programmin1]

Looks like it was merged into master, and the branch was deleted. Maybe this is the change?
#26