2020年5月时，段老师曾对我说过：“目前智能设备这个版块，最紧迫要做的事，就是有一套入门的指引。”

当时我答应了段老师会认真整理一个指引，然后不断丰满此指引中的内容，用各个案例来进一步说明每个细节，最终形成一个相对比较完善和全面的体系框架。

所以，就有了此文。很感谢段老师和gjden大佬等人的帮助，对文章内容进行了多次审阅。接下来就言归正传，开始正题。

目录:

1. 引言
2. 攻击面
3. 有固件逆向分析
   3.1 固件的获取
      A.    通过设备的云端获取
      B.    通过电路板接口获取
      C.    通过其他方法直接获取

   3.2 固件的内容分析
   3.3 固件的程序分析
      A.    无操作系统
      B.    操作系统与应用程序分开
      C.    操作系统与应用程序混合
  3.4 固件的调试
      A.    使用硬件调试器调试
      B.    使用gdbserver调试
      C.    使用qemu仿真调试
  3.5 固件的重打包
4. 无固件通信分析
  4.1 有线/无线网卡通信
  4.2 通过4G/2G通信
  4.3 通过Bluetooth通信
  4.4 通过Zigbee通信
  4.5 其他的通信情况
5. 智能设备漏洞分析
  5.1 逻辑漏洞
      A. 固件后门
      B. 认证绕过
      C. 加密不当
      D.    ……
  5.2 代码漏洞
      A. 栈溢出漏洞
      B. 整数溢出漏洞
      C. 命令注入漏洞
      D. ……
6. 小结

1. 引言

既然我们要研究智能设备，那么“智能设备”究竟是什么？可能我们暂时无法给“智能设备”一个准确而严谨的定义，但我们日常见到的那些能够联网通信的，与传统设备相比，功能更丰富的电子设备，都可以被当作一个“智能设备”而成为我们的研究目标。或许叫“IoT设备”更贴切一些。

一个常见的智能设备系统通常包含三部分：手机端，云端和设备端。采用这种架构的智能设备系统，例如我们经常使用的共享单车，设备端是自行车本身，手机端就是Android/ iOS手机中的app，云端就是共享单车的服务器。此外，有些系统的设备端除了设备本身之外，还包含一个网关，例如智能门锁中的门锁设备和配套网关。常见情况下，智能设备系统三端的关系图如下：

图1-1 智能设备系统

我们要研究智能设备的安全问题，具体讲就是研究手机端，云端和设备端，这三端中出现的安全问题。在《智能设备》板块中，我们的重心肯定不是研究手机端和云端，关于Web、Android、iOS的问题还是交给专门的同事去研究比较好。但我们有必要掌握一些关于云端和手机端的基本知识，如果一丁点Android/iOS的app逆向都不懂，那分析智能设备也会挺费劲的。

2. 攻击面

在上一章中，我们已经明确要研究的是“智能设备”中“设备端”的问题，那么接下来我们就看一下智能设备中可行的攻击面。智能设备是为我们服务的，我们在使用智能设备中或多或少的都会与智能设备产生通信，其通信方式就是智能设备暴露在外的通信接口。常见的通信接口可以归纳如下表：

表2-1 智能设备的常见通信接口

上表中列出的项目，仅仅是一些常见的应用层通信协议。一方面，我们整理得并不是全面，仅仅是把常见的列出来；另一方面，我们暂时不关心通信协议本身的安全问题，例如，我们目前不考虑智能设备tcp协议的实现代码是否存在安全问题。

事实上不仅仅正常使用智能设备时，需要通过表2-1归纳的各种通信接口，在攻击者进行漏洞攻击时，同样是通过上述的接口完成。比如说，常见路由器的各种RCE漏洞都是通过攻击监听http接口的程序、或者攻击监听udp接口的某个程序。

