re-iot-proto

IoT プロトコルのリバースエンジニアリング（MQTT / CoAP / BLE / Zigbee / NFC スマートカード）

使用する場合 / 使用しない場合

• 使用する：IoT デバイスのトラフィック（pcap / リアルタイムキャプチャ）を取得し、MQTT / CoAP のセマンティクスを解析する必要がある場合
• 使用する：BLE デバイス（adv / GATT）のインタラクションを分析する場合
• 使用する：Zigbee（802.15.4）ネットワークのキャプチャと ZCL コマンドの分析を行う場合
• 使用する：デバイスの「アップロード / 制御コマンド送信」のセマンティクスを理解し、ファームウェアと連携する必要がある場合
• 使用しない：汎用カスタムプロトコルの場合（[[re-proto-rev]] を使用してください）
• 使用しない：一般的なネットワークトラフィックのキャプチャの場合（[[re-netcap]] を使用してください）
• 使用しない：キーのない暗号化トラフィックの場合——まず [[re-crypto-id]] / [[re-crypto-keys]] を参照してください

ツールの準備

物理デバイスのキャプチャでは、権限の境界に注意してください（手順 5 を参照）。動的なシナリオでは、デフォルトでサンドボックス / 隔離ネットワークを使用してください（[[re-analyze/platform-tips]] の最優先原則）。すべてのツールは、使用前に検証してください。

wireshark / tshark —— 主要な解析ツール（MQTT/CoAP/BLE/Zigbee dissector を内蔵）

• Linux: apt install wireshark tshark / dnf install wireshark-cli wireshark / pacman -S wireshark-cli wireshark-qt（Arch は wireshark-cli + wireshark-qt に分割済みです。Debian ではインストール時に「root 以外のユーザーによるキャプチャを許可」を選択するか、sudo dpkg-reconfigure wireshark-common の実行後、ユーザーを wireshark グループに追加してください）
• macOS: brew install --cask wireshark（tshark CLI を含みます。または brew install wireshark で CLI のみをインストールします）
• Windows: choco install wireshark；WSL 内では Linux 版を使用してください
• 検証: tshark --version；tshark -G fields | grep -iE 'mqtt|coap|btatt|zbee' でフィールド名を一覧表示します（フィールド名はバージョンごとに多少異なります。表示された内容を基準にしてください）

scapy —— オプションの解析 / 構築ツール

• 全プラットフォーム: pip install scapy（Python 3）
• 検証: python3 -c "import scapy; print(scapy.__version__)"

MQTT —— mosquitto クライアント（能動的なサブスクライブ / パブリッシュの検証）

• Debian/Ubuntu: apt install mosquitto-clients（mosquitto_pub / mosquitto_sub）
• Fedora: dnf install mosquitto；Arch: pacman -S mosquitto；macOS: brew install mosquitto；Windows: choco install mosquitto
• 検証: mosquitto_pub -h；mosquitto_sub -h
• GUI の代替ツール: MQTT Explorer（クロスプラットフォームのデスクトップアプリ）

CoAP —— coap-client / aiocoap

• Debian/Ubuntu: apt install libcoap3-bin（coap-client を提供します）
• Fedora: dnf install libcoap libcoap-utils（coap-client は libcoap-utils サブパッケージに含まれます）；Arch: pacman -S libcoap（extra）；macOS: brew install libcoap
• ディストリビューションのパッケージにサンプルプログラムが含まれていない場合 → pip install aiocoap（コマンドは aiocoap-client、Python 3）
• 検証: coap-client -h（または aiocoap-client -h）

BLE —— bluez + ubertooth

