Libiphone libiphone → 1.0 Release

Comments and changes to this ticket

• 

  Martin S. November 23rd, 2009 @ 02:32 PM

  • Assigned user set to “Martin S.”
  • State changed from “new” to “open”
  • Tag set to “api, libiphone, lockdown, pairing, tethering”
  • Milestone set to “1.0 Release”

  Great information you have there. Now I understand why that Python pairing script was created in the first place for ipheth.

  Do you have some code to show your approach perhaps?
  Also assuming it is user-space, does it use libiphone?

  We have been elaborating just last week about the missing lockdown API calls.

  The plan is to extend the current lockdown API to expose all lockdown protocol calls and allow custom implementations of the handshake and pairing process without relying on our current "private" gnutls handshake.

  This will give you the ValidatePair request and all other not yet exposed functions.
  A helper will most likely take over the current SSL handshake functionality then.

  I'll cook up a patch to expose just ValidatePair in the lockdown API for now unless someone beats me to it earlier.

• You flagged this item as spam.
  

  Bradley Baetz November 23rd, 2009 @ 09:25 PM

  I'm only using libiphone to send the validatepair. I guess I'll use it for device discovery at some point - at the moment I've just hardcoded the USB ID for a 3gs. (it's not quite that simple though, because I need to get the same device from libusb) The network interface is done with libusb1 and the Linux tap interface apis.

  Currently I'm relying on lockdownd_client_new making sure that the device is paired - the new validatepair routine should ideally use libiphone's existing keys, first pairing if required.

  I'll put something up this evening (au time), although it'll still be hardcoded to my phone.

