Este es mi pequeño artículo que describe (casi) todo lo que sé sobre la interfaz Apple Lightning y las tecnologías relacionadas: Tristar, Hydra, HiFive, SDQ, IDBUS, etc. Pero primero, una pequeña advertencia ... ¡



Lea este artículo bajo su propio riesgo! La información se basa en muchos materiales internos de Apple Internal (filtraciones de datos, esquemas, códigos fuente) que leo en diagonal. Y, por supuesto, en mi propia investigación. Debo advertirte que nunca antes había hecho semejante investigación. Por lo tanto, este artículo puede estar usando términos incorrectos o simplemente extraños y puede ser parcial o completamente incorrecto.



Antes de profundizar, comprendamos brevemente los términos:

¿Qué es el rayo?

Lightning es la interfaz digital utilizada en la mayoría de los dispositivos iOS de Apple desde finales de 2012. Reemplazó el viejo conector de 30 pines.



La imagen de arriba es el zócalo del conector, y la imagen de abajo es su pinout:







tenga en cuenta que en el conector, los pines en ambos lados del conector no están conectados en el mismo orden. Por lo tanto, el dispositivo host debe determinar la orientación del cable antes de hacer nada.



Aunque este no es siempre el caso. Muchos accesorios Lightning con los que me he encontrado tienen pines reflejados en los conectores.

¿Qué son Tristar e Hydra?

Tristar es un circuito integrado integrado en cada dispositivo con un conector Lightning. Es esencialmente un multiplexor:







entre otras cosas, su propósito principal es conectarse al conector macho Lightning tan pronto como esté enchufado, para determinar la orientación, ID de accesorio y enrutar adecuadamente las interfaces internas como USB, UART y SWD.



Hydra es una nueva variante de Tristar, utilizada desde el iPhone 8 / X. Probablemente el cambio más significativo es la compatibilidad con la carga inalámbrica, pero esto aún no se ha verificado:







conozco cinco variantes principales del Tristar / Hydra:

• TI THS7383  - Tristar de primera generación en iPad mini 1 y iPad 4
  
  
• NXP CBTL1608A1  - Tristar de primera generación en iPhone 5 y iPod touch 5
  
  
• NXP CBTL1609A1  - misterioso Tristar de primera generación en iPod nano 7 - fuente
  
  
• NXP CBTL1610Ax  : TriStar de segunda generación, usado desde iPhone 5C / 5S y aparentemente en todo lo demás que no admite carga inalámbrica. Existen varias generaciones (x es el número de generación)
  
  
• NXP CBTL1612Ax  : Hydra se usa con iPhone 8 / X y aparentemente todo lo demás que admite carga inalámbrica. Existen varias generaciones (x es el número de generación)

De ahora en adelante solo usaré el término TriStar, pero tenga en cuenta que también significa Hydra, ya que son muy similares en la mayoría de los aspectos que se tratarán en este texto.

¿Qué es HiFive?

HiFive es un hijo de Lightning, es decir, un conector de enchufe. También contiene una puerta lógica: este chip se conoce como SN2025 / BQ2025.

¿Qué son SDQ e IDBUS?

Los dos términos a menudo se consideran sinónimos de tipo. Por conveniencia, solo usaré el término IDBUS, ya que me parece más correcto (y así es como se llama la tecnología en la especificación THS7383).



Entonces, IDBUS es un protocolo digital utilizado para la comunicación entre Tristar y HiFive. Muy similar al protocolo Onewire .

Ahora podemos empezar

Escuchemos las comunicaciones Tristar y HiFive. Obtenga un analizador lógico, un elevador Lightning con un conector y un conector macho, un accesorio (un cable Lightning a USB normal funciona muy bien) y, por supuesto, un dispositivo con un puerto Lightning.



Primero, conecte los canales del analizador lógico a las dos líneas de identificación del elevador (pines 4 y 8) y conecte la placa al dispositivo, pero todavía no conecte el accesorio:







inmediatamente después de eso, comience a tomar muestras (cualquier frecuencia de 2 MHz o superior servirá). Verás algo como esto:







Como puede ver, Tristar sondea cada línea de identificación, una tras otra. Pero como no conectamos ningún accesorio, la encuesta claramente fracasó. En algún momento, el dispositivo se cansará de este flujo interminable de fallas y lo detendrá. Por ahora, veamos qué sucede exactamente durante la encuesta:







Primero, vemos un intervalo largo (aproximadamente 1.1 milisegundos), cuando el nivel es simplemente alto, pero no sucede nada más:







Aparentemente, esta vez se usa para cargar el condensador interno HiFive; la energía de este se utilizará para alimentar los chips lógicos internos.



Mucho más interesante es lo que sucede a continuación:







Obviamente, esta es una secuencia de algunos datos. ¿Pero cómo interpretarlo? ¿Cómo descifrar? Dividámoslo virtualmente en partes mínimas significativas, lo que yo llamo palabras : de