• bluez（btmon / hcitool）: Debian/Ubuntu apt install bluez；Fedora dnf install bluez；Arch pacman -S bluez bluez-utils；検証 btmon --help
• ubertooth（2.4GHz スニッフィングハードウェア）: Debian/Ubuntu apt install ubertooth（ファームウェアは別途 ubertooth-firmware をインストール）；Fedora dnf install ubertooth（Fedora 43/44 の公式リポジトリにあります）；Arch の公式リポジトリにはありません → AUR；macOS brew install ubertooth；検証 ubertooth-btle -s
• Android btsnoop（インストール不要）: 開発者向けオプション →「Bluetooth HCI snoop ログを有効にする」にチェック → インタラクションを再現 → adb bugreport を実行するか、/sdcard/btsnoop_hci.log を取得します（btsnoop 形式。Wireshark で直接開けます）
• nRF Sniffer for BLE（Nordic、オプション）: nRF シリーズのドングル + Wireshark extcap が必要です（主に Windows/macOS 向け）

Zigbee —— Wireshark + スニッファーハードウェア + KillerBee

• Wireshark の zbee dissector は内蔵されています（zbee_nwk / zbee_aps / zbee_zcl）。復号は Preferences → Protocols → ZigBee → Security で設定します（Decryption にチェックを入れ、Network Key / Link Key を入力）
• スニッファーハードウェア（ディストリビューションのパッケージはありません。ハードウェアで対応）: TI CC2531 USB スティック（Sniffer ファームウェアを書き込み）または Silicon Labs EFR32MG（Simplicity Studio で sniffer を書き込み + Wireshark extcap）
• KillerBee（Python、ZCL のキャプチャ / 構築 / リプレイ）: Debian/Fedora/Arch の公式リポジトリにはパッケージがありません → pip3 install killerbee（PyPI。libusb/libpcap に依存します——Debian/Ubuntu apt install libusb-1.0-0-dev libpcap-dev、Fedora dnf install libusbx-devel libpcap-devel、Arch pacman -S libusb libpcap）；ファームウェアの書き込み sudo ./kb_install_firmware；検証 kb --version
• ZBOSS プロトコルスタック（DSR 社の Zigbee スタック）のドキュメントを NWK/APS/ZCL の構造を参照する際に利用します
• キー抽出との連携: [[re-firmware]]（ファームウェア flash からキーを読み取り、zbgoodfind と併用）/ [[re-crypto-keys]]

操作步骤

按顺序执行，每步产物（pcap / 密钥 / 解析脚本 + sha256）存档。

1. 协议识别：

   tshark -r cap.pcap -q -z io,phs                                   # 协议分层统计
   tshark -r cap.pcap -T fields -e tcp.dstport -e udp.dstport | sort | uniq -c | sort -rn
   

   • 端口速查: MQTT 1883（明文）/ 8883（TLS）；CoAP 5683（UDP）/ 5684（DTLS）；BLE: 广播与 GATT（bthci_evt / bthci_acl / btatt 层，无端口）；Zigbee: 802.15.4 帧（无端口，2.4GHz 信道 11-26）
   • 非标端口 → Wireshark Decode As / tshark -d tcp.port==9999,mqtt 强制指定
   • 特征确认: MQTT 首字节为控制类型（CONNECT 0x10 / PUBLISH 0x30 ...）；CoAP 头 Ver 字段 2 位（值 01）；BLE HCI 事件包 0x3e；Zigbee 帧首 2 字节 802.15.4 帧控制字段
2. MQTT/CoAP 解析（topic / payload）：

   tshark -r cap.pcap -Y mqtt -T fields -e mqtt.topic -e mqtt.msg
   tshark -r cap.pcap -Y 'mqtt.topic contains "ota"' -T fields -e mqtt.msg    # 按主题过滤
   tshark -r cap.pcap -Y coap -T fields -e coap.code -e coap.uri_path -e coap.opt.content_format
   

   • topic 即控制语义: device/<id>/sensor、ota/update、cmd/relay 等——先按 topic 分桶（-e mqtt.topic | sort | uniq -c）
   • payload 常见 JSON / protobuf / 自定义二进制 → 字段含义对照设备 App 或固件（步骤 5）
   • 主动交互验证（授权内）: mosquitto_sub -h <broker> -t '#' -v（全量订阅）、mosquitto_pub -h <broker> -t <topic> -m '{"relay":1}'；coap-client -m get coap://<ip>/sensor、coap-client -m put -e '{"on":1}' coap://<ip>/relay
   • 加密（8883 / 5684）: TLS 用 SSLKEYLOGFILE 解密；RSA 私钥只适用于旧式 static-RSA 密钥交换（TLS 1.3 与 ECDHE 会话解不开）；DTLS PSK 在 Wireshark dtls 偏好填十六进制预共享密钥（密钥来源见步骤 4 与 [[re-crypto-keys]]）