因此，不管是为了挖掘漏洞，还是为了分析漏洞，我们都有必要研究一下监听这些接口的程序，确定这些程序是如何处理收到的数据。所有这些我们打算研究和分析的程序，都在智能设备的固件中。所以，我们在展开研究之前，先要拿到固件内容。当然，我们不排除有些漏洞是不需要研究固件，直接分析通信内容就可以复现的，但多数情况还是离不开固件。在接下来的第三章和第四章中，将专门讨论固件分析和通信分析。

3. 有固件逆向分析

上一章中我们提到了固件，那么固件又是什么？其实简单说，固件就是运行在设备端的程序和数据，一方面固件和底层MCU等硬件直接打交道；另一方面固件还要完成智能设备的各种逻辑功能。

3.1 固件的获取

固件一般会保存在2个位置，其一是外置的Flash存储器中，其二是MCU内置的Flash存储器中。存储在不同位置的固件，可以使用不同的提取方法，我们在这里列出一些常见的方法供各位读者参考。

A. 通过设备的云端获取

有些设备的固件是可以直接在官网下载到的，如TP-Link、D-Link路由器等。关于这两个路由器，我们不但可以下载到固件，还可以下载到一部分代码，因为他们采用了OpenWRT嵌入式Linux操作系统，需要遵循GPL开源协议。关于在云端直接下载固件的案例，笔者正在整理，估计要8月或者9月才能整理出来。

有些设备的固件是不会让你直接下载的，这时可以尝试监听通信获取下载地址。但这招并不是每次都有效，毕竟通信内容可能是加密的，或者下载到的固件是增量更新，那我们只能再想别的办法。关于监听通信获取固件下载的案例，可以参考果加智能门锁分析的那篇帖子，链接如下：https://bbs.pediy.com/thread-259530.htm。

B. 通过电路板接口获取

每个MCU都有其对应的调试方法，通过专用的硬件调试器和调试接口即可调试MCU中的程序，比较常用的调试器有J-Link、ST-Link等，通过这些调试器也可以进行固件提取，例如J-Link调试器支持两种调试接口JTAG接口和SWD接口，接通J-Link调试器后，可以使用savebin等指令就读取并保存Flash中的内容。但这招也并不是每次都有效，因为很多设备的发行版本都会设置Readout Protection(RDP)，导致无法提取。关于通过调试接口提取固件的案例，笔者打算整理，但估计要9月以后才真正开始。

UART通信接口是一种被广泛使用的通信接口，绝大部分MCU都是支持的。但不同设备通过UART接口提取固件的方法也各有不同，例如，有些设备可以通过UART引导启动处于其他Flash中的固件，进而完成主Flash中的固件提取。关于通过UART接口提取固件的案例，笔者打算整理，但不知道啥时候能发出来。

C. 通过其他方法直接获取

当设备端使用外置Flash存储器时，可以将Flash芯片从电路板上取下来，使用热风枪或者电烙铁均可，然后通过支持读写该Flash的编程器来读取Flash中的固件内容。此外，有些BGA封装的Flash芯片可能需要更专业的设备和技术才能拆下来。关于通过Flash编程器提取固件的案例，笔者正在整理，估计要7月或者8月才能整理出来。

针对于内置Flash存储器，也有一些其他方法，例如利用芯片的漏洞或固有问题等。比如说，STM32F0系列MCU处于RDP level 1时，可以利用CVE-2017-18347以完成内置Flash中的固件提取。此外，芯片就是封装完备的电子元件，用芯片级的方法打磨腐蚀芯片封装，然后用显微镜和探针读写Flash的内容，这样也可以帮助提取固件，但需要专业设备。关于这些其他方法的案例，笔者打算整理，但不知道啥时候能发出来。

3.2 固件的内容分析

