加解密逻辑分析(重点)关于固件安全开发到发布的一般流程如果要考虑到固件的安全性，需要解决的一些痛点基本上是：

机密性:通过类似官网的公开渠道获取解密固件。

完整性:攻击者劫持升级渠道，或者直接将修改后的固件上传到设备上升级固件。

对机密性，从固件源头、传输渠道到设备三点进行分析。先在源头、官网或官方TFP上提供已加密的固件，设备自动或手动检查更新，从源头下载，下载到设备上后解密。其次，渠道可以通过类似HTTPS的加密传输来传输固件。但前两种方法最终都是将固件下载到设备中。

如果是简单的加密，这是一种非常常见的方法，尤其是对于一些低端嵌入式固件，通常采用硬编码对称加密方法，如AES、DES等，也可以基于硬编码字符串计算一些数据，然后作为解密密钥。DIR3040就是这种分析方法。对于完整性，开发人员可以在开始时基于自签证实现固件完整性的验证。开发者使用私钥签名固件，并将签名附加到固件中。在接受安装时，设备使用预先安装的公钥进行验证。如果检测到设备完整性损坏，将拒绝升级固件。签名过程一般不直接签名固件本身的内容。首先计算固件的HASH值，然后开发者用私钥签名固件的HASH，并将签名附加到固件中。设备出厂时，在文件系统中预装公钥，升级后通过公钥验证签名是否正确。

加解密逻辑分析，既然到了这个地方，顺便进去看看解密程序是怎么运行的。从IDA的符号表可以看出，对称加密AES、非对称加密RSA、哈希SHA512都是用来比较上面提到的固件安全开发到发布的过程的。下一步是真正负责解密和验证固件的函数actual_decrypt，位于00401770处。在分析这个函数时，我发现IDA的MIPS32在反编译处理函数的输入参数时，似乎是错误的。例如，fun(a+10)可以反编译成fun(a+12)。已修正函数参数值的反编译代码放在下面，所有代码分析都直接放在注释中。