honeylab's blog

各種ハードウェアの改造、主にファミコンミニなどをやってます(ました)

地域限定緊急告知受信ラジオを改造して別の地域で普通のラジオとして使う

たまたま見つけたこの記事が気になりました。

東海地震に備えて、そっちの地方では自動受信機能のあるラジオが行政から準備されているらしい、というのは知っていたが、どうやら最近はそれ以外の自治体でも行政補助などで比較的安価にこのような防災ラジオが聞けるとのことです。

防災ラジオ、でイメージされるのは手回し充電式やソーラー充電式のラジオなどもあるかもしれない。しかし、これは基本的には常時コンセントにつないで、逃げる前にその状態を知らせてくれる機能がメインのようです。

そして、これは各自治体で受信できる放送がプリセットされているため、例えば他県などに引っ越しすると突然役に立たなくなってしまう。これはもったいない。
せめて普通のラジオにとして使えたらいいのではないか、と思う人は結構いるようだが、それを実現までこぎつけてはいないようです。

どれどれ、これはいっちょやってみるか、とメルカリやヤフオクで検索していくつか購入してみました。

まずはこちら。

 

ホーチキ製の緊急ラジオ EMR-01

メルカリで送料込み1,200円。

これは静岡市の緊急情報に対応したラジオとのことです。

早速分解してみましょう。

皆さん、ラジオ分解したことあります?どんな感じだったか覚えてます?

バリコンがあって、IFTや裸コイルがあって、蝋で固めてあったり?

今のラジオこんなんですよ。

 

ででーん。コイル?バリコン?ありません。

メインのマイコンと思われるR5F2134がありますが、一昔前のポータブルラジオなんかに入っていたような受信専用のICは見当たりません。

果たして受信はどうやって???

 

その秘密はこちら。

Image

この超小型、高々5mm角のQFNパッケージのIC、Si4730がその正体です。

(データシート↓)

https://www.skyworksinc.com/-/media/Skyworks/SL/documents/public/data-sheets/Si4730-31-34-35-D60.pdf


これは受信アンプからアナログオーディオ出力、はてはデジタル音声出力まで備えたワンチップデジタルラジオ受信ICなのです。

f:id:honeylab:20210926225626p:plain

 

選局はバリコンやVCOではなく、マイコンからI2Cで制御することで行われます。

このラジオにはフルバンドのIC(Si4730-D60、3060と刻印)とFM専用(Si4704-D60、0460と刻印)のICが二系統載っていて、それぞれ音声受信と緊急信号受信用に割り当てられています。緊急受信信号を受信すると直ちにマイコン制御で緊急放送を受信できるようになっているようです。

基板上にI2C信号のテストパッドがあったので一応信号も見てみます。

確かに、マイコンからラジオ受信チップに信号を送っているようです。

 

この仕組みを理解したうえて、改造可能性を検討しますが…

f:id:honeylab:20210926234033p:plain

この部品構成では、周波数テーブルはメインのマイコン内蔵ROMに制御プログラムと一緒に書き込まれていると考えるしかありません。

書き込まれた制御プログラムは、専用のツールなどで読み込める場合もありますが、そうでない場合も多いです。また、プログラムを一から書けば、もちろん自由に受信周波数を変更することが可能でしょう。しかしながら、それはちょっと手間がかかりすぎます。

 

ちょっとこいつは置いておくことにして、次の機種にかかります。

mediaTRY さくらFM 緊急告知ラジオ

最初に紹介したさくらFMとやらのラジオを入手しました。

ヤフオクで1000円+送料520円

 

media-try.com

 

media-try.com

 

早速これも分解してみます。

 

f:id:honeylab:20210926234139p:plain

基板をよく眺めてみると、メインのマイコンのそばに…24C04と書かれたチップが!

これはI2C EEPROMと呼ばれ、マイコン制御などの機器で小容量のデータ保存などに使われる部品です。この部品が載っているということは、周波数テーブルがここに保存されているという期待が高まってきました。早速中身を覗いてみます。

中身の読み取りには、I2C EEPROM リーダを使います。
アマゾンで2000円程度で買えるものもあります。

 

安価なもの、持っているはずなのですが見つからなかったので、手持ちの中でも一番対応チップの多い大げさなものを使いました。

 

 

ICクリップを使ってリーダと接続します。回路構成によっては、このような接続ではうまくいかない場合がありますが、この機種ではうまくいきました。

