IoT简单的架构图如下，其中包含了移动端、设备端和云端，几个端之间涉及多种通信方式。
（引自freebuf）
以上只是一个粗略的架构，在实际测试过程中，我们需要更细致的架构图：
各个组件之间的通信，大致可以分为以下：
移动端会与云端、设备端进行通信：常见的通信方式包括HTTP、HTTPS、WS、WSS、TCP、UDP等；
硬件设备端会与云端、传感器、移动端进行通信：与云端通信常见方式包括HTTP、HTTPS、WS、WSS、TCP、UDP，甚至有的还有FTP等；与传感器通信常见方式包括ZigBee、BlueTooth、Zwave、RF433、WIFI、TCP、UDP等；
云端会与移动端、设备端及第三方云端进行通信：与第三方云端通信常见方式包括HTTP、HTTPS等；
云端和第三方云端之间的通信，一般不具备测试条件，其他几个组件之间的通信都有办法可以嗅探、截取。移动端与云端之间的通信测试，一般会采用Burpsuite或者Fiddler等代理工具进行截断测试，如果是HTTPS的还需要在移动端安装证书。但是设备端不一样，一般不允许我们在设备端配置代理、安装证书，那么对于设备端和云端之间的通信，我们怎么做呢，本文主要交流设备端和云端之间的通信测试方法。
配置设备端不可行，换个思路，能不能在设备的网关处进行拦截。
上面是我们测试设备与云端通信搭建的测试环境，下面简要说明：
网关直接用了kali系统，方便进行测试。
两块网卡，iInf用于连接互联网；wInf是wifi设备，配置为热点，供IoT设备连接。这样，IoT设备配网成功后就能直接联网了。
现在，我们只需要将IoT设备访问互联网的数据转发到代理端口就可以了，通过iptables很容易实现：
iptables -t nat -A PREROUTING -i $wInf -p tcp --dport 80 -j REDIRECT --to-ports 9999
iptables -t nat -A PREROUTING -i $wInf -p tcp --dport 443 -j REDIRECT --to-ports 9999我们开启Burpsuite，配置监听端口为9999，那么上面的命令会将IoT设备访问互联网的80、443端口的数据转发到Burpsuite。
Burpsuite很重要的一点，配置监听端口时需要启用invisible proxying，否则是看不到数据的，在Alert里面会有信息提示。
同时使用wireshark等抓包工具对网络流量进行嗅探，获取Burpsuite不能截断的流量数据。
以上过程可以脚本化，方便随时接入不同的新设备进行测试。
测试环境已经具备，现在我们拿到了一个新设备，该如何进行通信测试呢？我们能得到的信息可能就只有设备的使用说明书，除了内部团队，别人基本上拿不到产品系统架构、通信、api这种细致的文档。所以，上面只是具备了测试条件，实际进行通信测试需要一定的步骤、方法。
第一步：全面了解设备通信
拿到设备时，我们不了解设备与云端通信会使用哪些协议、哪些端口。
所以我们必须使用抓包工具，比如wireshark，全面了解设备与云端的通信。
我们也不了解设备与云端通信时的HTTP(S)、WS(S)等具体端口有哪些，所以我们需要把所有目的端口都重定向到代理工具：
iptables -t nat -A PREROUTING -i $wInf -p tcp --dport 1:65535 -j REDIRECT --to-ports 9999
这样，一方面我们能掌握设备与云端通信的HTTP(S)、WS(S)流量，同时又不会因为没有拦截某些端口导致放过某些流量。比如，测试某设备时发现设备升级时使用FTP，如果我们仅仅拦截了80、443等端口，虽然通过wireshark能看到FTP数据，但是因为没有拦截，这时候设备已经升级了。
第二步：正式测试
测试过程中，我们需要维护一张通信表，不用太细致，但是要大概描述出来某通信做什么用的，比如是ximalaya资源、还是home cloud等等。
对于IoT设备，有一些测试点需要考虑：
一般的安全测试，主要是涉及数据部分，这部分内容都很成熟了，不再赘述。
IoT设备涉及到设备控制功能部分的，比如控制灯光、颜色、声音、温度、运动等等等等可以与现实交互（想不出更好的词）的部分，可能更多的会采用UDP、TCP通信，需要重点测试，比如重放；
IoT设备一般都涉及升级更新，而且基本上厂商都不会开放升级包，那么最好把升级包截取下来做分析。
本文虽然主要讲设备与云端通信测试，但实际上我们基本都是通过移动端来对设备进行控制，所以测试过程中，应同时进行移动端通信测试。
移动端和设备端同时接入测试环境，代理监听在不同的端口，这样能同时观察到移动端和云端、设备端和云端交互的逻辑。
有些情况下，需要将移动端采用常规的配置代理方式，观察数据交互。
