2026/08/03 1:19

TP-Link TL-841N のルート化、ファームウェア解析および永続的認証情報に関する調査

RSS: https://news.ycombinator.com/rss

要約▶

Japanese Translation:

研究者らは、10 ドルで購入された安価な TP-Link TL-841N(EU) ルーターに対しハードウェアハッキング分析を実施し、小型の「交通灯」デバッグ穴を介した UART 接続によって root アクセスに成功しました。115200 バウドルで接続された USB-to-UART アダプターを使用することでロック画面を回避し、起動セクタ、カーネル、rootfs（SquashFS）、および config パーティションを含むフルファームウェアを抽出しました。分析により、この低コストの IoT デバイスに固有の重大なセキュリティ脆弱性が明らかになりました：ハードコーディングされた管理者認証情報が塩なしハッシュとして保存されており（具体的には

$1

）、これらはパスワード「1234」に解読されました；WPS パスワードはラベルと一致する形で平文で発見されました；また、工場出荷状態へのリセット後も感度の高い PPPoE ISP 設定情報が保持されていました。これらの脆弱性は、デバッグモードが有効または不適切に保護されているような既知の課題（CVE-2026-4346）と対応しており、これは基本的なハードウェアアダプターを使用した初歩的なハッキング手法によってユーザーのプライバシーとネットワークの完全性を曝露させます。

本文

TP-Link TL-841N(EU) のハッキング：UART 経由のダンプとハードコード認証情報の発見

免責事項

本記事で紹介されている手法は、自己責任で行ってください。低価格帯のルーターを対象にしていますが、重要なネットワーク機器を意図的に攻撃しないでください。 ※文中にある「パッポ（※）」という記述は、特定の状況や人物を示唆するものですが、実際のセキュリティ調査とは関係ありません。

1. はじめに：ターゲットと目的

ターゲットデバイスの概要

製品名: TP-Link TL-841N (EU)
価格帯: 低価格（約 $10）
購入経路: Facebook Marketplace の出品者との高リスク・ハイスタックな交渉

調査目的

IoT デバイスの内部構造解明（分解・探究）
デバッグログへのアクセスとルート権限シェル取得の練習
UART やフラッシュメモリからのファームウェアダンプ
ファイルシステム探索によるセキュリティ脆弱性の調査準備

2. 筐体を開封：UART の発見と接続

基板構成の確認とシリアルインターフェースの確保を行いました。

基板の特徴

UART ポート: ケース内部で明確なラベル付けが行われていました。
フラッシュメモリの位置: 基板上ではなく、底板（裏面）側に搭載されているという peculiar な特徴があります。
フラッシュメモリ型番:
```
GD25Q64CSIG
```

UART ポートの接続手順

ポート特定方法

視認による確認: ケースを開けた際の「信号機のような穴」が UART ポートです。
マルチメータプローブ法（ラベルがない場合）:
- デバイスをブート中に電圧変動を検出。
- 安定した 3.3V や 0V ではなく変化する電圧レベルを示すピンを
```
TX
```
  と判定。
- GND は常に 0V です。

アダプター配線図（4 色ドッポン端子）

色	機能	接続先
RED	5V	電源 (+)
BLACK	GND	ルーター GND または基板メタル部
GREEN	TX	ルーターの UART `TX`
WHITE	RX	ルーターの推測される `RX`

接続のコツ: USB の GND をルーターの GND に、USB の RX/TX をルーターの TX/RX に接続。キーボード入力確認で未割り当てポートを検出します。安定性を重視し、ハンダ付けを行って Plug & Play 化しました。

デバッグログの取得

USB to UART デバイスを

/mnt/dev

として認識し、以下のコマンドを実行：

picocom -b 115200 --logfile bootlog-tplink.txt /dev/tty.usbserial-1210

通信レート: 115200 baud（標準的）
結果: ルートシェルへのアクセスが容易に行えました。

補足: LAN ポートからの接続でも IP アドレス割り当てと管理コンソールアクセスが可能ですが、ログイン方法の確認が必要です。

3. ファームウェアのダンプ：手法 1（UART と TFTP）

ローカルデバイスへのファイル転送を