当我们顺利拿到固件之后，往往获得是一个二进制的文件，但是对于此文件道理包含什么内容还尚不明确。此外，我们获取此固件文件的方式不同，也会对该文件有所影响。例如，我们通过网页下载固件文件，那么文件中可能会包含一些烧录配置信息，此信息会被烧录程序读取并以此配置烧录固件；若是通过直接读取外置Flash内容而获取的固件文件，那么这个文件就是此Flash中保存的所有内容，除了固件之外，可能还包含一些设备端在运行时生成的需要保存在Flash中的其他数据。

在分析固件内容时，有一个很常用的工具：binwalk，其官方的github地址是：https://github.com/ReFirmLabs/binwalk。通过binwalk工具，可以快速发现并提取固件文件中包含的各种内容，如lzma压缩数据、squashfs文件系统等。binwalk的工作方式就是在固件文件中查找标志字节(magic number)，也称为特征码，如PE文件的前两个字节是’MZ’等，通过这些标志字节就可以辨认出固件中内容，如lzma压缩数据等。识别完成之后，就可以将这部分数据单独取出并解压缩。

当binwalk工具什么都没有分析出来时，那么常见情况下有以下几种情况：A. 固件文件就是个可执行文件，不存在其他压缩数据，所以什么都没识别出；B. 固件文件被加密了或者固件本身是增量更新的数据，导致binwalk什么都没有识别出来；C. 固件中的magic number被抹掉了，这同样会导致binwalk分析失败。具体怎么解决这三情况，就要具体问题具体分析了。

binwalk工具在提取文件时要依赖很多第三方工具，如提取jffs2文件系统时需要依赖https://github.com/sviehb/jefferson工具，有些工具很久不更新了，只能在python2环境下运行，所以目前安装binwalk工具还是建议使用python2环境，以后有更好的适配时再切换成python3不迟。关于binwalk工具的安装可以参考其官方的步骤；关于使用binwalk工具的案例，基本出现在所有分析文章中，就不再单独整理了。

3.3 固件的程序分析

完成固件内容的提取之后，就可以开始逆向分析固件中的程序了，常用的分析工具有IDA、Ghidra等。与Windows逆向、Android逆向不同的是，智能设备的MCU是多种多样的，这就意味着我们在进行逆向工作时会见到各种各样的指令集，在家用设备中最常见的有x86、ARM和MIPS等。我们没有必要为了逆向固件而专门去学习指令集的所有细节，这有些舍本逐末。一般情况下，我们能够理解反汇编得到的代码段的大致含义就好，只有我们在较真一些加密、解密算法或者某些关键代码段时，才有必要一行不漏地看每个汇编助记符。

接下来要根据智能设备中是否有操作系统，以及操作系统的不同而进行分类讨论了。但不管怎么分类，归根结底还是要看汇编代码，所以多看多分析才能不断提高。

A. 无操作系统

无操作系统（NoOS， No Operating System），NoOS这个词是笔者从TI官方提供的STM32 SDK中摘抄过来的，并没有严格考证过其出处。操作系统往往起到一个承上启下的作用，应用程序运行在操作系统之上，操作系统提供了内存管理、线程调度等核心功能，应用程序只要熟悉操作系统提供的各种API，即可完成开发工作。

如果智能设备中没有运行操作系统，那么开发者就需要直接操作底层硬件设备，这就导致我们在逆向过程中经常会看到直接操作物理内存，以及操作被映射到内存地址的各种外设，如GPIO等。此时，我们在进行逆向分析时，需要不断地参考MCU的芯片手册以帮助理解程序。关于NoOS的智能设备分析案例，可以参考：https://bbs.pediy.com/thread-259530.htm。

B. 操作系统与应用程序分开

操作系统与应用程序分开就是指，操作系统与应用程序被编译成不同文件。这个分类中最常见的就是嵌入式Linux操作系统，有很多优秀的操作系统都是基于嵌入式Linux实现的，比如OpenWRT、RTLinux等。当作系统与应用程序分开时，那么逆向工作就会相对简单，只需要单独逆向我们关注的某一个程序即可。