Image

24C04の容量は4kbit=512byte。バイナリデータが読み込まれました。

Image

さて、この中におそらく周波数データが含まれていると思われます。

テキストエディタに張り付けて、16進データの区切りを見ながら考えていくと

こんな感じに区切れて…

f:id:honeylab:20210926235010p:plain

この値…確かに周波数だ!

f:id:honeylab:20210926235232p:plain

周波数テーブル以外にもおそらく何らかの初期化データやステータスなどを保存していると思われる不明データもありますが、明確に周波数と思われる部分がありますので、ここを書き換えてしまえば改造できるはず!

 

というわけで早速書き換えていきます。(赤字の部分が書き換えたデータです)

f:id:honeylab:20210926235052p:plain


ここでは、さくらFM 78.7MHz→78.0MHz bayfmなど、関東圏のFM放送の値に変更し、データを書き込みます

はやる気持ちを抑えて電源を入れると…

 

成功しました!!!!

先ほどは当然ノイズしか流れなかった関西の防災ラジオを、関東用のラジオ、しかも放送局プリセットで使いやすいラジオに生まれ変わらせることができました!!!

とりあえず、ぼくのかんがえたさいきょうの関東ラジオプリセットは

f:id:honeylab:20210927005211p:plain

こんな感じになりました!

また、記事にあるように防災無線である60MHz帯の受信もできるようなので、(プリセットされていたのは69.15MHz、受信チップの下限は64MHz)、近々住んでいる市の防災無線が受信可能かどうか調べ、セットしてみたいと思います。

 

ちなみにこのラジオ、公式のYahooストアで「芦屋モデル」として8,800円で売られていますが、回路的に同じ「西宮モデル」は2,200円で売られているようです。

f:id:honeylab:20210927000442p:plain



(おそらく助成金が、とかそういう関係なんだとは思います。)


もしかすると、このラジオは引っ越した際にはその市内のどっかにおいていったほうが公共の助けにはなる気もしますが、自分のものとして持っているのであれば、このように改造し、新しい住まいでの防災に備える、という使い方もできるのかもしれません。

 

今回、偶然にもこのさくらFMモデルが(というより、紹介記事を読んで直感的に行けると思い)改造可能でしたが、そうでないものもあるかもしれません。

もし、手元にこういった防災ラジオをお持ちで、また、引っ越しなどにより当面使用の予定がないとか、単純に気になる、とか言った場合、中の写真を送っていただけるとそのラジオの可能性について検討できるかもしれません。

 

ATOMCam2の機能拡張用ツールを公開しました

過去にtelnetやftpd、rtspの機能を実装したツールを公開しましたが、

honeylab.hatenablog.jp

これらを整理して機能追加し、
また設定が容易になるようにWebUIを付けてリリースしました。

インストールは簡単で、ツールをダウンロードして展開し、普段録画に使用しているmicroSDに保存して電源を入れるだけです。

 

f:id:honeylab:20210924000146p:plain



不要になったら簡単に削除することができ、本体ストレージには一切手を加えることがありません。

 

これにより実現される機能はなんと!

FTPサーバ機能

Telnetコンソール

・RTSPサーバ機能 : VLCで開くためのURL表示機能が付きました!

FTPアップロード機能 ←New!! NAS転送機能の代替になります。
また、通常録画ファイルに加え、↓の検知動画もアップロードできます。
接続情報が正しいかどうかのテストボタンもあります。

・検知動画保存機能←New!! :検知動画、現在はクラウド・アプリ経由でしかダウンロードできませんが、内蔵microSDに保存することができるようになります。

・スケジュール録画機能 ←New!!:指定時間以外の録画は随時削除して容量を開けることができるかもしれません。昼間不要、とか夜だけ録画したい人、いる??

・定期リブート機能 ←New!! :何らかの理由で時々再起動したいことがあるかも…

・SWAPファイル設定機能 ← New!! :RTSPサーバを使用する際など、安定動作に不可欠です。初期状態では0ですので、RTSPサーバを起動する際は必ず設定してください。

・WebUI ←New !!:上記の機能のON/OFFをすべてブラウザから設定できます。

 

Web設定画面はこんな感じ!!

f:id:honeylab:20210923235358p:plain

ダウンロードはこちらから

github.com

 

ファイルの詳細、機能要望などはこちらのリポジトリから行えます。

