honeylab's blog

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

ジェネリックドンキWiFiカメラ

件のドンキのWiFiカメラが発表されたとき、どうもいろんなメーカから同じ形のカメラが出てるじゃないか、というのが話題になっていました。

例えば、

f:id:honeylab:20190512091333p:plain

https://www.alibaba.com/product-detail/P2P-Wifi-IP-Camera-YCC365-1080p_60761808715.html

これとか。

ドンキのカメラを外から利用するためのアプリ"YCC365"というアプリを使うことから、中身が似ているか、同じメーカが作っているOEMなのではないかという推測がされていました。
しかし、ドンキの言い分としては「プライベートブランド」であり(OEMであるということには反しない)、箱には「DESIGNED IN JAPAN」と書いてあります。

f:id:honeylab:20190512103617p:plain

DESIGNED とはなんなのか。
もし、それが、「この製品は我々がデザイン(設計)しました」ということであれば、ほかの製品はコピー・模倣商品ということなのかもしれません。

 

その謎をあきらかにすべく我々はアマゾン奥地へ向かった。

 

 こちらがジェネリックドンキWiFiカメラの一つ、HeimVisionのHM202というカメラだ。Aliなどにも多数出ているが、素人がいきなり手を出すのはハードルが高いし、到着まで時間がかかる。そのため、アマゾンプライムで入手可能なこの商品を購入してみた。

 

到着して即、分解す…その前に、とりあえず外観チェックします。

Image

確かに似ています。が、ロゴの有無以外にも微妙な差があるようです。

Image

底面の三脚穴に使われている圧入ネジのパーツは違います。また、形成用の注入経路も違うようです。

f:id:honeylab:20190512092544p:plain

RESETのフォント・大きさも違います。

f:id:honeylab:20190512092957p:plain

カメラ基板を取り付けている部分の基本的な構造は同じですが、やはり形成の方法が違いそうです。

商品の見た目から、金型を使いまわす(もしくは同一ラインで製造している)商品かと思ったのですが、どうやらそうでもなさそうです。

では、基板はどうでしょう。

f:id:honeylab:20190512093219p:plain f:id:honeylab:20190504231803p:plain

 

うん、一緒だねw
基板に書かれているシルクは全く同一、部品もおそらく同じです。
違うのは、HM202のほうはマイクがリードで引き出しになっていますが、ドンキのは基板に直付けになっています。また、レンズの部品がちょっと違うだけで同じ、と言っていいようです。むしろ、ドンキのほうがロット違いでWiFi基板が違ったりしているみたいです。

では、ソフトのほうはどうでしょうか。

ドンキのカメラと同じように、シリアルをつないで調べたところ、u-boot / Linux部分は完全に一致。おそらく、SDK提供のものをそのまま使っているのではないでしょうか。
p2pcamアプリのコンソール出力が若干違うので、それ以外、ソフトウェアとしてもほぼ同一と考えてよさそうです。

コンソール出力が違っても、クラウドの接続先やプロトコルは同じようで、ドンキのカメラが使用しているYCC365のカメラと同様にカメラを追加でき、全く差がないようにアプリ上でも並べて表示されました。

 

そうそう、国内で使うにあたって大事な技適

いくら物理的に使えても、これを取得していないと電波法違反になってしまう可能性があります。おそらく、Aliで売っている類似品は日本の技適は取得していないでしょう。しかし、HM202はアマゾンで売っていることもあって、技適取得済みのようです。

では、技適番号から違いを見てみましょう。

ドンキカメラの技適番号は 201-190027と書かれています。

これを総務省のサイトから検索すると、以下のデータが出てきました。

f:id:honeylab:20190512094037p:plain

細かいことはよくわかりませんが、どうやら、R.W.Cという会社、つまり例のアールダブリューシーがきちんと技適を取得しているようです。

添付のpdfを見ると、なんと製品写真が載っています。

f:id:honeylab:20190512094508p:plain

みんなの電波はこうやって守られているのですね。

なるほど、

f:id:honeylab:20190512094555p:plain

製品のラベルには確かにIP001と書かれて… いないですね。

f:id:honeylab:20190512094642p:plain

「IL-HIP291G-2M-AI」とかかれています。

なんということでしょう、ドンキのカメラ、IP001は、技適を取得するときの検査の時には「IL-HIP291G-2M-AI」という名前だったようです!

