これは、私がApple Lightningインターフェイスと関連テクノロジーについて知っている（ほとんど）すべてを説明する私の小さな記事です：Tristar、Hydra、HiFive、SDQ、IDBUSなど。しかし、最初に、少し警告...



この記事は自己責任で読んでください！この情報は、斜めに読んだ多くのアップル内部の資料（データ漏洩、回路図、ソースコード）に基づいています。そしてもちろん、私自身の研究についてです。私はこれまでにそのような研究を行ったことがないことを警告しなければなりません。したがって、この記事では誤った用語または単に奇妙な用語が使用されており、部分的または完全に正しくない可能性があります。



さらに詳しく説明する前に、用語を簡単に理解しましょう。

ライトニングとは？

Lightningは、2012年後半以降、ほとんどのApple iOSデバイスで使用されているデジタルインターフェイスです。古い30ピンコネクタを置き換えました。



上図はコネクタソケット、下図はピン配列です。







コネクタでは、コネクタの両側のピンが同じ順序で接続されていないことに注意してください。したがって、ホストデバイスは、何かを行う前にケーブルの方向を決定する必要があります。



これは常にそうであるとは限りませんが。私が出会ったLightningアクセサリの多くは、コネクタのピン配置がミラー化されています。

TristarとHydraとは何ですか？

Tristarは、Lightningコネクタを備えたすべてのデバイスに組み込まれた集積回路です。それは本質的にマルチプレクサです。







とりわけ、その主な目的は、差し込まれるとすぐにLightningオスコネクタに接続することです-方向、アクセサリIDを決定し、USB、UART、SWDなどの内部インターフェースを適切にルーティングします。



HydraはTristarの新しいバリアントで、iPhone 8 / X以降で使用されています。おそらく最も重要な変更はワイヤレス充電のサポートですが、これはまだ検証されていません







。Tristar/ Hydraの5つの主要な変種を知っています。

• TI THS7383  -iPad mini 1およびiPad 4の第1世代Tristar
  
  
• NXP CBTL1608A1  -iPhone 5およびiPod touch 5の第1世代Tristar
  
  
• NXP CBTL1609A1  -iPod nano 7の謎の第一世代Tristar- ソース
  
  
• NXP CBTL1610Ax-  第2世代のTriStar。iPhone5C / 5S以降で使用され、ワイヤレス充電をサポートしていない他のすべてのデバイスで使用されているようです。複数の世代が存在します（xは世代番号です）
  
  
• NXP CBTL1612Ax  -HydraはiPhone 8 / Xで使用されており、ワイヤレス充電をサポートする他のすべてのものと思われます。複数の世代が存在します（xは世代番号です）

今後はTriStarという用語のみを使用しますが、このテキストで説明するほとんどの点で非常に類似しているため、これもHydraの略であることを覚えておいてください。

HiFiveとは何ですか？

HiFiveは、Lightningの子、つまりプラグコネクタです。これには論理ゲートも含まれています-このチップはSN2025 / BQ2025として知られています。

SDQおよびIDBUSとは何ですか？

これら2つの用語は、しばしば同義語と見なされます。便宜上、IDBUSという用語のみを使用します。これは、私にとってより正しいように思われるためです（これは、THS7383仕様でこのテクノロジーが呼ばれているものです）。



したがって、IDBUSはTristarとHiFive間の通信に使用されるデジタルプロトコルです。Onewireプロトコルによく似ています。

さあ、始めましょう

TristarとHiFiveの通信を聞いてみましょう。ロジックアナライザー、ジャックとオス型コネクターを備えたLightningライザー、アクセサリ（通常のLightning-to-USBケーブルは適切に機能します）、そしてもちろん、Lightningポートを備えたデバイスを入手してください。



まず、ライザーの両方のIDライン（ピン4と8）にロジックアナライザーチャネルを接続し、ボードをデバイスに接続しますが、アクセサリはまだ接続しないでください。







その直後にサンプリングを開始します（2 MHz以上の任意の周波数で可能です）。次のようなものが表示されます。







ご覧のように、Tristarは各ID行を順番にポーリングします。しかし、アクセサリを接続しなかったため、調査は明らかに失敗しました。ある時点で、デバイスはこの無限の障害の流れにうんざりして停止します。とりあえず、ポーリング中に正確に何が起こるか見てみましょう。







最初に、レベルが高いだけの長い間隔（約1.1ミリ秒）が表示されますが、他には何も起こりません。







明らかに、この時間は内部HiFiveコンデンサーを充電するために使用されます-それからのエネルギーは内部ロジックチップに電力を供給するために使用されます。



さらに興味深いのは、次に何が起こるかです。







明らかに、これはいくつかのデータのストリームです。しかし、それをどのように解釈するのですか？解読する方法は？事実上、それを最小限の重要な部分に分割しましょう-私が言葉と呼ぶもの：







実際、言葉は落下-上昇-落下の組み合わせです：

• コンテンツステージ -単語の意味を決定する間隔
  
  
• 回復フェーズ -受信側でコンテンツフェーズを処理するため、および/または送信フェーズで次のワードを準備するために明らかに必要な間隔

これは、上で説明した両方のステージの間隔と有名な単語の表です（すべての単位はマイクロ秒単位）。



* STOPは、これがバイトの最後のビットである場合に使用され



ます。上記の表を使用して、単純なプロトコルデコーダーを構築できるようになりました。







ご覧のように、ホストが最初にBREAKを送信します。Tristarが新しいリクエストを送信する場合、ホストは常にそのワードで始まります。次に、データ転送ステージが始まります。バイトの最後（8番目）のビットは回復フェーズが長いことに注意してください。データ転送フェーズが終了すると、ホストは別のBREAKを送信します。次に、子は応答を送信する必要があります（少なくとも2.5マイクロ秒の遅延の後-表を参照）。 Tristarは約2.2ms待機します。この時間内に応答がない場合、Tristarは別のID行に問い合わせを試みます。



次に、上記の例を使用してデータステージを見てみましょう- 0x74 0x00 0x02 0x1f：

• 0x74 -リクエスト/レスポンスのタイプ。リクエストの場合は常に偶数、レスポンスの場合は奇数（リクエストタイプ+1）
  
  
• 0x00 0x02 -事実データ。空の場合があります
  
  
• 0x1f -これは、要求タイプバイトとすべてのデータの両方のCRC8です（多項式-0x31、初期値-0xff）

いくつかのアクセサリをリグに接続して、何が起こるか見てみましょう。私はAppleのオリジナルのLightning-to-USBケーブルを使用します：







0x74リクエストの後にIDBUSに表示されるものは次の







とおりです：HiFiveが回答しました！さらにスクロールすると、他の多くのリクエスト/レスポンスのペアが







表示されます。一部のリクエストはレスポンスを必要としません。

IDBUS要求と応答の解釈

最も重要なIDBUS要求は0x74であり、2つの目的で使用されます：HiFiveに全電圧とアンペア数（アクセサリーでサポートされている場合）をオンにするように指示すること、ケーブルがサポートするピン構成、およびその他のメタデータを確認すること。



0x75応答データのエンコード方法についてはあまり知られていません。ただし、一部のビットは古いTristar仕様で使用できます。



最初の応答データバイト0x75



ID0でIDが見つかった場合のACCx構成



IDがID1で見つかった場合のACCx構成



ID0でIDが見つかった場合のDx構成



IDがID1で見つかった場合のDx構成



これらのテーブルを使用し10 0C 00 00 00 00て、IDラインがID0ピンにあるという事実を考慮して、ケーブルのID（）を解読してみましょう：



0x75ケーブル応答の最初のバイト



つまり、ACCxは00です。これは、ID0ピンが単にIDBUSに接続されていることを意味し、Dx = 01は、DP1 / DN1ピンがUSB0_DP / USB0_DNとして構成されていることを意味します。標準のUSBケーブルに期待していたとおりです。



次に、もっと面白いものを傍受しましょう：





（？）ここからIDBUS要求の完全な一覧です@spbdimkaは：







ヒント＃1：あなたは簡単にaccctlを使用して、そのIDを含む付属品の性質を得ることができます。





これはNonUI / InternalUIアセンブリに付属している内部アップルのユーティリティです。ただし、脱獄後はどのデバイスでも簡単に実行できます。



ヒント2：診断を使用してケーブルのピン構成を簡単に取得できます。

tristar -p

このコマンドはiOS 7以降でのみ使用できます。



ヒント3：debugenv varを3に設定すると、SWDプローブによって生成された0x74 / 0x75リクエスト/レスポンスを簡単に追跡できます。

astrisctl setenv debug 3

次に、ケーブルからの仮想COMで、次のようなものが表示されます。

ホストID

上記の表の1つで、特定のHOSTIDについて言及しています。これは、0x74要求で渡される16ビット値です。HiFiveの回答にも影響しているようです。少なくとも、無効な値に設定した場合（はい、診断で可能です）、HiFiveはその操作を停止します。





ただし、KongSWD / KanziSWDファームウェアには、無効なHOSTIDを無視するように構成できる環境変数disableIdCheckがあります。

重要な注意： KongとKanziには、プログラム不可能な専用チップとしてのHiFiveはありません。これらのアクセサリは、マイクロコントローラおよび/またはFPGAでエミュレートし、更新/再プログラミングを容易にします。

ウェイク

上記のアクセサリIDの表では、Astrisが実行されているかどうかに応じて、KongとKanziが異なる応答を送信していることがわかります。これは、SWDプローブ（またはプローブ）でデバッグするAppleの内部ソフトウェアです。上記の表を使用してこれらの回答を解読すると、Astrisが起動に失敗した場合、プローブはDCSD-D1回線のUSBとまったく同じように動作し、D2回線のUARTをデバッグします。ただし、デバッグソフトウェアの実行中は、ACCIDラインがSWDに切り替わります。



しかし、プローブがすでにデバイスに接続されている後にAstrisを起動したい場合はどうでしょうか？ケーブルは何をしますか？ ACCとSWD回線をどのように切り替えますか？これがWAKEの出番です！ HiFive（またはそれをエミュレートするデバイス）が開始できますWAKE  -とIDBUS列挙プロセスが再び開始します：トライスターは（SoCのはもちろん、物理的なレベルでこれをサポートしている必要があります）、トライスターはそれとSWDの拡張へのセンドACCラインを確認する0x74は、香港/ Kanziは新しいIDで応答しますリクエストを送信します。

パワーハンドシェイク

最後に見ていくのは、パワーハンドシェイクです。これは、Tristarカーネルドライバーがアクセサリの充電を許可する前に使用するIDBUS要求/応答アルゴリズムです。



Lightningケーブルがどこかにあり、充電器/コンピューターに接続されているがデバイスには接続されていない場合、HiFiveはPWRの電流を非常に小さな値（私の測定では約10-15 mA）に制限します。全電流を有効にするには、リクエスト0x74がTristarによって発行され、HiFiveによって処理される必要があります。SecureROM / iBootの場合はこれで十分ですが、カーネルをロードするときに追加の手順を実行する必要があります。

1. TriStarは2つの0x70リクエストを発行します
   
   
2. 2番目の要求がHiFiveによって処理され、応答が送信されるとすぐに、約20ミリ秒間電流をオフにします。
   
   
3. Tristar 0x70, 0x80 . HiFive
   
   
4. , Tristar,

: , . , . ,

ESN Tristar I2C

Tristarのもう1つの特徴は、ESNです。これは、TristarがEEPROM（CBTL1610A2以降）に保存する小さなblobです。これは、シリアル番号リーダーケーブルを使用してIDBUS経由で取得できます（またはKanzi、それらは異なるUSB-PIDとわずかに異なるエンクロージャーを除いて基本的に同じです）



簡単に言うと、このblobをttrs.apple.comに送信することで、デバイスのシリアル番号を取得できます... このメカニズムは、（トライスターがまだ生きている場合）、死者のデバイスからSNを取得するためにアップルストア/アップルプレミアムリセラーの従業員によって使用されます







ESNを受信したとき、IDBUSに何が起こる@spbdimka文書化：

トレーニング

「ファームウェア»ESNの手順では、Tristar トレーニング（プロビジョニング）が必要でした。これは、3つのステップで受信側のEzLinkを介して、デバイス側の診断で行われます。



診断を使用してステータスを確認できます。

tristar --prov_stat

...そしてESNも取得します：

tristar --esn

ちなみに、diagには通常、Tristarコマンドの豊富なセットがあります（iOS 7以降で利用可能）：

Tristar I2C

TristarはI2Cバスで利用できます（書き込み用のアドレス0x34、読み取り用の0x35）。これは、diagおよびカーネルドライバーが対話する方法です。あまりされて公に知られている



レジストリについて。レジスタマップ自体に関する多くの情報は、リークされたiBootソースコードから取得できます（THS7383の場合のみ-CBTL1608およびCBTL1610と下位互換性があるようです）。興味深い結果を得るには、そこに何を書き込む必要があるかについてはあまり詳しくありません。 もう1つの知識源は、diagsからのTristarモジュールです（実行中にSWDから簡単に取得できます）。たとえば、プロビジョニングとESN読み取りアルゴリズムを逆にすることができました。次に、これをLinaというiBootの負荷への追加として実装しました。











また、ESN書き込みアルゴリズムを変更しようとしましたが、失敗しました。メカニズムが複雑すぎるためです。ただし、Linaのコードスニペットはこちらから入手できます。

Tristarの電気的特性

Tristar自体は1.8V電源で動作します。私のオシロスコープによれば、IDBUSのラインは3.0Vトレラントです。







したがって、レベルシフト回路がないと、一部のArduinoモデルのような5Vトレラントデバイスを使用してIDBUSと通信しようとしない方が良いです。 ...