3. BLE 抓包（adv / GATT）：
   • Android btsnoop: 开发者选项开启 snoop 日志 → 复现 App 与设备交互 → 拉取 btsnoop_hci.log 用 Wireshark 打开（自动解 HCI）
   • Linux: btmon -w out.btsnoop（配合目标连接过程；写出的 btsnoop 格式 Wireshark 直接打开）
   • ubertooth（无主机侧蓝牙时可嗅 2.4GHz）: ubertooth-btle -f -c 0（follow 模式观察广播 / 连接包）、ubertooth-btle -s（扫描）——实时显示不落盘，配合屏幕分析；要落盘进 Wireshark 用 btmon / Android btsnoop / nRF Sniffer（extcap）
   • GATT 解析:

     tshark -r ble.pcap -Y btatt -T fields -e btatt.opcode -e btatt.uuid -e btatt.value
     

   • 关注: 广播包（设备名 / 厂商数据 / 服务 UUID）与 GATT 读写特征（传感器值、控制指令、固件版本）
4. Zigbee（802.15.4）：
   • 硬件 sniffer 捕获（CC2531 / EFR32，选对信道）→ Wireshark zbee 解析
   • 解密: Preferences → Protocols → ZigBee → Security: 勾 Decryption、填 Network Key（16 字节 hex）与 Link Key（Zigbee 3.0 常见默认 TC link key 为 ZigBeeAlliance09）
   • 密钥获取路径: ① 抓网络组网过程（Trust Center 向新节点下发 network key）② 默认 TC link key / install code ③ 固件 flash 提取（[[re-firmware]] / [[re-hardware-io]]，配合 zbgoodfind 在固件里找密钥）④ 物理访问协调器读配置
   • 层结构: NWK（寻址/加密）→ APS（端点/簇）→ ZCL（命令: 开关 / 读属性 / OTA）——tshark -r zigbee.pcap -Y zbee_zcl -T fields -e zbee_zcl.cmd 看命令（字段名以 tshark -G fields | grep -i zbee 为准）
   • KillerBee 交互（授权内）: zbdump（抓包）、zbstumbler（扫网）、zbreplay（重放 ZCL 命令）
5. 设备固件联动（走 [[re-firmware]]）：
   • 协议语义不明 / 自定义 payload → 固件提取（binwalk 解包）→ rootfs 里找协议实现（字符串 / so）、密钥、topic 硬编码 → [[re-fw-emulate]] 仿真设备复现协议行为
   • 协议常量与固件字符串交叉验证（端口、magic、topic 前缀）
   • OTA 通道也是协议面: MQTT topic ota/update 下发固件 → 截获的固件镜像可再走 [[re-firmware]]

BLE 链路层

应用层之外补链路层视角：空口嗅探、广播/连接帧结构、配对加密协商与密钥定位。抓包工具底座见上文「BLE —— bluez + ubertooth」，本节侧重链路语义与深挖点。

嗅探硬件与软件（泛化选购指引）

• 主机侧（btmon / Android btsnoop）只能看到本机参与的过程；设备与第三方设备之间的交互需空口嗅探
• nRF 系 dongle + Sniffer 固件 + Wireshark extcap（桌面端为主）: 选购关注芯片覆盖的蓝牙核心版本（4.2 / 5.x 是否支持 LE Secure Connections 跟踪）、固件是否支持连接事件跟踪（跟随跳频）、天线形式（板载/外置，影响接收距离）
• ubertooth 类 2.4GHz 嗅探器: 适合广播与无加密连接的链路层数据；不参与连接，加密连接内容看不到
• 共性局限: 空口嗅探对加密连接只能看时序与包长，内容解密需 LTK（见下）