おもしろいね。

この名前で検索すると、やはりいろいろなメーカがガワを変えて似たようなカメラを出しているようです。

この製品に使われているSoC「GK7102」は

www.gokemicro.com

ここのメーカが製造しています。

このSoCを使って、何社かが、IPカメラ作成用のベースボードとして基板を作って販売しているようです。

www.ruision.com

それらの中の一つとして、このカメラの基板のシルクに書いてある「BK-XHR 2.0」というものがあり、p2pcamというアプリを付けて売っているのではないでしょうか。
おそらく、p2pcamとクラウドサーバを利用させて費用を回収するモデルで。

私の勝手な推測ですが、そのため卸値はかなり抑えられているのではないでしょうか。
IP001やHM202はエンドユーザ価格が4000円程度ですが、Aliで売っているのは1200円程度。それでも利益が出る程度ということはおそらく数百円でしょう。仮に製造原価ぎりぎりだとしても、クラウドモデルの月額利用料がいくらでしたっけ?利用率がどのぐらいになるかわかりませんが、そこで元を取ることを主目的にしているのではないでしょうか。

 

先ほどの型番で検索すると「INQMEGA」というブランドのカメラが多くヒットします。

redlightgreen.org

部品や添付パーツから考えると、ドンキのカメラのOEM元はここなのではないでしょうか。ほかのメーカのジェネリック品は、コピー品か別ルートでの製造品なのかもしれません。
ドンキの箱には「製造元」として「アール・ダブリュー・シー」と書かれていますので、こいつはいわゆる「部品」で、それを飾り付けて、説明書を付けて、ドンキのプライベートブランドとして完成させる、大事なお仕事=製造 ということのようです。

 

「DESIGNED」は?ねぇ?どの辺が「DESIGNED」なの?という答えにはまだたどり着けていません。が、いろいろ奥が深いですね。

 

技適の方向から調べたところ、ほかにもいろいろ興味深いこともありましたので、おいおい書いていきたいと思います。あぁやっぱりもうこのネタで本全然一冊書けるじゃん!こんなに無料コンテンツで書いてたらもったいない!と思ったりもする。

 

ところで、この騒ぎのおかげでたぶんドンキカメラ20台ぐらいは売上増えてると思うんだけど、何ももらってないし、たぶんメーカには恨まれてると思いますね。

 

ドンキWiFIカメラ(6) 製品に含まれるLinux等のソースコードが公開されました。

www.rwc.co.jp

ドン・キホーテのサポートから連絡があり、上記の製造元のサイトで公開されたことを確認しました。

また、上記サイトの案内にもあるように、今後のソースコードに関する問い合わせは同社の問い合わせから送るように書いてありますので(ドンキに問い合わせても二度手間になるでしょうし)そのようにするのがいいと思います。

内容は現在精査中ですが、多分チップメーカから出てるSDK由来なんですかね。
(今の所、p2pcamアプリのGPL問題には触れていませんが)

f:id:honeylab:20190510155651p:plain

本来は、これに加えて著作権表示が必要な気がするんですが、そのへんはこれからどうなるか、ひっそりと見守って行きたいと思います。

 

また、ソースコード公開及び権利の確認に工数をかけていただいた皆様お疲れ様でした。
次は最初からやってね。

 

関連して過去の記事の内容を修正しています。
修正漏れがありましたら教えてください。

(汎用) SPIメモリのダンプからパーティションを切り出す

吸い出したメモリダンプからパーティション切り出すために、サイズを確認します。

手がかりとなるのは、Kernelコマンドライン

Kernel command line: console=ttySGK0,115200 mem=36M rootfstype=squashfs root=/dev/mtdblock2 init=linuxrc mtdparts=gk_flash:320K(U),1664K(K),1152K(R),2560K(A),-(H)\

mtdpartsパラメータと起動時の下記の表示です。

f:id:honeylab:20190510083000p:plain

なぜこのようなパラメータが必要なのか。それはSPIメモリは、USBメモリやHDDのような共通的なパーティションテーブルの仕組みを採用していないことが多いからです。
そのため、明示的にこのようなサイズ指定を行ってパーティションを決定してやる必要があります。

