I have the problem that as soon more then one phone is connected the machine idevicerestore fails with an error :"ERROR: Failed to place device in recovery mode" and keeps the phone stuck.

Plattform: windows Source: it's reproduceable with the current pushed source code Build: with msys64 Systems: tested on different windows10 machines, different iTunes versions, different phones, different cables - no change noticable Call: idevicerestore -C -l -e -y -d

Behaviour: As long only one phone is connected the whole process runs without any problem through. As soon a second phone is conneced the call fails with the error and phone is stuck.

Do you have any idea what could trigger that problem? I saw there was a change in that code area on 11 Oct 2019 commit [https://github.com/libimobiledevice/idevicerestore/commit/767fcceaeb456f5e281a6bd1b3f51713e4989293] - but no clue if that could be related to that behaviour.

` idevice_event_cb: device 0000000000000000 (udid: 1bfd3526abc6a6ccb46b57e4413e754d2a35406a) connected in normal mode idevice_event_cb: device 0000000000000000 (udid: 1bfd3526abc6a6ccb46b57e4413e754d2a35406a) connected in normal mode

Trying 104.24.27.50:443...
TCP_NODELAY set
Connected to api.ipsw.me (104.24.27.50) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
error setting certificate verify locations, continuing anyway:
CAfile: D:/git/securaze/mobile/desktop/build-mobiletest-Desktop_Qt_5_13_0_MSVC2017_64bit-Debug/ssl/certs/ca-bundle.crt CApath: none
SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
ALPN, server accepted to use h2
Server certificate:
subject: CN=ssl373768.cloudflaressl.com
start date: Jan 6 00:00:00 2020 GMT
expire date: Jul 14 23:59:59 2020 GMT
subjectAltName: host "api.ipsw.me" matched cert's "*.ipsw.me"
issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO ECC Domain Validation Secure Server CA 2
SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
Using HTTP2, server supports multi-use
Connection state changed (HTTP/2 confirmed)
Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
Using Stream ID: 1 (easy handle 0x281e150)

GET /v3/device/iPhone7,2 HTTP/2 Host: api.ipsw.me User-Agent: InetURL/1.0 idevicerestore/1.0 Accept: /

old SSL session ID is stale, removing
Connection state changed (MAX_CONCURRENT_STREAMS == 256)! < HTTP/2 200 < date: Wed, 12 Feb 2020 15:55:05 GMT < content-type: application/json < set-cookie: __cfduid=d7548ca8b6368e5b4f3df90800379619d1581522905; expires=Fri, 13-Mar-20 15:55:05 GMT; path=/; domain=.ipsw.me; HttpOnly; SameSite=Lax; Secure < vary: Accept-Encoding < access-control-allow-origin: * < access-control-expose-headers: X-Data-Location, X-Server-Location < cache-control: public < content-md5: L8Z9OCHZdwC+4WZ9zWb4Xw== < content-security-policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none' < expires: Wed, 12 Feb 2020 16:10:02 GMT < vary: Origin < x-content-type-options: nosniff < x-data-location: cache < x-frame-options: DENY < x-server-location: b62748e18422 < x-xss-protection: 1; mode=block < strict-transport-security: max-age=15552000; preload < x-frame-options: DENY < cf-cache-status: HIT < age: 1394 < expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" < server: cloudflare < cf-ray: 563fbeae4ed9fca9-VIE <
Connection #0 to host api.ipsw.me left intact Getting device's ECID for TSS request NOTE: Unable to find BbCalibrationManifestKeyHash node NOTE: Unable to find BbFactoryActivationManifestKeyHash node NOTE: Unable to find BbSkeyId node DEBUG: Applying restore request rules for entry AppleLogo DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry BatteryCharging0 DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry BatteryCharging1 DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry BatteryFull DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry BatteryLow0 DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry BatteryLow1 DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry BatteryPlugin DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry DeviceTree DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry KernelCache DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry LLB DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry OS DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry RecoveryMode DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry RestoreDeviceTree DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry RestoreKernelCache DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry RestoreLogo DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry RestoreRamDisk DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry RestoreSEP DEBUG: Adding ESEC=true to TSS entry DEBUG: Adding EPRO=true to TSS entry DEBUG: Applying restore request rules for entry RestoreTrustCache DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry SEP DEBUG: Adding ESEC=true to TSS entry DEBUG: Adding EPRO=true to TSS entry DEBUG: Applying restore request rules for entry StaticTrustCache DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry ftap DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: No Digest data, using empty value for entry ftap DEBUG: Applying restore request rules for entry ftsp DEBUG: Adding ESEC=true to TSS entry DEBUG: Adding EPRO=true to TSS entry DEBUG: No Digest data, using empty value for entry ftsp DEBUG: Applying restore request rules for entry iBEC DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry iBSS DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry iBoot DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: Applying restore request rules for entry rfta DEBUG: Adding EPRO=true to TSS entry DEBUG: Adding ESEC=true to TSS entry DEBUG: No Digest data, using empty value for entry rfta DEBUG: Applying restore request rules for entry rfts DEBUG: Adding ESEC=true to TSS entry DEBUG: Adding EPRO=true to TSS entry DEBUG: No Digest data, using empty value for entry rfts DEBUG: Waiting for device to disconnect... ERROR: Failed to place device in recovery mode ERROR: Unable to place device into recovery mode from normal mode `

Feb 14 '20 01:02 devhem

I confirm that there is some random issues on detecting iOS devices at recovery mode. I found out that when Windows Update driver (ver 423.36.0.0) is loaded for iOS device (device shows also three instances on Device Manager at Windows ) it is working even worse. It is bit complicated to remove those 423 drivers from use but I was able to do that with NirSoft USBDeView tool. Search for vid 05ac for Apple devices.

Feb 19 '20 07:02 taanders

@taanders Thank you for the hint with USBDeView tool.

I checked the connected devices and they are all using the driver which gets installed alongside with iTunes (e.g. 10.0.18362.1 in that case)

Do you have any further idead what could be the reason? The problem didn't exist a few weeks ago, till now it was working perfectly - with current state in git it's failing on all my tests.

Feb 20 '20 08:02 devhem

I think best way for now is to revert broking changes from commit 767fcceaeb456f5e281a6bd1b3f51713e4989293 until someone figures out how it is not working properly. I think it is something related device detection callbacks.

Feb 20 '20 08:02 taanders

@taanders Thank you for the hint. i made a fork and implemented a #define to switch between old WAIT_FOR (__usleep) method and new mutex method: https://github.com/devhem/idevicerestore/commit/419a60a0b593a9545db66e13929fbae1f842cd15

With the current state + enabled WAIT_FOR it's working again as expected.

@nikias It would be interresting if that problem (more then one connected device leads to the problem) only appears on windows or also on linux with the new mutex-method.

Feb 22 '20 12:02 devhem

Hi @devhem, thanks for your commit. Does your definitions fix also issue with multiple devices or is it still existing? As @nikias wrote before @282:

Ok I pushed some commits, but I ended up not checking for multiple devices and just pick the first one it finds.

_Originally posted by @nikias in https://github.com/libimobiledevice/idevicerestore/issues/282#issuecomment-538976017

I think it acts on Mac like the same:

What platform are you guys on? I tested this on macOS

Originally posted by @nikias in https://github.com/libimobiledevice/idevicerestore/issues/282#issuecomment-536555845

Feb 25 '20 07:02 taanders

Hi all,

i used latest libmobiledevice code (18-5-2020) for restore device on windows 10 Device given ERROR: Device failed to enter restore mode.

when i debug idevicerestore code then below given code it given error...

if (client->mode->index != MODE_RESTORE) { mutex_lock(&client->device_event_mutex); info("Waiting for device to enter restore mode...\n"); cond_wait_timeout(&client->device_event_cond, &client->device_event_mutex, 180000); if (client->mode != &idevicerestore_modes[MODE_RESTORE] || (client->flags & FLAG_QUIT)) { mutex_unlock(&client->device_event_mutex); error("ERROR: Device failed to enter restore mode.\n"); if (delete_fs && filesystem) unlink(filesystem); return -1; } mutex_unlock(&client->device_event_mutex); }

+++++++++++++++++++++++++++ Stashbag created. Getting ApNonce in normal mode... d0 fd 73 4e b0 d8 bc 08 90 67 db c8 20 71 1b a9 ff a8 fb eb Trying to fetch new SHSH blob Getting SepNonce in normal mode... 08 df a5 c7 68 8b 58 c5 9c d6 da 65 73 88 d5 4f 88 84 df 22 Request URL set to https://gs.apple.com/TSS/controller?action=2 Sending TSS request attempt 1... response successfully received Received SHSH blobs Committing stashbag... Stashbag committed! Entering recovery mode... INFO: device serial number is DX3TH4ZCFRC5 Waiting for device to enter restore mode... ERROR: Device failed to enter restore mode. +++++++++++++++++++++++++++++++

May 20 '20 04:05 yogendra123456

@taanders Thank you for the hint. i made a fork and implemented a #define to switch between old WAIT_FOR (__usleep) method and new mutex method: devhem@419a60a

With the current state + enabled WAIT_FOR it's working again as expected.

@nikias It would be interresting if that problem (more then one connected device leads to the problem) only appears on windows or also on linux with the new mutex-method.

Hi @taanders, I am trying to implement your hint with WAIT_FOR, but since I don't code in C, I need some more of your help. When compiling the project code on MacOS Big Sur, I first get a warning about implicit WAIT_FOR, and then the error:

/Library/Developer/CommandLineTools/usr/bin/make  all-recursive
Making all in src
  CC       idevicerestore-idevicerestore.o
  CC       idevicerestore-common.o
  CC       idevicerestore-tss.o
  CC       idevicerestore-fls.o
  CC       idevicerestore-mbn.o
  CC       idevicerestore-img3.o
  CC       idevicerestore-img4.o
  CC       idevicerestore-ftab.o
  CC       idevicerestore-ipsw.o
  CC       idevicerestore-normal.o
  CC       idevicerestore-dfu.o
  CC       idevicerestore-recovery.o
recovery.c:253:2: warning: implicit declaration of function 'WAIT_FOR' is invalid in C99 [-Wimplicit-function-declaration]
        WAIT_FOR(client->mode != &idevicerestore_modes[MODE_RECOVERY] || (client->flags & FLAG_QUIT), 30);
        ^
1 warning generated.
  CC       idevicerestore-restore.o
  CC       idevicerestore-asr.o
  CC       idevicerestore-fdr.o
  CC       idevicerestore-limera1n.o
  CC       idevicerestore-download.o
  CC       idevicerestore-locking.o
  CC       idevicerestore-socket.o
  CC       idevicerestore-thread.o
  CC       idevicerestore-jsmn.o
  CC       idevicerestore-json_plist.o
  CCLD     idevicerestore
Undefined symbols for architecture x86_64:
  "_WAIT_FOR", referenced from:
      _recovery_enter_restore in idevicerestore-recovery.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [idevicerestore] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Jan 24 '21 18:01 singulart

I have found a workaround that fixed it but still I need to do this after every restart of my Windows. I use 3uTools. Go to Toolbox>iTunes Utility>Repair Driver>Advanced Repair>Uninstall the old driver files stored in the system

Once it finishes then you won't have any issues and the device will be detected in Recovery mode.

But I would still like this issue to be fixed in future.

Feb 28 '21 21:02 tausift0

idevicerestore
idevicerestore copied to clipboard

Device failing to enter recovery mode

when i debug idevicerestore code then below given code it given error...

idevicerestore idevicerestore copied to clipboard

Device failing to enter recovery mode

when i debug idevicerestore code then below given code it given error...

idevicerestore
idevicerestore copied to clipboard