[PwnMonkey]海康萤石智能门锁的网关分析

确实是个孩子谥

本文内容较长，所以将目次整理在最前面，用于方便各位读者查阅，目次如下：

目次

• 简介
  
• 通信分析
  
• 电路分析
  3.1 紧张芯片分析
  3.2 电路接口分析
  
• 固件分析
  4.1 固件提取
  4.2 固件结构分析
  4.3 固件重打包
  
• 紧张程序分析
  5.1 静态分析
  5.2 日志分析
  5.3 动态调试的预备
  5.4 加密和认证流程分析
    5.4.1 master key 天生流程
    5.4.2 share key 天生流程小结
  

下面开始正文：

1．简介
海康威视作为国际大厂，旗下如摄像头等产品早就被无数人分析过了，通过google和github等可以找到很多分析记录和分析工具。萤石是海康威视的一个子品牌，相比于海康威视，萤石的绝大部分产品侧重于家用领域，本文将要分析的智能门锁和网关就是萤石的产品。
之前果加门锁的分析文章中，我们分析了门锁和相关的app，这篇文章我们计划对门锁配套的网关举行一些分析（真正原因是门锁让我们搞坏了，虽然海康又补发了一个，但型号没对上）。刚刚看了看萤石的网上商城，最新的联网门锁已经没有外置网关了，我们在2019年分析的智能门锁还是有外置网关的格局，图片如下：

图2-1 海康萤石网关通信内容
通过上图中的通信内容，我们大体上可以分析出一些内容：
A. 网关上电之后，与litedev.ys7.com举行通信。
B. 与litedev.ys7.com通信中，获取了另一个ip，即101.71.30.172。此后，终止了与litedev.ys7.com通信，并一直保持与101.71.30.172的tcp连接。
C. 通信内容看起来是加密的，通信内容中没有很多直接可见的明文。
既然抓包获取不了太多有效的信息，那么我们就要进一步研究网关固件是如那边理这些通信数据的。

3． 电路分析
这次并没有像之前的果加智能门锁那样顺利：萤石配套的app不能获取固件的下载地址，在海康和萤石的官网仔细翻找，同样没有查到固件的下载地址。那么接下来我们需要先对电路举行一些分析，以找到固件提取和调试的方法。
3.1 紧张芯片分析
我们首先来看一看网关电路板上用哪些芯片，尤其注意主控MCU的型号，以及有没有外置的Flash芯片。电路板如下图所示：

图3-2 MT7688AN芯片的特点
上图可以看到该芯片并没有内置Flash，而是使用SPI通信的外置Flash，那么我们继续在电路板上寻找Flash芯片。
在图3-2中，MCU的上方是Winbond W9751G6KB芯片，该芯片是DDR2 SDRAM存储器，简朴说就是断电丢数据的内存，固件程序不可能在里面。在MCU的下方有两个芯片，分别是PCM5100A和GD25Q127CSIG芯片， PCM5100A是个音频立体声DAC芯片，而GD25Q127CSIG芯片则是128M-bit的Flash芯片，我们要提取的固件文件应该就是在此Flash中。关于Flash中固件的提取方法，我们将在第4章中先容。
3.2 电路接口分析
IoT装备在开发和测试过程中，都会使用JTAG、UART等接口用于辅助调试工作。在装备的发行版中，MCU的这些引脚是否与电路板上的接口接通就不一定了，这需要我们测试一下。
在MT7688AN的芯片手册中，我们可以看到该芯片UART0接口和UART1接口。其中UART0接口在30和31引脚，如下图：

图3-4 海康萤石网关软排线接口
为了接通软排线接口，我们需要购买一段20pin的软排线和转接板，淘宝可以买到，楼下手机店可能也有，软排线的尺寸间距我们在图3-4已经测量出来了。此外，我们还需要一个USB转TTL模块才气将UART口连接到电脑上，该模块用于调整usb电路和ttl电路的电平逻辑，软排线+转接板+USB转TTL模块的连接如下图所示。

图3-6 串口输出内容
上图中的输出内容显然是网关上电之后的输出日志，待体系启动完成之后，我们可以试着输入一些内容，这时就会出现登陆嵌入式Linux体系的提示字符，但是登陆用户和登陆密码我们暂不知道。现在是时候去分析固件了。

4． 固件分析
4.1 固件提取
我们在3.1节提到固件应该存储在电路板的Flash芯片中，要读取Flash芯片，只需要将芯片连到编程器上即可。如果环境允许，烧录夹是最优选择，这样我们就不需要将芯片焊下来了。不巧的是，烧录夹有点粗，海康萤石的门锁网关计划的很紧凑，烧录夹夹不上去。所以我们只好用热风枪和镊子就可以把Flash吹下来了，如下图所示：

图4-2 将Flash芯片放置于编程器上
将编程器连接到电脑上，使用编程器配套的软件，选择相应的Flash芯片型号后即可提取芯片内容，提取完成后可以将读出的内容保存成文件，并命名为OriginFirmware.bin。
4.2 固件结构分析
提取出固件之后，我们可以尝试用binwalk对它举行分析，这里，我们直接用-Me参数提取固件内容，其中M参数表示递归提取：

