Restauration iOS / iPadOS depuis Linux

Vérification bloquante — à faire AVANT toute manipulation

Le verrouillage d'activation. Sur un appareil verrouillé, « Localiser » est forcément resté activé (impossible de le désactiver sans déverrouiller). Après restauration, l'appareil exigera l'identifiant Apple et le mot de passe du compte auquel il est lié. Sans eux, il reste bloqué sur l'écran d'activation, définitivement — aucun outil ne contourne cela.

Demander explicitement à l'utilisateur s'il possède ces identifiants avant de lancer quoi que ce soit. Une restauration sans eux transforme un appareil verrouillé mais intact en presse-papier.

Prévoir aussi un accès réseau pour l'appareil à la fin (Wi-Fi configurable dans l'assistant, partage de connexion, ou données mobiles) : l'activation contacte les serveurs Apple.

Demander aussi s'il existe un Mac ou un PC Windows physique accessible. Si oui, le dire franchement : le Finder ou iTunes font la même chose en un clic, sans ligne de commande, sans mode récupération qui expire. Ce skill existe pour le cas où seul Linux est disponible, pas pour rivaliser avec eux. L'IPSW téléchargé ici se réutilise d'ailleurs sous iTunes avec Maj + clic sur « Restaurer » (Alt + clic sur Mac), ce qui évite de le retélécharger. Ne jamais orienter vers une VM Windows en revanche : voir la section dédiée plus bas.

Installation (Ubuntu / Debian)

sudo apt update
sudo apt install -y libimobiledevice-1.0-6 libimobiledevice-utils usbmuxd idevicerestore irecovery

⚠️ Le paquet libimobiledevice6 n'existe pas — c'est libimobiledevice-1.0-6. Beaucoup de tutoriels en ligne donnent le mauvais nom. Vérifier avec apt-cache policy en cas de doute.

irecovery est indispensable au diagnostic : il montre si l'appareil dialogue réellement.

Étape zéro : identifier l'appareil pour de vrai

Ne jamais déduire le modèle du CPID. C'est le code du SoC, pas celui de l'appareil, et plusieurs modèles partagent le même. Se tromper coûte le téléchargement complet d'un IPSW (~10 Go) inutilisable. Vécu : CPID:8120 pris pour un A14 (iPad13,1, iPad Air 4) alors que c'est un A16 (iPad15,7, iPad A16).

Seule source fiable, une fois l'appareil en mode récupération :

sudo irecovery -q      # lignes PRODUCT / MODEL / NAME — c'est CE qu'il faut utiliser

Sans sudo, on obtient déjà l'identité brute (ECID, CPID, BDID, numéro de série) — utile, mais insuffisante pour choisir le firmware :