tftp

を使用して実施しました。

環境準備 (Mac / Apple Silicon)

# Homebrew で tftp サーバーを開始
brew install tftp-now
tftp-now serve

重要: ルーター側がアップロードするパス（例：
/var/
）に、ローカルで対応するフォルダを作成しないとエラーが発生します。

ダンプ手順 (cat と TFTP)

ルーターのストレージ容量 (

df

で確認) に注意し、RAM 負荷を防ぐために各パーティションを順次転送・削除します。

# 1. パーティションダンプ
cat /dev/mtd0 > /var/boot.bin

# 2. TFTP 経由で転送（PC の IP を変更してください）
tftp -p -l /var/boot.bin 192.168.1.100

# 3. ローカルファイルを削除して次のパーティションへ
rm /var/boot.bin

クライアントコマンド例

複数のセクションを処理するスクリプト：

cat /dev/mtd1 > /var/kernel.bin
cat /dev/mtd2 > /var/rootfs.bin
cat /dev/mtd3 > /var/config.bin
# ... 他の mtd 領域も同様に行う

代替案: ルーターに USB 搭載または TFTP クライアントをアップロードして BusyBox を導入すれば、
dd
など標準コマンドが利用可能になり作業が楽になります。

4. ファームウェアのダンプ：手法 2（物理抽出 / flashrom）

基板裏面のフラッシュチップ

GD25Q64CSIG

を物理的に読み取る方法です。

チップの確認と接続

電圧確認: データシートより 3.3V 動作（CH341A で安全）。一部の IC は 1.8V なので注意が必要です。
ピン割り当て: クリップのカット端（赤線）をチップの「PIN 1」位置（通常は対角隅に円印あり）に合わせます。

flashrom の使用

# flashrom をインストール・起動
flashrom --programmer ch341a_spi -r modem.bin

これにより完全なフラッシュダンプ

modem.bin

が取得されます。

ダンプの解析とセクタ分離

取得した

modem.bin

から各機能領域（mtd0〜mtd6）を

dd

コマンドで切り出します。

# 構造例：binwalk -e modem.bin などを使用可能

# mtd0 (U-Boot)
dd if=modem.bin of=mtd0-boot.bin bs=1 count=$((0x20000))

# mtd1 (Linux Kernel)
dd if=modem.bin of=mtd1-kernel.bin bs=1 skip=$((0x020000)) count=$((0x140000))

# mtd2 (RootFS - SquashFS)
dd if=modem.bin of=mtd2-rootfs.bin bs=1 skip=$((0x160000)) count=$((0x660000))

# ... その他 config, rom, radio なども同様

フラッシュマップ（概略）

セクタ	サイズ	内容の推測
`mtd0`	128 KiB	Custom U-Boot (Ralink)
`mtd1`	...	Linux Kernel
`mtd2`	6.6 MiB	SquashFS (ルートファイルシステム)
`mtd3`	64 KiB	Config
`mtd4~6`	64 KiB	ROM/Radio 等

5. ルートファイルシステムの展開（Un-squashing）

Mac 環境での扱いやすさから、

sasquatch

は失敗したため手動で展開しました。

# squashfs を確認
file mtd2-rootfs.bin

# xz 形式で展開
unsquashfs -no-xattrs mtd2-rootfs.bin

注意点:
create_inode: could not create character device...
エラーが発生した場合、Mac のセキュリティ制限によるものであり、通常問題ありません（Linux 上なら
sudo
で容易に解決）。

6. 予備的なスノオピング：驚くべき発見

抽出したファイルシステムを

strings

grep

binwalk

で解析した結果、以下の重大な脆弱性を発見しました。

発見されたハードコード認証情報

1. WPS パスワード（平文）

場所:
```
mtd3-config.bin
```
内容: ルーター背面に表示されているパスワードそのものがハードコードされていました。
関連 CVE:
```
CVE-2026-4346
```
（TL-WR850N v3 などで報告された類似問題）
概要: シリアルインターフェースが有効かつ弱保護状態で、管理・WiFi 情報がフラッシュメモリに平文保存。

2. PPPoE ISP 認証情報（平文）

