自分の部屋にあるあのタッチスクリーンは何なのか？
(laplab.me)- 2015年に完成した英国のアパートにあった正体不明のタッチスクリーンは、NETTHINGSのエネルギーモニタリングシステムの一部で、電力使用量の現在値と過去データを表示する装置だった
- 構成はメーター側のエネルギーマネージャーと、部屋の中にあるAndroidタブレット型クライアントに分かれており、近距離で壁をいくつか挟んでいてもケーブルではなくWiFiで通信していた
- 画面が動作しなかった直接の原因は、エネルギーマネージャー回路の3Aヒューズが抜けていたことで、ヒューズを交換するとWiFiネットワークとWebベースの使用量画面が復活した
- タブレットUIはWebViewで、サーバーはNode.js、Express、Socket.IOを使っており、メーター装置は
172.16.0.254でDNS、HTTP、SSH、TCFサービスを開いていた - 公開されたtcf-agentがroot権限でファイルシステムとプロセスへのアクセスを提供していたため、SSHパスワードなしでも装置を変更でき、内部はLinux 3.10ベースのARM9デバイスとCSVベースの電力データ保存構造になっていた
正体不明のタッチスクリーンの用途
- 新しいアパートの部屋には、ボタンもラベルもなく、小さな黄色い電源表示灯だけがあるタッチスクリーンが設置されていた
- 家主もそれが何を制御する装置なのか分かっておらず、引っ越し後しばらく忘れられたままになっていた
- 家電の説明書バインダーから同じ装置が載ったパンフレットが見つかり、正体が判明した
- 装置はエネルギーモニタリングシステムの一部
- 現在の電力使用量と過去の使用量データを表示する
- パンフレットには、電力メーターに直接接続される第2の構成要素であるエネルギーマネージャーも紹介されていた
- 共用メーターボックスには、NETTHINGSブランドの装置が他の住戸の装置と一緒に設置されていた
WiFi接続のエネルギーマネージャーとAndroidタブレット
- システムは、データを収集する「サーバー」役のエネルギーマネージャーと、それを読み取って画面に表示する「クライアント」役のタッチスクリーンで構成されていた
- 2つの装置の距離は数メートルしかなく、壁も2〜3枚ほどだったが、パンフレットにはSSIDとPwdが書かれていた
- 実際の通信もケーブルではなくWiFiで行われていた
- タッチスクリーン側面の小さな穴の中にあるボタンを押すと、Androidの起動画面ロゴが表示された
- 古いAndroidタブレットだった
- Google Talk、Flashなど古いアプリが入っていた
- Android 5に見えたが、正確なバージョンははっきりしなかった
- 「NetThings」アプリを起動するとWiFiネットワーク選択画面が出るが、パンフレットのネットワークは当初一覧に現れなかった
抜けていたヒューズと復活したモニター
- メーターボックスでは他の住戸のエネルギーマネージャーは点灯していたが、その住戸の装置だけ電源が落ちていた
- 原因はヒューズボックス内のヒューズ欠落だった
- ヒューズがないため電気接続が切れていた
- エネルギーマネージャーに電源が供給されていなかった
- WiFiホットスポットも現れなかった
- 同じメーターボックス内の他のエネルギーマネージャーのヒューズを確認し、必要な規格が3Aヒューズであると確認した
- Amazonで3Aヒューズを注文して翌日取り付けたところ、エネルギーマネージャーの緑色LEDが点滅し、WiFiネットワークが現れた
- 作業は主電源の近くで行われ危険であり、その後1日かけてヒューズの温度を何度も確認しており、このような実験は他人には勧めていない
期待外れなWeb UIと固定された料金値
- AndroidタブレットでWiFiを選ぶと、資源の種類を選ぶメニューが表示された
- 実際に動作する項目は、エネルギーマネージャーが接続されたMains Electricityだけだった
- 電力使用量画面は右側の色インジケーターと左側の数字5つを表示していたが、UIの意味は明確ではなかった
- 緑が低使用量なのか通常使用量なのか分からない
- 色インジケーターの縦位置が何と比較されたものなのか分からない
- 最大位置が過去最大使用量と関係するのかも分からない
- 左側に表示される5つの数字のうち、実際に正しい値はkW消費量1つだけだった
- 電気料金とkWあたりのCO2推定値は設定できない
- パンフレットでは初回設置時に設定可能とされている
- システムを再設定可能な状態に戻す方法は案内されていない
- パンフレットにはデータ時刻補正のためPCから接続するよう書かれており、Androidタブレットの時計は2015年の設置以来約15分ずれていた
WebView、Socket.IO、Node.jsサーバー
- エネルギーマネージャーのデータを直接読めるなら、kW使用量に正しい料金率を掛けてGrafanaなどに表示できる
- パンフレットにはPCでエネルギー使用量を確認する利用例があり、そこにIPとポートが記されていた
- ブラウザで接続するとAndroidタブレットと同じ画面が表示され、タブレットUIがWebViewであることが確認できた
- WebインスペクターでAPI呼び出しを調べると、Socket.IOが使われていた
- クライアントはサーバーから数字5つを受け取る程度だったが、コードにはRequireJSモジュール、Handlebars、Backbone.js、Underscore.jsなどが含まれていた
開いていたポートとtcf-agent
- 装置のIPは
172.16.0.254で、ssh root@172.16.0.254は最初「Connection refused」で失敗した - 全ポートスキャンの結果、次のサービスが開いていた
53/tcp: dnsmasq 2.63rc680/tcp: Node.jsベースのHTTP1534/tcp:micromuse-lm?3000/tcp: Node.jsベースのHTTP41142/tcp: OpenSSH 6.2
dnsmasqは装置がWiFiアクセスポイントであるため、DHCPサーバーの役割とも合致していた- SSHは41142番ポートで開いていたが、rootアカウントはパスワードで保護されており、
admin/admin、root/rootのような単純な組み合わせは通らなかった - 1534番ポートの正体を調べるうちに、Xilinxフォーラム投稿を通じてtcf-agentというキーワードを確認した
TCFで得たrootファイルシステムへのアクセス
- TCFはTarget Communications Frameworkの略で、対象システム上でファイルシステムの読み取り、新しいプロセスの起動、プロセスへのシグナル送信などを支援するテキストプロトコルである
tcf-agentはこのプロトコルを実装したサーバーで、この装置ではrootユーザーとして動作していた- TCFはEclipseエコシステムと密接に結び付いており、Getting Started文書ではEclipseプラグインを主な利用方法として案内している
- 新しいEclipseバージョンでプラグインを導入しようとしたが、依存関係の衝突でうまくインストールできなかった
- 代わりにTCFプロジェクトのPython SDKを見つけて使った
- 案内ページ: TCF/Python_Scripting
- 旧リポジトリ案内: git.eclipse.orgのパス
- 現在のリポジトリ: Eclipse GitLab TCF
- プロトコル文書: TCF Specification, TCF Services
- TCFの
FileSystem、Processesサービスによって、ls、cat、psのようなコマンドの代替ツールを作ることができ、成果物はtcf-toolsにまとめられている
SSHアクセスと装置内部の仕様
- 当初は
/etc/passwdと/etc/shadowをTCFで取得し、John the Ripperでrootパスワードを破ろうとした - 約7時間実行しても一致は見つからず、Johnは総当たり完了予定時刻を2035年と表示した
- その後
/etc/shadowを修正してrootパスワードを空にし、再び電源を入れたが、SSHログインは依然として拒否された - 原因は
sshd_configの**PermitRootLogin no**設定だった- この行を
PermitRootLogin yesに変えるとrootのSSHログインが可能になった
- この行を
- 装置は
Linux 3.10.28 armv5tejlを実行していた - CPUはARM926EJ-S rev 5で、ARM9系に該当する
/proc/cpuinfoの機能一覧にあるjavaは、Javaバイトコード実行のためのARM拡張であるJazelleを指している- メモリは
MemTotal: 118172 kBと表示され、この装置ではNode.jsアプリが動作していた
アプリケーション構造とデータ保存
- サーバーアプリケーションは
/srv/server配下にあり、Gruntfile.js、app.js、bower.json、package.json、node_modules、routes、views、publicのような構成を持っていた - アプリは大きく2つの部分に分かれていた
- 電力メーターから使用量データを読み取るPulse app
- CSVデータを読み込んでWeb UIに表示するNode.jsアプリ
- Pulse app関連ファイルは
binフォルダにあったpulse-apppulse.koct-read-daemon- 月別・日別・時間別・週別・年別ディレクトリ
pulse.koの.ko拡張子は通常Kernel Objectを意味し、カーネルモジュールの可能性がある- Pulse appはGPIOピンからデータを読み取り、その結果をCSVファイルとして保存していた
- CSVファイルは月・日・時間単位のディレクトリに分かれており、Web UIの過去データ表示も月別・日別・時間別のみをサポートしていた
- Node.jsアプリはNode.js 0.10.26、Express.js 4.13.3、Socket.io 1.3.6を使用していた
- 依存関係には
mqttパッケージがあり、ソースにはパンフレットで約束されていたクラウド統合と思われる未完成コードとハードコードされたブローカーIPがあった- それらのIPはすでに動作していなかった
- 装置自体にもインターネット接続はなかった
その後の発見
- 装置を作ったNETTHINGS社はすでに解散済みだった
- Hacker NewsユーザーのM6WIQは、NetThingsのエンジニアリング判断の結果を扱った別の記事を紹介した
- その記事の著者はMastodonで、この装置がまだ自分のNTPサーバーIPを使っているのか尋ね、実際の状況はさらにひどいものだと確認された
- Marc BevandがGPUリソースを提供し、エネルギーマネージャーの元のLinuxユーザーパスワードを総当たりで解析した
- ハッシュは少なくとも30年前のアルゴリズム)を使っていた
rootとgecko_userのパスワードはNewt@rd$prod_testアカウントのパスワードはNetTh@ng
- あるホスティング会社がこの記事をロシア語に翻訳した
1件のコメント
Hacker News のコメント
数年前、人々が電気・水道・ガスといった公共料金の使用量を、より環境にやさしく経済的に管理できるようにするには、月ごとの合計値ひとつよりもはるかに良いデータが必要だと気づいた
少なくとも5分単位くらいで使用量を見られなければ、「電気ヒーターを数時間つけっぱなしにしたほうが、1か月分の照明より電気を使っていた」といったことには気づけない
南アフリカの中流家庭では、不安定な電力供給のためインバーターと太陽光パネルが一般的で、私の家でも全体の電力使用履歴を見られるので、どこで効率を上げられるか把握しやすい
ただし、依然として総量データなので原因は推測する必要がある。たとえばシャワー後に1時間ほど3kWが記録されるのは給湯器が再加熱しているためで、このときバッテリーは一晩で放電済み、朝なので太陽光発電量は少なく、電力網から引いていることがインバーターの記録から分かる
そこで給湯器にタイマーを付け、午前10時以降、太陽が十分に昇って太陽光でまかなえるときだけ温めるようにすれば、電気代を簡単に減らせる。今度は水の使用量も同じくらい手軽に監視したい
オランダなら「slimme lezer」のようなものを電力メーターの p1 ポートに挿せば、Home Assistant に適切なセンサーとしてすぐ表示される
エネルギーダッシュボードはガス・電気の使用量、太陽光発電量、電力網/太陽光の使用比率、あれば家庭用バッテリーまで表示してくれるので非常に良い
Aqara の電力測定コンセントは Zigbee なので過負荷になりやすく、Shelly は WiFi だがかなり堅牢だった。こうしたものと併用すれば節電対策の優先順位がよく分かり、Home Assistant のセンサーに kWh あたりの費用やガス 1m³ あたりの費用も入れられる
腕に貼る大きなバンドのような装置で、細い針を皮膚の下に入れ、スマートフォンアプリと通信して血糖値のような情報を知らせてくれる
食べていたものがどんな影響を与えるか分かると、すぐに食事を変え、モニターをもう着けていない今もそれを続けている。アプリの UI も悪くなかったが、決定的に効いたのは履歴データだった
料理のときに電力使用量が高いと分かったら、サラダをもっと食べるようになるだろうか？ 欧州全域で電力メーターがスマートメーターに置き換えられており、エネルギー使用量を継続的に見られるという利点が大きく宣伝されているが、実際に意味のある削減につながるかはまだ判断しにくい
結局、最も大きな効果は大型家電や冷暖房が自家発電量に反応したり、時間帯別・日別の動的料金プランで電気が安い時間を活用したりするときに出る。自分で設置した簡単なタイマー、調理中に暖房を切るリレー、あるいは太陽光の余剰発電量に合わせて加熱電力を調整する Fronius Ohmpilot [1] のような装置がこれに当たる
[1] https://www.fronius.com/en/solar-energy/installers-partners/...
別の方法として、入ってくる水道管に温度プローブを直接取り付け、周囲温度と比較してうまくいったことがある。私の住む場所では水が地下から来ていて、常に周囲の空気よりずっと冷たいので可能だった
2つの温度差を時間に沿って積分すると、水使用量のおおよその代用値になるが、意味のあるデータを得るまでにはずっと手間がかかる
金属を検知する近接センサーが最も単純かもしれない。回転する金属ゲージ付きの水道メーターなら、https://www.alldatasheet.com/view.jsp?Searchword=LJ12A3-4-Z/... のようなものを使える
Home Assistant のエネルギーダッシュボードで、「ラック」（UPS+Mac mini+5ベイのディスク装置+その他）が冷蔵庫や洗濯機と比べて実際にどれくらい使っているのか、デスクのコンピューティング自体は低いが画面が点いているとかなり消費するのか、電動自転車の充電費用はいくらか、冬にサーモスタットを20度ではなく19度にするとどんな差が出るのか、といったことが分かる
夏によく使う扇風機が、実際には給湯器並みに電気を使っていた、というような驚きの事実も見える。電力測定は Shelly Plug Plus S、3EM、4PM で行い、温度測定は Shelly H&T Plus で行っている
Linuxで動く家電という技術的な奇形に筆者が驚いている点が興味深い。NodeサーバーがWiFi経由でWebサイト、API、WebSocketを提供し、そのサイトが別用途に再利用できない制約だらけの端末の古いWebViewエンジンに表示される構造が、今ではよくある標準のようになっている。
数字をいくつかと棒グラフを表示するだけなら、有線バスで通信するマイクロコントローラー2個でも十分だったはずなのに、この時代の電源装置なら2つの機器がアイドル時に16Wほど消費していてもおかしくない。
24時間365日つけっぱなしなら小型冷蔵庫並みに電気を使い、数ドルのマイクロコントローラー数個と比べればライフサイクル評価も良くないはず。
最悪なのは、この複雑な装置が設置から3年後、もしかするとそれより早く文鎮化していた可能性が高いこと。
ビジネスの観点では、マイクロコントローラーのプログラミングができる高価な人材を使いたがらない。棒グラフを見せるだけの単純なインターフェースなら、フロントエンド開発者のほうがずっと安く済む。
一部のボードにはすでにMEMSマイクとカメラが入っていて、写真の箱にもカメラレンズが見える。自分なら装置を分解して中を見るか、少なくともどんなハードウェアが搭載・検出されるのか診断を走らせていただろう。
https://www.wolframalpha.com/input?i=16+watts++24+hours++3...
SSIDとパスワードが印刷されていた点はまったく驚かない。こうした装置は新築に組み込まれるというより、既存住宅に後付け設置されることが多いだろうし、既存の壁内に配線を通すのは面倒なので、販売上の障壁を作りたくなかったのだろう。
今では数ドルで十分なWiFiチップセットが手に入る。
3Aヒューズもそこまで心配する必要はなさそう。3Aヒューズならアパート全体の主電力がそこを通る構造ではないし、もしそうしようとしていたなら一瞬で切れていたはず。
それにJazelleとは。Javaバイトコードのハードウェア支援は、結局うまくいかなかった技術だった。
[0]: https://www.youtube.com/watch?v=B90_SNNbcoU
必須ではないが、電気的に危険な部分と人が触れる部分を費用対効果よく分離し、問題が起きたときにループを避ける方法になり得る。無線には、単に電線をなくす以上の用途がある。
少なくとも、切れたヒューズを永遠の命と確実な死をもたらす儀式用アルミ外装できれいに巻いて差し込んだコンセントを見つけたわけではなかった。子どもの頃、火事にもっと弱かった時代に私がやらかしたかもしれない犯罪だ。
自分のコンフォートゾーンの外で不快に感じる人が多いのは興味深い。もちろん私は、一生触る必要のないものに首を突っ込む人間だ。
もちろんセキュリティが十分で、定期的なセキュリティアップデートを受け続けているなら問題ではなく、筆者が見つけた装置はそうした条件を満たさない非常に珍しい例外だったのだと推測するしかない。
Netthingsという会社名には見覚えがあった。この会社の装置にハードコードされたNTPサーバーがファイアウォールでブロックされ、時刻同期を失ったという記事を以前読んだことがある。
記事: https://strugglers.net/~andy/blog/2018/12/24/the-internet-of...
2018年に清算手続きに入ったようなので、この装置のサポートを受けるのは難しいだろう。
「DATE & TIME ARE ALWAYS CORRECT AND NEVER NEED TO BE ADJUSTED」は、Philip K. Dickの小説に出てくる一文のように読める。
明らかにうまくはいかなかった。
「IoT の C は cost-effective（費用対効果）なのだろう」という冗談は短く気が利いているが、実際に WiFi 対応 SoC がどれほど安く、費用対効果に優れているかを知ると驚くかもしれない
多くの場合、WiFi は事実上ただで付いてくるし、こうした SoC の大半には標準で Ethernet コントローラーがないため、用途に合いさえすれば WiFi のほうが費用対効果は高い
ほかの物理プロトコルや接続方式ももちろん可能だが、このような後付け設置型クライアントでは WiFi や一般的な無線プロトコルが最善だ
3m ケーブル、コネクター、ケーブル接続処理用の安価なチップと同程度で、ケーブル敷設の人件費はそれよりはるかに高い。だから WiFi で接続するのが無駄だと見る理由がよく分からない
元記事の筆者に、John The Ripper で総当たりに失敗した
/etc/shadowファイルを送ってもらったところ、旧式の UNIXcrypt()ハッシュだったため、hashcat と 12 台の RTX 4090 で約 7 時間で root パスワードを破ることができたroot パスワードは
Newt@rd$だこのデバイスは認証なしでも TCF 経由で root アクセスできるので特に有用ではないが、このパスワードが別の場所でも再利用されていた可能性はある
ドメインが時の砂に埋もれてしまう場合に備えて、記事そのものをそのデバイス上でホストするとよさそうだ
3A は 720W だ。あの小さな箱がそれだけの熱を出すなら、クローゼット全体が文字どおりオーブンになるだろう
そもそもエネルギーメーターがそれほど電力を使うなら本末転倒で、マッチをテストするようなものだ。多くても 10W だろうし、突入電流もそこまで高くはなさそうだ
1A ヒューズで十分だと思うし、設置もかなりきれいに見えるので、主電源の近くだったという点もそれほど怖がるほどではない
英国のすべての家電は建物の配線に接続される地点にヒューズがあり、通常はプラグ内にあるが、この装置のように固定式ヒューズホルダー内にある場合もある
値があまりに多様だと利用者にとって紛らわしく面倒だという判断から、これらのヒューズは同じサイズで標準値の 13A、5A、3A のいずれかに制限されている。ほかでも述べたように、このヒューズは英国のスーパーマーケットやコンビニでも買える
3A が機器に対して高すぎるなら、設計者は 3A 定格のフレックスケーブルを使ってプラグ側のヒューズで保護し、装置側により低電流の保護を追加すべきだ
英国式のシステムは導入当時には標準ヒューズ値のような微妙な細部までうまく合っていた賢い構造だが、低電流機器の多い現代の住宅にはやや過剰設計で、最適化されていない
自宅でこのようなリアルタイム使用量データを見たいなら、IoTaWatt を強くおすすめする: https://iotawatt.com
家のブレーカーパネルに設置する完全ローカルのエネルギーモニターで、デバイス上で動くローカル Web サーバーのダッシュボードを見たり、API でデータを読んだりできる
センサーの数を自分で選べ、家全体だけでなく個別の回路も監視できる
たとえば洗濯機、食洗機、電子レンジのような家電が起動・停止したときに追跡し、自動化をトリガーできる
ただし自分で設置するには、調査と基本的な電気知識、高電圧の主電源接続作業に対する抵抗のなさが必要だ。それでも手は届く範囲で、設定は簡単だった
見た目はこんな感じだ: https://i.ibb.co/qBVmBD1/IMG-1595.jpg