ハクソク

世界を動かす技術を、日本語で。

私のオーディオインターフェースはデフォルトでSSHが有効です

12時間前原文(hhh.hn)

概要

  • RODECaster Duoの導入と使用体験の共有。
  • ファームウェア更新の仕組み解析とセキュリティ面の考察。
  • SSH有効化やパーティション構成など内部構造の発見。
  • カスタムファームウェア作成・導入の手順解説。
  • RODE製品への満足感と今後の期待。

RODECaster Duo導入と使用感

  • RODECaster Duo購入の目的は、同室で複数PC間のマイク利用を実現すること。
  • Discord通話時のエコー防止や、作業PCへの簡単な切替を重視。
  • 使い勝手の良さ安定動作に満足し、同様のニーズには積極的に推奨。
  • ファームウェア更新時には、挙動や更新ファイルの取得方法を常に記録。

ファームウェアアップデートの解析

  • macOS Instrumentsでディスクアクティビティを監視し、ファームウェアの格納場所を特定。
  • ファームウェア本体は単なるgzipped tarball形式で保存。
  • USB書き込み無効化状態ではアップデート失敗となる挙動を確認。
  • 本体内バイナリアップデート用シェルスクリプトの抽出に成功。
  • 二重パーティション構成(片方が破損してももう片方から起動可能)。
  • 署名チェック等のセキュリティ機構は未実装で、ユーザーによる改変が容易。

SSHとデフォルト鍵

  • SSHがデフォルトで有効公開鍵認証のみ許可の状態を確認。
  • 標準で登録済みの公開鍵(ssh-rsa, ssh-ed25519)を発見。
  • Ethernet接続でSSHアクセスが可能であることを実証。

Windows環境でのアップデートトラフィック解析

  • Wireshark + USBPcapでアップデート時のUSB通信内容をキャプチャ。
  • HIDコマンドによるアップデート制御の流れを特定。
    • 'M'コマンドでアップデートモード移行。
    • 'U'コマンドでフラッシュ実行。
  • **アーカイブ(archive.tar.gz, archive.md5)**をディスクにコピーし、コマンド送信でアップデート完了。

カスタムファームウェアの作成とSSH強化

  • SSHパスワード認証有効化独自公開鍵追加のため、**カスタムファームウェア(CFW)**を作成。
  • 必要ファイルを編集・アーカイブ化し、前述の手順でデバイスへフラッシュ。
  • 簡単なスクリプト実行のみでSSHアクセス実現

総括と感想

  • 容易なファームウェア書き換えに驚きと所有感。
  • RODECaster Duoの安定性と使いやすさへの高評価。
  • SSH有効化や標準鍵追加の理由は不明だが、RODEにセキュリティ報告を実施(返答なし)。
  • 今後もRODE製品を購入したいという満足度の高さ。
  • 質問や連絡はドメインの頭文字を利用してメールで受付。

RODECaster Duoの内部構造やアップデート手順の解析、セキュリティ面の考察、カスタムファームウェア作成の実践例を通じ、ガジェット好きや技術者にとって有益な知見を提供。

Hackerたちの意見

