Voici mon petit article décrivant (presque) tout ce que je sais sur l'interface Apple Lightning et les technologies associées: Tristar, Hydra, HiFive, SDQ, IDBUS, etc. Mais d'abord, un petit avertissement ...



Lisez cet article à vos risques et périls! Les informations sont basées sur un grand nombre de documents internes Apple internes (fuites de données, schémas, codes sources) que je lis en diagonale. Et, bien sûr, sur mes propres recherches. Je dois vous avertir que je n'ai jamais fait de telles recherches auparavant. Par conséquent, cet article peut utiliser des termes incorrects ou simplement étranges et être partiellement ou complètement incorrect!



Avant de plonger plus profondément, comprenons brièvement les termes:

Qu'est-ce que Lightning?

Lightning est l'interface numérique utilisée dans la plupart des appareils Apple iOS depuis fin 2012. Il a remplacé l'ancien connecteur à 30 broches.



L'image ci-dessus est la prise du connecteur, et l'image ci-dessous est son brochage:







Veuillez noter que dans le connecteur, les broches des deux côtés du connecteur ne sont pas connectées dans le même ordre. Ainsi, le périphérique hôte doit déterminer l'orientation du câble avant de faire quoi que ce soit.



Bien que ce ne soit pas toujours le cas. De nombreux accessoires Lightning que j'ai rencontrés ont des broches en miroir dans les connecteurs.

Que sont Tristar et Hydra?

Tristar est un circuit intégré intégré à chaque appareil avec un connecteur Lightning. Il s'agit essentiellement d'un multiplexeur:







entre autres, son objectif principal est de se connecter au connecteur Lightning mâle dès qu'il est branché - pour déterminer l'orientation, l'ID d'accessoire et acheminer correctement les interfaces internes telles que USB, UART et SWD.



Hydra est une nouvelle variante de Tristar, utilisée depuis l'iPhone 8 / X. Le changement le plus important est probablement la prise en charge de la charge sans fil, mais cela reste à vérifier:







je connais cinq variantes principales du Tristar / Hydra:

• TI THS7383  - Tristar de première génération sur iPad mini 1 et iPad 4
  
  
• NXP CBTL1608A1  - Tristar de première génération sur iPhone 5 et iPod touch 5
  
  
• NXP CBTL1609A1  - Tristar mystérieux de première génération dans l'iPod nano 7 - source
  
  
• NXP CBTL1610Ax  - TriStar de deuxième génération, utilisé depuis l'iPhone 5C / 5S et apparemment dans tout le reste qui ne prend pas en charge la charge sans fil. Plusieurs générations existent (x est le numéro de génération)
  
  
• NXP CBTL1612Ax  - Hydra est utilisé avec l'iPhone 8 / X et apparemment tout ce qui prend en charge la charge sans fil. Plusieurs générations existent (x est le numéro de génération)

À partir de maintenant, je n'utiliserai que le terme TriStar, mais gardez à l'esprit qu'il signifie également Hydra car ils sont très similaires dans la plupart des aspects qui seront couverts dans ce texte.

Qu'est-ce que HiFive?

HiFive est un enfant de Lightning, c'est-à-dire un connecteur. Il contient également une porte logique - cette puce est connue sous le nom de SN2025 / BQ2025.

Que sont SDQ et IDBUS?

Les deux termes sont souvent considérés comme des synonymes. Pour plus de commodité, je n'utiliserai que le terme IDBUS, car il me semble plus correct (et c'est ainsi que la technologie est appelée dans la spécification THS7383).



Ainsi, IDBUS est un protocole numérique utilisé pour la communication entre Tristar et HiFive. Très similaire au protocole Onewire .

Maintenant nous pouvons commencer

Écoutons les communications Tristar et HiFive. Procurez-vous un analyseur logique, une colonne montante Lightning avec une prise et un connecteur mâle, un accessoire (un câble Lightning vers USB classique fonctionne très bien) et bien sûr un appareil avec un port Lightning.



Tout d'abord, connectez les canaux de l'analyseur logique aux deux lignes d'identification de la colonne montante (broches 4 et 8) et connectez la carte à l'appareil, mais ne connectez pas encore l'accessoire:







Immédiatement après cela, commencez l'échantillonnage (toute fréquence de 2 MHz ou plus fera l'affaire). Vous verrez quelque chose comme ceci:







Comme vous pouvez le voir, Tristar interroge chaque ligne d'identification à tour de rôle, l'une après l'autre. Mais comme nous n'avons branché aucun accessoire, l'enquête a clairement échoué. À un moment donné, l'appareil se fatiguera de ce flux sans fin de pannes et l'arrêtera. Pour l'instant, voyons ce qui se passe exactement pendant le sondage:







Premièrement, nous voyons un long intervalle (environ 1,1 millisecondes), lorsque le niveau est juste élevé, mais rien d'autre ne se passe:







Apparemment, cette fois est utilisée pour charger le condensateur HiFive interne - l'énergie qui en découle sera ensuite utilisée pour alimenter les puces logiques internes.



Ce qui se passe ensuite est beaucoup plus intéressant: il s'agit







