44Netに生やしたFirefox OSスマホが黙るので、rootを取ってWi-Fiを眠らせないようにした

前回の記事では、44Netというネットワークを知ったことをきっかけに、眠っていた2014年発売のFirefox OSスマートフォン au Fx0（LGL25） を復活させ、44Net上でHTTPSのWebサーバとして公開するところまでを書いた。

構成はこんな感じ。

Internet
   |
44Net / AMPRNet
   |
WireGuard
   |
GL.iNet Mango
   |
nginx / TLS termination
   |
192.168.8.128:8080
   |
Fx0 (LGL25)
   |
BusyBox httpd

Fx0自体はHTTPSを処理しているわけではなく、Mango上のnginxでTLSを終端し、Fx0のBusyBox httpdへHTTPで流している。

公開URLは、

https://fx0.jn1eep.ampr.org/

である。

ここまではよかった。

問題は、その後だった。

Fx0、しばらくすると黙る

公開してしばらくすると、Webページが見えなくなる。

最初はBusyBox httpdが落ちているのかと思った。

しかし調べてみると、どうも違う。

Fx0を見ると、

• wlan0はUP

• IPアドレス `192.168.8.128` も残っている

• デフォルトルートも残っている

• wpa_supplicantも動いている

• Wi-Fiアクセスポイントとのassociationも残っている

ように見える。

なのに、

ping 192.168.8.1

すら通らない。

つまり、

という状態だった。

なんとも嫌な壊れ方である。

以前の記事を書いた時点では、

などと思っていた。

だが、常設サーバにするなら、やはり直したい。

pingを流し続けてもダメだった

「省電力でWi-Fiが寝ているだけでは？」

と思い、Fx0からMangoへpingを流しっぱなしにした。

ping 192.168.8.1

さらにFx0はUSB給電中。

それでも、時間が経つと通信不能になる。

単純な「無通信だからWi-Fiを切る」動作ではなさそうだった。

ログを見ると、QualcommのWi-Fiドライバはアクセスポイントに接続しているつもりのまま。

電波も非常に強い。

つまりRFの問題でもなさそうだ。

だんだん、

という方向になってきた。

Wi-Fiの設定ファイルを発見

Fx0にはQualcomm系Wi-Fiの設定ファイル、

/system/etc/wifi/WCNSS_qcom_cfg.ini

が存在していた。

中を見ると、こんな設定がある。

gEnableImps=1
gEnableBmps=1
gEnableSuspend=3
McastBcastFilter=3
hostArpOffload=1
gStaKeepAlivePeriod=30

この中で気になったのが、

gEnableBmps=1

だった。

BMPSは Beacon Mode Power Save。

アクセスポイントとの接続を維持したまま、Wi-Fi側を省電力状態にするQualcomm系の仕組みである。

今回の、

接続情報は残る
↓
でもパケットが通らなくなる

という症状とは、妙に相性がよさそうに見える。

そこで、

gEnableBmps=1

を

gEnableBmps=0

にしてみたい。

ところが、ここから話がややこしくなった。

普通のADBでは変更できない

まず、

adb root

を試した。

しかしFx0はproduction buildなので、

adbd cannot run as root in production builds

で終了。

`su` も入っていない。

さらに、

iw dev wlan0 set power_save off

も、

Operation not permitted

となる。

つまり、

になった。

2014年のスマートフォンを2026年にroot化する旅が、ここから始まったw

Dirty COWを使ってrootを取る

Fx0はAndroid 4.4.2世代のLinux環境をベースにしている。

そこで試したのが、2016年に話題になったLinuxカーネルの脆弱性、

Dirty COW（CVE-2016-5195）

だった。

WSL上に古いAndroid NDKを用意し、PoCをARM向けにビルド。

まずシステムファイルには触らず、テスト用ファイルで脆弱性が成立するか確認した。

結果、

vulnerable!!!!!!!

となった。

Fx0、ちゃんとDirty COWが刺さった。

その後、Dirty COWを使って `/system/bin/run-as` を一時的に差し替え、

uid=0(root)

を取得することに成功した。

これで終わりだと思った。

終わらなかった。

rootなのにrootじゃない

プロンプトは、

root@madai:/ #

になった。

しかし、

iw dev wlan0 set power_save off

は相変わらず、

Operation not permitted

だった。

さらに、実際にWi-Fiドライバが読んでいる、

/data/misc/wifi/WCNSS_qcom_cfg.ini

も、

Permission denied

で読めない。

調べてみると、

uid=0(root)
context=u:r:shell:s0

だった。

Capabilityも制限されている。

つまりこれは、

という状態だった。

Androidのrootは「rootかrootでないか」の二値ではない。

UID 0でも、CapabilityやSELinuxによってできないことがある。

今回かなり勉強になった部分である。

wifiグループに入ってみる

`/data/misc/wifi` を見ると、

wifi wifi

所有だった。

そこで小さなARMバイナリを作り、現在のroot shellを、

gid=1010(wifi)

に変更した。

これで読めるかと思ったが、

Permission denied

だった。

SELinuxのコンテキストは、

u:r:shell:s0

のまま。

ここで、

と判断した。

なぜかfastbootへの旅が始まる

そこでFx0で昔使われていた別ルートへ進むことにした。

LG端末には `laf` という、Download Modeに関係するパーティションがある。

Fx0では、

/dev/block/mmcblk0p27

だった。

まずこれを丸ごとバックアップ。

33,554,432 bytes

つまり32MiBの `laf.img` をPCへ保存し、SHA-256も記録した。

ここは怖いので、バックアップを取るまで絶対に書き換えない。