此外，操作系统和应用程序分开之后，在很多其他方面也提供了便利，比如说我们可以上传其他的可执行文件至操作系统中，使用这些程序用以帮助分析和调试。关于操作系统与应用程序分开的案例，笔者正在整理，估计要7月或者8月才能整理出来。

C. 操作系统与应用程序混合

操作系统与应用程序混合就是指，操作系统和应用程序被编译成了同一个可执行文件。这个分支下同样有很多优秀的操作系统，例如FreeRTOS、ThreadX等。笔者在撰写本章节时，原计划是每个操作系统都整理一个案例用于说明情况，但一方面工作量确实很大，另一方面他们都是大同小异的关系，所以就将这几个操作系统暂时归位了同一个类别，3.3章节总共3个小节的分类方式。

当操作系统与应用程序混合时，可以适当的识别一下该操作系统提供的各种接口，通过这些接口可以辅助我们分析和定位应用程序中的关键代码和数据。举个简单的例子，我们要写游戏外挂，所以应该着重分析与游戏相关的exe和dll，而分析mfc.dll可能并不会有太多收获。关于操作系统与应用程序混合的案例，笔者正在整理，估计要8月或者9月才能整理出来。

3.4 固件的调试

有些情况下，静态逆向分析可能很难解决问题，比如说我们要分析一些自定义的复杂加密算法，单纯靠静态阅读代码还是有不小的难度，如果我们能够单步跟踪调试一下，问题就变得简单了。所以我们就在这个章节讨论一下固件的调试问题，很多智能设备是可以调试，也有很多智能设备是无法调试的，调试和反调试始终是一个相互对抗的博弈过程。我们不打算花大篇幅文字去介绍调试与反调试，那些情况需要具体问题具体分析，在这里，我们的主要目的还是列举一些常见的可调试的情况，以供大家参考。

A. 使用硬件调试器调试

运行于Windows、Android等操作系统内的应用程序，主要依靠windows或者android操作系统建立的调试体系，由内核层和应用层协同合作，以完成应用程序的调试工作。当我们研究的固件没有操作系统或者操作系统与应用程序混合时，无源码调试固件就相当于同时调试操作系统和应用程序，在固件中下断点意味着操作系统和应用程序的执行过程都被暂停。此时，我们需要一个硬件调试器以完成调试工作。

不同的MCU会使用不同的硬件调试器，常见的硬件调试器J-Link、ST-Link等。我们需要阅读MCU的芯片手册，用以确定选择何种硬件调试器；然后将硬件调试与MCU的引脚接通，此步骤可能涉及到一些电路板焊接工作；最后，接通硬件调试器和计算机，开始调试。关于硬件调试器调试固件的案例，笔者正在整理，估计要7月或者8月才能整理出来。

B. 使用gdbserver调试

我们这里所说的gdbserver一般是指运行于嵌入式Linux操作系统中的gdbserver程序。使用gdbserver可以直接在智能设备的设备端中调试应用程序，相比于在仿真环境中调试固件程序，在原本的环境中调试程序要更加稳定一些，毕竟模拟环境与原本的执行环境还是有一些差别的。

在固件中使用gdbserver一般有两个步骤，其一是开启shell，无论是串口登录后的shell或是ssh、telnet等shell，总之需要通过shell上传gdbserver以及运行gdbserver程序；其二是选择合适版本的gdbserver，不同的MCU指令集可以执行的gdbserver是不同的，即便是同一个ARM指令集，也分为很多版本如armv7、arm64等。此外，在编译gdbserver时选择的编译参数同样对最终gdbserver是否可以运行有着直接关系。这里我们还是具体问题具体分析，关于使用gdbserver调试固件的案例，笔者正在整理，估计要7月或者8月才能整理出来。

C. 使用qemu仿真调试