hecho, una palabra es una combinación de caída-subida-caída:

• Etapa de contenido : el intervalo que determina el significado de la palabra
  
  
• Fase de recuperación : el intervalo que aparentemente se requiere para procesar la fase de contenido en el lado del receptor y / o preparar la siguiente palabra en la fase de envío

Aquí hay una tabla de palabras famosas con su espaciado para ambas etapas que discutimos anteriormente (todas las unidades en microsegundos):



* STOP se usa cuando este es el último bit en un byte.



Usando la tabla anterior, ahora podemos construir un decodificador de protocolo simple:







como puede ver, el host envía un BREAK primero; cuando Tristar quiere enviar una nueva solicitud, el host siempre comienza con esa palabra. Luego viene la etapa de transferencia de datos. Tenga en cuenta que el último (8º) bit en un byte tiene una fase de recuperación más larga. Cuando finaliza la fase de transferencia de datos, el host envía otro BREAK. El niño debe enviar una respuesta (después de un retraso de al menos 2.5 microsegundos, consulte la tabla). Tristar esperará alrededor de 2.2ms por una respuesta. Si no se da respuesta dentro de este plazo, Tristar intentará interrogar a otra línea de identificación.



Ahora veamos la etapa de datos usando el ejemplo anterior 0x74 0x00 0x02 0x1f:

• 0x74 - tipo de solicitud / respuesta. Siempre par para una solicitud e impar para una respuesta (tipo de solicitud +1)
  
  
• 0x00 0x02 - datos de hecho. Puede estar vacío
  
  
• 0x1f - este es el CRC8 tanto del byte de tipo de solicitud como de todos los datos (polinomio - 0x31, valor inicial - 0xff)

Conectemos algún accesorio a nuestro equipo y veamos qué sucede.







Usaré el cable Lightning a USB original de Apple: y esto es lo que aparece en IDBUS después de la solicitud







0x74 : ¡ HiFive respondió! Y si se desplaza más, verá muchos otros pares de solicitud / respuesta:







Algunas solicitudes no necesitan una respuesta:

Interpretación de solicitudes y respuestas de IDBUS

La solicitud IDBUS más importante es 0x74, se usa para dos propósitos: decirle a HiFive que active el voltaje completo y el amperaje (si es compatible con el accesorio), preguntarle sobre la configuración del pin que admite el cable y algunos otros metadatos.



No se sabe mucho acerca de cómo se codifican los datos de respuesta 0x75. Pero algunos bits están disponibles en la antigua especificación de Tristar:



primer byte de datos de respuesta 0x75



Configuración de ACCx cuando se encuentra ID en ID0



Configuración de ACCx cuando se encuentra ID en ID1



Dx config cuando se encuentra ID en ID0



Dx config cuando se encuentra ID en ID1



Usando estas tablas, descifremos la ID de nuestro cable ( 10 0C 00 00 00 00), teniendo en cuenta el hecho de que la línea de ID se encuentra en el pin ID0:



el primer byte de la respuesta del cable 0x75



Entonces ACCx es 00, esto significa que el pin ID0 simplemente está vinculado a IDBUS, y Dx = 01 significa que los pines DP1 / DN1 están configurados como USB0_DP / USB0_DN. Exactamente lo que esperábamos de un cable USB estándar.



Ahora interceptemos algo más interesante:





Aquí hay una lista completa (?) De solicitudes IDBUS de @spbdimka :







Consejo # 1 : Puede obtener fácilmente las propiedades de un accesorio, incluida su ID usando accctl:





Esta es una utilidad interna de Apple que viene con ensamblajes NonUI / InternalUI. Pero puede ejecutarlo fácilmente en cualquier dispositivo después del jailbreak.



Consejo # 2 : Puede obtener fácilmente la configuración de pines de un cable usando diags:

tristar -p

Tenga en cuenta que este comando solo está disponible en iOS 7+.



Consejo # 3 : Puede rastrear fácilmente las solicitudes / respuestas 0x74 / 0x75 generadas por las sondas SWD configurando debugenv var en 3:

astrisctl setenv debug 3

Luego, en el COM virtual del cable, verá algo como esto:

HOSTID

En una de las tablas anteriores, puede ver la mención de un determinado HOSTID. Este es el valor de 16 bits pasado en la solicitud 0x74. Parece que también afecta la respuesta de HiFive. Al menos si lo configura en un valor no válido (sí, es posible con diags), HiFive deja de funcionar con él:





Sin embargo, el firmware KongSWD / KanziSWD tiene una variable de entorno disableIdCheck, que puede configurar para ignorar el HOSTID no válido.

Nota importante: Kong y Kanzi no tienen HiFive como un chip dedicado no programable. Estos accesorios lo emulan con un microcontrolador y / o FPGA, lo que facilita su actualización / reprogramación.