場所:
```
mtd3-config.bin
```
内
発見された情報:
- ユーザー名：
```
@unitiair
```
  などの ISP 固有アカウント
- パスワード：ハードコード済み

致命的な事実: これらの認証情報は、**「ファクトリーリセット」**後も存在し続けます。

リセット操作（RESET ボタン長押し）を行っても、ISP の PPPoE WAN 認証情報がフラッシュストレージから永続的に消去されません。
これはプライバシーリスクとして極めて重大です。

3. デフォルトログイン情報（平文）

場所:
```
./web/help/RestoreDefaultCfgHelpRpm.htm
```
デフォルトユーザー:
```
admin
```
デフォルトパスワード:
```
admin
```

4. 管理用 OS ユーザーのパスワードクラック

ハッシュ:

/etc/passwd.bak

に

$1$iC.dUsGpxNNJGeOm1dFio/

(MD5) が保存。

塩化なしであるため容易にクラック可能でした。

# パスワードハッシュの作成
printf '%s\n' '$1$iC.dUsGpxNNJGeOm1dFio/' > admin.hash

# hashcat によるクラック（辞書攻撃）
hashcat -m 500 -a 0 admin.hash common.txt --status

結果:

admin:1234

で即座にクラック成功。ルート権限の完全なアクセスが可能になりました。

7. 結論

手法 1 (UART+TFTP) と 手法 2 (物理抽出 flashrom) の両方で同様のファイルシステムを抽出できました。
この低価格ルーターには、ハードコードされた認証情報（WPS、PPPoe、管理用）や、リセットしても消えない設定情報が多数存在します。
これらの脆弱性は「安価な IoT デバイス」によく見られるセキュリティ対策の不備を示しています。

次回: 脆弱性の詳細なリバースエンジニアリングについては、能力のある方や別の記事にて行います。

同じ日のほかのニュース

一覧に戻る →

2026/08/03 1:26

Show HN: Kakehashi – Linux ARM で macOS バイナリを実行するための実験的なユーザースペース

## Japanese Translation: Kakehashi は、JIT コンパイルや Apple の専用 SDK に依存せず、Linux aarch64 上で実際の macOS ARM64 ゲストを実行するためのオープンソースで CLI ファーストのユーザースペース翻訳層です。中心となるクリート（`kh-loader`、`kh-runtime`、埋め込まれた `libSystem.B.dylib`）を中心に構成され、システムコールを翻訳するとともに、ゲストのファイルシステムをホストに `/Volumes/linux/…` を介して橋渡しします。具体的には、ゲストの `/usr/local/bin` をホストのバイナリに、`/etc/ssl/cert.pem` を CA バンドルにマッピングします。インストールは `cargo install kakehashi`（ソース：`crates/kh-cli`）で行い、事前に `kh bottle ensure` でボトルを確保します。ツールの追加は `kh install`、実行は `kh run` によって行われます（例：マルチスレッド圧縮用の `kh run 7zz -- -mmt=4` や、単に `kh run curl --` など）。Linux aarch64 ベアメタル、VM、Docker/Colima（ヘルパーがアーティファクトを `.tmp/kh-out/` に出力）上で動作し、Rust 1.88 以上（Linux aarch64）、コンテナの種類に応じて 4 KiB または 16 KiB のページサイズに対応します。ベンチマークの結果では、Linux 側のマルチファイル 7-Zip 圧縮とネイティブ実行を比較した場合の全実行数のギャップは約 5.2 倍ですが、単一ファイルまたは圧縮負荷の重いワークロードではオーバーヘッドは約 1.1〜1.2 倍に留まります。Darwin クライアントツールを高価な macOS ランナー（$0.062〜$0.102/分）ではなく、低価格な Linux ARM64 ランナー（$0.005/分）上で実行できるため、パフォーマンスのオーバーヘッドがあっても Kakehashi は多くの場合で費用対効果に優れています。Apache 2.0 ライセンスの下にあり、Darling から派生していない本ツールは、自動化された CLI ワークフローのためにエコシステムを橋渡しする無料の代替手段を提供します。

2026/07/28 23:21

メモTaking とパーソナルナレッジ管理