如果我们手头没有打算研究的智能设备，又想调试其固件程序，那么就可以选用qemu作为仿真器。qemu提供两种仿真模式，其一是user-mode emulation，另一个full-system emulation。通常我们在分析嵌入式Linux系统时，可以使用user-mode emulation仿真想要调试的程序。根据qemu的介绍，user-mode emulation会接管被仿真程序的system call、POSIX sigal等，将其翻译转发给宿主机。在实际分析中，被仿真的程序读写/dev目录下的设备文件，或者与其他程序进行通信程序等，这就导致某些程序运行在qemu仿真环境中和真实环境中表现出不同的行为。

关于qemu的full-system emulation是另一个话题了，这种仿真方式可以近乎完全的将整个固件运行起来，早在前些年就出现了使用full-system emulation实现仿真固件的工程，如firmadyne等。但不同的智能设备底层差异较大，firmadyne也只能适配其指定的几个固件，其他固件需要进行很多调试工作才能重新适配支持。关于使用qemu仿真调试固件的案例，笔者正在整理，估计要8月或者9月才能整理出来。

3.5 固件的重打包

固件可以分析可以调试之后，顺其自然的，就会想到能不能把我们修改过的固件在重新打包烧录回去。相比于拆解设备的固件，将固件内容重打包并烧录到智能设备中显然要更麻烦一些，主要是因为我们在拆包时可以用binwalk，在打包时则没有成熟可用的工具。但只要多做一些尝试，大多数情况下，重打包的固件是可以烧录回去的。

当我们需要将固件重新打包时，需要根据binwalk的提取结果而分情况进行讨论。当binwalk的分析结果显示固件文件就是数据和程序拼接而成的文件，没有任何压缩和编码，此种情况常见于无操作系统或者操作系统和应用程序混合的情形，那么我们对固件的修改通常是二进制修改，比如用UltraEdit直接编辑固件文件，那么此时只要保证修改的汇编指令是可以运行于此MCU的，应该就没什么大问题。

如果binwalk将固件文件中的各个组成部分分别解压提取出来，此种情况常见于操作系统和应用程序分开的情形，如果我们修改了某一个程序，那么一定要按照原格式再压缩回去，然后再重新将各个部分拼接成为原本的固件文件。在压缩过程中需要稍作注意，一定要压回原本固件的格式，比如在squashfs文件系统，不同版本的mksquashfs4打包的文件系统是有细微差别的，打包参数对生成的固件也有影响，如果固件文件格式不对，那么设备系统在启动过程中就会出现错误。此外，在拼接完整的固件文件时，固件中各部分内容的偏移最好不要改变。

最后，将固件文件重打包之后，通过什么样的方法烧录回去也是一个问题。有一个基本原则可供参考：固件怎么来的，就怎么回去。如果固件是直接在云端下载到的，那么就通过设备端对外提供的固件更新接口，将重打包的固件烧录回去。此种情况可以参考果加智能门锁分析的那篇帖子，链接如下：https://bbs.pediy.com/thread-259530.htm；如果固件是直接读取外置Flash芯片而来的，那么就还用编程器将重打包的固件写回去。此种情况的例子，笔者正在整理，估计要7月或者8月才能整理出来。在烧录我们修改过的固件之前，最好将原本的固件做一个备份，以免出现各种情况而导致设备变砖。如果设备真的变砖了，也不要惊慌，大部分情况还是可以挽救的。

4. 无固件通信分析

通信分析是智能设备安全研究中很重要的一部分。即便是可以获得固件，我们也会采用通信分析这种方法。通过监听智能设备固件的通信内容，可以辅助我们的逆向工作。在本文中，我们把通信分析整理单独整理在这个章节中，只用于说明当我们无法获取固件时，就只好分析一下智能设备的通信内容了。

4.1 有线/无线网卡通信

通过有线/无线网卡通信常见于设备端与云端的通信过程中。这种情况的通信也比较好抓，只要有一个能做端口镜像的交换机，使设备端通过有线/无线的方式通过此交换机，然后就可以直接监听端口镜像而来的通信数据。如果没有这种交换机，也可以尝试用计算机开热点，然后监听热点的通信内容。关于有线/无线网卡监听通信内容的案例，笔者正在整理，估计要7月或者8月才能整理出来。