一通りテストはしてますが、細かい挙動など、いろいろあるのでとりあえずRCです。

github.com

 

READMEをよく読んでくださいね。

こんな感じのカメラとかを使ったことがある人ならなんとなくで使えるかもしれません。

あと、くれぐれも、これは非純正なのでそこんとこよろしく…

RTSPサーバ機能は、純正が走り出したら落としますたぶん。

 

尚、手元のATOMCam2でしか確認していません。
もしかするとATOMCamでも動くかもしれませんが、動かないかもしれません。

ATOM Cam2のAppleHomeKit対応が正式にあぼーんしたので試してみる

readyfor.jp

 

Apple Homekit対応

→あいにく技術的な観点より難しいとのことで未対応です。

 

 ということらしいです。

なので、せっかくなのでAppleHomeKitに対応させてみようと思って調べてみました。

qiita.com

www.apollomaniacs.com

 

いろいろ調べてみたところ、どうやらRTSP対応カメラと、「Homebridge」とやらをインストールして動かすサーバ用のLinuxがあればとりあえず動かせるようです。

こちらの記事でまとめたように、ATOMCam2には無理やりRTSP機能は追加してあります。

honeylab.hatenablog.jp

 

外からも見えるようにするにはiPadとかAppleTVが必要、ということですが、ぶっちゃけApple製品についてはさっぱりわからないので、これらの記事を参考にしてどしどし進んでみます。

 

Linuxマシン、まぁRaspberry Piを使って単体で仕上げておく、のが便利な気がしますが、とりあえずは手元のハッキング用Linux環境にHomebridgeをインストールしてみます。

f:id:honeylab:20210805003140p:plain

ブラウザで設定画面を開きます。なんだかかっこいいです。

Image

さて、ここで上記のリンクにあるように「Homebridge Camera FFmpeg」をインストールします。

インストールできたら、JSON Configから以下のように設定します。

IPアドレスはお持ちのカメラに合わせてください。

f:id:honeylab:20210805003428p:plain

 

{
    "name""Camera FFmpeg",
    "cameras": [
        {
            "name""ATOM Cam2 Hack",
            "manufacturer""honeylab",
            "model""atomcam",
            "videoConfig": {
                "source""-i rtsp://192.168.0.20:8554/unicast",
                "maxStreams"2,
                "maxWidth"1920,
                "maxHeight"1080,
                "maxFPS"10,
                "maxBitrate"300,
                "vcodec""copy",
                "mapvideo""0",
                "audio"false,
                "debug"true
            }
        }
    ],
    "platform""Camera-ffmpeg"
}

この設定を行い、Homebridgeを再起動し、手持ちのiPhoneを該当のLANに接続しておきます。

iPhoneが接続できたら、HomebridgeのQRコードを「ホーム」アプリに読み込ませて連携させます(この辺は外部リンクを参照してください)

 

Image

するとついに、iPhoneの「ホーム」アプリからカメラとして認識されました。

すごいすごい。
カメラの場所を「ガレージ」に設定したので、Siriに「ガレージのカメラを見せて」というと自動でこのカメラ画像を出してくれます。めっちゃ便利やん!!!

 

さらに、この画面でピクチャインピクチャとして表示させるようにすると…

Image

Image

おおおお!ピクチャインピクチャで普通に見れるじゃん!!便利!!!!

 

 

いや、思ったより簡単にできたわ。

で、RTSP対応は一番上のリンクの公式アナウンスにあるように一応公式実装されるので、それさえできればこのように自分のHomebridgeサーバを使って、AppleHomeKitに連携することはできるんじゃないかな…と思っています。
公式がお手上げしたのは、なにか、これより難しいNativeな構成や、商用対応が難しかったのでしょう。

ま、まだまだ遊べますね。

SwitchBot Indoor CameraのOSS/GPLソースコードがなかなか届かないけど

honeylab.hatenablog.jp

 

こちらの記事にあるように、このカメラ、いわゆる中華カメラOEM製品で、
ReaktekのSDKを使用してカメラのアプリを、クラウドサーバとしては"TUYA"というプラットフォームを利用しているようです。
そのため、u-boot(GPLv2)、Linux Kernel(GPLv2)、busybox(GPLv2)などが例によってOSSのコードを利用しています。

※例によっての例※

honeylab.hatenablog.jp

 

