3COINSのビデオトランシーバーで遊ぶ

はじめに

話題になっていた元ツイート
https://x.com/MieAC129/status/2056599281726025899?s=20

自分の関わってる団体でも

じゃあ自分もやるしかないよなぁと思い

商品について

3850円で"2つ"もトランシーバーがついている優れもの(当たり前)
その値段でこの品質のものが作れるんだというのが驚き

僕が買おうとした時(2026/5/28時点)にはもう既にオンライン通販は売り切れになっていたので大学の近くにあったスリコまで買いに行きました。

ということで

入手。

説明書などからわかること

2.4ghzで通信してるらしい(WifiやBluetoothなど様々な機器で使われている帯域)

機能

• ビデオ通話モード
• メッセージ送受信出来るモード(lineみたいな感じ)
• カメラ
• 撮った写真を見るアルバム
  の4つの項目となっている。

調べていくうちに分かったこと

• HG-WIFI_?????? (?は個体ごとのランダムな数字)というAPが出ている
• このAPを出しているのは紫の方の機体
• デフォルトでは紫が親機、水色が子機となって通信を行っている
• Xで見た情報によると隠しAPがあるらしい(未検証) https://x.com/atc1441/status/2058216242352144678?s=20
• Macアドレスで制限を行っている

実際に調査をする

SSID接続

まず、Wifiを確認した際にHG-WIFI_??????というSSIDが出ていたので純粋に接続
パスワードは必要なかった

windows,mac,RaspberryPiOSで試して失敗

AIに聞いたらmacアドレスで制限がかけられているぽい

じゃあ子機と同じmacアドレスに変更して接続しちゃえばいいよねという話

macアドレス解析

暗号化されていないwifiは繋がなくても流れてる通信を覗くことが出来る、という知識はあったので調べる

monitor modeを使う

Wiresharkのmonitor modeで覗けるらしい
しかし、設定を変更しても何のパケットも流れない
昔は出来たけど現在のmacのバージョンだと厳しいらしい

RaspberryPiOSでも試してみたが、Broadcom内蔵Wi-Fiは monitor mode 出来るほどの性能がないらしく、
sudo iw dev wlan0 set type monitor
で:
Operation not supported (-95)

別でwifi子機を接続すればいけそう？(未検証)

自分で調べてもストップしてしまったので現代の最強知能、claudeさんを使うことに
する

Wireless Diagnostics Snifferを使う

Macのデフォルトで入ってるアプリのWireless Diagnostics Snifferを使えばいけるらしい
日本語だとこれ

ウィンドウから色々な機能を使うことが出来る

スキャンからチャンネルを見る

このように表示されるので自分のトランシーバーのチャンネルを確認する
自分の場合は7だった

スニファではチャンネルを指定する必要があるので先程発覚したチャンネルを指定する

中止を押すまでファイルが生成されないところに注意

このような.pcapファイルが生成されるのでwiresharkで解析

キャプチャしたpcapを解析してみる

キャプチャした .pcap / .pcapng を解析すると、UDP payload内にJPEG断片が存在していた

実際に観測された通信:

192.168.1.1:11012 -> 192.168.1.100:11014
192.168.1.100:11013 -> 192.168.1.1:11011

平文で流れており、JPEG開始マーカー

FF D8

が確認できた

通信内容を調べる

ポート構成

11011 映像受信
11013 子機映像送信
11012 制御/probe
11014 維持応答
5008 keepalive/状態通知

11013 -> 11011
でJPEG chunk

UDP payloadを調べると、

20 byte header + JPEG chunk

という形式で、JPEGは1308 byteごとに分割され、独自ヘッダ付きで送られていた。

デコード

decode_pcap.pyでpcap/pcapngをデコードし、jpeg画像に変換出来る

子機として認識させる

先程の解析によってmacアドレスが分かるので子機っぽい方のmacアドレスを偽装する

現在のmacアドレスを確認

ifconfig en0 | grep ether

Wi-FiをOFFにしてから

sudo ifconfig en0 ether ???????????

で再起動するまでmacアドレスを変更することが出来る

HG-WIFI_??????に接続が出来るはず

画像、動画を送る

まずはデモ

画像、動画を送ってみた

画像

動画

https://github.com/yama4936/video-transceiver.git
send_image.py
send_video.py
を実行することで再現出来る

画像・動画はどのような形式で送られているのか

キャプチャした通信を解析すると、映像データはTCPではなくUDPで送信されていた。

主な通信ポートは以下の通りです。

11011 映像受信
11013 映像送信
11012 制御/probe
11014 維持応答
5008 keepalive

特に、11013 → 11011
の通信にJPEGデータが含まれていました。

JPEGそのものが送られていた

UDP payloadを解析すると、
FF D8
で始まり、
FF D9
で終わるデータが確認できた。
これはJPEGファイルの開始マーカー(SOI)と終了マーカー(EOI)である。
つまり映像は、独自圧縮形式ではなく、JPEG画像をそのまま送信している。

実際にキャプチャからJPEGを抽出すると画像の復元に成功した(decode_pcap.py)
1枚のJPEGを分割して送信している
しかしJPEG全体が1パケットに入っているわけではありません。
解析すると、
20 byte 独自ヘッダ + JPEGデータ
という構造になっていた。

JPEGは約1308byteごとに分割され、

[header][jpeg chunk]
[header][jpeg chunk]
[header][jpeg chunk]
...

として送信されている。

推定した映像フレーム構造
実装では以下の形式を採用した。

20 byte header
1308 byte JPEG chunk

ヘッダには以下の情報が含まれていると推定しています。

frame id
chunk number
chunk count
tick
flags

特に先頭1byteには
開始フラグ 終了フラグ frame id
が格納されている

動画も実質JPEG連続送信

さらに動画通信を観測すると、

H.264やH.265のような動画コーデックではなく、

JPEG
↓
JPEG
↓
JPEG
↓
JPEG

というMotion JPEG(MJPEG)に近い方式で送信されていた。

そのため、

OpenCV
↓
JPEG変換
↓
UDP送信

だけで動画表示に成功した。

実際の送信処理

静止画の場合

Pillowで画像読込
↓
JPEG変換
↓
1308byteごとに分割
↓
独自ヘッダ付与
↓
UDP送信

動画の場合

OpenCVでフレーム取得
↓
JPEG変換
↓
1308byteごとに分割
↓
独自ヘッダ付与
↓
UDP送信

という流れで行っています