4.2 通过4G/2G通信

通过4G模块或者2G模块通信也是比较常见的情况，也出现在设备端和云端的通信过程中。如果是2G模块通信，可以用USRP、BladeRF等搭建一个仅限于研究的基站，有很多开源的项目可供参考如openBTS、Osmocom等，然后监听此基站的通信数据。如果是4G模块通信的话，可以把要研究的设备放在没有信号的地方，比如说地下车库，此时设备就会被迫使用附近的2G基站，如果设备不会降级使用2G模块通信，那可能就不太好搞了。关于监听4G/2G通信内容的案例，笔者打算整理，但不知道啥时候能发出来。

4.3 通过Bluetooth通信

通过bluetooth通信常见于手机端和设备端的通信。通常情况下，bluetooth有两种不同的通信模式br/edr和le，前者被称为经典蓝牙，后者被称为低功耗蓝牙。在智能设备中，ble即bluetooth low energy更常见一些，经典蓝牙常用于手机和耳机的通信。常见的抓包工具如usb dongle只能监听未配对的ble通信，不管是经典蓝牙还是低功耗蓝牙，配对之后会产生link key用于加密通信，这种加密会导致usb dongle无法监听。高级点的抓包设备如Ellisys又很贵。所以，我们一般不直接监听空气中的bluetooth通信内容，而是手机端监听bluetooth通信内容，在Android手机端开启HCI log之后，可以通过此日志分析蓝牙通信。此外，我们还可以直接逆向运行于手机端的app，直接分析调用蓝牙接口的相关代码。关于监听bluetooth通信内容的案例，可以参考果加智能门锁分析的那篇帖子，链接如下：https://bbs.pediy.com/thread-259530.htm。

4.4 通过Zigbee通信

通过Zigbee通信的设备常见于设备端与设备网关的通信，在这种情况下，监听通信内容就变得麻烦了一些，并不是在手机端开个日志就能解决的。通常情况下，我们选择比较廉价的usb dongle作为监听设备。由于很多厂家在开发固件的时候，并没有更改默认的Global Link key，这就导致我们给usb dongle设置同样的密钥，即’ZigbeeAlliance09’，就可以直接监听一部分智能设备的通信内容。如果设备端更改了默认的密钥，那就没有特别好用的监听方法了。关于监听Zigbee通信内容的案例，笔者正在整理，估计要8月或者9月才能整理出来。

4.5 其他的通信情况

其他的常见情况有使用unlicense频段直接通信，如433MHz，或者使用其他通信协议如LoRa、NB-IOT等。针对这些情况，暂时也没有特别好用的监听方法，这里有两个建议可以去试试，其一是通过示波器或者逻辑分析仪监听MCU与无线通信芯片的通信内容，然后解码分析采集的引脚通信数据；其二是通过USRP、BladeRF等SDR设备在其通信频段直接监听通信内容，然后解码分析采集的无线通信数据。这两个方法工作量都比较大，而且有可能搞到最后时，发现通信是加密的，最终无功而返。关于监听其他通信情况的案例，笔者打算整理，但不知道啥时候能发出来。

5. 智能设备漏洞分析

以上几个章节的内容都趋向于智能设备的研究方法，那么仅仅掌握这些方法是不够的，关键还是要用这些方法对智能设备展开分析才行。智能设备的漏洞，可以归属为二进制程序漏洞的领域，常见的二进制代码漏洞，如栈溢出、堆溢出、整数溢出、命令注入、格式化字符串、UAF等都可能出现在智能设备中。除此之外，智能设备作为一个新兴领域，还有很多业务逻辑上的漏洞，如固件后门、认证绕过、加密不当等。