广播包解析

• PDU 类型区分连接意图: ADV_IND（可连接非定向，最常见）、ADV_SCAN_IND（可扫描）、ADV_NONCONN_IND（纯广播）、ADV_DIRECT_IND（定向）
• 帧结构: 2 字节头（PDU 类型 + 长度）+ Payload（AdvA + AdvData）；AdvData 为 AD structure 链（Length + AD Type + Data）: 0x01 Flags、0x03/0x07 服务 UUID、0x09 完整本地名、0x0A Tx Power、0xFF 厂商数据
• 解析: tshark -r ble.pcap -Y btle -T fields -e btle.advertising_address -e btle.advertising_header.pdu_type -e btle.advertising_data（字段名以 tshark -G fields | grep -i btle 为准）；0xFF 厂商数据段常含私有协议与设备标识，值得逐字节对照固件
• 广播只承载低频状态通告（名字/状态/服务发现），业务数据一般在连接后 GATT 通道

连接事件时序与信道 37/38/39

• 主广播信道固定 37/38/39（2402/2426/2480 MHz），广播事件在三信道轮转；扫描请求/响应与 CONNECT_IND 也在这三个信道
• CONNECT_IND 携带访问地址、跳频增量与连接参数 → 据此可推算后续数据信道序列（0-36）与事件节奏
• 连接参数: connInterval（1.25ms 步进）、slaveLatency、supervisionTimeout，在 HCI 层 LE Connection Complete 事件可见；连接事件以锚点（anchor point）起算，按 connInterval 周期出现
• 验证: 抓包中连接数据包间隔应为 connInterval 的整数倍；间隔混乱或单侧缺失 → 跳频跟踪脱同步（见坑 3）

ペアリング／暗号化ネゴシエーション

• フロー：Pairing Request/Response（SMP）→ 一時鍵の導出 → LTK の生成 →（ボンディング）双方で LTK を保存
• LE Legacy：PIN／一時値に基づいて STK を導出します。LE Secure Connections：P-256 ECDH を使用し、AuthReq の MITM ビットで中間者攻撃への対策の有無が決まります（Just Works はユーザー認証なし、Passkey／Numeric Comparison はあり）
• 確認箇所：Wireshark で SMP の交換を確認し、AuthReq（SC／MITM／Bonding ビット）を確認します（フィールドは tshark -G fields | grep -i smp を基準にします）。まずモードを確認してから、復号するかタイミングのみを見るかを決めます
• ボンディング後の再接続では再ペアリングされず、LTK の交換は初回ペアリング時のみ発生します
• 鍵の保存先：ホスト側（システムの Bluetooth 設定／キー値ストレージ）とデバイス側（flash／外部 EEPROM）→ [[re-firmware]] ／ [[re-crypto-keys]] で抽出します。LTK を入手したら Wireshark の BLE 設定に入力して、接続データを復号できます

GATT サービスと特性の列挙

• パッシブ：btmon／btsnoop でサービス検出（Discover All Primary Services／特性検出）をキャプチャします。btatt 層で UUID とハンドルの対応を直接確認できます
• アクティブ（接続後）：gatttool 系ツール（bluez）の primary ／ characteristics で handle ↔ UUID ↔ 属性を列挙します
• 読み書き／通知箇所：特性ハンドルと CCCD（0x2902）で通知／表示を有効にすると、値のストリームは btatt.value に表示されます。tshark -r ble.pcap -Y btatt -T fields -e btatt.handle -e btatt.value

注意点と落とし穴