## Japanese Translation: 本稿の主要な論旨は、ブレンnan ケネス・ブラウンの記事に対し、ノートツール「Obsidian」に独自の知的価値を誤って帰属させ、不均衡な見解を示していることを批判しています。著者は、ソフトウェアが整理を助けることは事実だが、画期的なアイデアそのものの源泉ではないと主張します。証拠によると、ブラウンは Obsidian が複雑なシステムであるかのように誤って描写しており、実際には 1994 年頃の技術に準じるような個人的なウィキとして機能しています。この分析では、PARA やニコラス・ルーマンが使用した歴史的なゼッテルkasten メソッドなど、確立された枠組みを参照して議論の文脈を設定し、そのようなツールは人間の創造性を置き換えるのではなくそれを支援するに過ぎないと指摘します。さらに、Obsidian のダウンロード数が約 75 万回に達しているにもかかわらず、それは 460 億ドル規模の巨大な業界内で運営されており、その現在の影響は限定的であることを示唆しています。この批判は、世界を変えるような貢献を直接ソフトウェアに帰属させることは誤った結論と不確実な引用につながることを警告しています。結局のところ、ユーザーはこのツールを独自性の源泉ではなく、個人的な解決策のための基盤として認識するべきです。 ## Text to translate: The central argument critiques Brennan Kenneth Brown's article for presenting an unbalanced view that wrongly attributes unique intellectual value to the note-taking tool Obsidian. The author asserts that while software facilitates organization, it is not the source of groundbreaking ideas itself. Evidence shows Brown mischaracterizes Obsidian as a complex system when it functions essentially as a personal Wiki, comparable to technologies from 1994. This analysis contextualizes the debate by referencing established frameworks like PARA and the historical Zettelkasten method used by Niklas Luhmann, noting that such tools merely support human creativity rather than replacing it. Furthermore, despite Obsidian having roughly 750,000 downloads, it operates within a vast $46 billion industry, suggesting its current impact is limited. The critique warns that attributing world-changing contributions directly to the software leads to flawed conclusions and inconclusive citations. Ultimately, users should recognize these tools as foundations for personal solutions rather than engines of original thought.

2026/08/03 5:26

FamilyWild を用いたホスト間の X11 サーバー共有

## Japanese Translation: 2026 年 8 月 2 日、隔離環境（コンテナや chroots など）内または非転送された SSH 接続上でグラフィカルな X11 アプリケーションを動作させる際に生じる「Authorization required, but no authorization protocol specified」というエラーを解決するための方法が詳述されました。根本原因は、`.Xauthority` クッキーが family と hostname の双方で鍵付けされており、クライアントが自分のマシン名と一致しない hostname を持つクッキーを拒絶する点にあります。解決策は、クッキーの family フィールドの最初の 2 バイトを `0100`（`FamilyLocal`）から `0xffff`（`FamilyWild`）に書き換えることです。これには以下のコマンドを使用します：`xauth nlist :0 | sed 's/^..../ffff/' | xauth -f /tmp/portable.Xauthority nmerge -`（`:0` を `$DISPLAY` に置き換えてください）。family を `FamilyWild` に変更することで、クッキーは任意の hostname に対して有効となり、hostname が不一致のクライアントからの接続も可能になりつつ、ホストベースのアクセス制御を完全に無効にすることなく済みます。これを使用するには、生成された `/tmp/portable.Xauthority` ファイルを bind-mount または SCP でクライアント環境に移動し、`$XAUTHORITY` 変数を指すように設定します。ただし、厳格なセキュリティ上の注意が必要です：`FamilyWild` クッキーはローカルなものよりも特定の情報が少ないため、ソケットアクセスがありファイルを閲覧できるあらゆるユーザーが表示器に接続できるようになります。そのため、ファイルのパーミッションは必ず 0600 を維持し共有マシンにはコピーを残すべきではありません。このアプローチは、ホストベースのセキュリティを完全に無効にする `xhost +` の使用や、全クッキーをクリアしつつ無効なエントリを残そうとする危険な方法よりも優先されます。著者はこのトリックを、特別に非特権 LXC コンテナへの X11 転送のために適用しています。