私の顕微鏡はドライブレコーダーだった

それ自体について語るものがないデバイス このユニットは「Tomlov 7」として販売されていました。届いたときには、ケースにモデル番号がなく、シルクスクリーンもなく、ステッカーもなく、一切のマーキングがありませんでした。製品のどこかにあった唯一の自己識別情報は、設定メニューの奥深くに埋め込まれた一行でした：firmware 20220905 V1。目標は小さく、完全に外観的なものでした：起動時のスプラッシュ画面を置き換えること。それはファームウェアイメージを必要とし、ファームウェアイメージはデバイスが実際に何であるかを知ることを必要としました。USBが最初の明白な手段でしたが、それは興味深い方法で行き止まりでした。デバイスは、接続方法によって3つの異なる個性を示しますが、そのうち2つは嘘です。 モードごとのUSB ID デバイス上で確認済み Mass storage 1b3f:8301 Generalplus MSC + ライブベンダーコマンドチャネル PC camera 05e3:f12b "GENERAL - UVC" UVCのみ、拡張ユニットなし Charging 何も列挙しない 05e3はGenesys Logicに属しています。これは、製造元が所有していないUSBブリッジチップから借りたベンダーIDです。カメラモードでベンダーIDで検索しても、実際のデバイスとは全く関係のない場所に行き着きます。したがって、USBディスクリプタは識別には役立ちませんでした。残されたのは、デバイスが生成するデータでした。 ドライブレコーダーの角度が始まったのはどこからか 製品についての推測からではありません。3つの識別子があり、どれも顕微鏡に言及しておらず、すべて同じシリコンベンダーを指しています。最初のものはデバイス自身の録画から来ました。顕微鏡がキャプチャするすべてのビデオは、それを多重化したコードによってスタンプされており、そのスタンプには次のように書かれています： Fingerprint 1 · the AVI muxer デバイス上で確認済み RIFF AVI hdrl avih strl strf JUNKGP$322 Generalplus AviPackerV3 20140916movi キャプチャされたすべての.aviに存在し、ファームウェア自体では0x05d8e4にあります。Generalplusは台湾のSoCベンダーです。ここにはTomlovも顕微鏡も示されていません。 2番目のものは、マスストレージIDから来ました。SCSI INQUIRYは、製品文字列なしの純粋な定型文である44バイトを返します。これは汎用ディスク名とビルドタグです： Fingerprint 2 · SCSI INQUIRY デバイス上で確認済み GENPLUS USB-MSDC DISK A 1.00GP-PROD. 後に、参照実装のSCSIInquiryData[]配列とバイトごとに一致することが判明しました。製造元はそれを編集しませんでした。 3番目は、動作するベンダーコマンドチャネルでした。これは、コマンドブロックの固定オフセットにある2バイトの署名、「G」と「P」によってゲートされるプライベートSCSI拡張機能です。同じコマンドは、これらのバイトがあれば成功し、それらがなければ拒否されます。これはデバイス上でライブで確認されました。 3つの独立した識別子、1つの結論：これはGeneralplusの部品です。そして、Generalplusのソースコードを探しに行くと、調査が分岐した瞬間です。 実質的に1つの公開Generalplusコードベースがあります それはZTKVRと呼ばれるGitHubリポジトリです。これは、ヘッダーで326B_CVRとして識別される製品ラインの完全なSDKです。CVRはCar Video Recorderの略です。これは車のドライブレコーダーSDKです。顕微鏡SDKではありません。顕微鏡SDKは公開されていません。なぜなら、当時、誰も顕微鏡SDKを構築したことがないように見えたからです。 ドライブレコーダーの角度は、製品についての理論から始まったわけではありません。それは、誰かが持っていた唯一の地図であり、それは間違った車両の地図でした。当時デバイスについて知られていたすべては、そのリポジトリから出てきました：リソースコンテナフォーマット、起動スプラッシュのロードパス、ファームウェアアップデートメカニズム、ベンダーコマンドテーブル。すべて、フロントガラスに取り付けるデバイスのために書かれたコードから読み取られました。それは、すべての結論にアスタリスクが付き、アスタリスクは荷重を担っていたことを意味します。 このSDKが記述するアップデートパスには、署名、チェックサム、マジックナンバー、バージョンチェックがありません。それは、ファイルにあるバイトでSPIフラッシュをゼロオフセットから消去して書き換えます。ドライブレコーダーの仮説が重要な点で間違っていた場合、最初の書き込みが最後の書き込みになります。そのため、作業ノートは2つの列に分割されました - デバイス上で確認済み、SDKから推測 - そして、2番目の列に重要なものが含まれている間は、ハードウェアに何も書き込まれませんでした。 間違った地図がコストしたもの 兄弟製品からの推論は、自信に満ちた、もっともらしい、間違った答えを生成します。これらはそれぞれ、崩壊する前に実際の時間を消費しました。 GP$322 部品番号として読み取られます。これはSDK自体のソース内のビルドタグであり、ダイマーキングではありません。シリコンとして検索しても何も返されません。なぜなら、それはシリコンではないからです。 GPCV1322 / GPL32680 そのタグから、実際のGeneralplus部品番号の2つのもっともらしい再構築。両方とも間違っており、どちらも追跡されました。 SPCA… このベンダーに属しているように見えるチップの全ファミリー。それらはSunplusです - 全く別の会社です。Generalplusの部品はGPCVとGPLです。 fvvlstore.com このチップファミリーのダウンロードミラーとして参照されています。デッドドメインです。 05e3:f12b Genesys Logicに属し、製品ではなくブリッジチップを記述するウェブカメラモードのUSB IDです。 4つのメール もう一つの方法は、デバイスで既に実行されているファームウェアのコピーを製造元に尋ねることでした。これは、思っていたよりもコミュニケーションが難しいことが証明されました。リクエストは2回かわされました。まず：このモデル用のファームウェアアップデートはありません。次に、保証と返品条件に関する無関係な返信でした。最前線のサポートは、「私がすでに持っているファームウェアのバックアップコピー」を「ファームウェアアップデート」とは異なるものとして解析できませんでした。 最終的にうまくいったのは、新しいバージョンというフレームワークを完全に却下することでした。アップグレードを要求するのではなく、デバイスが故障した場合のバックアップとして、すでに支払ったバージョンを要求すること、さらに保証が切れた後に再フラッシュできないと顧客がお金を失うという観察でした。サポートは誤解を認め、工場にエスカレーションしました。工場はファイルを送ってきました。 ファームウェアはそれを確認し、さらにそれ以上のものを提供します イメージはすぐに自己識別します。0x01ae8cには、ASCII文字列20220905 V1.0があります。これは、デバイス自身のメニューが報告するバージョンとバイトごとに一致します。正しいファームウェア、正しいデバイス。 次にリソーステーブルがロードされ、ドライブレコーダーは推論ではなくなります。ファームウェアのGPコンテナ（0x154000）にある18個のリソース。ハイライトされた行は、顕微鏡にあるべきではありません。 Resource Bytes What it is BACKGROUND.GPZP 2,494 UI sprite BEEP.WAV 4,076 sound CAMERA.WAV 5,524 shutter sound CLICK.WAV 616 sound DAY_SELECTBAR.GPZP 118 date-stamp overlay picker GPRS.PAK 169,139 nested pack INSERTSDC.GPZP 410 “insert SD card” prompt LDW_ALARM.WAV 5,320 lane departure alarm LDW_TURNOFF.WAV 14,692 spoken “LDW turn off” LDW_TURNON.WAV 17,382 spoken “LDW turn on” POWER_OFF_LOGO.JPG 26,178 shutdown splash POWER_ON_LOGO.JPG 26,178 boot splash POWERON_AUDIO.WAV 27,628 startup sound SELECTBAR_LONG.GPZP 796 UI sprite SELECTBAR_MIDD.GPZP 592 UI sprite SELECTBOX_SUB.GPZP 689 UI sprite TOPBAR.GPZP 327 UI sprite YEAR_SELECTBAR.GPZP 15,872 date-stamp overlay picker そして、工場が送ってきたファームウェアアップデートファイルには、変更を怠った名前が付いています： The hardcoded update path デバイス上で確認済み 0x004b7c C:\gp_cardvr_upgrade.bin cardvr。車のビデオレコーダー。SDKはこのファイル名を、顧客ごとに変更されるコンパイル時定数として文書化しています。それは変更されませんでした。 誰も顕微鏡のファームウェアを書かなかった。誰かがダッシュカムのビルドを取り、起動時に表示されるJPEGを交換し、出荷しました。レーン逸脱アラームの音声、日付スタンプオーバーレイウィジェット、アップデートファイル名をそのまま残して。 修正 実際のイメージを読むことで、ダッシュカムSDKが自信を持って提供していたものも反証されました。SDKは、ファームウェアにコンパイルされた配列、au32ResFileLenList[]に各リソースの長さを格納しています。その詳細は非常に重要でした。なぜなら、それは交換用スプラッシュのハードリミットを設定したからです。新しいJPEGは、コンテナではなく、コードに記録されたサイズと一致する必要がありました。それはそこにありません。すべての真のリソースサイズは、32ビット値としてバイナリ全体で検索されました - 26178、169139、27628、14692、5320 - そして、それらのどれもどこにも現れません。このビルドは、リソースの長さを別の方法で導き出します。兄弟製品から引き継がれた結論であり、数週間保持されていましたが、実際のアーティファクトとの接触で解消されました。これは、おおよそ、推論が...から行われる場合の予想される失敗率です。