évidemment d'un flux de données. Mais comment l'interpréter? Comment décrypter? Divisons-le virtuellement en parties significatives minimales - ce que j'appelle des mots :







en fait, un mot est une combinaison de chute-montée-chute:

• Étape du contenu - l'intervalle qui détermine la signification du mot
  
  
• Phase de récupération - l'intervalle qui est apparemment nécessaire pour traiter la phase de contenu du côté du récepteur et / ou pour préparer le mot suivant à la phase d'envoi

Voici un tableau de mots célèbres avec leur espacement pour les deux étapes dont nous avons discuté ci-dessus (toutes les unités en microsecondes):



* STOP est utilisé lorsqu'il s'agit du dernier bit d'un octet.En



utilisant le tableau ci-dessus, nous pouvons maintenant construire un décodeur de protocole simple:







comme vous pouvez le voir, l'hôte envoie d'abord un BREAK - lorsque Tristar veut envoyer une nouvelle demande, l'hôte commence toujours par ce mot. Vient ensuite l'étape du transfert de données. Veuillez noter que le dernier (8e) bit d'un octet a une phase de récupération plus longue. Lorsque la phase de transfert de données se termine, l'hôte envoie un autre BREAK. L'enfant doit alors envoyer une réponse (après un délai d'au moins 2,5 microsecondes - voir tableau). Tristar attendra environ 2,2 ms pour une réponse. Si aucune réponse n'est donnée dans ce laps de temps, Tristar essaiera d'interroger une autre ligne d'identification.



Regardons maintenant l'étape des données en utilisant l'exemple ci-dessus - 0x74 0x00 0x02 0x1f:

• 0x74 - type de demande / réponse. Toujours pair pour une requête et impair pour une réponse (type de requête +1)
  
  
• 0x00 0x02 - données factuelles. Peut être vide
  
  
• 0x1f - c'est le CRC8 de l'octet de type de requête et de toutes les données (polynôme - 0x31, valeur initiale - 0xff)

Connectons un accessoire à notre plate-forme et voyons ce qui se passe. J'utiliserai le câble Lightning vers USB original d'Apple:







Et voici ce qui apparaît sur IDBUS après la requête







0x74 : HiFive a répondu! Et si vous faites défiler plus loin, vous verrez de nombreuses autres paires demande / réponse:







certaines demandes n'ont pas besoin de réponse:

Interprétation des demandes et réponses IDBUS

La requête IDBUS la plus importante est 0x74, elle est utilisée à deux fins: pour dire à HiFive d'activer la tension et l'ampérage complets (si pris en charge par l'accessoire), pour lui demander la configuration des broches prise en charge par le câble et d'autres métadonnées.



On ne sait pas grand-chose sur la façon dont les données de réponse 0x75 sont codées. Mais certains bits sont disponibles dans l'ancienne spécification Tristar:



premier octet de données de réponse 0x75



Configuration ACCx lorsque l'ID est trouvé sur ID0



Config ACCx lorsque l'ID est trouvé sur ID1



Dx config quand ID est trouvé sur ID0



Dx config lorsque l'ID est trouvé sur ID1



À l'aide de ces tableaux, déchiffrons l'ID de notre câble ( 10 0C 00 00 00 00), en tenant compte du fait que la ligne ID se trouve sur la broche ID0:



Le premier octet de la réponse du câble 0x75



Donc ACCx est 00, cela signifie que la broche ID0 est simplement liée à IDBUS, et Dx = 01 signifie que les broches DP1 / DN1 sont configurées comme USB0_DP / USB0_DN. Exactement ce que nous attendions d'un câble USB standard.



Maintenant, interceptons quelque chose de plus intéressant:





Voici une liste complète (?) Des requêtes IDBUS de @spbdimka :







Astuce n ° 1 : Vous pouvez facilement obtenir les propriétés d'un accessoire, y compris son ID, en utilisant accctl:





Il s'agit d'un utilitaire Apple interne fourni avec les assemblys NonUI / InternalUI. Mais vous pouvez facilement l'exécuter sur n'importe quel appareil après le jailbreak.



Astuce n ° 2 : Vous pouvez facilement obtenir la configuration des broches d'un câble à l'aide de diags:

tristar -p

Veuillez noter que cette commande n'est disponible que sur iOS 7+.



Conseil n ° 3 : Vous pouvez facilement suivre les requêtes / réponses 0x74 / 0x75 générées par les sondes SWD en définissant debugenv var sur 3:

astrisctl setenv debug 3

Ensuite, sur le COM virtuel du câble, vous verrez quelque chose comme ceci:

HOSTID

Dans l'un des tableaux ci-dessus, vous pouvez voir la mention d'un certain HOSTID. Il s'agit de la valeur 16 bits transmise dans la requête 0x74. Il semble que cela affecte également la réponse de HiFive. Au moins si vous le définissez sur une valeur invalide (oui, c'est possible avec diags), HiFive arrête de fonctionner avec lui:





Cependant, le micrologiciel KongSWD / KanziSWD a une variable d'environnement disableIdCheck, que vous pouvez configurer pour ignorer le HOSTID invalide.