16進表記 10進表記 サイズ(K表示)
Start End Start End  
0 50000 0 327680 320
50000 1f0000 327680 2031616 1664
1f0000 310000 2031616 3211264 1152
310000 590000 3211264 5832704 2560
590000 800000 5832704 8388608

2496

さて、実際に吸い出したROMを解析します。
Linuxでよく使われる binwalk というツールを使います。 

binwalk dump.img -y filesystem

 によって、以下の出力が得られます。

DECIMAL HEXADECIMAL DESCRIPTION
---------- ----------------- -----------------------------------------------------
2031616 0x1F0000 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 1058498 bytes, 217 inodes, blocksize: 131072 bytes, created: 2018-08-28 05:24:06
3211264 0x310000 Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2248460 bytes, 4 inodes, blocksize: 131072 bytes, created: 2019-01-14 08:29:23
5832716 0x59000C JFFS2 filesystem, little endian

このパーティションの開始位置は、先程の開始位置と一致します。

しかし、3番めからです。

1番めと2番めはそれぞれ U-boot と Kernelのバイナリイメージがそのまま書き込まれています。パーティション内にファイルシステムを持っていません。

では、それぞれのパーティションをファイル化します。

 dd if=dump.img of=mtd2_Root.img skip=1984 bs=1024 count=1152

 dd if=dump.img of=mtd3_A.img skip=3136 bs=1024 count=2560

 dd if=dump.img of=mtd4_H.img skip=5696 bs=1024 count=2496

 これらのコマンドで後半3つのパーティションが切り出せます。
mtd2とmtd3はhsquashファイルシステム、mtd4はjffs2ファイルシステムのようです。

これをLinuxマシンに持っていって、マウントを試してみます。

マウントポイントを作成します。

sudo mkdir /mnt/mtd2

sudo mkdir /mnt/mtd3

sudo mkdir /mnt/mtd4

 マウントしてみます。

sudo mount mtd3_A.img /mnt/mtd3
sudo mount mtd4_H.img /mnt/mtd4 

 エラーが出なかったようなので、マウントできているようです。

マウントポイントに移動してlsしてみます

 /mnt/mtd2$ ls
bin etc init linuxrc mnt opt proc run sys usr
dev home lib media nfsroot p2pcam root sbin tmp var

 /mnt/mtd3$  ls
ca-bundle-add-closeli.crt cloud.ini p2pcam

 マウントできたようです。

mtd2がLinuxのルートファイルシステムです。また、mtd3はルートファイルシステムの/p2pcamをマウントポイントとしてマウントされます。

p2pcamは前に書いたように、このカメラのメインアプリケーションです。

どうやら、パーティション名の’A' は Application , ’R' は Root file system, 'H' は Homeのようですね。

そして、mtd4をマウントしようとしたところ、jffs2がサポートされていないと言われてしまいました。

jffs2はフラッシュメモリ用のファイルシステムのため、一般的なデスクトップ用のLinuxではドライバが入っていないようです。この辺を後で続けて試してみようと思います。

ドンキWiFIカメラ(6) SPIメモリをダンプする

さて、もういいかげんなんかハックしなきゃと思いつつ、とりあえずSPIメモリのフルダンプを取ります。
この間リーダーを買ったので取り外して読んでもいいですが、

honeylab.hatenablog.jp

ここはひとつ、u-bootから読んでみます。

シリアルを接続し、u-bootの起動中にキー入力でコンソールに落ちます。

 

GK7102 # sf probe

で実装されているSPIフラッシュが確認できます。

GK7102 # sf read 0xc1000000 0 0x800000

で、RAM上に SPIフラッシュの 0番地から 8Mぶん(全部)を読み込み、

SDカードを認識させます。

GK7102 # fatinfo mmc 0
[PROCESS_SEPARATORS] fatinfo mmc 0
Interface: MMC
Device 0: Vendor: Man 035344 Snr 173110f7 Rev: 8.0 Prod: SU32G
Type: Removable Hard Disk
Capacity: 30436.5 MB = 29.7 GB (62333952 x 512)
Partition 1: Filesystem: FAT32 "VOLUME1 "

先ほど読み込んだ内容をSDカードに書き込みます。

GK7102 # fatwrite mmc 0:1 0xc1000000 dump.img 0x800000
[PROCESS_SEPARATORS] fatwrite mmc 0:1 0xc1000000 dump.img 0x800000
writing dump.img
8388608 bytes written

 