ファームウェアのイメージがただのつまらないタールボールとハッシュだけって、めっちゃいいよね。もっと多くのデバイスがこんな風にオープンだといいな。Rodeがこれを見て、ファームウェアのアップグレードをロックしないことを願ってる。
もしRodeの人がこれを見てたら、あなたの機材を買いたくなる!変えないでね。今これが話題になるのが面白い。明日、Zoom R20レコーダーを持って現場に行くんだけど、単一マイクのライブストリーム用に過剰な機能を持つUSBオーディオインターフェースとして使う予定。もし一週間前にRodeのことを知ってたら、これを買ってR20をホームスタジオに繋げっぱなしにできたのに!
数年前にHPプリンターのファームウェアをアップグレードしなきゃいけなかった。たぶん2009年頃に発売されたプリンターで、RAMを256MBにアップグレードするためにはファームウェアの更新が必要だったんだ。これがめんどくさくて嫌だったけど、ファームウェアを更新するのはネット越しにFTPでtarボールをプリンターに送るだけだって分かった。FileZillaで送ったら、数分間うなりながら、ファームウェアが更新された。それから、ファームウェアの更新がもっと複雑になってるのが腹立たしくなった。FTPかSCPかSFTPでデータを送って、セキュリティのためにチェックサムでもやって、あとは何もせずに済ませたいよ。
コマンドを有効にするために、何らかの物理ボタン入力が必要になるようにロックすべきだと思う。「DFU」モードみたいな感じでね。そうじゃないと、USBアクセスがあるものは、悪いファームウェアをフラッシュしてデバイスを壊しちゃうかもしれない。
個人的には、オーディオインターフェースにSSHを動かしたくないな(ランダムな認証キーが追加されるのも嫌だし)。
なぜ開示が目的だったの?このインターフェースをオープンに保ちたいと思わない?
目的ってわけじゃないけど、RODEがオープンなままでいてくれることを願ってる。
デバイスを自由に扱う楽しさは分かるけど、そのままでいてほしいな。でも…CRAがその火に重い布をかけることを忘れないでね。
TLA症候群がまたやってきた。CRAがここで何を指しているのか全然分からない。
今やみんながポケットにAIハッカーを持ってて、ファームウェアをチェックしたりデバイスを改造したりできるのが信じられない。エージェントをインストールすれば、数分でアクセスできちゃうんだもん。去年の今頃、これに近いことをするにはHotzクラスのハッカーじゃないと無理だったし、少なくとも長時間根気よく待つ必要があったよ。
これ、1000%同意!自分が持ってるPhase OneのデジタルバックでSSHを有効にするのにAIを使ったし、別のバックのファームウェアをリバースエンジニアリングしてパッチを当てて、バックを別のものだと思わせることもできたよ - Credo 50からIQ250に!内部はまさに同じなんだ。
パケットキャプチャを何時間も見て回る必要がないのは本当に楽だね。掘り下げるのは好きだけど、年を取るにつれて16時間もランダムなファームウェアの塊を見てる時間が減ってきた。
うわ、もしかしたらエージェントを使ってUnifi LTEモデムのIMEIスプーフィングを解除することに挑戦できるかも。そのLTEモデムのアンロックをやってるあの人、ツイートに返事くれなかったし :(
>「去年の今頃、これに近いことをしたいならHotzレベルのハッカーでなければならない」ってのは全然違うよ。確かに、LLMのおかげで分析やデバッグ、回避が劇的に楽になった。スキルがない人にも、やり方を知ってるけど面倒だからやらない人にもね。この特定のデバイスはほとんど保護されてなかった。暗号化されたファームウェアも、署名チェックも、SSHアクセスもあったし。中程度のスキルを持つ人なら、良いモチベーションと努力があれば十分にできることだよ。君が言ってるのはGeorge Hotzのことで、彼は最初のPS3ハイパーバイザーのエクスプロイトを公開したことで知られてる。PS3は攻撃者に対して完全にセキュリティが施されていて、ハイパーバイザー層の存在自体がその証明なんだ。エクスプロイトを作るには、FPGAを使って物理ハードウェアでボルテージグリッチを行う必要があった [1]。おそらくLLMがその攻撃を実行するのを手伝うことはできるけど、完全なフィードバックループがないから、やっぱりたくさんの人間の努力が必要だよ。[1] https://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was...
LLMはほとんどのことに対してそれをする能力がないよ。オープンSSHデバイスを持ってるからって、特別な「スキル」は必要ないしね。
HABがない埋め込みLinuxなら、「調整」するのはそんなに難しくないよ。ファイルとbinwalkを使って、何かを特定して開けてみればいい。
ここでのハッキングはほとんどないよ。あの人はファームウェアを見て見つけたけど、nmap -p 22でも見つけられたはず。だから、デバイスを攻撃するために最初にやることだね。ISP提供のルーターでまったく同じ問題を見つけたことがある。俺はgeohotには全然及ばないけど、記事の人よりも何もしてないよ、笑。
記事から見ると、彼はClaude CodeをWiresharkの代わりに使ってUSB HIDトラフィックをデコードし、Googleでプロトコルのドキュメントを探してたみたい。Wiresharkがインストールされてないなら、ちょっと時間を節約できるかも。ただ、少し幻覚のリスクがあるけどね。あと、彼はDockerを使って、なぜか~root/.ssh/authorized_keysと/etc/shadowをファームウェアのtarballで編集して、関連するHIDメッセージを送るための簡単なPythonスクリプトを書いて、HIDメッセージの一つに応じてデバイスがUSBドライブからマウントしたボリュームに修正したtarballをコピーしてたみたい。もしかしたら、Claudeを使って他のこともやってたのかも。誰がわかるんだろう?でも、投稿やリンクされたスクリプトの中で、私にとってすぐに分からなかったのは、彼がUbuntuコンテナにwhoisパッケージをインストールした理由だった。実は、Debianではmkpasswdユーティリティが歴史的な理由でwhoisパッケージに含まれてるんだよね。だから、基本的に、狂ったハッカーでない限り、Linuxシステム管理の基本的な知識が必要だし(少なくともman(1)コマンドの使い方を知ってるとかね。まあ、Googleでも代用できるだろうけど)、USB HIDライブラリにバインディングのある言語で簡単なプログラムを書く方法も知ってないといけない。* たぶん、彼がMacを使ってて、ハッシュ化されたパスワードを生成するためのLinuxボックスが手元になかったからだと思う(glibcのcrypt(3)を使う必要があるけど、macOSのlibcのcrypt(3)とは互換性がないから、Macでは面倒なんだよね)。最初にパスワード認証が必要だった理由はわからないけど、著者のリクエストに従って、彼を責めるつもりはないよ。ただ、デバイスのsshd_configファイルがPermitRootLoginをデフォルトの「prohibit-password」以外に設定してなければ、PasswordAuthenticationを「yes」にしてもrootとしてログインするためのパスワード認証は機能しなかっただろうね。
どうやってこの問題を解決したのかめっちゃ知りたい。私も同じ問題に直面してるから。 >「去年、ゲームを一緒にやったり、同じ部屋でDiscordで話したりするために、彼女とそれぞれのコンピュータにマイクを接続できるようにRodecaster Duoを買ったんだ。」
Rodecasterは二台のコンピュータに接続できるし、私たちはいつも同じDiscordコールにいるんだ。だから、二つのマイクを一つのコンピュータの入力にルーティングして、もう一人はマイクをミュートにして、その音声は一つのクライアントからだけ流れるようにしてる。ミキシングがローカルだからエコーもないよ。もっと質問があったらメールしてね :)
指向性のブームマイク付きヘッドセットで解決できるんじゃない?でも、問題の説明を誤解してるかも :-)。
いい記事だし、素敵なドメインだね。Zolaは知らないけど、これが一般的なテンプレートなのかカスタムなのかは分からないけど、すごくいい感じ。
https://www.getzola.org/themes/radion/のテーマに似てるね。
「俺のオーディオインターフェースは64ビットのLinuxコンピュータだ」ってタイトルの方が、もっと面白かったと思うな。10年か20年前だったら、そのデバイスの機能は小さな16ビットや32ビットのSoCで、VxWorksみたいなRTOS上で実装されてたかも。物理的なコントロールがたくさんあるから、ゲームコンソールにするのは理にかなった次のステップだね。
私のオーディオインターフェースは、FPGAが入ったLinuxコンピュータなんだ(実際にフィールドプログラムされるやつ)。それに、2つのギガビットイーサネットポートがあって、それぞれマシンの異なる部分と通信してる。でも、ここにいる人たちはそんなこと気にしないだろうな。そんなに珍しい構成じゃないし。自宅のデスクで使うのはちょっとすごいかもしれないけど、プロオーディオの世界では実は普通なんだよね。もっと詳しく書くかも、rootシェルを取る勇気が出たら(それとも壊しちゃうか、どっちが先か)。その部分はみんなも興味持つかもしれないね。 :)
あなたのビデオドングルはUnixコンピュータかもしれないよ: https://www.macrumors.com/2025/02/04/doom-apple-lightning-hd...
いい感じのオーストラリアの地元の人たちがこれを書いてるよ。何か報告したいことがあれば、電話すればいいと思う。ここではほぼ英語を話してるからね。
これ、ジャックオーディオが動いてるんだよ。まさに「ジャック・イン・ザ・ボックス」だね!
そうだね、デバイスに本格的なDSPが入ってると、これは結構普通だよ。ARM SoCの下に簡素化されたLinuxがあって、ベンダーのBSPはたまたまsshdがオンになってることが多い。悪意があるわけじゃなくて、オーディオ側の人たちがrootfsを本当に所有してるわけじゃないからね。大事なのは、USB側のネットワークだけでリスニングしてるのか、実際のLANでもリスニングしてるのかってこと。前者は面倒だし、後者は実際に気になる。
LANでリスニングしてるよ。特定の機能を使うときだけWi-Fiに接続するから、そのインターフェースもリスニングしてるかどうかはテストしてないんだ。