• アドバタイズと接続データの混同：現象——アドバタイズパケットのベンダーデータ領域に業務データらしきものを見つけ、報告内容として解析した結果、アプリの動作と一致しません。原因——アドバタイズは低頻度の通知のみを担い、業務データのストリームは接続後の GATT チャネルにあり、暗号化されている場合もあります。対策——まずフレームタイプごとに振り分けます。btle のアドバタイズパケットでは AdvData を解析し、接続データは btatt 層で確認します。対象デバイスが接続状態に入っているかを判断してから、どのデータをキャプチャするか決めます
• ペアリングモードの誤判定：現象——「ペアリング過程をキャプチャすれば復号できる」と進めた結果、接続がすべて暗号文になるか、平文だが認証されない状態になります。原因——モードは AuthReq ビットで決まります。SC=0 かつ MITM=0 は LE Legacy Just Works で、ユーザー認証がなく、盗聴者によるなりすましも防止しません。SC=1 は LE Secure Connections（ECDH）です。対策——SMP Pairing Request の AuthReq を解析してモードを確認し、復号（LTK が必要）するか、タイミングのみを見るかを選びます
• キャプチャで接続イベントを取りこぼす：現象——アドバタイズと接続確立は確認できるのに、接続イベントが断続的にしか記録されないか、片側のパケットしかありません。原因——データチャネルの周波数ホッピングを追跡できていません（アンカーを逃すと同期が外れます）。単一チャネルだけを固定して監視しているか、無線干渉でパケットが失われています。対策——まずホスト側の btmon／btsnoop を使います（全チャネルを確実に取得できます）。無線キャプチャには接続追跡機能を備えたファームウェアを使用し、CONNECT_IND のアクセスアドレスとホッピング増分に基づいて追跡を検証します
• LTK はキャプチャに含まれない：現象——SMP の交換後に LTK 関連のパケットがなく、復号に必要な鍵がありません。原因——ボンディング後の再接続では保存済みの鍵を直接使うため、再交換されません。対策——ペアリング情報を消去／リセットしてから初回ペアリングを再キャプチャするか、デバイスの flash ／アプリのストレージから抽出します（[[re-firmware]] ／ [[re-crypto-keys]]）

NFC ／スマートカード

接触型／非接触型スマートカード：ISO14443 リンク、APDU のやり取り、一般的なカードファミリーの弱点を扱います。ハードウェアには proxmark3 系の汎用リーダー／ライターを使用します（一般的な選定基準）。キャプチャ／分析の前に、許可された範囲を確認してください。

ISO14443 のフレーム構造とアンチコリジョン処理

• ISO14443A のフロー：REQA（0x26 の短フレーム）→ ATQA → アンチコリジョン（UID を CL1／CL2／CL3 の各カスケードレベルでビット単位にネゴシエート）→ SELECT → SAK（カードタイプ識別子）
• フレーム構造：SOF + データバイト（各バイトにパリティチェック付き）+ CRC_A（2 バイト）+ EOF。短フレームは 7 ビットです（REQA/WUPA）
• SAK による判定：0x08/0x88 系 → MIFARE Classic ファミリー（Crypto-1、セクター／ブロック構造）、0x20/0x40 系 → DESFire ファミリー（ファイルシステム + AES/3DES）。まずタイプを判定してから手順を選びます（落とし穴 1 を参照）
• リーダー／ライターの手順：hf 14a reader 系のコマンド（proxmark3 系の汎用コマンド）で ATQA ／ UID ／ SAK を一括出力し、それに基づいて該当するカードファミリー用のツールに進みます

APDU のやり取り