• You flagged this item as spam.
  

  Bradley Baetz November 24th, 2009 @ 12:06 PM

  Current code at http://members.optusnet.com.au/~bbaetz/iphonenet-0.1.tgz

  If you don't have a 3GS you'll need to change the productid in the code. You'll also need to change the path to userpref.h, and use libiphone 0.9.3 (hey, I said it was a hack :)

  Requires root to run, and tethering enabled by your carrier (if its not, I'd be interested what value get_tether_status produces, though)

• 

  Nikias Bassen November 29th, 2009 @ 03:32 PM

  @Martin: You're right, the lockdown API does too many things internally without letting the user (coder) control how/when things should be done. For example, lockdownd_client_new does the QueryType request, the device pairing, and the session startup together. This may be convenient when you don't know how those things actually work. But lockdownd_client_new should only set up the lockdownd client object, so that a client program would have to do:
  

  lockdownd_client_new(device, &client);
  lockdownd_query_type(client);
  lockdownd_pair(client, UUID, HOSTID);
  lockdownd_start_session(client, HOSTID);
  ...
  lockdownd_stop_session(client);
  lockdownd_free(client);
  

  Perhaps lockdownd_start_session could be made more intelligent to do query_type and pairing if necessary (perhaps with an additional parameter?)

  Just my thoughts on this topic.

• You flagged this item as spam.
  

  Bradley Baetz November 30th, 2009 @ 02:08 AM

  Does the iPhone support multiple active hosts being paired to it at the same time? If so, that may make sense (with HOSTID being NULL to use libiphone's builtin key management, and removing UUID from the call and just getting it from the client param)

  However, since TrustedHostAttached stays true after closing the lockdownd connection, I'm not sure if the iPhone supports it, and even if it did if there would be any point. I think a better interface would be:

  lockdownd_is_paired(client)
  lockdownd_pair(client)
  lockdownd_validate_pair(client)

  with the keys/uuid/etc coming from the device directly (possibly _validate_pair would automatically pair if not already paired - ditto for start_session?)

  querytype should probably be start of _client_new - is there any reason not to?

• 

  Nikias Bassen November 30th, 2009 @ 04:20 AM

  You're right, there's no disadvantage of performing the QueryType request inside lockdownd_client_new, so we should keep it this way.

  I can use multiple computers to access my device via gvfsd-afc/ifuse as it basically depends on the computer having the device certificate (which is retrieved during pairing). So lockdownd_is_paired would in fact tell if the computer has already been paired with the phone; the phone itself does not know to which computer it is paired to.

• You flagged this item as spam.
  

  Bradley Baetz November 30th, 2009 @ 04:40 AM

  • Tag cleared.

  I can use multiple computers to access my device via gvfsd-afc/ifuse

  Yes, but not at the same time. (Although this still doesn't help if two different users are trying to use libiphone at once, which will happen if a user has the iphone mounted via afc and has my iphonenet daemon running as root - the keys will be different. This actually works at the moment, but they're not trying to both use lockdownd simultaneously)

  as it basically depends on the computer having the device certificate (which is retrieved during pairing).

  But the hostid is passed to the device when starting ssl, so it does know (and has to, because it has to encrypt the reply using our host cert)

  Plus ValidatePair (the point of this ticket) provides the host cert to the device. This is required before tethering works, and possibly other functions too.

• You flagged this item as spam.
  

  dborca December 1st, 2009 @ 07:37 PM

  Attached is a patch that does 3 things:
  1. fixes a bug where lockdown_check_result() might return -1 and lockdownd_pair() still return success
  2. allow lockdownd_pair() with host_id==NULL, in which case userpref host_id will be used
  3. new lockdownd_validate_pair() API, using the same code as lockdownd_pair()
  May not be the best approach, but does the trick: (2) was needed to ValidatePair using the same host_id as lockdownd_client_new()

  • libiphone-095.patch 3.4 KB
• 

  Martin S. December 1st, 2009 @ 09:47 PM

  • Tag set to “api, libiphone, lockdown, pairing, tethering”

  @dborca: Yes, it's an elegant and proper "fix" for now I guess. Please use "git format-patch" for generating patches and try to keep individual "things" as seperate commits if possible.

  Nevertheless, mind that the lockdown API might be changed (still discussing best design). The idea is to closely reflect the lockdown protocol with the C API (same for the other protocol APIs libiphone offers), thus the pairing functions would more look like this:

  lockdownd_error_t lockdownd_pair(lockdownd_client_t client, lockdown_pair_record_t pair_record);
  lockdownd_error_t lockdownd_validate_pair(lockdownd_client_t client, lockdown_pair_record_t pair_record);

  The current "private" gnutls session functionality will most likely end up in a helper function to still offer a simple API next to the native low-level one.

  Thus one will be able to either completely reimplement the handshake if desired or use the helper to keep it simple like now.

• You flagged this item as spam.
  

  dborca December 1st, 2009 @ 10:59 PM

  Hi,

  I don't use git that much (except "clone"), so I'm not used to its patch format; I suppose a "git diff" should do.
  Also, I agree about separating patches. I guess I just took the easy way out, seeing those 3 things as being somehow related. As a matter of fact, I almost included a simplification of lockdownd_client_new() by having it pass host_id=NULL to lockdownd_pair(), but that was really beyond the scope of what I was trying to achieve.

  About the API change. I am aware that it might be useful, yet a higher-level wrap-up also has its advantages. Actually, it was the gory details in ipheth-pair.py (which does everything through recv/send) that put me off debugging it and instead looking inside libiphone. Moreover, think of error handling: having error checking at each primitive (and then clean up gracefully) will turn much of the libiphone client code into a mess.

• 

  Nikias Bassen December 7th, 2009 @ 06:49 PM

  • Tag changed from “api, libiphone, lockdown, pairing, tethering” to “api, libiphone, lockdown, pairing, patch, tethering”
  • Assigned user changed from “Martin S.” to “Matt Colyer”

  OK, here I have some great patches. Two of them are not directly related to the topic of this ticket, so I've put them into ticket #94 so get them from there.

  0001: Fixes the possibly erroneous return of LOCKDOWN_E_SUCCESS in lockdownd_pair
  0004: Cache the device uuid in the client struct when lockdownd_client_new is executed. This will make accessing the appropriate keys from the userprefs a bit nicer because the uuid does not have to be retrieved from the device. This one also removes the uuid parameter from lockdownd_pair().
  0005: This one will allow passing NULL as HostID to lockdownd_pair(). The documentation to this function was already updated in patch 0004 (accidentally).
  0006: Finally, this one introduces lockdownd_validate_pair() which allows the host becoming the trusted host of the device.

  Of course these patches still reflect the 'old' API. This will change soon, but in the meanwhile this should give coders the ability to do what they need ;-)

  Happy patching!

  • 0001-lockdown-fix-lockdownd_pair-returning-success-on-err.patch 1.2 KB
  • 0004-lockdown-cache-device-uuid-in-client-struct.patch 6.1 KB
  • 0005-lockdown-allow-passing-null-as-hostid-to-lockdownd_p.patch 2.1 KB
  • 0006-lockdown-new-function-lockdownd_validate_pair.patch 5 KB
• 

  Nikias Bassen December 7th, 2009 @ 06:49 PM

  • Assigned user changed from “Matt Colyer” to “Martin S.”
• 

  Matt Colyer December 8th, 2009 @ 03:48 AM

  • State changed from “open” to “resolved”

  (from [318cc4f7b336109819c7b4c6a1a9f2e8d37d9bed]) New function lockdownd_validate_pair()

  This function allows the current host (or the host specified by the
  given HostID to become the trusted host of the device.

  [#89 state:resolved]

  Signed-off-by: Matt Colyer matt@colyer.name
  http://github.com/MattColyer/libiphone/commit/318cc4f7b336109819c7b...