ちゃんと書かれているか確認します。

GK7102 #
GK7102 # fatls
[PROCESS_SEPARATORS] fatls
usage: fatls <interface> [<dev[:part]>] [directory]
GK7102 # fatls mmc 0
[PROCESS_SEPARATORS] fatls mmc 0
dcim/
system volume information/
lost.dir/
android/
139676 board.pdf
27 info.txt
8388608 dump.img

3 file(s), 4 dir(s)

 SDカードを流用しているので他のファイルも見えますが、正しく書き込めているようです。

これをWindowsに持って行って読んでみます。

 

f:id:honeylab:20190509165721p:plain

読めてるっぽい。

 との結果も同じっぽいのでちゃんと読めてるっぽいな。

 

ドンキWiFIカメラ(5) じゃぁ何が問題なのか

まだ書くのかよ…という声が聞こえてきそうだけど、自分の勉強のためにも少しまとめておこう。

例のWiFiカメラ、Linuxは入っていないとのことですが、
基板に搭載されたSPIフラッシュの中身及び、電源が入っている状態で以下のソフトウェアが動作しています。

 

パッケージ名

該当バージョン  ライセンス
u-boot U-Boot 2012.10 (Dec 26 2017 - 18:17:43) for GK7102 rb-sc1045-v2.0 (GOKE) GPL
Linux

Linux version 3.4.43-gk (root@localhost.localdomain)

(gcc version 4.6.1 (crosstool-NG 1.18.0) ) #71 PREEMPT Fri Nov 10 15:20:07 CST 2017

GPL
busybox BusyBox v1.22.1 (2018-08-20 14:07:18 CST) multi-call binary. GPL
     
p2pcamに 以下のライブラリが静的リンクされている模様  
mkdosfs mkfsdos 2.11由来のリソースが多数検出 (2.11 (12 Mar 2005)) GPL
Wireless-Tools  Wireless-Tools 由来のリソースが多数検出 GPL
Zbar QRコード読み取りに使用 LGPL

 

そもそも、本体のプログラムとしてGPLのものを使っている場合(バイナリが当然配布されますので)、GPLに基づく著作権表記をしなければなりません。

例えば、これはe-mobileのPocketWiFiの説明書にある表示です。

f:id:honeylab:20190508001345p:plain

最近のルータ等、ネットワークでちょっと難しいことをするような製品にはたいていLinuxをはじめとするGPLのモジュールが含まれることがほとんどです。

しかし、ドンキのWiFi見守りカメラのどこを見てもこのような表示は見当たりません。
つまり、GPLの要求する著作権表示条件を満たしていないことになります。

まぁ、Linuxが入っていないと思っているんだから仕方ないかもしれません
その他、上の表に入っているモジュールが確認されていますので、それぞれの著作権表記と、ソースコードの公開が必要です。
p2pcamというクラウドサーバと通信するこのカメラのキモのアプリですら、GPLLGPLの制限により同様の処置が必要です。
設定用のQRコードを読み取るっていう重要そうな処理にZBarを使っているのですが、静的リンクにしてればちょっと状況は違ったかもしれませんが、ほかにもGPLが入っているので結局駄目ですね。

 

以下、お詫びして訂正します。出てきたわ。

 

でも、ソースコード絶対出ないよ。出すわけないもん。

 

なんでかっていうとまぁ結構みんな指摘している通り、このカメラは中華のどっかのメーカが作っているOEM製品なわけですよ。

例えばこれ

https://hkhongmei.en.alibaba.com/product/60861646443-805849863/YCC365_Plus_APP_auto_tracking_HD_720P_indoor_Fixed_WiFi_IP_Camera.html

https://ja.aliexpress.com/item/Wdskivi-1080-1080P-IP-WiFi-Cctv/32967060735.html

https://store.shopping.yahoo.co.jp/ekou/288zd-1080.html

こんなの。

見てわかるように、なんだかよくわからない販売店が売っているような製品です。
このメーカたちにコード請求しても絶対出さないよ。
国内のメーカーですら出さないところあるし。

 

そんな製品を、国内のあるメーカが開発元としてドンキに納品して、こうやって私のお手元に届いたわけ。
これ、ドンキみたいな販売店が手を出しちゃいけなかった製品なんだよ。