その後、LAFを無効化すると、Download Modeへ入る操作からfastbootへフォールバックできた。

Windowsから、

fastboot devices

を実行。

最初は何も出ない。

ただしWindows側を見ると、

VID_18D1&PID_D00D

のAndroidデバイスがいる。

つまりFx0はfastbootまで来ていて、Windowsのドライバだけが足りない。

Android Bootloader Interfaceのドライバを入れると、

e7a3aa35    fastboot

が出た。

さらに、

fastboot getvar product

で、

product: MADAI

。

ついにFx0のbootloaderと直接会話できるようになった。

TWRPを「インストールせず」に起動

Fx0用のTWRPイメージ、

twrp_2870-madai-a01-recovery.img

を使った。

ただしrecoveryを書き換える必要はない。

fastboot boot twrp_2870-madai-a01-recovery.img

で、TWRPを一時起動した。

これで、

adb shell

に入ると、

uid=0(root)
context=u:r:su:s0

。

今度こそ、目的のファイル、

/data/misc/wifi/WCNSS_qcom_cfg.ini

が読めた。

長かったw

変更したのは1行だけ

今回、Wi-Fi安定化のために変更したのは、基本的にこの1行だけ。

変更前：

gEnableBmps=1

変更後：

gEnableBmps=0

他の、

gEnableImps
gEnableSuspend
hostArpOffload
McastBcastFilter

などは触っていない。

一度にいろいろ変更すると、何が効いたのか分からなくなるからである。

つまり今回の実験は、

BMPS ON
↓
数時間後に通信不能

BMPS OFF
↓
どうなる？

というA/Bテストである。

……切れない

設定を書き換えてFirefox OSを起動。

BusyBox httpdも復旧。

そして外部から、

https://fx0.jn1eep.ampr.org/

へアクセスする。

見える。

しばらく待つ。

まだ見える。

さらに放置。

まだ見える。

これまでなら通信が死んでいた時間を越えても、Webページが見えている。

どうやら、

ようだ。

もちろん、1回の実験だけで完全に原因確定とは言えない。

ただ、

gEnableBmps=1 → 再現
gEnableBmps=0 → 長時間安定

なので、かなり怪しいところを引いた感じはある。

せっかくなのでhttpdも自動起動

もうひとつ問題があった。

Fx0を再起動すると、手動で起動していたBusyBox httpdも当然終了する。

せっかくWi-Fiが安定しても、

では常設サーバとして微妙である。

そこでFx0に存在する、

/system/etc/init.madai.post_boot.sh

を利用した。

これは起動後にCPUやQualcomm関連の設定を行うスクリプトである。

BusyBoxを、

/system/xbin/busybox-fx0

Webページを、

/system/etc/fx0web/index.html

へ配置。

そしてpost-boot処理の末尾から、

/system/xbin/busybox-fx0 httpd -p 8080 -h /system/etc/fx0web

を実行するようにした。

Fx0を再起動。

手動操作を何もしない。

しばらくして、

https://fx0.jn1eep.ampr.org/

へアクセス。

見えた。

これで、

Fx0電源ON
 ↓
Firefox OS起動
 ↓
Wi-Fi接続
 ↓
BusyBox httpd自動起動
 ↓
Mango nginx
 ↓
44Net
 ↓
Internet

まで自動化できた。

ようやく「常設サーバ」っぽくなった。

さらにアクセスカウンターも付けた

せっかくなので、WebページにはGoatCounterも導入した。

元々アクセス解析には使っていたが、ページ上にもVisitorsカウンターを表示することにした。

2014年のFirefox OSスマホで動くWebサーバに、

👀 Visitors: xxx

みたいなカウンターが付いている。

なんだか1990年代の個人ホームページ感まで出てきたw

現在の構成

2026年9月現在、こんな構成になっている。

Internet
   |
44Net / AMPRNet
   |
Dallas
   |
WireGuard
   |
自宅 GL.iNet Mango
   |
nginx / HTTPS termination
   |
192.168.8.128:8080
   |
LG Fx0 (LGL25)
   |
Firefox OS
   |
BusyBox httpd

Fx0側では、

Qualcomm Wi-Fi BMPS OFF

としている。

そしてFirefox OS起動時にBusyBox httpdも自動起動する。

つまり電源を入れて放っておけば、

fx0.jn1eep.ampr.org

として44Net上に現れる。

rootを取った目的は「Android化」ではない

今回、Dirty COWを使ったり、fastbootへ入ったり、TWRPを起動したりしている。

字面だけ見ると、

と思われそうだが、そうではない。

ROMをAndroidへ入れ替えたわけではない。

Firefox OS端末としてのFx0をそのまま使っている。

rootを取った目的は、

である。

これが今回いちばん気に入っているところだったりする。

12年前のスマホを「サーバ」にする意味

性能だけを考えれば、Raspberry PiやN100の小型PCを使った方が圧倒的に楽だ。

新しいルータを買った方が安定するかもしれない。

だが今回やりたかったのは、それではない。

眠っていた2014年のFirefox OSスマホが、

2026年になって、

アマチュア無線家向けネットワーク44Netにつながり、

グローバルIPv4を与えられ、

HTTPSで世界からアクセスされ、

しかも自力でWebサーバとして動いている。

その状況自体がおもしろい。

最初の記事では、

という話だった。

今回はその続きで、

という話になった。

まさかその答えが、

2016年のLinux脆弱性を突いてrootを取り、Qualcomm Wi-Fiの省電力設定を1行変更する

になるとは思っていなかったけれどw

44Net、なかなか深い沼である。

続きはこちら!