本篇是”手上有啥就搞啥“系列的第四篇，研究对象是H3C TC2100 智能摄像头(云台)，侧重点是流量截取和协议分析。

摄像头是电信宽带赠送的，是H3C为电信的定制设备，从官网看到还有移动定制版，型号为 TC2101。该摄像头仅通过（电信）小翼管家APP管理，无其他管理接口，设备小众，研究资料基本（或者把基本二字去掉也不为过-.-）为零。

此次就侧重流量和协议分析，

虚假原因：之前文章都涉及一些硬件调试和固件逆向，大同小异的；

真实原因：固件没下到，提取要拆机，设备是新的，不拆还能卖掉回血 $.$。

内容主要包括：

• 0x00 基础知识：智能摄像头原理与流量抓包

• 0x01 站在巨人肩上：设备信息与失败的社工

• 0x02 自己动手做：流量与协议的分析

• 00x3 做个总结：简单总结

• 0x04 参考资料：参考链接

往期回顾：

手上有啥就搞啥(一) — 小米手环3

手上有啥就搞啥(二) — 猫盘

手上有啥就搞啥(三) — WiFi信号放大器

0x00 基础知识

0x00 - 00 智能摄像头(一般)工作原理

摄像头类型不同管理架构也各异，有些较早或者外部摄像头直接开放web、ssh等管理接口，访问管理方便，但安全问题突显，研究资料教多。而家用智能摄像头一般使用APP，通过云服务管理，即管理端和摄像头并非直接CS关系，管理APP与摄像头(或其他智能家居设备)的直接网络也是非必须的，如下图所示：

0x00 - 01 Andriod APP 抓包

APP 抓包的方法很多，可以直接使用APP端软件(Http Canary等)，手机(模拟器)APP + BP/Fiddler Proxy，或者直接在手机底层抓包等。除了获取权限后的底层抓包，其余的思路基本都是作中间人，步骤大同小异：

• 安装证书

• 设置服务端

• 设置客户端
  

此文比较详细，可做参考。

0x01 站在巨人肩上

0x01 - 00 设备信息

• 硬件信息

来自官网的设备信息，对研究者来说基本无价值。

• 端口信息

通过Nmap扫描，并没有开放常用的端口，结果如下：

0x01 - 01 失败的社工

上文已提到，因为某些经济原因不想拆机，固件网上也找不到，突发奇想找客服要吧，但手段还是不够老辣，以失败告终，不过并不妨碍流量分析。

具体交流忘记截图，客服很耐心的，聊了一会编不下去了，最后客服要求拍个故障视频，太麻烦就不了了之。

• H3C 常规设备客服

• H3C 智能设备客服

0x02 自己动手做

0x02 - 00 流量截取

• 路由器端截取设备流量

在设备端加了一层之前刷了 pandora的路由器，通过 tcpdump抓包，简单过滤出设备IP进出的流量，其中设备 IP 为 192.168.123.142：

tcpdump -i eth2 dst 192.168.123.142 or src 192.168.123.142 -w /tmp/tc2100.pcap

存储成 pcap方便分析：

• 手机端截取APP流量

首先对app作简单逆向，代码在分析时可作参考，可以看到使用了 kotlin, 还有一些alibaba/j256/juphoon/qq的文件夹，可能使用到了此中一些服务。

手机端直接使用 HTTP Canary 直接抓包，此时需要安装根证书：

可能会出现证书安装错误，笔者使用的是MIUI，参考了该链接，通过下载Backup并恢复的方式安装了APP，之后就可以导入证书实现抓包。

在抓包时发现一旦开启抓包模式，APP就连接不上服务，说明APP与服务端有双向认证(至少服务器验证了APP证书)，所以此种中间人的抓包方式并不必能抓取到整个过程的数据。

0x02 - 01 协议分析

从设备端流量入手，分析截取的 pcap文件。在众多TCP中看到了 HTTP 的协议，从这个简单的开始：

可以看到设备访问了如下几个 IP 的 HTTP 服务：

• 36.111.152.223

• 221.228.33.234

• 58.216.20.8

通过浏览器访问发现服务确实开放：

36.111.152.223

先从36这个IP开始，Follow下TCP流：

除了注意到 IP转换的域名 cte.ux.21cn.com外，最明显的是两个 base64 编码的字符串。解码后短字符串0x20字节，长字符串0x160字节，且全是二进制乱码。字符串长度都是16的整数倍，下面就开始猜、猜、猜。

猜想长字符串是密文，短的是密钥(密钥明传一般不太可能，但是没有其他线索，只能试试)。传输的32字节可能是 AES256/ECB，可能是 AES128 + IV/CBC，经过多次尝试解出来都是乱码，还胡乱试了OFB和CFB，当然也没有结果。

于是将两次的HTTP请求的长base64字符串解码异或，发现前0x20字节相同：

又对该0x20字节作了文章，也解密失败。于是转过来看 cte.ux.21cn.com

该域名：

从官网可以看出是电信天翼账号可直接登录的数据分析服务网站。用BP测试发现修改之前的短字符串也不影响 success 返回值，但此项不能为空：

修改部分长字符串也不影响返回结果，这就完全排除了上面的猜测。为了不让一个设备研究项目突变成渗透测试项目，笔者就没有对该网站作过多测试，这让研究又回到了起点。

回到网站本身，发现其有 SDK，于是查阅了使用手册。

从平台概述记进一步确定该平台为数据服务平台，主要对数据惊醒统计和分析。其服务使用时需要一个公钥作为客户端唯一标识，说明该服务有完善的认证体系，之前的解密尝试就变得更加可笑了。

通过查看 Andriod SDK手册，发现公钥会出现在 Andriod APP 的 AndroidManifest.xml 文件中：

回去查看反编译后的小翼管家APP，果然找到了相关代码：

设备端的使用协议应该类似，从 POST的 URL /collect/custom/v1.0/reportData来看也是收集设备状态数据，在后台分析后推送给APP端，因为无法取得私钥，想进一步分析就很难了，姑且当作是个功能更强大的日志服务器吧。

题外话：如果使用RSA等作密钥交换，当取得私钥后能从流量中获取会话密钥，从而解密历史流量，所以在认证后尽量选择DH这样的密钥协商机制，这样即使取得私钥也很难解密历史流量，但对于IOT设备来说能认证加密已经不错了。

221.228.33.234

通过 Follow TCP 流，发现设备向该URL提交了很多信息，都是明文，不用过多分析可以直接查看：

Urldecode后是Json格式的数据，与POST的主体数据相同:

jsonstr=
{
  "VER": "03",
  "CTEI": "18XXXXXXXXXXXXXX",
  "MAC": "70:XX:XX:XX:XX:XX",
  "IP": "192.168.123.142",
  "UPLINKMAC": "28:XX:XX:XX:XX:XX",
  "LINK": "2",
  "FWVER": "V1.2.6-00-220914",
  "DATE": "2023-01-17 20:49:30"
}

注意到 reqId应该是设备标识。

58.216.20.8

这个的数据包较长，还使用了 PUT关键字:

通过JFIF关键字，很明显传输的是JPEG格式的图片，将其另存为再打开，果然是摄像头拍摄到的内容截图，幸亏笔者分析时将始终将摄像头对着墙，不然就要入镜了~.~。请欣赏桌面乱线：

至此，简单分析了几个HTTP数据包，大致得知了些HTTP服务的内容，下面看比较困难的TLS/SSL。

同样可以看到有几个目的 IP：

• 203.195.93.62

• 203.195.95.24

• 121.229.44.227

因为使用了完整的SSL加密，除了明显的协议握手流程并看不出更多信息，所以还是从 IP入手，先查下域名：

都是与 ehome.21cn.com 相关的域名，与之前的 HTTP 服务器根域名相同，浏览器直接访问，80/443 都是开放的。如前所述，笔者并不想对服务器作测试，从APP抓包截图可以看到，这些域名也出现其中，所以转向APP数据包看能否有进一步发现。

ux.21cn.com

还是之前的云涛数据分析平台，APP同样向其POST了许多数据信息，数据最后仍然是一段base64字符串，在我看来有些数据的收集并无必要，比如我的手机品牌型号，这不就暴露贫穷了-.-。

具体信息如下，个人信息太多打了码：

ehome.21cn.com

从设备端已经知道，此为数据传输的主要云服务，如下是挑出的一次APP会话：

POST /app2/sigtran/ZJ_UpgradeDevice HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 548
Host: ehome.21cn.com
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/3.12.2

clientType=1005&method=ZJ_UpgradeDevice&signature=a6a18426154b538180348cadf64216a00ef6656e91b19e95574a038f7775898f&appKey=xy_guanjia&params=7cfab4794568bf75c2a74c7f9e613d4ec6f74ab4993a8bb7796de7e68b5310263874f95e5516ba5f537ad85624a80912868a950c03ec97ca4adf6bf8ccc5f4e3284f49e007d6b7f5803799e55cae9080e094c739fbdbd7b72e981e6a92f036f4c4073f36cfc5e821921572777c22d803c8a97187fae5cc8a944b1affc239f94313d744d29c27dc3414402bca0b82b88821ab2e4070ce10e126dd136ee97f94ce8e252a2b3cd42ef5685ef14dba0b718a&version=404&nonce=d7c7e13e-ace8-4d&timestamp=1673529077

HTTP/1.1 200 OK
Date: Thu, 12 Jan 2023 13:11:19 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 210
Connection: keep-alive

{"METHOD":"3415","SEQID":"200166","CODE":"0","FROM":{"DID":"3XXXXXXXXXXXXX"},"TO":{"UserToken":"cbxxxxxxxxxxxxxxxxxxxxfe"},"BODY":{"CurrentVersion":"V1.2.6-00-220914","NewVersion":"","UpdateFlag":"0"}}

显然与设备升级相关，signature=a6a18426154b538180348cadf64216a00ef6656e91b19e95574a038f7775898f

128位，应该是MD5值，params后的160字节应该是加密后的数据，

从appKey=xy_guanjia并不能判断出加密方式，和密钥生成方式，返回值中，"UpdateFlag":"0"表示最新版本，无需升级。

从抓到的数据来看，APP还与很多服务器有交互，比如 maketapi.189smarthome.com、adashbc.ut.taobao.com)等等，由于时间和篇幅的限制未作分析。

0x02 - 02 也许更好的方法

流量抓取或许用下述方法更好，但代价也更大。

• APP 端

使用Root过的Andriod手机，安装r0capture，可忽略证书问题，在Andriod底层抓包。

• 设备端

拆机提取固件，寻找硬件或软件调试口，因为设备上大概率只有公钥，所以可以借助gdb调试(系统为类Linux时)，获取解密后内存数据，当然能在装上ssl抓包软件更好，这要视系统复杂度而定。

0x03 做个总结

本篇针对H3C TC2100 智能摄像头作了流量分析和协议还原，可以看到随着智能家居设备在安全方面逐步重视，保护措施和管理协议也越来越合理。由于一些限制因素，没有能够全面分析，尤其是设备绑定的环节，不过每次都能弥补一点知识盲区也算没有浪费，值放假期间，水一下吧~.~，那就下个设(po)备(lan)见。

0x04 参考资料

H3C TC2100家用全功能云台机-新华三集团-H3C

智能摄像头安全分析及案例参考 - FreeBuf网络安全行业门户

一文帮你解决APP抓包难题 - FreeBuf网络安全行业门户

使用burpsuite对安卓软件进行抓包_5wimming的博客-CSDN博客_burpsuite android

终端应用安全之网络流量分析

Reverse Engineering cheap chinese "VRCAM" protocol

HttpCanary根证书安装(MIUI13 Android 12可用)