本来は製品の公開と同時、もしくは製品などに添付する形でOSSの使用許諾宣言を添付したり、著作権者の表示が必要で、また製品・バイナリの入手者からの請求に応じてソースコードを提供する必要があります。これは任意、サービスではなく、そもそも製品の提供時に満たされていなければいけない条件ですので、現時点でこの製品は

GPL Violated」である、という状態です。

 一応、開発担当者には伝えている、とされていますが、それからそろそろ2週間ぐらいたつので、早めにソースコードが欲しいのですが…

 

なんだよおまえGPL警察かようぜーなとお思いかもしれませんが、ぶっちゃけその辺は私はどうでもよくて、この製品のGPLコードを手に入れてさっさと解析して、この機械を自由に改造できるようにしたいのです。

 

 

GPLは、プログラム(日本国著作権法ではプログラムの著作物)の複製物を所持している者に対し、概ね以下のことを許諾するライセンスである。

  1. プログラムの実行[注釈 2]
  2. プログラムの動作を調べ、それを改変すること(ソースコードへのアクセスは、その前提になる)
  3. 複製物の再頒布
  4. プログラムを改良し、改良を公衆にリリースする権利(ソースコードへのアクセスは、その前提になる)

 

 と、Wikipediaにはこのように書かれています。

特に、おそらくu-bootのソースコードにはmicroSDからのファームウェア更新ルーチンが含まれているため、それを使用してファイルシステムの書き換えを行いたいのです。

 

(Ghidraで解析してみてるんですが、なんかうまくいかないの…)

さて、ソースコードが手に入らないので似た製品のソースコードがないかを調べていたところ、割とメジャーな TP-Link C100が同じSoCであるRTS3903を使用し、コードを公開しているようでした。

 

ダウンロードしてみると、大変親切なことに、Reaktek RTS3903 SDKに含まれるソースコードの多く、さらにビルド用のGCCまで一緒に公開してくれていました。
大変親切ですので、展開して中身をあれこれ調べているところです。

www.tp-link.com

このgccでビルドしたコードはおそらくそのままSwitchbot Indoor Cameraで動かすことができると思います。

ところで大変興味深いのですが、このアーカイブに含まれる環境はOpenWrtのファームウェア作成環境のようで make 一発で書き込み用のファームウェアまで作成することができる完全なものでした。すごいすごい。

 というわけで、ある程度はRTS3903の素性もわかり、buildrootを使用してIndoor Cam上で動く実行バイナリを作成するところまではやってきました。

RTS3903はMIPSなんですが、ATOM Camとかに使われてるMIPS32より圧倒的に古い、MIPS Iというレベルのコードしかサポートしていないようで、buildrootの2013年版のリリースまで戻る必要がありました。

 

f:id:honeylab:20210724143415p:plain

シリアルログインだと、カメラアプリからのデバッグメッセージが延々と表示されて醜いのですが、telnetdを動かすことができるとそれに邪魔されずにシステムを調べることができます。

さて、もはや全然普通の使い方してないんですが、これからどういじっていこうかなぁ

ATOMCam2でIFTTTやLINEで通知を送る(webhookを利用する)

これもコミュニティで何度も話題となりつつスルーされている外部連係機能ですが、例によって無理やり実装してみます。

Cam1の時にも実装した、通知用のmp4ファイルが作成され、AWSにアップロードされた後に削除しようとする動作をフックしてファイルを横取りする、という部分

honeylab.hatenablog.jp

を改造し、ここでWebhookを行うことで各種通知サービスを利用することとします。

 

まず、rm.shというスクリプトを作成しておき、そこから呼び出される alarmhook.sh を作成します。

さらに、起動時スクリプトで、/bin/rm が呼び出される際に、代わりにrm.shが呼び出されるようにシンボリックリンクを書き換えます。

それらの内容はこんな感じ。

gist.github.com

 

この方法で、webhookを利用する連携サービスを使って検知画像を飛ばしたり、自動で何かを行うようなことが可能となります。
rm.shを書き換える方法だと、ATOMAWS に画像を転送してから実行するのでちょっとタイムラグが発生してしまうことは留意する必要があります。
もうちょっと工夫すれば、その前に引っ掛けることはできると思いますが、まあいいでしょ。

 

では、実際に動かしてみた感じを貼っておきます。

IFTTTからTwitter投稿を行ってみました。

f:id:honeylab:20210719232358p:plain

 このように、いきなりTweetすることができます。

