MacBook Pro M3 2023 Unable to connect to device

I assume that you are trying with the latest code?

Yes I'm trying with the latest code.

This is how it is showing in USB Tree and Apple Configurator

Ahhh I see. It's using KIS DFU. I have pending commits to push that add support for it (macOS and Linux -- windows not yet). Will push it later today and then you can try again.

I actually pushed the commits now. Let me know if this works now.

Sure, I'll test this.

@nikias it is working with the new commits. But the thing is if I have 2 Macs connected in DFU it only gives 1 device, Is there a way to list them all?

Thanks for confirming. The irecovery tool hasn't been designed to support multiple devices; the underlying library code could handle it though. The enumeration of devices is missing, then it would be just a matter of calling irecv_open_with_ecid with the given ECID of the devices found. I will see what we can do here.

@nikias I got M3 Pro (15,6) as well and that is not showing in irecovery -q and this one looks different from the simple M3 in terms of response from System report. Please check the below screenshots. However the simple M3 (15,3) is showing perfectly fine with the last changes you made.

I see. The USB Product ID is different, 0xf014 as you can see in the screenshot. This is Port DFU mode, not sure how this is different...

@Cardiox12 in KIS mode, the serial string is taken from a buffer (KIS_device_info) read from the device, that contains a usb descriptor buffer. It's not read from a typical string descriptor.

You can turn on debug info for libirecovery by setting an environment variable, so you can run

LIBIRECOVERY_DEBUG_LEVEL=1 idevicerestore file.ipsw

Look out for a line Loading device info in KIS mode... and see what follows.

You can turn on debug info for libirecovery by setting an environment variable, so you can run LIBIRECOVERY_DEBUG_LEVEL=1 idevicerestore file.ipsw Look out for a line Loading device info in KIS mode... and see what follows.

idevicerestore SEGFAULTs (in libirecovery.c:2437) before we can get a chance to get this message. This is because it uses libusb_usb_open_handle_with_descriptor_and_ecid which doesn't implement reading serial string from KIS. (This is a piece of code that is located in irecv_open_with_ecid).

We managed to leverage code from irecv_open_with_ecid to get the serial string and move on. We are now stuck further down the process in idevicerestore_start, we need to check out why. Will get back to you in January with more findings, this is holidays time now 😁.

Just tested on macOS and it has the same issue when the _irecv_handle_device_add code is used; the KIS init is missing. Working on a fix.

@nikias I tried what you merged for M3 support on M3, install was ok, we'll try on M3 Pro tomorrow.

Thanks, excited to see the results.

We tried on M3-Pro, it does not work yet, we may not be very far from making it. It is probably caused by how idevicerestore handles the 4 USBPortControllers (those ones are not present on M3 "not pro" variant).

See the log file m3-pro.log

First clue is line 198 (not sure what RestoreRequestRules are) :

DEBUG: tss_request_add_ap_tags: Skipping 'USBPortController1,USBFirmware' as it doesn't have RestoreRequestRules
DEBUG: tss_request_add_ap_tags: Skipping 'USBPortController2,USBFirmware' as it doesn't have RestoreRequestRules
DEBUG: tss_request_add_ap_tags: Skipping 'USBPortController3,USBFirmware' as it doesn't have RestoreRequestRules
DEBUG: tss_request_add_ap_tags: Skipping 'USBPortController4,USBFirmware' as it doesn't have RestoreRequestRules

Second clue, is line 2386-2421:

• the Trusted, EPRO and ESEC keys are missing for the 4 USBPortControllers
• the digest list size for USBPortController4 is different from the others (again not sure what this is).

Third clue:

• at line 3726: it sends firmware for USBPortController4 and then requests ticket for the 4 USBPortControllers
• at line 4180: it believes it received a ticket for USBPortController1 (probably can't handle the 4 tickets bundle response)
• at line 4205: sends firmware for USBPortController4 but requests tickets for USBPortController 2-4 only
• at line 4567: it complains it received no ticket for USBPortController1 and exits

We are working on it, if you have any ideas on where we can start, we would love to hear about it.

About lin 4180, the culprit is in restore_get_generic_firmware_data:

        const char* response_ticket = NULL;
	if (PLIST_IS_ARRAY(response_tags)) {
		plist_t tag0 = plist_array_get_item(response_tags, 0);
		if (tag0) {
			response_ticket = plist_get_string_ptr(tag0, NULL);
		}
	}

If multiple tickets are requested, we only keep track of the first one to verify the response is correct. However this simply is a warning, no big deal.

Some oddities:

• the mac asks twice for the same USBPortController4,Firmware (lines 3726 and 4205)
• the second time, the DeviceGeneratedRequest received doesn't contain info about USBPortController1 but a ticket for it still is requested in ResponseTags
• in both cases, Arguments.MessageArgInfo.TicketName is USBPortController1,Ticket which is not consistent with the firmware just sent.

Keeping up with digging... 😄

Little update: I couldn't find something suspicious in the code today. idevicerestore seems to be performing the job, properly forwarding Ace3 TSS requests from the mac to the TSS server and sending back the tickets to the mac.

The following questions remain unanswered:

• why is the mac unhappy with the first set of 4 tickets?
• why is it doing something looking like a retry with a different query? (no TSS query data for USBPortController1,Firmware)
• why is the mac asking for a 4 tickets set instead of just one for the previously requested firmware? (here USBPortController4,Firmware)

The TicketName query parameter for 4 tickets being USBPortController1,Firmware may indicate a confusion in the firmware request order (the first usb port controller firmware request being for controller 4) or just a "why not? there is only room for one value there"

Still pretty much in the dark there.

Allright, time for a little update. I have been skimming through a USB dump of the communication between an M2 Pro being restored and Apple Configurator 2 restoring it. The interesting fact is the same happens there (USBPortController4,USBFirmware is asked twice, asks for 4 tickets the first time, then 3 tickets only).

In this dump, after the 3 tickets are send back to the mac, I get 7 ProgressMsg in a row and then CHECKPOINT_COMPLETE for update_ac3.

With idevicerestore I can't reach this checkpoint, it fails before (see my previous log's ending, ReverseProxy[Ctrl]: Connection closed)

I now think the problem is somewhere else. If the Ace3 TSS process was incorrect, it would probably fail before asking for the 3 tickets.