DESPERTAR

En la tabla de ID de accesorios anterior, puede ver que Kong y Kanzi envían diferentes respuestas dependiendo de si Astris se está ejecutando o no, que es el software interno de Apple para la depuración con sondas SWD (o sondas). Si descifra estas respuestas usando las tablas anteriores, encontrará que cuando Astris no se inicia, la sonda actuará exactamente como DCSD - USB en líneas D1 y depurará UART en líneas D2. Pero cuando el software de depuración se está ejecutando, las líneas ACCID cambian a SWD.



Pero, ¿qué sucede si queremos iniciar Astris después de que la sonda ya esté conectada al dispositivo? ¿Qué hará el cable? ¿Cómo cambiará entre ACC a líneas SWD? ¡Aquí es donde entra en juego WAKE ! HiFive (o un dispositivo que lo emula) puede iniciarDESPERTAR  - y el proceso de enumeración IDBUS comenzará nuevamente: Tristar enviará una solicitud 0x74, Kong / Kanzi responderá con una nueva ID, Tristar lo confirmará y enviará líneas ACC a las extensiones SWD (SoC debe admitir esto en el nivel físico, por supuesto).

Apretón de manos

Lo último que voy a ver son los poderosos apretones de manos. Este es un algoritmo de solicitud / respuesta IDBUS que utilizan los controladores del núcleo Tristar antes de permitir la carga de accesorios.



Cuando el cable Lightning simplemente se encuentra en algún lugar, conectado al cargador / computadora, pero no conectado al dispositivo, HiFive limita la corriente en el PWR a un valor realmente pequeño (aproximadamente 10-15 mA según mis mediciones). Para habilitar la corriente completa, Tristar debe emitir la solicitud 0x74 y HiFive debe procesarla. Para SecureROM / iBoot, esto es suficiente, pero se deben tomar pasos adicionales al cargar el kernel:

1. TriStar emite dos solicitudes 0x70
   
   
2. Tan pronto como HiFive procesa la segunda solicitud y se envía una respuesta, apaga la corriente por completo durante aproximadamente 20 milisegundos
   
   
3. Tristar 0x70, 0x80 . HiFive
   
   
4. , Tristar,

: , . , . ,

ESN Tristar I2C

Otra característica de Tristar de la que me gustaría hablar es ESN. Este es un pequeño blob que Tristar almacena en su EEPROM (en CBTL1610A2 y posterior). Se puede obtener a través de IDBUS usando el cable del lector de número de serie (o Kanzi, son básicamente los mismos, excepto por diferentes PID USB y gabinetes ligeramente diferentes)



Simplemente, enviando este blob a ttrs.apple.com , puede obtener el número de serie del dispositivo ... Los empleados de Apple Store / Apple Premium Reseller utilizan este mecanismo para recuperar SN de dispositivos muertos (si Tristar todavía está vivo):







lo que sucede en IDBUS cuando se recibe un ESN, @spbdimka documentó :

Formación

El procedimiento para "Firmware» ESN solicitó capacitación de Tristar (aprovisionamiento). Se lleva a cabo con diagnósticos en el lado del dispositivo, a través de EzLink en el lado receptor en tres pasos.



Puede verificar el estado usando diags:

tristar --prov_stat

... y también obtener ESN:

tristar --esn

Por cierto, los diags generalmente tienen un rico conjunto de comandos Tristar (disponible desde iOS 7):

Tristar I2C

Tristar está disponible en el bus I2C (dirección 0x34 para escritura, 0x35 para lectura). Así es como interactúan los controladores diag y kernel. No se sabe mucho públicamente



sobre los registros . Se puede obtener mucha información sobre el mapa de registro en sí mismo del código fuente filtrado de iBoot (solo para THS7383, parece ser compatible con versiones anteriores de CBTL1608 y CBTL1610), pero no mucho sobre lo que se debe escribir allí para lograr resultados interesantes. Otra fuente de conocimiento es el módulo Tristar de diags (recuperado fácilmente a través de SWD mientras se está ejecutando). Por ejemplo, pude revertir el aprovisionamiento y los algoritmos de lectura ESN. Luego implementé esto como una adición a mi carga para iBoot llamada Lina :











También intenté cambiar el algoritmo de escritura de ESN pero fallé: el mecanismo es demasiado complicado para mí. Sin embargo, los fragmentos de código de Lina están disponibles aquí .

Características eléctricas del Tristar.

El propio Tristar está alimentado por un suministro de 1.8 V. Las líneas para IDBUS son tolerantes a 3.0 V, según mi osciloscopio: por lo







tanto, sin un circuito de cambio de nivel, es mejor no intentar comunicarse con IDBUS utilizando dispositivos tolerantes a 5 V como algunos modelos Arduino ...