若打算利用代码漏洞，还需要了解各种阻止漏洞利用的缓解措施。与windows或者linux系统不同，他们有更为健全的缓解机制，智能设备中的缓解机制要少一些，最常见的就是内存地址随机化(ASLR)和数据执行保护(DEP)。业务逻辑的漏洞利用要相对简单很多，不需要繁琐的内存布局就可以完成利用。

5.1 逻辑漏洞

逻辑漏洞应是智能设备中最为常见的一类漏洞了。与代码漏洞不懂，逻辑漏洞往往是因为在设计时没有考虑周全而导致的。逻辑漏洞的种类有很多，有的影响比较大，也有的需要前置条件才能利用，我们没办法把所有逻辑漏洞全部都拿来讨论一番。在这里，我们按照案例做一些简单的整理。

A. 固件后门

固件后门在早些年的时候还比较多，到现在就不多了。一方面是因为很多固件后门都被曝光了，另一方面是因为设备厂商主动的删掉了后门。关于固件后门的案例，可以参考果加智能门锁分析的那篇帖子，链接如下：https://bbs.pediy.com/thread-259530.htm。

B. 认证绕过

认证绕过也是早些年比较多，尤其是在路由器和摄像头中这类问题尤其的多，到现在就渐渐地减少了。关于认证绕过的案例，笔者打算整理，但不知道啥时候能发出来。

C. 加密不当

在近些年的智能设备中，完全用明文通信的情况越来越少，或多或少的会有一些加密措施，但是错误的加密方法也会导致一些问题，例如将密钥和密文同时发送的情况等。关于加密不当的案例，笔者正在整理，估计要8月或者9月才能整理出来。

D. ……

5.2 代码漏洞

相比于逻辑漏洞，代码漏洞要更隐蔽一些，而且不管是挖掘难度还是利用难度，代码漏洞都要更复杂一些。在研究智能设备代码漏洞时，不妨多参考一下其他已经很成熟的领域，如Windows程序漏洞、Linux程序漏洞等，在这些领域有更通俗易懂的资料，可以直接拿来借鉴。在本章节，我们也对智能设备中的代码漏洞做一些简单的整理。

A. 栈溢出漏洞

栈溢出漏洞在智能设备中是很常见一类代码漏洞，也是比较适合初学者的漏洞。栈溢出，顾名思义，就是在栈中存储了过多的内容，而导致溢出，覆盖了栈中其他的有效数据。关于栈溢出漏洞的分析案例，可以在看雪《智能设备》板块中找到很多例子，笔者就暂时先不整理了。

B. 整数溢出漏洞

整数溢出也是一种溢出漏洞，其出现原因是变量被赋予了超过其取值范围的值，有时是因为数学运算而导致溢出，有时是因为对变量的取值没有做合理的过滤。关于整数溢出漏洞的分析案例，笔者正在整理，估计要8月或者9月才能整理出来。

C. 命令注入漏洞

命令注入漏洞同样是智能设备中很常见的一类漏洞，经常出现于嵌入式Linux系统的设备固件中。此类别的漏洞往往是因为没有对system()等敏感函数的参数进行有效过滤而导致的。关于命令注入漏洞的分析案例，笔者正在整理，估计要8月或者9月才能整理出来。

D. …..

6. 小结

写到此处，本文差不多就要结束了，还希望看到这里的读者能有所收获。在文中，我们首先明确了要研究的智能设备，以及智能设备中设备端可能出现的攻击面；接下来我们讨论了智能设备的研究方法，如固件分析、通信分析等；最后结合之前的研究方法分析了一些智能设备的安全问题。一方面，不熟悉智能设备的读者可以通过阅读此文，与我们一起开始智能设备的安全研究；另一方面，当遇到没有研究思路时，也可以随时翻看本文以找到新的突破口。最后，受限于个人的知识水平，整理难免会出现不正确的地方，如若发现了问题，可以及时指出，笔者也会修改和完善相关位置。

最后于 21小时前 被胡一米编辑 ，原因：