…が、スクリプトを見るとわかるように、どうもIFTTT経由で画像をTweetしたり、gmailで添付させようとすると、いったんHTTPアクセス可能な外部サーバーに画像を保存する方法でしかできないように見えます…

もしもほかの方法でできることを知っている方がいれば教えてください。

IFTTTだとそこから先の連係機能がかなり強いので、IoTホームを作るにはなかなかいいと思います。

 

そのほか、LINE Notify APIを使ってみました。

Image

上の画像のように、直接LINEのトーク画面に送られてきます。

 

参考にしたのは公式のこちらのブログです。

engineering.linecorp.com

LINE Notifyだと、画像の添付に外部サーバを必要とせず、直接curlで投げ込むことができて便利です。

まあ、Lineに通知を放り込む場面がまだいまいち思いつきませんが…
家族・会社グループチャットに投げ込む、とかはできて便利だとは思います。

 

また、slackの投稿APIもどうやら画像を直接投げ込めるようです。

まだ試していませんが、たぶんできると思いますw

 

そのほか、何か外部連係周りでできたらいいなと思うもの、あったら教えてください。

SwitchBot Indoor Cameraを解析する(u-boot編)

honeylab.hatenablog.jp

 

さて、カメラの画質とか、そういうのは普通の人にやってもらうことにして、
私はシステムに入ってあれこれできないかを確かめてみます。

 

まず、UART端子が見つかったので、これを使ってu-bootコンソールかLinuxのシェルに残ることを試みます。

u-bootの起動時にいろいろなキーを押していると、ESCを押したときに、パスワードの入力を促されることに気づきました。

 

どうやら、ここで正しいパスワードを入力すれば操作が可能になるようです。

とりあえず、適当に入れてみましたが駄目です。
これは、ここで使われているu-bootのソースコードにパスワードの保存箇所が記録されているはずです。
では、ソースコードを… まだ公開されてないようですね。
とりあえず、メーカに問い合わせて、ソースコードを送ってもらうことに…

 

まぁ、一般のメーカのサポート窓口なんてこんなものです。とはいえ、もうちょっと丁寧に書いてもいい気がしたので改めて返信しておきました。

 

で、u-bootのソースコードが無いのでパスワードのヒントがありません。

取り合えず、同じSoCであるRTS3903を使用している TP-Link C100のu-bootソースを見ていくことにしました。

www.tp-link.com

いろいろ調べてみると、ここでは、CONFIG_ENV領域にある特定の環境変数を取得・比較しているようでした。

f:id:honeylab:20210711010014p:plain

このENV領域がFlash上にあれば、参照できるはずです。

というわけで、Flashを引っぺがしてダンプします。

 


しかし、目grep程度では見つけられませんでした。
では、改めてu-bootのソースを見ていくと…

getenvでは

f:id:honeylab:20210711010152p:plain

CONFIG_ENV_ADDRというアドレスが環境変数の格納されている場所です。

定義を探していくと…

f:id:honeylab:20210711010424p:plain

#define CONFIG_ENV_ADDR 0xB0030000

…はて?どこのアドレスだこれ…?

…CPUのレジスタ空間に近いな

…ああああああ… これたぶんCPU内蔵Flashのアドレスじゃないかな…
(データシートが無いのでほんとかどうかはわからないが、おそらくそう)

ってことはFlashダンプには入ってないわ…

 

残念!!!!!

 

ということで、まずはu-boot shellへの進入に失敗!

 

あとは、本物のu-bootのソースが手に入ったら最終確認してみよう。
もしかしたら、起動したLinuxから無理やりregister読めるかもしれんし…

 

 

 

SwitchBot Indoor Cameraが届いた

ので、早速分解しました。

 実際、このコネクタがUARTでした。

起動ログはこんな感じです。

Switchbot indoor cam bootlog · GitHub

 

SoCはRealTekのRTS3903、MIPSらしいです。

FlashはGigaDeviceのGD25Q64、RAMは64MBです

 

とりあえずFlashを引っぺがして、ROMの解析を始めました。

今のところ、そんなに面白いことはわかっていません。

また、パッと見た感じ、RTSPでストリームを取れたり、HTTPで何かができたりは一切無いようです。

むしろ、どうもセキュアのほうに振ってるらしく、microSDカードに保存された映像、クラウドに保存された映像いずれも、専用アプリからしか見えないとのことです。

support.switch-bot.com

 

へーーーー。