Device has no langid [Error] #55
Comments
|
I get this error too with the iPhone 5S. I get my CPID ECID etc. and then it gives me |
|
Getting the same error on MacOS |
|
I also can confirm same error on OSX Mojave 10.14.6
|
|
This is really the only blocker to Windows support (for me). |
|
Got the same issue on my mac :/ |
|
Same on Ubuntu 18 |
|
ubuntu 18.03 too. i install libusb1.0.0-dev and libusb1.0.0 and python-libusb1. |
Similar error over here, currently running an iPhone 5S and Ubuntu 19.04, had to install Python 2.7 for the exploit to run {THIS EXPLOIT WILL NOT RUN ON PYTHON 3}, and installed libusb via This is assuming the exploit doesn't fail and throw my iPhone 5S out of DFU mode. |
|
The reason for this error may be that you forgot to use You can check if python is able to use talk to your device by putting it in DFU mode and running: This should print a lot of info about your device. |
|
Yeah there seems to be two causes of this.
In the case of the latter, i experienced it on both Ubuntu and OSX with an iPhone 5 (GSM) which was never successful. I don't have the errors on hand, but i can tell you there was some pipe stalls and communication timeouts. Sometimes the device had rebooted. Other times, it would be stuck in limbo. No longer detected by the computer, but also not turned off. It appeared as though is was still in DFU. I'm yet to dig into it further. I suspect, given that the iPhone 5 uses the very failure prone 1608A1 Tristar, that the issue is with the Tristars internal multiplexer detaching. This is a fairly common failure mode of a defective Tristar, in all models (TRISTAR-1608A1.. TRISTAR2 -1610A1,1610A2,1610A3,610A3B.. and the TI variant of TRISTAR used in some iPad Mini/iPad 4th Gen, whos model i don't have on hand but is just as if not more failure prone than the 1608A1). Given just how failure prone the Tristar is, it's not clear if a bunch of people have defective Tristars (far more common than you would expect) or an issue with timing/offsets in the exploit, or even an issue with libusb1.0. Has anyone successfully exploited an iPhone 5 GSM that can confirm it worked for them? In any case, there may be a better way to deal with error handling of a device that disconnected. Im not sure |
Except that in my case, it is being run as Notice the error thrown my runtime The part of this to note is the traceback. Not running sudo gives line 48 (with every run I might add): However, on me and @lithiumvantage 's runs, we get a different line: And OP: Furthermore every traceback has one thing in common that not using sudo does not: the error traces to So though some users may have issues with sudo this is definitely not an issue with either privileges or connections (at least physically anyway, I am using a brand new cable). As of recent however I switched the offsets to that of pull request #51 for my 5S, and while I have not yet gotten this exploit to work, I have not had this error since. |
|
Yes, and in the latter i explained, it doesn't happen every time either. The exploit isnt successful either, is it? When it does occur, it seems to be a connection issue. I wasn't calling you out in a personal attack for not using sudo. You clearly need to breathe into a bag or something. What I was saying, is heres the two things that i have been able to determine result in that error. Both if which come back to "we can't talk to the device", be it from lack if permission, or lack of connection. Thats not to say, black and white, its an issue with your cable. Lightning devices have a lightning protocol negotiation ic, Tristar, which is a multiplexer. It assigns the data pairs from your lightning port up to 2 functions (theres two data pairs), one of which is SOC USB. What in saying is, in many of the cases i have observed that multiplexer detaching from USB SOC, its not clear exactly why thats happening, but Tristar failure is incredibly common on the device i was testing it on (and yours too). Tristar failures also tend to be intermittent. Furthermore, if you do a little more digging, and rather than just import and enable traceback, you add some additional debugging.. you will see exactly what the error returned from libusb itself is. In my case, its communication timeouts and pipe stalls. Both if which are incredibly common errors during an itunes restore on a device with a bad tristar. Look at geohots fork, and you will see how he added additional debugging to show the response from libusb. You may very well find since changing those offsets, your device is no longer rebooting/disconnecting, or causing whatever exception resulted in the multiplexer detaching before. I'll attach some documentation that explains how Tristar works, and what im talking about. I'm not saying your tristar is faulty. There could absolutely be some kind of exception thats occuring resulting in the detach. Im just suggesting theres a possibility, and narrowing it down further for you, than "somewhere in this python file". I also want to know if anyone has been successful with an iPhone 5, because if the answer is yes, then its less likely the issue in the code, and more likely its my device. |
|
Explanation of the charging circuit (and in turn also USB communication/tristar function): https://www.aonemobiles.com.au/2018/06/iphone-battery-charging-analysis/ Tristar IC itself: https://www.aonemobiles.com.au/product/1610a3-tristar-ic/ |
|
Sorry didn't mean to make it an issue just wanted to make sure the issues were clear for anyone else following. Thank you for the additional information on Tristar, a write-up on this really does need to be made more common in regards to this issue so people know about it in the future. Do you have the enhanced libusb debugging exceptions on hand? I can run Geohot's fork for debugging on both offsets and get the pastes here |
I can confirm that the iPhone 5 (GSM) fails consistently with this exploit (I've tested 3 identical devices, my own and two others). They all seem to fail with pipe and timeout errors, which seem as though the device has disconnected (which would go along with the failing tristar mp theory). I've only been testing on Ubuntu 18.04 machines, as I don't have any physical Macs to test with. In addition, running I haven't tested an actual iTunes restore from DFU yet (no access to a physical windows machine for a few days) but I would assume that a similar error could occur. I'm not sure how to work around this yet, but (using logging from geohot's fork) it can be seen that there are some successful payload transfers to the device. It may be possible to manipulate the timing or sequence of these to improve reliability but I'm not sure. Regardless, once the device has disconnected, it appears to be game over, since once it disconnects, it must be restarted (either regularly or back to DFU mode) to be usable again; it appears as though whatever state the USB controller is in when it disconnects does not allow reattaching (perhaps it's being put in a state that makes any communication impossible?) Edit: specifically, the following errors occur: Occasionally, rather than the final error, a USBError is thrown with the following stack trace: |
|
Thats pretty much exactly what i found. I did the same (watch lsusb) in another window and found the same. Given that you have experienced the same on 3 devices, you are either unlucky, or the issue is indeed with the exploit. So far that makes 4 devices stuck in a detached state, and no reports of success for the iPhone 5 (GSM). Starting to think the detaching is occuring at the SoC due to some kind of exception rather than tristar. Thats not to say having 3 consecutive iPhone 5 with failed tristar is unheard of. But it does seem less likely. I did test on OSX 10.6.8 (the only Mac i have at my disposal) and the results were identical to Ubuntu 18.04 (my daily driver). |
|
I found out, if you run ipwndfu and device does NOT reboot, I very quickly pull out and reinserted the cord from the iDevice side, I have CPID: 8960 [iPad Mini 3, A1600] With a few Fixes of my own. |
|
so if it fails but doesn't reboot, but then you just replug the USB,
suddenly you're in pwnDFU?
or are you getting the langID then doing the replug
*--Jake*
…On Fri, Oct 18, 2019 at 8:00 AM Valentinez ***@***.***> wrote:
I found out, if you run ipwndfu and device does NOT reboot,
lsusb -d 0x5AC:0x1227 -vv returns:
Bus 001 Device 023: ID 05ac:1227 Apple, Inc. Mobile Device (DFU Mode)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x05ac Apple, Inc.
idProduct 0x1227 Mobile Device (DFU Mode)
bcdDevice 0.00
iManufacturer 2 (error)
iProduct 3 (error)
iSerial 6 (error)
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 0
bConfigurationValue 1
iConfiguration 5 (error)
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Device Status: 0x1680
(Bus Powered)
I very quickly pull out and reinserted the cord from the iDevice side,
Somehow 'reboots' just secureROM, and Boom, I'm in PWND Mode.
I have CPID: 8960 [iPad Mini 3, A1600]
Using Cryptiiiic/ipwndfu_public
<https://github.com/Cryptiiiic/ipwndfu_public>
With a few Fixes of my own.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#55?email_source=notifications&email_token=AH5TRT3MWGGYQ5VGBEOBPNDQPGXQJA5CNFSM4I3KX7I2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBUK5QQ#issuecomment-543731394>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH5TRTY54C7PPUCVAFNG4ZLQPGXQJANCNFSM4I3KX7IQ>
.
|
|
Run ipwndfu, Detects device at first, [Found: Device Serial] Need to VERY QUICKLY remove insert, remove insert multiple times, I run:
|
|
macOS Catalina , iPhone 5S, same problem |
|
Run the command with sudo and as well as python. sudo python ./ipwndfu -p |
|
Hola, que tal, estuve probando hasta que entre, el error al parecer le da a muchos. Tengo Parrot OS y pensé que era por eso. También háganlo con sudo e instalen libusb Suerte!! |
|
I had this exact error every single time with Apple TV 3 (7.4) with MacOS 10.15.1. Updated libusb to 1.0.23 and it worked first try. Hope this helps someone. |
|
1 similar comment
|
### **** |
I only run the command like a root and done |
|
i'm having this error - i followed this Youtube tutorial since i also have the problem in Activation lock same response even when i do |
|
how to fix? |
Maybe restarting the idevice and reentering the dfu. |
|
i met this problem about 1 year ago. It seemed checkm8 driver problem or system problem. And it also doesn't work now |
|
As ghost said, sudo python ./ipwndfu -p This command worked for me. |
|
It doesn't work for me. I tried printing some extra logs before I get Following is the result.
|
|
Hello thanks for this sharing! Im on OS Catalina, I have the same problem with iphone 5c... i dont have idea why i have this error can check pls thanks. |
This helped me to successfully downgrade my 1st gen iPad Air. |
|
and others
Hello thanks for this sharing! Im on parrot os new fresh install. I have the same problem with iphone 5c and 5s... i dont have idea why i have this error can check pls thanks"
*** checkm8 exploit by axi0mX *** Found: CPID:8950 CPRV:20 CPFM:03 SCEP:10 BDID:0E ECID:0000009xxxxx8 IBFL:00 SRTG:[iBoot-1145.3] Traceback (most recent call last): File "ipwndfu", line 62, in <module> checkm8.exploit() File "/home/gen/ipwndfu/checkm8.py", line 510, in exploit if 'PWND:[checkm8]' not in device.serial_number: File "/home/gen/ipwndfu/usb/core.py", line 830, in serial_number self._serial_number = util.get_string(self, self.iSerialNumber) File "/home/gen/ipwndfu/usb/util.py", line 314, in get_string raise ValueError("The device has no langid") ValueError: The device has no langidThe text was updated successfully, but these errors were encountered: