GhidraでElgato HD60 S HDMIキャプチャデバイスを修理する
(downtowndougbrown.com)- USBで認識されなかった Elgato Game Capture HD60 S は、電源レールを引き下げていた電源IC 3個を交換すると、HDMIキャプチャとパススルーが正常に復旧した
- サーモグラフィー・電圧測定・SMDマーキング検索により、Fitipower FP6373A レギュレータ 2個と TI TPS60403DBV 電圧インバータを特定し、部品代はLCSC基準で 1ドル未満だった
- キャプチャ機能は復活したものの、白色 7個・赤色 7個の ステータスLED は消灯したままだったが、LEDドライバとLEDアレイ自体は Raspberry Pi Pico による直接制御で正常だと確認された
- Ghidra で Nuvoton M031LD2AE ファームウェアと Cypress/Infineon CYUSB3014 用 SPIフラッシュを追跡した結果、0x300000 以降にあるはずの LEDアニメーションデータが空か破損していた
- 正常な HD60 S の LEDデータ領域だけを問題のあるデバイスの SPIフラッシュに合成して書き込むとステータスLEDが復活し、残っていた故障はハードウェアではなくソフトウェア・プログラミング・アップデート経路の問題だった
USBで認識されなかったHD60 Sの電源部修理
- eBayで購入した故障した Elgato Game Capture HD60 S USB 3.0 は、接続してもコンピュータ上に何も現れなかった
- 基板を開けて電圧を測ると、電源レールが低く引き下げられており、サーモグラフィーカメラで発熱しているチップを見つけた
- 問題の部品は小さなマーキングしかない電源ICだった
fiVJVEと表示されたチップ 2個は 2.2µH インダクタの近くにあり、スイッチングレギュレータと推定された- SMDマーキング検索と Fitipower の資料確認を経て FP6373A に絞り込まれた
PFNIと表示されたチップは Google 検索で TI TPS60403DBV 電圧インバータだと確認できた
- この 3つのチップはすべて 5V入力を受けており、出力側の抵抗が低く、ある FP6373A の出力レールに 2.7V を直接注入するとそのレギュレータが発熱した
- FP6373A は LCSC で 1個 $0.17、TI チップは $0.58 で購入でき、送料のほうが部品代よりずっと高かった
部品交換後に残ったステータスLEDの問題
- 3つの電源ICを交換したあと、HD60 S は USBデバイスとして認識され、HDMIキャプチャとパススルーも正常に動作した
- しかし、デバイスの ステータスインジケータ は依然として点灯しなかった
- 白色 LED 7個と赤色 LED 7個がある
- 白色 LED は接続直後に 2回点滅するはずだった
- LED関連チップは Innochip の IT1504 で、データシート上では 16チャネル LEDドライバだった
- オシロスコープで IT1504 の入力ピンを見ると、SPI に似たシリアルトラフィックが入っていた
- PCBを追跡した結果、IT1504 は Nuvoton M031LD2AE ARM Cortex-M0 マイクロコントローラが制御していた
IT1504代替品の探索と回路検証
- IT1504 は一般流通では入手しにくく、Innochip も在庫がフルリール単位しかなくサンプル提供はできなかった
- 代替品を探す過程で Macroblock の MBI5040 を見つけた
- MBI5040 のデータシートは IT1504 のデータシートと構成・ブロック図がほぼ同じだった
- 出力電流の仕様はやや異なっていたが、機能と命令体系は非常によく似ていた
- MBI5040 データシートの命令情報は LED制御方式の把握に役立った
- MBI5040GF を購入して IT1504 の代わりに実装したが、LED はやはり点灯しなかった
- ベンチ電源と抵抗で LED を 1個ずつ点灯させた結果、LED自体は正常 だった
- Raspberry Pi Pico を MBI5040 の入力に直接つないでコマンドを送ると、LED を完全に制御できた
- LEDドライバ回路と LEDアレイには物理的な問題がないと判断した
- 元の IT1504 を再実装しても Pico 制御が正常に動作したため、既存の LEDドライバも故障していなかった
Nuvoton MCUファームウェアをGhidraで解析
- Elgato サポートにステータスLED関連の既知の問題や設定の有無を問い合わせたが、実質的な解決策は得られなかった
- Nuvoton MCU のファームウェアを確認するため、基板上の 4ピン JST コネクタを追跡し、これが MCUプログラミング用コネクタだと確認した
- Nu-Link2-Me と NuMicro ICP Programming Tool で読み出しを試みたが、チップ内容は保護されていた
- その代わり、Elgato 4K Capture Utility に含まれる
FW_HD60_S_MCU.binファイルを見つけたElgatoDeviceCapabilities.jsonによれば、このファームウェアは USB product ID 0x0076 のデバイス用だった- Elgato はこれを “Game Capture HD60 S Rev.4” と呼んでいた
- バイナリは Cortex-M0 ファームウェアのように見え、先頭ワード
0x20000E70は有効なスタックポインタらしく、続くワード群はフラッシュアドレス形式のベクタテーブルに見えた - ファームウェアを Ghidra に読み込み、SVD-Loader を使ってレジスタマッピングを試みた
- NuMicro_DFP の
M031AE_v1.svdを修正し、プラグインで読み込めるようにした - Nuvoton の M031BSP は関数識別に役立った
- NuMicro_DFP の
デバッグのためのMCU交換とロック解除
- 元の M031LD2AE の代わりに新品の空チップを実装し、Elgato ファームウェアを書き込むと動作はしたが、チップが再び保護状態になってしまいデバッグできなかった
- Ghidra で保護設定を更新する関数を見つけ、チップをロックしないように パッチした
- パッチ済みファームウェアを書き込むと、OpenOCD と GDB で初期化コードをデバッグできた
- LED制御コードの経路はファームウェア内に存在したが、通常の実行フローではスキップされていた
- GDB でレジスタと RAM の値を強制的に埋めて LED制御コードが実行されるようにすると、点灯させられた
- ファームウェアには LED制御コードが存在している
- 問題は、そのコードが正常条件では実行されないことだった
ブートローダと完全なファームウェアバックアップ
- 保護ビットを解除したファームウェアを Elgato のアップデート経路で別の HD60 S にインストールし、本来は保護されている全内容を読み出す実験を行った
- アップデート後、デバイスはキャプチャカードとして動作していないように見えたが、チップは意図どおりアンロックされていた
- その結果、次の領域を読み出せた
- LDROM: Elgato の 1段階ブートローダ
- データフラッシュ
- 元の設定レジスタ値
- APROM アプリケーションファームウェア
- LDROM ブートローダは I2C でコマンドとデータを受け取り、APROM を再フラッシュできた
- チップが保護解除状態だと、ブートローダはアプリケーションファームウェアへ進まず、アップデートコマンドを待機した
- Elgato はロック・アンロックビットを、ブートローダ待機状態を示す信号のように使っていた
- アンロック済みファームウェアをインストールしたあとデバイスが止まった理由も、この動作で説明できた
HD60 Sの内部構造を把握
- デバイス内部では 2つの ARM系プロセッサが協調動作していた
- Cypress/Infineon CYUSB3014 USB 3.0 周辺機器チップは ARM926EJ-S で、PC と USB 3.0 で通信する
- Nuvoton M031LD2AE Cortex-M0 MCU は ITE ビデオチップと LED を制御する
- Nuvoton MCU は別の I2C バスで ITE チップ群を設定・監視していた
- ITE IT6802E は HDMIレシーバに見える
- ITE IT66121FN は並列データストリームを HDMI に出力する役割のようだった
- CYUSB3014 は Nuvoton MCU に I2C でコマンドを送り、Nuvoton は状態情報を CYUSB3014 に返していた
- CYUSB3014 は IT6802E から来たビデオデータストリームを受け取り、USB 経由でコンピュータへ送っていた
- 基板には Altera MAX II CPLD もあり、ビデオデータが CYUSB3014 が受け取れる形で入るように関与しているようだった
SPIフラッシュとLEDアニメーションデータの発見
- CYUSB3014 ファームウェアは Winbond W25Q32JVSSIQ 4MB SPIフラッシュに保護なしで保存されていた
- SPIフラッシュダンプを調べると、オフセット 0x300000 以降に小さな画像のように見えるデータ塊があった
- Nuvoton ファームウェアで正体不明だった GPIO 5本を追跡すると、これらのピンは Diodes Incorporated PI5C3257 quad 2:1 mux/demux bus switch につながっていた
- このバススイッチは、SPIフラッシュに接続する主体を CYUSB3014 と Nuvoton MCU の間で切り替えていた
- 当初は SPIフラッシュが CYUSB3014 専用だと思っていた
- 実際には CYUSB3014 の起動後、Nuvoton MCU が SPIフラッシュの制御権を取得していた
- Ghidra で新たに識別した関数群は、ビットバンギングによる SPIトランザクションと SPIフラッシュの消去・読み出し・書き込みに関するコードだった
LED故障の実際の原因
- SPIフラッシュの 0x300000 以降のデータは一般的な画像ではなく、LEDアニメーションフレーム だった
- 16バイトごとの各ブロックは 14個の LED に書き込まれるアニメーションフレームだった
- 各行の最後の 2バイトは次フレームへ進む前の遅延時間だった
- Nuvoton ファームウェアは 0x300000 開始位置の先頭 2バイトが 16ビット値 0xAA55 かどうかを確認していた
- LED が動作しない 2台のデバイスの SPIフラッシュダンプでは、この領域が空か破損していた
- あるダンプでは 0x300000 領域がほぼすべて
0x00で埋まっていた - 一部のアニメーションは
AB 03 12 39のような異常なヘッダで始まっていた
- あるダンプでは 0x300000 領域がほぼすべて
- 正常動作する 3台目の HD60 S の SPIフラッシュには、0x300000 に正しいヘッダと LEDデータが存在した
- 最初の 16ビットワードはファームウェアが探していた
0xAA55だった - ヘッダには 26個のLEDアニメーション に関する情報が含まれていた
- IT1504 にロードされる dot correction データは 0x3007F8 にあり、続く
0x521114A7は直前 16バイトの CRC-32 だった
- 最初の 16ビットワードはファームウェアが探していた
SPIフラッシュのパッチでLEDを復旧
- 問題のあるデバイスの SPIフラッシュでは、0x000000 から 0x2FFFFF までは各デバイス固有のデータを保持した
- USB シリアル番号がこの領域のどこかに含まれていたためだ
- 0x300000 以降の LEDデータ領域だけを正常デバイスのダンプ由来データで置き換えた ハイブリッドイメージ を作成した
- このイメージを LED不良デバイスに書き込むと、白色 LED が 2回点滅し、赤色 LED が短く 1回点灯した
- 正常デバイスのほうが古いリビジョンで Nuvoton MCU モデルも異なっていたが、LEDデータは新しいファームウェアが期待する形式と一致していた
- Windows と Mac の既存 Game Capture アプリ内にもアニメーションの生データが存在していた
- Windows のパスは
C:\Program Files\Elgato\GameCapture\Animations - Mac のパスは
/Applications/Game Capture HD.app/Contents/Resources/Animations 01.ani,02.aniなどのファイルデータを LED順に合わせて並べ替えると、正常なフラッシュダンプ中のアニメーションデータと一致した
- Windows のパスは
アップデートツールと復旧手順の制約
- Elgato 4K Capture Utility の Windows 用ファームウェア更新は、十分に長く待たないという問題があった
- 更新がまだ進行中なのに失敗と表示される
- そのまま待つとデバイスの LED が点滅し、新しいファームウェアで正常に再起動する
- 失敗メッセージ直後にデバイスを抜くと、不完全なフラッシュが残る可能性がある
ElgatoDeviceCapabilities.jsonのupdateDurationSecの値を 40 から 80 に増やすと、この問題は解消した- Elgato は HD60 S のファームウェア更新を、技術サポートから指示されない限り行わないよう推奨しており、その機能も設定画面の特殊キー操作の先に隠されている
- LED復旧手順は複雑だった
ElgatoDeviceCapabilities.jsonを修正してファームウェア更新を許可する- 更新開始直後にデバイスを抜き、Cypress チップが SPIフラッシュを制御するよう誘導する
- PCB ジャンパを外して CYUSB3014 が USB から起動するようにする
- Cypress SDK の
download_fx3でcyfxflashprog.imgを RAM にロードする - 修正した
fx3_spitestで SPIフラッシュ全体をダンプし、LED領域をパッチする - ジャンパを戻し、4K Capture Utility で通常のファームウェア更新を行って Nuvoton ファームウェアを復元する
- 最終的に本来の修理は 1ドル未満のチップ 3個の交換で完了しており、LED問題は一部の HD60 S で発生するソフトウェア・プログラミング・アップデート関連の不具合だと分かった
1件のコメント
Hacker Newsのコメント
全体構造の中で目的を理解するのが難しく、しかも何段階もの関数呼び出しの奥深くに埋もれていることもあった。
ソースコードを直接見るときでも、こういうことはよくある。たいていのソフトウェアは過度に抽象化されていて、MCUが非常に大きく安くなった結果、HDMIキャプチャ装置にARMコアが2つ入っているようなことが組み込みの世界でも見られ始めている。この装置にはMCUは1つ以上必要なかったように思う
20年ほど前にインドで育ったころは、購買力が低く物が高かったので、ほとんど何でも修理したり手を加えたりして使っていた。
物を動くようにするためにjugaadのようなあらゆる間に合わせを多用し、服も再利用して、仕立屋がrafuという継ぎ当て修理をして寿命を延ばしていた。私のような中流家庭では特によくあることだった。
衣料輸出会社で働いていた父は、西洋の人々は車でも電子機器でも服でも使い捨ての物や新品を好むとよく話していたが、当時はその考え方が理解できなかった。だが今では購買力が上がり、中国のおかげで価格も下がったことで、こちらもただ捨てて買い替える方向に傾いている。
途中で投げ出さず、新品を買う方が簡単だとだけ考えない人たちには深い敬意を抱く。こうした粘り強さと工夫する力は本当に称賛に値する。
自分で直せて必要な部品も手に入るなら問題ない。だが誰かの経験や知識に対価を払わなければならない場合、少なくとも私の住む場所ではかなり高く、しかも修理してくれる人を見つけるのも難しい。空き店舗ばかりなのにTV修理の看板だけはたくさん見かける。
幸い、私は半分引退して時給の仕事をしているので、自分の余った時間には金銭的コストがかからない。だから1日かけて食洗機を直してみて、数日後にまた壊れたら、さらに1日かけて新品を設置することもできる。プロの設置業者なら新品を1時間で取り付けただろうが、少なくとも予定を取るまで待つ必要はなかった
消費主義が広がり、衣類のような物の品質と価格が下がったのは、この50年ほどのことにすぎない。
最近は自分でバイク整備をしているが、最初はオイルフィルターを外す工具のような多少の工具投資が必要で、部品や消耗品もそろえなければならない。オイル類、銅ワッシャー、古いブレーキ液リザーバーのネジの代わりになるネジなどだ。それでも整備工場の提示した**€1000**ではなく、だいたい€100〜€150で済んでいる
母は幼いころにズボンの裾を詰めておき、私たちが成長するとまた伸ばしてくれたし、膝や肘が擦り切れると継ぎ当てをしていた。
こういう環境は良い習慣と悪い習慣の両方を植え付けた。家の修理はほとんど全部自分でやるが、働きすぎで時間や気力が常に十分とは限らない。十分に払えるのに人に金を払って任せるのが難しく、そのせいで壊れた物を必要以上に長く放置してしまう。
その時間をメンテナンスや修理ではなくサイドプロジェクトに使っていたら、もっとお金があったかもしれない
そうした人たちが他の人に基本を教え、予期しない問題が起きたときには助けてくれた。共同体全体に知識と初歩的な徒弟的学習が組み込まれていたようなものだ。
今日では修理は一人でやることになった。YouTubeのようなものは大いに助けになるが、共同体的な側面は失われてしまった
残念な副作用として、修理や再利用の魅力が薄れ、修理しやすさや長寿命も製品機能として重要視されなくなった。いまやアメリカの経済成長は、特に99%の人々にとって停滞しており、その中で私たちが失ったものが明らかになっている。長持ちするよう作られた物はなく、企業も修理可能で長く使える製品を提供しない、あるいはできない。だから自分の持ち物を直そうとわざわざ努力する人でさえ、数えきれない障害にぶつかる
フラッシュチップ内のデータの塊が画像だと気づくくだりが面白かった。普通の意味での画像ではなく、複数のLEDアニメーションを記述するデータだった。
Hueランプのアニメーション用に、これと似た形式を独自に作ったことがある。ただしバイナリではなくテキストだった。
bulb1 bulb2dly R G B WW CW R G B WW CW100 10 25 20 0 0 25 10 20 0 0200 10 50 20 0 0 50 10 20 0 0最初の値は次の行に進むまで待つミリ秒で、その後に各LEDチャンネルの明るさを100基準で書く。数字以外で始まる行はコメントで、チャンネル間には1つ以上の空白を好きなだけ入れられる。
市販製品で似たようなバイナリ形式を見ると楽しい。実際かなり自明なやり方ではあるが、それでも実際に見ると興味深い
https://en.wikipedia.org/wiki/Piano_roll
謙虚な気持ちになる記事だった。これこそ本物のフルスタックエンジニアリングだ
Elgatoがこの記事にどう反応するのか見てみたい
私の経験ではElgato製品は安いが、ひどく不安定だ。この記事はその理由を非常に詳しく示している
ソフトウェアにも欲しい機能は全部あり、自分でプラグインも作れ、プラグイン作成の過程も文書化されている。どれも本当に悪くない。
だが実際にはKey Lightの電源を何度も入れ直さなければならず、WindowsではStream Deckアプリも何度も再起動しなければならない
こういうプロジェクトで、どうやってモチベーションを保っているのか気になる。部品を何度も注文して到着を待たなければならず、特に中国から来る部品は、待っているうちにかなり多くのプロジェクトを諦めてしまう
ちゃんと数えていれば、筆者は少なくとも3回は注文している。それでも本当に興味深い
サーモグラフィカメラがなければ、基板に消毒用アルコールを塗って、どこが最も早く蒸発するかを見るといい。
もちろん低電圧の機器でしか使えない方法だ
真実を探究し、最後まで追いかける能力こそが私たちを神聖なものにし、何かを作り、改善する人間らしさそのものだ。この人は世俗的な物をひとつ探究しながら、非常に深い精神的な道を歩んだ。
機器が私たちに抵抗してくるという事実は、あまりにも悲しく、苛立たしく、地獄のようだ。コンピューターや機器は、自らを成り立たせている真実を増幅し、放射するものであるべきだ。だが人類は自分たちが作った殻の中に閉じ込められ、参加や学習の可能性を拒むトップダウンの消費主義の中にいる。特にコンピューターは、真実と理解を覆い隠す代表的な不透明化装置になってしまうことが多い。膨大な可能性があまりにも無駄にされている。
生きているうちに、開かれた機械が現れる突破の流れを見られることを願う。Dougに拍手を送りたい