本篇是”手上有啥就搞啥“系列的第四篇，研究对象是H3C TC2100 智能摄像头(云台)，侧重点是流量截取和协议分析。
摄像头是电信宽带赠送的，是H3C为电信的定制设备，从官网看到还有移动定制版，型号为 TC2101。该摄像头仅通过（电信）小翼管家APP管理，无其他管理接口，设备小众，研究资料基本（或者把基本二字去掉也不为过-.-）为零。
此次就侧重流量和协议分析，
虚假原因：之前文章都涉及一些硬件调试和固件逆向，大同小异的；
真实原因：固件没下到，提取要拆机，设备是新的，不拆还能卖掉回血 $.$。
内容主要包括：
0x00 基础知识：智能摄像头原理与流量抓包
0x01 站在巨人肩上：设备信息与失败的社工
0x02 自己动手做：流量与协议的分析
00x3 做个总结：简单总结
0x04 参考资料：参考链接
往期回顾：
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 失败的社工
上文已提到，因为某些经济原因不想拆机，固件网上也找不到，突发奇想找客服要吧，但手段还是不够老辣，以失败告终，不过并不妨碍流量分析。
具体交流忘记截图，客服很耐心的，聊了一会编不下去了，最后客服要求拍个故障视频，太麻烦就不了了之。
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 返回值，但此项不能为空：
修改部分长字符串也不影响返回结果，这就完全排除了上面的猜测。为了不让一个设备研究项目突变成渗透测试项目，笔者就没有对该网站作过多测试，这让研究又回到了起点。
从平台概述记进一步确定该平台为数据服务平台，主要对数据惊醒统计和分析。其服务使用时需要一个公钥作为客户端唯一标识，说明该服务有完善的认证体系，之前的解密尝试就变得更加可笑了。
通过查看 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¶ms=7cfab4794568bf75c2a74c7f9e613d4ec6f74ab4993a8bb7796de7e68b5310263874f95e5516ba5f537ad85624a80912868a950c03ec97ca4adf6bf8ccc5f4e3284f49e007d6b7f5803799e55cae9080e094c739fbdbd7b72e981e6a92f036f4c4073f36cfc5e821921572777c22d803c8a97187fae5cc8a944b1affc239f94313d744d29c27dc3414402bca0b82b88821ab2e4070ce10e126dd136ee97f94ce8e252a2b3cd42ef5685ef14dba0b718a&version=404&nonce=d7c7e13e-ace8-4d×tamp=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 参考资料
智能摄像头安全分析及案例参考 - FreeBuf网络安全行业门户
一文帮你解决APP抓包难题 - FreeBuf网络安全行业门户
使用burpsuite对安卓软件进行抓包_5wimming的博客-CSDN博客_burpsuite android
如有侵权请联系:admin#unsafe.sh