• ISO7816-4 APDU：CLA + INS + P1 + P2。その後に Lc／データ／Le がケースに応じて現れます（Case1 は 3 つともなし、Case2 は Lc／データなしで Le はあり、Case3 は Lc+データありで Le なし、Case4 はすべてあり）。解析境界を判断する前に、まずケースを特定します。レスポンスは SW1/SW2（0x9000 は成功）です
• 一般的な命令：0xA4 SELECT（アプリケーションの選択）、0xB0 READ BINARY、0xB2 READ RECORD、0x20 VERIFY（パスワード認証）、0xD0 WRITE BINARY、0xD6 UPDATE BINARY。ただし、カード／アプリケーションごとに命令セットが異なります（落とし穴 2 を参照）
• 接触型カードは ISO7816 T=0/T=1 を使用します。非接触型カードでは APDU がそのまま転送されることが多く（DESFire ISO モードなど）、キャプチャ位置が異なります
• 特定のコツ：既知の正規なやり取り（リーダー／ライターのログ／スマートフォンの NFC ログ）をキャプチャして命令シーケンスと照合すると、ドキュメントを見ながら推測するより速く特定できます

MIFARE Classic と Crypto-1 の弱点（一般論）

• Crypto-1 は 48 ビットのストリーム暗号です。認証時にはリーダー／ライターがチャレンジを送信し、カードが暗号化されたレスポンスを返します。PRNG と認証プロトコルには既知の弱点があり、暗号化されていない認証レスポンスのサンプルを基に、鍵を復元できる場合があります（リプレイ／既知平文の考え方）
• 前提：カードが任意のリーダー／ライターからの認証要求に応答すること（未知の鍵を拒否するよう設定されていないこと）。この前提を満たさない場合、この方法は適用できません。鍵の抽出（[[re-crypto-keys]] ／ [[re-firmware]]）またはファームウェア分析に切り替えます
• 適用範囲：Crypto-1 系カードのみが対象です。AES 系カード（DESFire ファミリー）は構造が異なるため、適用できません

proxmark3 系デバイスの手順（一般的な選定基準）

• 選定時の確認事項：13.56MHz の高周波に対応していること（必須）、ファームウェアが継続的に更新されていること、現場での書き換えに対応していること、アンテナ性能と筐体の形状
• 手順：電源投入時のセルフテスト → hf 14a reader でタイプ判定 → カードファミリーに応じた攻撃／読み書き手順を選択 → 結果を検証
• 許可範囲：読み取り専用とカードへの書き込み／複製のいずれも許可が必要です。ラボ環境でカードの所有者と目的を確認してください（[[re-analyze/platform-tips]] 最優先原則）

注意点と落とし穴

• カードタイプの判定ミス（MIFARE と DESFire は構造が異なる）：現象——Classic のセクター／ブロック構造に基づいてカードを解析しても、アドレスとデータがまったく一致しません。原因——Classic（Crypto-1、セクター／ブロック構造、SAK 0x08/0x88 系）と DESFire（ファイルシステム、AES/3DES、SAK 0x20/0x40 系）では内部構造がまったく異なります。対策——まず SAK（ATQA と併せて確認）でカードファミリーを判定してから、解析／攻撃手順を選びます。ひとつの構造をすべてのカードに当てはめないでください
• APDU 命令セットの違い：現象——同じ命令でも A カードでは成功し、B カードでは 0x6A82（ファイルが見つからない）／0x6D00（命令がサポートされていない）系のエラーが返ります。原因——カード／アプリケーションによって、CLA プレフィックス、INS、P1/P2 の規則が異なります（独自の CLA、拡張命令、パラメーターの意味の違い）。対策——まず対象のアプリケーションを SELECT し、既知の正規なやり取りをキャプチャして命令シーケンスと照合し、SW ステータスコードに基づいて一つずつ調整します
• Crypto-1 攻撃の前提条件：現象——鍵の復元手順を実行できないか、結果が正しくありません。原因——この方法では、まずカード側の暗号化されていない認証レスポンスのサンプルを入手する必要があります。カードが未知のリーダー／ライターからの認証を拒否する場合や、環境上中間者を介在させられない場合は、手がかりがありません。対策——まずカードが任意のリーダー／ライターからの認証要求に応答するかを検証します。前提を満たす場合は攻撃手順に進み、満たさない場合は鍵の抽出／ファームウェアの手順に切り替えます（[[re-crypto-keys]] ／ [[re-firmware]]）
• UID とデータブロックの混同：現象——カードへの書き込み／複製後に対象カードの動作がおかしくなるか、読み書きに失敗します。原因——UID とメーカー領域（ブロック 0）にはロック／チェックサムがあり、一部のカードファミリーでは UID を変更できません。変更するとアクセス制御が無効になる場合があります。対策——書き込み前にメーカー領域とセクタートレーラー（access bits）を読み取り、書き込み可能か、許可範囲内かを確認します