cat /sys/bus/usb/devices/*/serial | tr ' ' '\n' | grep -E 'CPID|BDID|ECID|SRNM'

idevicerestore refuse heureusement de flasher un IPSW qui ne correspond pas (Could not make sure this firmware is suitable for the current device. Refusing to continue.) : ce message signifie « mauvais firmware », pas « appareil en panne ».

Piège n°1 : le mode restreint USB

Depuis iOS 11.4.1, si l'appareil n'a pas été déverrouillé avec son code depuis plus d'une heure, le connecteur ne fait plus que charger — les lignes de données sont coupées côté appareil.

Conséquence : un appareil verrouillé n'apparaît JAMAIS dans lsusb en mode normal. C'est attendu, pas une panne.

Ne jamais diagnostiquer un câble ou un port avec l'appareil iOS lui-même : port mort et mode restreint donnent un résultat identique. Tester un port avec un périphérique non-Apple (souris, clé USB).

En mode récupération ou DFU, c'est le bootloader qui gère l'USB : le mode restreint ne s'applique plus et l'appareil doit apparaître.

Entrer en mode récupération

Garder le câble branché à l'ordinateur — sans ordinateur détecté au bout du fil, l'appareil démarre normalement au lieu d'entrer en récupération.

iPhone 8 et plus récent, iPad sans bouton Accueil :

1. Volume Haut — presser et relâcher aussitôt (comme un clic)
2. Volume Bas — presser et relâcher aussitôt, enchaîné
3. Bouton latéral / supérieur — maintenir sans relâcher

iPhone 7 / 7 Plus : Volume Bas + bouton latéral maintenus ensemble.

iPhone 6s et antérieur, iPad avec bouton Accueil : bouton Accueil + bouton latéral maintenus ensemble.

Repères de durée (l'erreur la plus fréquente est de relâcher trop tôt) :

• ~10 s → écran noir puis logo Apple — continuer à maintenir, le logo n'est pas la fin
• ~25-30 s → le logo laisse place à l'icône de câble pointant vers un ordinateur → relâcher
• > 40 s de logo Apple seul → c'est raté, recommencer

Sur un appareil figé (barre de progression bloquée après une restauration ratée), la même séquence sert de redémarrage forcé, mais il faut maintenir 30 à 45 s, nettement plus longtemps que d'habitude. Les deux clics volume doivent en outre être vifs et enchaînés (moins d'une seconde chacun, sans pause) : trop lents, la séquence n'est pas reconnue.

Vérifier immédiatement :

lsusb | grep -i 05ac        # 05ac:1281 = recovery | 05ac:1227 = DFU
sudo irecovery -q           # doit afficher CPID, ECID, MODE et surtout NONC

Si NONC est absent, l'appareil ne dialogue pas correctement : ne pas lancer la restauration.

Savoir si la manip a seulement fonctionné : regarder le numéro de Device dans lsusb (Bus 003 Device 018). Tout redémarrage force une réénumération, donc un numéro différent. S'il n'a pas changé, l'appareil n'a pas redémarré du tout — inutile de chercher ailleurs, c'est la séquence de boutons qui n'est pas passée.

Surveiller les changements d'état sans rester devant l'écran :

prev=""; while :; do
  id=$(lsusb | grep -oiE '05ac:[0-9a-f]{4}' | head -1); [ -z "$id" ] && id=absent
  [ "$id" != "$prev" ] && { echo "$(date +%T) -> $id"; prev=$id; }
  sleep 5
done

Piège n°2 : le mode récupération expire (cause d'échec la plus fréquente)

Le mode récupération sort tout seul après ~10 minutes sans recevoir de commande.

idevicerestore -e -l télécharge d'abord l'IPSW (8-10 Go, souvent > 8 min) puis interroge l'appareil. Pendant le téléchargement, aucune commande n'est envoyée : l'appareil décroche et la restauration échoue avec des messages trompeurs :

Device is in an invalid state
Device supports Image4: false
Getting ApNonce failed / Getting SepNonce failed
ERROR: Unable to send TSS request
Unable to get SHSH blobs for this device

Ces erreurs ne signalent ni un problème de câble, ni un refus d'Apple : l'appareil n'était plus connecté.

Toujours procéder en deux temps. Attention, idevicerestore -n -l n'est pas une solution : -l doit connaître le modèle, donc l'appareil doit être connecté — or un appareil verrouillé est invisible en mode normal (mode restreint USB) et décroche du mode récupération pendant les 8-10 minutes de téléchargement. On tourne en rond.

Télécharger l'IPSW hors de idevicerestore, ce qui n'exige aucun appareil connecté :

# 1. Identifier le modèle (irecovery -q, cf. "Étape zéro"), puis lister les firmwares SIGNÉS.
#    Seul un firmware "signed": true est restaurable — Apple cesse de signer les anciennes
#    versions à la sortie d'une nouvelle, et un IPSW non signé devient inutilisable.
curl -s "https://api.ipsw.me/v4/device/iPad15,7?type=ipsw" | python3 -m json.tool | less

# 2. Télécharger avec reprise (-C -), l'appareil peut rester éteint pendant ce temps.
#    NE PAS écrire dans /tmp : c'est souvent un tmpfs en RAM, trop petit pour 10 Go.
#    Vérifier : findmnt -no FSTYPE,SIZE /tmp
mkdir -p ~/ipsw && cd ~/ipsw
curl -4 -L -C - --retry 8 --retry-all-errors -O "<url renvoyée par l'API>"

# 3. Vérifier l'archive AVANT de toucher à l'appareil
unzip -p iPad15,7_*.ipsw BuildManifest.plist | grep -m2 -E 'iPad15,7|j481ap'

# 4. Mettre en mode récupération, puis restaurer depuis le fichier local :
#    démarre en quelques secondes, le compteur des 10 min est largement suffisant
sudo idevicerestore -e "$HOME/ipsw/iPad15,7_26.6.1_23G83_Restore.ipsw"

⚠️ Quoter le chemin : les noms d'IPSW contiennent une virgule (iPhone11,8).

⚠️ La confirmation d'effacement n'accepte que YES en majuscules — yes est refusé. Répondre vite, le compteur du mode récupération tourne.

Piège n°3 : le réseau doit tenir pendant TOUTE la restauration

Le téléchargement de l'IPSW n'est pas le seul moment où le réseau compte. idevicerestore interroge les serveurs Apple plusieurs fois pendant le flash, dont une fois après que le système de fichiers est écrit à 100 %, pour obtenir le ticket Cryptex1. Une coupure de quelques secondes à cet instant fait échouer toute l'opération :

Sending Cryptex1 TSS request...
Unable to fetch Cryptex1 ticket
restore_send_firmware_updater_data: Couldn't get Cryptex1 firmware data
Unable to restore device

L'appareil reste alors figé sur une barre de progression qui n'avance plus — il attend des données que plus personne ne lui envoie. Ce n'est pas une brique : forcer le mode récupération et relancer suffit, et comme l'IPSW est déjà sur disque, la reprise ne prend que ~6 minutes.

Avant de lancer, stabiliser la connexion : si c'est un partage de connexion, poser le téléphone à côté du PC, écran allumé, verrouillage automatique désactivé, et ne rien lancer d'autre de gourmand. Une box filaire est évidemment préférable.

Surveiller la disponibilité d'Apple pendant l'opération, dans un autre terminal :

while :; do
  c=$(curl -4 -sk -o /dev/null --max-time 5 -w '%{http_code}' https://gs.apple.com/TSS/controller)
  [ "$c" != "200" ] && echo "$(date +%T) !!! Apple injoignable ($c)"
  sleep 5
done

⚠️ Le -k est nécessaire : la chaîne de gs.apple.com remonte à Apple Root CA, absente du magasin système, ce que curl signale à tort comme « certificat auto-signé ». Ce n'est pas une interception TLS, et idevicerestore (via libtatsu) n'a pas ce problème.

Pendant la restauration

• Ne jamais débrancher. Une coupure pendant l'écriture du firmware peut rendre l'appareil irrécupérable.
• Empêcher la veille : systemd-inhibit --what=sleep:idle --why="restauration iOS" sleep 3600
• L'appareil change plusieurs fois d'identifiant USB et se déconnecte brièvement : c'est normal.
• Durée typique : ~7 min d'écriture, puis 5-15 min de finalisation par l'appareil lui-même (seconde barre de progression, sans le PC).
• Fin attendue : Done: restoring succeeded. puis l'écran « Bonjour ».

Suivi utile en arrière-plan pendant l'opération :

while :; do
  printf '%s | %s\n' \
    "$(lsusb | grep -oiE '05ac:[0-9a-f]{4}' || echo absent)" \
    "$(pgrep -x idevicerestore >/dev/null && echo ACTIF || echo TERMINE)"
  sleep 10
done

Ne pas proposer une VM Windows

Le passthrough USB en machine virtuelle est la cause classique d'échec des restaurations iOS : l'appareil change d'identité USB trois ou quatre fois et la VM doit le recapturer à chaque transition. Une restauration interrompue en plein flash est le vrai scénario de brique.

De plus, cela ne résout rien : un appareil verrouillé est tout aussi invisible sous Windows (mode restreint USB). Si un autre système est nécessaire, orienter vers une machine physique (Mac/Finder ou Windows/iTunes), ou un Apple Store.

Diagnostic rapide

Notes : l'IPSW n'est pas conservé par -l en mode « download on demand » selon les versions — vérifier le répertoire courant. Un appareil en mode récupération s'énumère toujours en USB 2.0 (480 Mbps) : ce n'est pas un défaut, et le débit du port n'a aucune importance ici. Conserver l'IPSW quelques jours après une restauration réussie : une seconde tentative prend alors 6 minutes au lieu d'une heure.