iPwnder32 fails to pwn dfu on iPhone 5s on macOS 11.3 & 11.3.1 Public Releases

[AyyItzRob]

Describe the bug
iPwnder32 fails to pwn dfu on iPhone 5s on macOS 11.3 & 11.3.1 Public Releases. Tested on my iPhone 5s running iOS 12.5.3, with my M1 2020 MacBook Air running macOS 11.3.1 (released earlier today). Also never worked on macOS 11.3. Only worked on macOS 11.2 in my experience.
To Reproduce
Steps to reproduce the behavior:

1. Build iPwnder32 with -DEHAVE_DEBUG flag
2. Enter DFU Mode on your 5s
3. Execute ./iPwnder32 -p
4. Look for errors like the ones in my screenshot.

Expected behavior
I expected iPwnder to pwn dfu mode my device with 0 issues considering it worked perfectly fine on macOS 11.2 (there wasn't any huge security changes with 11.3 and 11.3.1 coming from 11.2), but instead of saying "successfully entered pwn dfu mode" or whatever it says when it executes successfully, instead I am met with the errors in the screenshot every time I run iPwnder32. libusb and libusbmuxd are installed as well.

Execution environment (please complete the following information):

• macOS/iOS Version: macOS - 11.3.1, iOS-12.5.3
• BuildVersion: 20E241
• Device: MacBookAir10,1
• Architecture: arm64
• Jailbreak Tool: checkra1n

Target iOS devices (please complete the following information):

• Device: iPhone6,1 running latest iOS 12.5.3
• CHIP (uint16_t): 0x8960

Build version of iPwnder32 (please complete the following information):

• Version: v3.2.0
• Build: 3C152

[dora2-iOS]

Well, on Intel Mac (11.3) works, but maybe it doesn't work on M1?
Is an any process sending usb-request to the device while the tool is running? If a junk request is sent to an iOS device while the tool is running, it fail.
Alternatively, it may be possible that there is a problem with the standard OS request on M1 mac + USB Type-C. This is what the checkra1n team has pointed out.

[AyyItzRob]

Well, on Intel Mac (11.3) works, but maybe it doesn't work on M1?
Is an any process sending usb-request to the device while the tool is running? If a junk request is sent to an iOS device while the tool is running, it fail.
Alternatively, it may be possible that there is a problem with the standard OS request on M1 mac + USB Type-C. This is what the checkra1n team has pointed out.

There are no processes sending usb requests to the device. And I got iPwnder32 to execute successfully every single time I ran it back on macOS 11.2. I just now started having these issues starting on macOS 11.3. It shouldn't be an M1 issue if I had it working at one point every time I executed it.

[dora2-iOS]

It definitely works on the Intel version. I don't have M1, so if it doesn't work it could be a problem with M1. For example, does Finder get a response when the device reconnects? Catalina or later, it becomes an obstacle to operation.

[AyyItzRob]

It definitely works on the Intel version. I don't have M1, so if it doesn't work it could be a problem with M1. For example, does Finder get a response when the device reconnects? Catalina or later, it becomes an obstacle to operation.

Yes, finder gets a response once my device reconnects.

[dora2-iOS]

Perhaps that is the cause. Those connections send junk stuff. Please stop it and try again.

[AyyItzRob]

Perhaps that is the cause. Those connections send junk stuff. Please stop it and try again.

How would I do so?

[dora2-iOS]

Stop 'AMPDevicesAgent' process

[dora2-iOS]

&& AMPDeviceDiscoveryAgent

[AyyItzRob]

&& AMPDeviceDiscoveryAgent

Terminating these processes changed nothing. Exploit still fails.

[dora2-iOS]

Ah, please stop it, not kill.
killall -STOP ...

[AyyItzRob]

Ah, please stop it, not kill.
killall -STOP ...

Stopping them did nothing either.

[dora2-iOS]

Oh, OK. Probably not working on M1 + 11.3 or later.
If you want to use it, please use it at 11.2.3 or below.

[dora2-iOS]

This is a temporary measure. If the cause is found, it will be fixed.
ae26584

[dora2-iOS]

Works on all Intel Mac. Even M1 works fine on Mac mini. This is a problem with Mac with M1 and Type-C ports.

[Cryptiiiic]

On checkm8.c:238 irecv_usb_control_transfer returns IRECV_E_TIMEOUT on rob's m1 for 5s.