正直、ドンキには同情します。本当に知らなかったんじゃないかと。
しかしまぁ、開発元としてやってるところはこれほんとは知ってるだろ。
扱ってる商品がAndroidタブレットだったりナビだったり、OEMやってたり。

 

そんなわけで、セキュリティがポンコツうえにGPL違反でアレげな製品ですが、カメラと無線LAN(RTL8188)とSDカードスロットとマイクとスピーカー(単純なADCとDACっぽくてLinuxから見えないけど)がついて、実際に使える上に3980円となかなかお値打ちな製品なんで、そういうものを自作する代わりに買う、という用途にはおすすめです。

 

GPL関係で何か間違ってたら教えてください。ライセンス周りは素人なので。

 

ドンキWiFiカメラハック(4) セキュリティ上の問題と、Linuxは使用されていなかった!

【追記】改めて確認したところ、製造元及びドンキホーテLinuxの使用を確認し、ソースコードの開示をはじめました。

 

ここまでの調査の結果、以下のような問題がわかりました。

 

このカメラ、とにかくWiFiにつないでクラウド経由で画像を表示することが目的で、ローカルのセキュリティはポンコツです。
アプリからはメールアドレスとパスワードで紐付けられたユーザしか利用できませんが、
telnetやRTSPはローカルに流れたままのため、このカメラが接続されたネットワーク環境内からは画像が自由に見れることになります。また、パスワードを設定することは不可能です。
そのため、このカメラを設置したネットワーク環境では、WiFiのパスワード管理を行ったり、知らない人にLANポートを貸したりしないようにしたほうがいいです。

f:id:honeylab:20190507132346p:plain



先述の通り、telnet経由で自由にスクリプトを仕込むことができます。
定期間隔で、自分の専用サーバに画像を送ったり、動画を見続けることも可能になってしまう可能性があります。(実行した本人が法に触れる可能性があります。)

ただし、これはこの製品特有のものではなく、いわゆる中華カメラ製品にはよく見られるものです。それなのにそのまま、まるで日本の市販製品のようなガワをつけて販売しているのは問題ではないかと思いますが、あんまり追い詰めるとこんなにおもしろいデバイスが安く買えなくなってしまいますのでそっとしておきましょう(遅い)。

 

以下は、最初の対応ですが、その後Linuxが使われていることを確認してくれました。

また、ここまでの調査で、本体内にはu-bootやLinuxカーネルbusyboxのバイナリがあることがわかっていました。そのため、発売元であるドン・キホーテソースコードの開示を請求したところ、きちんと開発会社に確認を取り、

Linuxを使用していないので開示できるソースコードはない」

と返答をしてくれました。

 

なんと!Linuxは使用されていないとのことでした!
販売元を通じた回答なのでこれが正式な回答なのでしょう。

基板に乗っているSPIFlashにu-bootやLinuxKernelのバイナリが入っていますが、使用していないなら仕方ありま…

(しかし、使用されていなくてもバイナリが渡ってたらソースもいるんじゃなかったっけ…)せん!

いや、ぶっちゃけそのモノ自体には興味がなく、販売元と製造元がどんな対応をするのか、ということ自体に興味があったので、その結果が得られて満足です。

 

さてさて、まぁLinux入ってるんで、まだまだいろいろ遊んでみますかね。

改めて言うけど、パスワード設定できないんで、ローカルLAN内でのセキュリティに気をつけてね!!

ドンキWiFiカメラハック(3)

前回までの記事はこちら

honeylab.hatenablog.jp

honeylab.hatenablog.jp

 

追加してきたのでもう安心。

Image

 

さてと、このカメラ、AndroidiOSにターゲットを絞り、クラウドに誘導することで日銭を稼ぐシステムの片棒を担がされている気がするので、その辺を外していきます。

ドンキはこれいくらで仕入れてきてるんだろう?

開いてるポート番号を調べてみます。外からツールを使うのではなくて、netstatで調べます。

