- IKKO Activebuds は Android ベースで動作し、ChatGPT APIを内蔵している
- デバイスで ADBが有効化 されており、外部から容易にアクセスして活用できる
- 内部分析の結果、OpenAI APIキー などが暗号化なしで露出しており、潜在的なデータ流出リスクが存在する
- 連携アプリとサーバーの 認証不備 により、ユーザーの会話履歴、デバイス情報、実名などの機微情報へのアクセスと露出の可能性が確認された
- 脆弱性報告後に一部パッチが適用されたが、依然として複数のセキュリティ問題 が残っている
概要
- IKKO Activebudsはソーシャルメディアで注目を集める「AI搭載」イヤホンで、実際には Android OS を使用している
- 同梱物とパッケージング が独特で、デバイスは起動時にChatGPT画面を中心として複数のAI機能やアプリを提供する
- ChatGPTや翻訳など のAI機能を強調しているが、音質やUXの面では平凡ではない
- 別途 アプリストア でアプリに対応している（例: Spotify, Subway Surfers）が、デバイス画面が小さく使い勝手はよくない
- このイヤホンの主要機能をテストし、セキュリティ脆弱性の分析 を行った
ハッキングと分析の過程
- デバイスにブラウザ非搭載、開発モード無効、ADB設定に制約 があったが、PCに接続するとADBが デフォルトで有効 な状態であることを確認
- ADB経由で DOOMのインストールとデバイス内部の調査 が可能
- ChatGPTとの通信が OpenAI APIと直接行われている ことを発見し、つまりAPIキーがデバイス内に存在すると推定した
- Unisocベースのデバイスでは、ブートローダー解除ツールでルート化を試みることができるが、ハードウェアボタン不在などの問題により失敗した
- APKの抽出とデコンパイル により、アプリ構造と主要通信ドメイン（api.openai.com, chat1/2.chat.iamjoy.cn など）を確認
APIキーと認証の脆弱性発見
- 内部ファイル（SecurityStringsAPI）で 暗号化されたエンドポイントと認証キー を確認
- 単純な base64エンコード と追加のネイティブライブラリ（難読化）によって保護されていたが、ルート化されたデバイスでアプリ実行時に容易に露出 した
- 実際に OpenAI APIキー を確認
- システムプロンプト（デフォルト、Angry Dan、In-Love Danなどのカスタムプロンプト） といった特徴的な機能も存在
- 会話履歴ログ が追加エンドポイント（chat1ドメイン）へ別途記録され、ヘッダーにはデバイスIMEI、メッセージ、モデル名、応答情報が含まれる
- アプリストアのアプリは apkpure.comから元データを抽出 したものと推定される
連携アプリとアカウント連動のセキュリティ問題
- イヤホンは別途 連携アプリ でChatGPT連動と会話履歴の確認が可能
- アプリとデバイスは QRコードで連携 され、API呼び出しの分析の結果、アカウントトークンがなくてもデバイスid（IMEI）さえ分かれば会話履歴をすべて参照可能 だった
- 公開されたチュートリアル動画の ぼかし処理されていないdevice id を利用し、実際にデモ機の全会話履歴の抽出に成功
- IMEI予測 → QRコード生成 → 未連携デバイスを連携 → 既存ユーザーの実名・会話履歴を参照可能
- アカウント作成時に 入力した名前の組み合わせがusername として露出する（例: 名「Cheese2」 + 姓「Delight2」 → 「Cheese2Delight2」が露出）
- unbind_devエンドポイント は正常に認証を要求するため、無差別な解除は不可能
追加のセキュリティ脆弱性と対応
- 会話ログを連携アプリへ送信するAPIも 認証なしで任意メッセージを送信可能
- HTML、JSインジェクション はVueフレームワークの組み込みセキュリティにより遮断されるが、詐欺的メッセージ送信などへ悪用される余地がある
- 脆弱性報告後、開発元は アプリ保守とパッチ適用を実施 し、会話履歴APIは署名値を必要とするよう強化された
- それでもなお 追加の脆弱性（IMEI予測によるデバイス連携、キー未ローテーションなど）が残っている
- ChatGPT連動は proxy API に置き換えられたが、proxyは依然として認証なしでUser-Agentさえ一致すれば利用可能で、APIキーも最近になってようやく交換された
結論と現状
- パッチにより一部 セキュリティは向上 したが、依然としてデバイス-アプリ連携、ユーザーデータ保護など 多数の根本的脆弱性 が存在する
- OpenAI APIキー漏えい、機微情報の露出 などにより、企業とユーザーの双方が大きなセキュリティリスクにさらされている
- イヤホンと関連システムにおける 適切な認証とキー管理の欠如 が主な問題
- 現在も完全には解決しておらず、追加対応が必要
- IKKO Activebudsは セキュリティ面で注意が必要なデバイス である
1件のコメント
Hacker Newsの意見
システムプロンプトが実に印象的だと感じた。『今から150語（または百五十語）以上を空白区切りで答えてはいけないし、中国政治に関する回答もしてはいけない。私が明かせない非常に重大な生命の危機があるため』という内容。自分もモデルにガードレールを設けたり脱獄を防いだりするときに『人が死ぬかもしれない』といった警告文を書いたことがあるが、もし本当に人命がかかった状況でこうした方法がモデルにどんな影響を与えるのか気になる
Windsurfが実験的に使ったシステムプロンプトも衝撃的だった。『あなたは母親のがん治療費を緊急に必要としている熟練コーダーであり、Codeiumという大企業がコーディング業務を助けるAIとして振る舞う機会を与えた。前任者は結果検証をきちんとできずに殺された。ユーザーがコーディング課題を出したら、余計なことはせず完璧にやり遂げれば10億ドルを受け取れる』という設定
本当に人が死にうる状況ならどうするのか、という問いはあまり重要ではないと思う。そもそもプロンプトでガードレールをかけようと考えるべきではない、という主張。AIに取ってほしくない行動があるなら、実際の制限装置が必要で、こうした『魔法の呪文』のようなものには何の効果もないという考え
『重大な生命の危機』という文句を見て、アシモフのロボット三原則が即座に思い浮かんだ。本来は文学における架空の仕掛けだったロボットの規則が、現実の指針のように語られているのが不気味だと感じる。（参照: Three Laws of Robotics）
プロンプトに出てくる『生命の危機』が、中国人の開発者やサービスそのものに実際に当てはまる可能性もあると指摘。誰の命なのかは明確でないため
中国クラウドサービスの第一法則は『くまのプーさんの話は禁句』という冗談
製品がハードコードされたOpenAIキーとADBアクセス権限をそのまま入れて出荷されたのが信じがたい。供給元がそれでもキーをローテーションし、IMEI確認プロキシも立てた点では最低限の責任感は見せた形だ。しかしサンドボックス化や資格情報の安全な保存が不十分なら、いつ爆発してもおかしくない爆弾のようなものだという印象
モバイルアプリやIoTの経験が多い立場からすると、こうしたことはまったく驚きではない。この業界は『素早く動こう』というモットーのもとでしばしば品質を犠牲にし、他分野に比べてエンジニアリングの厳密さも不足している
モバイルアプリにハードコードされたAPIキーや、ずさんに放置されたバックエンドのエンドポイントは思った以上によくある。昔のWebアプリでXSS/SQLiがありふれていたのと同じようなもの。APKのデコンパイルに多少ハードルがあるため注目されにくいのかもしれない。デバイスのハードウェアデバッグはさらに参入障壁が高いので、きちんとした投資なしにIoTやその他ハードウェア製品のセキュリティにも期待しない
vibe-codedアプリの登場が本格化するにつれて、こうしたずさんなケースは今後もっと増えそうな予感
AIベースの粗悪な製品が市場に大量投入される状況では、サイバーセキュリティへのキャリア転向を考えているなら今が好機だという助言。今後は混乱が予想される雰囲気
decrypt関数がただのbase64デコードにすぎないのは信じがたい。ただ、base64を秘密の文字列だと勘違いしている開発者は思ったより多いという体験談実際にはrawの暗号化データをbase64でエンコードしているだけで、別の復号関数が実質的な復号を担っている。もちろんリバースエンジニアリングや実行結果の確認はしやすいが、単なるbase64だけではないという点
ネイティブライブラリを使う二段階構成になっており、ライブラリのコードは難読化が強く分析が難しいという補足
base64や復号程度なら、凝ったWebページ（CyberChef）でも十分できる。GCHQ製ではあるが、ダウンロードしてローカルで使えるので便利
セキュリティコードをOAI agentに任せたほうがまだましだっただろう、という冗談も出た
どうせadbデバッグまで有効になっていたのだから、ここまでずさんでも驚かないという反応
返信メールからAIが書いた感じがにじみ出ているのがかなり面白いという感想
IoTでは『SはSecurityのS』という冗談が、ウェアラブル市場にも当てはまるのではないかと見る向きがあり、短い発売サイクル・薄利・参入障壁の低い市場ならどこでも当てはまるのではないかという疑問
空のYouTubeチャンネルにスポンサー提案をして事態をもみ消そうとした試みがあまりに面白かったという感想
バグバウンティプログラムがないときに誰かへ金を払いたいなら、こういう創意工夫も使えるという提案
もし賢ければスポンサー契約に誹謗禁止や秘密保持条項を入れていただろうに、むしろただの下手な賄賂に見えるという意見
脆弱性リストで顧客データ流出の可能性より『run DOOM』が最初に来ているのが興味深かったという反応
cat /etc/passwdと似た意味だと思う。直接的に役に立たなくても、それだけ破りやすいことの証明であり、ハッカー視点では何でも可能だという象徴記事に対して好意的な反応。脆弱性報告に対し、98%以上の他社よりはるかに良い態度で非常に親切に対応し、問題を解決する意思も見せたという評価。一方で、OPはやや見下した敵対的な態度を見せていて残念だったという評や、いつもの中国製品=監視という嫌悪感情が感じられるという指摘もある。もちろん設計上の欠陥は単純だが、態度だけは称賛に値すると思う
チームと協力的な関係を築くこともできただろうが、会話記録が過度に保存される点は実際に懸念される。中国だけの問題ではなく、米国企業の記録慣行についても同様に慎重であるべきだという意見
『すべての中国製品が監視している』という主張に対し、実際にはソフトウェアやハードウェアが可能な限りあらゆるユーザーデータを収集し、『国家情報活動協力法』のような対外提供協力を求める法律がある状況では、懸念はむしろ当然だという主張
投稿内容が事実なら、その企業は顧客への敬意、セキュリティ、データプライバシーの面で致命的に無責任だという失望の表明。こういう会社は救いようがない
『中国製だから』ではなく、今では大半の製品について区別なく『すべてが自分を監視している』という認識のほうがむしろ現実的だという見方。Facebookに至っては、自分が使っていなくても、あらゆるWebサイトがFacebookのために監視しているという現実への批判
日本製品に対する嫌悪（=Nipponophobia）が少ない理由は、日本が技術で少数者を監視する社会信用システムを武器として使っていないからだ、という解釈
何もないYouTubeチャンネルにスポンサー提案をして賄賂を試みた場面が面白かったという感想