跨域联合

• [[re-protocol]]: 本技能是其 IoT 分支（工作流第 5 步之后的选择树入口）
• [[re-netcap]]: 捕获原料（抓包点 / 隔离）
• [[re-firmware]]: 固件联动（协议实现 / 密钥 / OTA 镜像，配合 [[re-fw-extract]] / [[re-fw-emulate]]）
• [[re-crypto-id]] / [[re-crypto-keys]] / [[re-crypto-decrypt]]: 加密流量链路（TLS / DTLS / PSK 密钥提取与解密）
• [[re-proto-rev]]: 私有 IoT 协议状态机重建
• [[re-hardware-io]]: 串口 / flash 芯片读密钥
• [[re-sandbox]]: 设备测试网络隔离与授权边界（[[re-analyze/platform-tips]] 最高原则）
• 本技能被 [[re-analyze]] 的 triage「协议分析」路径引用（re-protocol → re-iot-proto）
• 射频信号级逆向（采集/解调/帧恢复）→ [[re-sdr]]
• [[re-javacard]]: NFC/智能卡链路之上的 applet 逻辑（CAP 文件解析、process(APDU) 分派还原）

常见坑与陷阱

• MQTT 明文 topic 泄露控制语义：现象——pcap 里 topic 直接写明 device/x/ota/update、cmd/relay，业务意图一目了然但 payload 加密或二进制；原因——设备常只加密 payload、topic 明文（或 broker 无 TLS）；对策——topic 是语义金矿：先 -e mqtt.topic | sort | uniq -c 分桶，按 topic 定位关键流再解 payload；payload 二进制用 JSON/protobuf 假设对照固件（步骤 5）
• DTLS/PSK 加密需密钥：现象——5684 / 8883 流量熵高全是密文，dissector 只出乱码；原因——DTLS/TLS 加密层（PSK/RSA）；对策——PSK 从设备固件 / App 侧提取（[[re-crypto-keys]] → [[re-firmware]]），Wireshark dtls 偏好填十六进制 PSK；TLS 用 SSLKEYLOGFILE（RSA 私钥仅旧式 static-RSA 会话可用，现代 ECDHE/TLS 1.3 解不开）；拿不到密钥则该通道只能看时序，标注局限并转向语义推测
• BLE 白名单/配对绑定：现象——连接请求之后没有后续数据，或设备根本不广播；原因——白名单过滤未知主机、已配对设备按绑定信息直接连接（跳过广播 / 配对过程）；对策——清除设备配对 / 出厂重置后重抓首次连接配对过程；广播阶段数据（adv 包，含设备信息与服务 UUID）先抓全
• Zigbee 网络密钥获取困难：现象——zbee 帧可解析但 APS / ZCL 全密文（payload 乱码）；原因——network key 未在手，链路/网络层加密；对策——按步骤 4 密钥路径逐项试: 组网期抓包 → 默认 TC link key → 固件提取（zbgoodfind 扫固件找 key）；TC link key 与 network key 两层密钥都要拿
• 抓包硬件/信道错配：现象——BLE 只抓到零星广播、Zigbee 一个包都没有；原因——BLE 40 信道跳频（普通适配器只能看到广播或部分连接包）、Zigbee 信道选错（11-26 选错即静默）；对策——BLE 用 btmon / btsnoop（主机侧全信道）或 ubertooth 配合 follow；Zigbee 用 sniffer 信道扫描（zbstumbler）确认工作信道再抓