图4-4 海康萤石网关提取内容
上图中，前2个文件夹即2个LZMA压缩的数据，解压之后会发现是cpio文件体系，binwalk会自动帮我们递归全部提取。
逐个浏览这些文件体系中的内容，可以得到以下信息：
A. jffs2文件体系保存着门锁和网关的相关信息，如id等；
B. 两个cpio文件体系中，其中一个应该是规复出厂设置时的备份文件体系，另一个是当前正在使用的文件体系；
C. 两个squashfs文件体系中，一个保存的全部都是mp3文件，另一个保存着网关的主程序，该程序即为我们将要分析的主程序。
D. 在固件的cpio文件体系中，可以找到/etc/shadow文件，文件内容如下：

图4-6 智能网关中/sbin/telnetd程序
该程序是指向busybox的软链接，如果把解压缩出的固件内容拿到windows环境后，可能会导致/sbin目次中是空的。我们可以使用串口shell登陆装备，然后运行telnetd程序，但这就意味着每次装备重启之后，我们都要使用shell启动telnetd程序，这样操作很麻烦。
继续翻找，我们在squashfs文件体系中找到initrun.sh脚本，这个脚本是在网关上电启动后举行初始化操作的。如果我们在该脚本中启动telnetd，然后将固件重新打包烧录回去，这样应该就不需要软排线连接装备了，为此我们给initrun.sh增加telnetd下令，如下图：

图4-8 打包squashfs文件体系的下令和参数
同时，在‘staging_dir\host\bin’目次中可以找到图4-8 中的mksquashfs4程序.
我们尝试用SDK中的mksquashfs4程序和图4-8中的参数打包一下开启了telnetd程序的squashfs文件体系，如下图所示：

图5-1 patch日志输出代码
除了要patch日志输出代码之外，davinci在启动之后，初始化了一个线程操作看门狗，该线程会不停向/dev/watchdog举行写操作。如果一段时间内/dev/watchdog没有收到任何数据，那么整个装备就会重启。由于我们计划调试davinci程序，如果在调试过程中，触发断点导致看门狗线程挂起，那么整个体系就会重启。为此，我们先把该线程patch掉，然后再弄一个写入/dev/watchdog的小脚本，用以专门喂狗防止重启。相关位置的代码截图如下：

图5-3 喂狗小脚本
相信脚本内容一眼就能够看懂，所以我们不做太多的解释了。此外，另有个guard.sh是用于检测davinci程序是否运行的，但它不影响我们的操作，所以就不讨论该脚本了，有兴趣的读者可以去看看。
完成上述操作之后，就可以把被patch的davinci上传至海康萤石的智能网关，此处我们不再采用烧录固件的方法，因为过于麻烦。通过翻阅该装备的文件体系，可以在装备中发现tftp程序，这是一个使用tftp协议传输文件的程序，可以用它从tftpd服务器上传或下载文件。我们使用从这个链接下载到的tftpd程序：http://tftpd32.jounin.net/tftpd64_download.html，运行后，调整tftpd服务器的文件目次和监听网卡。然后在智能网关装备中使用tftp程序获取相关文件即可，相关下令截图如下：
图5-5 启动patch之后的davinci进程
待程序运行一段时间之后，就可以查看程序的运行日志，然后通过日志分析程序的各种行为。
5.2 日志分析
待程序运行一段时间之后，就会在‘/applog/devlog’目次下天生日志文件，每个文件500KB左右，如下图所示：

图5-7 与litedev.ys7.com有关的日志
上图中，我们可以看到由litedev.ys7.com解析而来的ip地址：115.231.107.14，这与我们用wireshark抓包时得到的结果是相同的。继续翻看日志，在距离上图不远的地方，可以看到另一条日志，看起来像是与海康萤石MQTT服务器相关的日志内容，截图如下：

