Age | Commit message (Collapse) | Author | Files | Lines |
|
lockdownd
In restore mode these requests fail so we need to make sure we are
actually talking to lockdownd
|
|
signing pairing certificates
|
|
Allows -Wimplicit-fallthrough to pass in LLVM.
Thanks to @r-barnes for pointing this out.
|
|
This allows getting a numerical representation of the device's
ProductVersion string for easier version range checks
|
|
This way we make sure to also retrieve the device version and class if the
device is not paired yet.
|
|
|
|
|
|
|
|
A logical bug did prevent parsing the 'Error' node since the code
path is never reached when a 'Result' node is found first. This
is mitigated by always checking for the 'Error' node first.
|
|
|
|
Signed-off-by: Rosen Penev <rosenp@gmail.com>
|
|
Found with bugprone-suspicious-string-compare
Signed-off-by: Rosen Penev <rosenp@gmail.com>
|
|
|
|
|
|
reference
|
|
correctly
The code in lockdownd_client_new_with_handshake would call the function
lockdownd_validate_pair based on the OS version being less than 7.0 without
taking into account that Watch OS has a different versioning scheme compared
to the other device classes. For this and any future version/device specific
checks, the code now queries the DeviceClass and stores it in the
idevice_private struct.
|
|
|
|
|
|
|
|
lockdownd_error_t
|
|
older devices
|
|
Do it in all comments and errors messages
|
|
|
|
|
|
Credit to Rudolf Tammekivi (Blefish), see issue #599
|
|
older device
On newer iOS version, ValidatePair is not mandatory to gain trusted host
status. Starting with iOS 11, the ValidatePair request has been removed from
lockdownd and will throw an error. This commit adds a version check so that
ValidatePair is only called on devices prior iOS 7.
|
|
error for most failures
|
|
When the check of /var/db/lockdown was removed, lockdownd_do_pair started to
always return LOCKDOWN_E_INVALID_CONF instead of usually (but not always...)
returning LOCKDOWN_E_INVALID_HOST_ID for devices not currently paired. This
change not only breaks some third-party code, but also breaks the other code
in this library calling this function (lockdownd_client_new_with_handshake).
|
|
During device pairing the code in lockdownd_do_pair() is checking if there
is a pair record on disk for the current device, and then requests it from
usbmuxd. This additional check is not only unnecessary since usbmuxd can
obviously only return a pair record if it exists, but is also causing issues
on newer versions of macOS where /var/db/lockdown is mode 700.
|
|
are called with NULL arguments
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When connecting with an existing pair record failed we attempted to
pair again which generated a new host id but then connect after
successful pairing tried to use host id from the old record and
failed. Make sure we forget the old host id when re-pairing.
This also fixes a possible memory leak.
|
|
This simple change provides various benefits for developers like compile
time errors, better auto-completition in editors and the ability of a
debugger to show the constant instead of just the raw value.
Thanks to Aaron Burghardt for the proposal.
|
|
|
|
Signed-off-by: Martin Szulecki <m.szulecki@libimobiledevice.org>
|
|
contains a value
This will prevent a crash in libplist when plist_new_string() will be called with
a NULL pointer.
|
|
|
|
Minor cleanup. Drop useless code. We're already at "leave",
so there's no need to (conditionally!) goto it.
|
|
When userpref_read_system_buid fails to retrieve the buid,
systembuid will be set to NULL. It was then unconditionally passed
to plist_new_string - which will crash with a NULL argument.
See https://bugs.debian.org/730756 for people reporting this
happening in the real world.
See https://github.com/libimobiledevice/libimobiledevice/commit/1331f6baa1799e41003aa812c0d1bf36193535ea
("lockdown: Make sure to set SystemBUID in generated pair records")
for the commit where this problem was introduced.
|
|
Conflicts:
include/libimobiledevice/afc.h
|
|
https://github.com/libimobiledevice/libimobiledevice/issues/67
The lockdownd_get_value() function is not properly handling an error
situation. The code logic always returned success as long as the lockdown
response was properly received. Thanks to Aaron Burghardt for spotting this.
|
|
userpref_read_pair_record()
|
|
|
|
|
|
|