| Age | Commit message (Collapse) | Author | Files | Lines |
|
libusb_get_string_descriptor_ascii() uses a fixed 1 s timeout for the
control transfer. The Apple T1 (iBridge1,1) in recovery mode answers the
iSerialNumber read only intermittently and often later than that, so the
read returns LIBUSB_ERROR_TIMEOUT. Losing it costs the device identity and
the AP and SEP nonces, and in the hotplug add handler it meant giving up on
the device: IRECV_DEVICE_ADD was never emitted and callers concluded that
nothing was attached.
- When the libusb helper fails, retry the descriptor read a few times with
libirecovery's own USB_TIMEOUT.
- On Linux, when the read still yields no iBoot string, fall back to the
serial string the kernel already cached for the same bus and device
number under /sys/bus/usb/devices. Used both when opening a device and in
the hotplug add handler; never fatal, and a no-op on other platforms.
- Only assume the legacy CPID 0x8900 when the iBoot string is non-empty but
carries no CPID field. An empty string means the read failed, and
claiming 0x8900 there mis-identifies every modern part.
Behaviour for devices that answer the first read promptly is unchanged.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
|
The T1 in the 2016 and 2017 Touch Bar MacBook Pros (MacBookPro13,2, 13,3,
14,2 and 14,3) runs its own EmbeddedOS and enumerates over the host's
internal USB as 05ac:8600, or as 05ac:1281 in recovery mode when it has
nothing to boot. It identifies as iBridge1,1 / x619ap with CPID 0x8002 and
BDID 0x12; all four machines share that one identity.
Without a device table entry the part stays unidentified, and tools built
on libirecovery cannot address it.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
|
|
|
|
|
|
|
Based on chip ID in macOS 27.0 IPSW file, M6 Mac mini's chip ID
should be 0x8152 instead of 0x6050
Signed-off-by: Alan H.L. Li <mainreturnzero@gmail.com>
|
|
Add/remove/lookup of the devices collection is now serialized with device_mutex. The lock is never held while listener callbacks run, so lock order stays listener_mutex -> device_mutex.
|
|
- Add win32_device_io_control() that always uses OVERLAPPED and waits for completion (including after CancelIo on timeout)
- Use it for control, bulk, reset and KIS ioctls
- Reject short control transfer replies instead of underflowing count
|
|
(cherry picked from commit 793f0ca5d36a6bbb360858b198caf9c5565e4eb5)
|
|
|
|
|
|
These devices boot from DFU mode and runs recovery mode via iBSS.
Signed-off-by: Nick Chan <towinchenmi@gmail.com>
|
|
and use 0 instead of '\0' everywhere consistently
|
|
KIS discovery reused one retained reference across multiple open attempts.
A retry could therefore release an invalid Mach port and cause macOS
to terminate the process with EXC_GUARD.
Retain the service separately for each open attempt while preserving
the callback's iterator-owned reference.
|
|
Signed-off-by: Yureka <yuka@yuka.dev>
|
|
|
|
|
|
|
|
|
|
requests
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- iPad Air (M3, 11-inch and 13-inch)
- iPad (A16)
- MacBook Air (M4, 13-inch and 15-inch, 2025)
- Mac Studio (M3 Ultra and M4 Max, 2025)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows to specify different options. To not break existing behavior, a
value of 1 or (1 << 0) means IRECV_SEND_OPT_DFU_NOTIFY_FINISH which is used
extensively in e.g. idevicerestore. Other options are
IRECV_SEND_OPT_DFU_FORCE_ZLP which I don't remember what it was added for,
and a new option IRECV_SEND_OPT_DFU_SMALL_PKT which needed for upload in
port DFU mode, as it won't accept packets with more than 64 bytes data and
also doesn't like a CRC attached to it.
|
|
Note: This does not allow restoring devices in Port DFU mode, this is
handled in idevicerestore.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This requires and up-to-date AppleMobileDeviceSupport64.msi package
installed that contains the AppleKIS driver.
|
|
|
|
|
|
Also, print the detailed mode in irecovery -q and -m output.
|