图5-19 调用lbs_connect函数
可以看到在lbs_connect函数返回成功之后，就会调用send_authentication_i函数。这个函数看起来就是加密和认证相关的函数，接下来我们通过动态调试的方式分析网关加密和认证的流程。
5.3 动态调试的预备
对于嵌入式Linux操作体系，我们通常选用gdb和gdbserver作为调试工具。我们可以直接在装备上使用gdb举行本地调试，但gdb程序体积比力大，而且直接在装备上运行gdb会有很多不方便的地方，所以我们选择通过gdbserver举行远程调试。为了完成调试工作，我们首先需要一个可以运行在海康萤石智能网关装备上的gdbserver程序。
在4.3节中，我们使用MT7688 SDK中的工具对固件举行了重打包，所以当我们需要与芯片配套的gdbserver时，也是去MTK官方查阅资料。事实上，MT7688开发板的固件包中确实内置了一个gdbserver，但是当我们提取出这个gdbserver，并通过tftp传输到网关上开始运行后，发现并没有任何输出，可能是MTK官方定制了gdbserver的代码，导致我们无法使用该程序调试。
那么，就只能去找一找有没有其他可以正常运行在海康萤石智能网关中的gdbserver程序了。经过一番搜索后，在rapid7官方github账户上发现了已经编译好的gdbserver程序，链接如下：https://github.com/rapid7/embedded-tools/tree/master/binaries/gdbserver， 这里我们选择下载芯片对应的mipsle版本的gdbserver。
这里需要分析一下，rapid7提供的gdbserver，可能在某些装备上也无法正常使用，所以最靠谱的方法是使用SDK本身编译一个出来，但是这里既然有可用的，我们就不（懒）再（得）去费功夫了。
我们通过tftp将gdbserver传输到网关中，并使用 gdbserver启动davinci。如果使用附加方式调试，很可能会错过davinci程序与服务器通信的认证过程。所以我们选择使用gdbserver启动程序，这样一来，在远程调试器连接之前，davinci程序将处于挂起状态。下令如下：

图5-11 运行gdb-multiarch程序
上图中，我们分别设置architecture为MIPS，读取davinci的符号文件，在main函数设置断点，并连接远程的gdbserver，关键位置已用绿框圈出。然后，我们用快捷键c（continue），让程序开始执行，过一会程序就会在main函数的入口处被断下来。
此时，参考图5-11中的file下令加载libmicrokernel.so.1的符号文件，然后就可以直接使用函数名lbs_connect下断点了，如下图：

图5-13 程序掷中lbs_connect断点
图5-13最下方，打印出了函数调用栈，可以看到，程序是从lbs_redirect调用过来的，我们可以继续在外层函数下断点调试，以帮助我们理解程序的逻辑。
5.4 加密和认证流程分析
至此，我们已经具备了调试本领，可以调试固件中的davinci程序以及libmicrokernel.so.1等动态连接库。为了节约篇幅，我们先将一些分析结论与各位分享，然后再具体调试其中的某个细节。
在海康萤石的智能网关中，完备的通信流程涉及到3个密钥，分别是share key、master key以及session key。其中，share key是智能网关与litedev服务器（与之对应的另一个服务器是MQTT服务器）共有的密钥，由装备序列号等常量经过多次MD5运算得到，每个智能网关装备的share key都是独一无二的；master key是智能网关与litedev服务器经过密钥协商而来，用于加密传输session key，关于master key的密钥协商过程就是我们将要分析的重点内容；最后session key是智能网关与MQTT服务器通信时使用的加密密钥，该密钥由litedev服务器直接下发给智能网关。
以上三个密钥在使用过程中，share key是与装备绑定，且固定不变的，一旦获取了share key，就可以完成所有的认证过程，终极被海康萤石认定为合法的网关装备；使用者通过手机app绑定智能网关时，会经过密钥协商天生master key，每绑定一次会就更新一次；最后的session key则每次运行davinci程序时，都会更新，这也意味着每次重启网关都会更新session key。三个不同级别的密钥，三个不同的密钥生存周期。
在对海康萤石智能网关的密钥体系有所相识之后，我们就可以聚焦到某些细节上，下面来着重看一下master key和share key的天生过程。
5.4.1 masterkey天生流程
为了触发智能网关的密钥协商流程，我们需要先删除当前的master key，具体讲就是删除 “/cfg/dev_masterkey”文件，如下图所示：

图5-15 第一次打印发送数据
在上图中，可以看到待发送数据内容还是空的。待函数common_serialize执行完毕之后，重新打印该地址的数据，如下图所示：

图5-17 第三次打印发送数据
可以观察到，authentication_i_serialize函数执行完毕之后，待发送数据基本构造完毕。我们对比一下本次发送数据和之前我们通过wireshark抓包获取的发送数据，如下图所示：

图5-19 authentication_i_serialize函数的内部
在该签名函数之前和之后下断点，可以观察到需要签名的数据以及签名结果。结合之前用gdb调试send_authentication_i时获得的发送数据，就可以分析出发送的数据格式如下：

图5-21 master key的天生过程
根据图中红框标出的偏移可以知道，master key的天生过程就是将random_1、random_2、random_3、random_4和share_key拼集在一起，然后调用sha512函数，其hash结果就是终极的master key了。继续分析其固件的后续内容可以发现以master key作为密钥，使用aes cbc算法解密session key相关的代码段，这里就不截图了。获取session key之后，通信数据的加密密钥就完全切换为session key，不再使用master key了。5.4.2 share key天生流程
相比于master key的天生过程，share key的天生无疑简朴了很多。可以在generate_sharekey函数中找到关于share key的各种运算，通过阅读IDA反汇编后的代码，可以确认share key是通过对dev_subserial和dev_verification_code以及一个固定的盐举行多次MD5而得到，其中dev_verification_code是装备的认证码，该认证码被贴在海康萤石智能网关背面的标签上。在md5运算过程中，固定的盐值如下图所示：