Remarque importante: Kong et Kanzi n'ont pas HiFive comme puce non programmable dédiée. Ces accessoires l'émulent avec un microcontrôleur et / ou FPGA, ce qui facilite sa mise à jour / reprogrammation.

RÉVEILLER

Dans le tableau des ID d'accessoires ci-dessus, vous pouvez voir que Kong et Kanzi envoient des réponses différentes selon qu'Astris est en cours d'exécution ou non, qui est le logiciel interne d'Apple pour le débogage avec des sondes SWD (ou sondes). Si vous déchiffrez ces réponses en utilisant les tableaux ci-dessus, vous constaterez que lorsque Astris ne démarre pas, la sonde agira exactement comme DCSD - USB sur les lignes D1 et déboguera UART sur les lignes D2. Mais lorsque le logiciel de débogage est en cours d'exécution, les lignes ACCID basculent vers SWD.



Mais que se passe-t-il si nous voulons lancer Astris après que la sonde soit déjà connectée à l'appareil? Que fera le câble? Comment basculera-t-il entre les lignes ACC et SWD? C'est là que WAKE entre en jeu! HiFive (ou un appareil qui l'émule) peut lancerWAKE  - et le processus d'énumération IDBUS recommencera: Tristar enverra une requête 0x74, Kong / Kanzi répondra avec un nouvel ID, Tristar le confirmera et enverra des lignes ACC aux extensions SWD (le SoC doit prendre en charge cela au niveau physique, bien sûr).

Poignée de main puissante

La dernière chose que je vais regarder, ce sont les poignées de main puissantes. Il s'agit d'un algorithme de demande / réponse IDBUS que les pilotes du noyau Tristar utilisent avant d'autoriser le chargement des accessoires.



Lorsque le câble Lightning se trouve quelque part, connecté au chargeur / ordinateur, mais non connecté à l'appareil, HiFive limite le courant sur le PWR à une très petite valeur (environ 10-15 mA selon mes mesures). Pour activer le courant complet, la requête 0x74 doit être émise par Tristar et traitée par HiFive. Pour SecureROM / iBoot, cela suffit, mais des étapes supplémentaires doivent être prises lors du chargement du noyau:

1. TriStar émet deux requêtes 0x70
   
   
2. Dès que la deuxième requête est traitée par HiFive et qu'une réponse est envoyée, il coupe complètement le courant pendant environ 20 millisecondes
   
   
3. Tristar 0x70, 0x80 . HiFive
   
   
4. , Tristar,

: , . , . ,

ESN Tristar I2C

Une autre caractéristique de Tristar dont je voudrais parler est ESN. Il s'agit d'un petit objet blob que Tristar stocke dans son EEPROM (sur CBTL1610A2 et versions ultérieures). Il peut être obtenu sur IDBUS en utilisant le câble Serial Number Reader (ou Kanzi, ils sont fondamentalement les mêmes sauf pour différents USB-PID et des boîtiers légèrement différents)



En termes simples, en envoyant ce blob à ttrs.apple.com , vous pouvez obtenir le numéro de série de l'appareil ... Ce mécanisme est utilisé par les employés de l'Apple Store / Apple Premium Reseller pour récupérer SN à partir d'appareils morts (si Tristar est toujours en vie):







Que se passe-t-il sur IDBUS lorsqu'un ESN est reçu, @spbdimka a documenté :

Formation

La procédure «Firmware» ESN fait appel à la formation Tristar (provisioning). Il se déroule avec un diagnostic côté appareil, via EzLink côté réception en trois étapes.



Vous pouvez vérifier l'état à l'aide de diags:

tristar --prov_stat

... et obtenez également ESN:

tristar --esn

À propos, les diags ont généralement un riche ensemble de commandes Tristar (disponibles depuis iOS 7):

Tristar I2C

Tristar est disponible sur le bus I2C (adresse 0x34 pour l'écriture, 0x35 pour la lecture). C'est ainsi que les pilotes diag et noyau interagissent avec lui. Les



registres sont peu connus du public . Beaucoup d'informations sur la carte de registre elle-même peuvent être obtenues à partir du code source iBoot divulgué (uniquement pour THS7383 - semble être rétrocompatible avec CBTL1608 - et CBTL1610), mais pas grand-chose sur ce qui doit être écrit pour obtenir des résultats intéressants.



Une autre source de connaissances est le module Tristar de diags (facilement récupéré via SWD pendant son exécution). Par exemple, j'ai pu inverser les algorithmes d'approvisionnement et de lecture ESN. Ensuite, j'ai implémenté ceci en complément de ma charge pour iBoot appelée Lina :







J'ai également essayé de changer l'algorithme d'écriture ESN mais j'ai échoué - le mécanisme est trop compliqué pour moi. Cependant, des extraits de code de Lina sont disponibles ici .

Caractéristiques électriques du Tristar

Le Tristar lui-même est alimenté par une alimentation de 1,8 V. Les lignes pour IDBUS sont tolérantes à 3,0 V, selon mon oscilloscope:







donc sans circuit de décalage de niveau, il est préférable de ne pas essayer de communiquer avec IDBUS en utilisant des appareils tolérants à 5 V comme certains modèles Arduino ...