# netstat -a -p
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 localhost:9008 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:www 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:telnet 0.0.0.0:* LISTEN 204/telnetd
tcp 0 0 0.0.0.0:5050 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:7101 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:7103 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:8001 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:3201 0.0.0.0:* LISTEN 159/tees
tcp 0 0 0.0.0.0:554 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:843 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 0 0.0.0.0:6670 0.0.0.0:* LISTEN 187/p2pcam
tcp 0 157 192.168.200.1:telnet 192.168.200.100:5388 ESTABLISHED 204/telnetd
udp 0 0 0.0.0.0:7998 0.0.0.0:* 187/p2pcam
udp 0 0 0.0.0.0:8001 0.0.0.0:* 187/p2pcam
udp 0 0 0.0.0.0:8002 0.0.0.0:* 187/p2pcam
udp 0 0 0.0.0.0:bootps 0.0.0.0:* 269/udhcpd
udp 0 0 0.0.0.0:8888 0.0.0.0:* 187/p2pcam
udp 0 0 0.0.0.0:20188 0.0.0.0:* 187/p2pcam
udp 0 0 0.0.0.0:9999 0.0.0.0:* 187/p2pcam
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 259 185/rsyscall.goke /tmp/systemcall.sock
unix 2 [ ACC ] STREAM LISTENING 282 187/p2pcam /tmp/aaa
unix 2 [ ] DGRAM 547 264/hostapd /var/run/hostapd/wlan0
unix 3 [ ] DGRAM 231 159/tees /var/run/tees.sock
unix 2 [ ] STREAM CONNECTED 327 264/hostapd /tmp/systemcall.sock
unix 2 [ ] DGRAM 299 187/p2pcam 

見にくい。Excelで整形しよう。

9008 187/p2pcam
www 187/p2pcam
telnet 204/telnetd
5050 187/p2pcam
7101 187/p2pcam
7103 187/p2pcam
8001 187/p2pcam
3201 159/tees
554 187/p2pcam
843 187/p2pcam
6670

187/p2pcam

 telnetdはbusyboxで、そのほかのサービスは内蔵のカメラアプリが開いて要るっぽい。
専用サーバアプリじゃないのでURLが分かりにくい…

使えそうなポートを確認してみる。554はRTSPだ。

VLC Media Playerを開き、rtsp://192.168.200.1:554/ を開く。

f:id:honeylab:20190507050737p:plain

うん。簡単に再生できた。ローカル内で監視するならこういった簡単な操作が望まれる。

f:id:honeylab:20190507051003p:plain

(上記画像は、暗いところなので暗視白黒になっている)

これで遠隔からptzを制御できれば完璧なのだが、どうやら今のところ独自プロトコルらしく、独自に解析されたこちらのツールを使うのがいいようだ。

https://github.com/ant-thomas/zsgx1hacks

wwwもあるのだが、どうも該当ファイルが置いていないか無効化されていて何もできないっぽい。上のハックツールではそれを利用しているようにも見える。

 

そして、ここの解析にもある通り、このWebカメラ、起動時にmicroSDスロットに特定のファイル名でシェルスクリプトを置いておくと実行してくれる超便利な機能があるっぽい。

f:id:honeylab:20190507052835p:plain


うーん、便利!

このカメラ、なんとスピーカーが付いていて起動後何も設定されていなかったりすると「QRコードを読み込んでなんたらかんたら」って怪しいイントネーションの日本語でしゃべったりするんですよね。

この音声ファイルはFLASHに圧縮されて書き込まれていて、起動時にRAMに展開されています。

FLASHを上書きするのはちょっとめんどいので、RAM上のこのファイルを上書きすると好きな音声でしゃべらせられるようになると思います。

f:id:honeylab:20190507053507p:plain

あと、一部の音声は英語のままなので出ないと思いますし、怪しくないイントネーションの日本語もあるので、オリジナルの日本語対応の後、クラウド化による日本語追加が行われている気がします。

alarm.wavはひゅーんっていう効果音で、何か警告音を鳴らせるのでしょうか。

これが謎の音声とかにできれば不審者にいいトラウマを植え付けられますね(駄目です)
うーん、単独で音声ファイルを再生できるツールがあれば任意のタイミングでならせる気がするが、これp2pcamバイナリでしかできないのかな…(Linuxサウンドバイスとしては見えてない)

 

その他のポートが何なのか今のとこわかっていないが、RTSPでストリームを見れるだけで結構便利だと思います。
ネットワークに詳しいならクラウド使わなくてもこれだけ転送すれば行けるでしょ

(セキュリティに気を付けてね!)

 

<追記>

普通にONVIFカメラとしてストリーム再生、PTZ操作できました…

f:id:honeylab:20190507073821p:plain