背景：
分析某路由器产品的时候，发现部分通过aes加密的信息，可以通过一些技术手段获取明文。从分析接口和路由器功能来看，这部分加密信息可能还是核心业务逻辑中的重要数据。
具体步骤
1，先尝试获取固件下载地址，直接对路由器进行抓包，固件默认信任了第三方证书，抓包可以查看到https内容
请求的返回文件中包含了固件的下载地址，md5校验等参数，可以直接通过url下载到固件。
2，下载固件后使用binwalk进行解包，固件没有做加密或者特殊处理，可以用binwalk直接成功解包。解压后目录如下:
3，到固件的app目录下，app目录下每个文件夹对应一个程序模块，这次的目标模块目录如下，bin目录下为二进制文件
4，bin目录下的id_manager文件，先查找有没有字符串信息，简单点，直接用notepad++打开id_manager
进入app\id_manager\bin目录下，直接打开id_manager，可以看到部分字符串内容。有一段wget请求，这里比较明显的应该是代码里的辅助日志输出，没有做处理。
wget -t 3 -T 10 -c "http://%s/rule/check?ckey=%s&data=%s" -O %s url /tmp/ib_server_response_enc.file %s: line = %d cmdline:%s
实际的Url应该是http://url/rule/check?ckey=XXX&data=XXX
5，为了验证这条请求是否真实存在，对路由器进行抓包，看到一条实际请求为
从样式上看，推测ckey是加密后的秘钥，data是用秘钥加密过的实际内容。在id_manager中查看有postdata相关内容如下
model=%s&mac=%s&firm_ver=v%s&plugin_ver=v%s&app_id=%s&rules_md5_id=%s %s: line = %d post_data:%s
查看id_manger中上下文，有字符串%s: line = %d aes_key:%s ，推测这部分参数应该是使用aes加密，ckey的内容是ras加密后的秘钥。
再在id_manager中搜索“public”,找到代码中的public key 如下
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCYnS2SjPOIsIUCUdWNzCD19J1G
8fO0Phm9g97kxL5PthYTCkuaKmToBSgrLW4eT6L3cxq2tlaJ+RviNcEgYTwHAOG3
qiooVGoxu2m0kqg1eQrjoCtjTzvutbPO3qp0r/Xzet3jUE+5KuXpEGhQFAud7+Gc
An/27zJZFsY0+JbnDQIDAQAB。
6，尝试使用指定的aes key伪造一条请求，看看服务端是否可以正常返回。
伪造的核心思路是，在分析出来URL的具体参数后，同时又获取了偏移量，那么我们可以随意指定一个AES秘钥，把URL内容进行AES加密。在获取服务端的响应内容后，就可以利用我们指定的AES秘钥解密服务端返回的内容，获取明文信息。
伪造逻辑是指定一个asekey，按照上文中的格式把原文使用aeskey加密，作为data的参数值。再使用publickey对ase key加密后作为ckey参数值传递。
data部分按照格式设置为
“model=v1&mac=xx-xx-xx-xx-xx-xx&firm_ver=x.x&plugin_ver=3.0.0&app_id=&rules_md5_id=”
指定一个aes秘钥为abcdabcdabcdabcd，偏移量也可以直接在id_manger文件中看到明文的，为J1Ldv7shzA75WSa7
获得参数data=x0y9QUPganyXrn9uOZMTOKN+OuBOsaZnrcBcO//eyErApG0ZkqAb+Cg1C+KfEgAvI5u0pB4a4P0Qo7yEleCdnnqjF8TSruLjRRI+yUb7n6adYgM83UdMYycZ6lRjcneX
ckey=E9EBs6eZL+eDwiRG3lVb+5Cxlsl8vxJYpq2qYj3cQAU2uHx4OjJiLoz/Z5SPQI1upj4+X9OUvSXXmzxe5Dmb7ykmnQcjK7J3RIb3c8cqB0zHIspnvmoLsxWFKhDu3ELSfacRr90++K5iT88VVDZpJOGuDD3FgZGmBiM+pDVDR5M=
构造请求
服务器有正常返回，返回了几次错误码，包括固件版本号缺失，插件版本号缺失，根据错误提示补全data内容后，构造出一条可用的请求
最终的data=x0y9QUPganyXrn9uOZMTOERH7xeaOEW2i7wlOzUpxOpQm5WqHC/vs0cCDpcihKrf0N7C2pFWr+qIkXC60qbJaDOQ1ABJivUBQI8Qj+Ow7kZ0INHzeAOgI0p9LasstmLS
服务器有正常响应。
7，拿到服务端返回结果，使用指定的aes秘钥wtBEabcdmm2wg5a5解密。如下图 ，获取了加密后的内容
问题分析
这次发现的信息泄露漏洞，本身加密机制是没什么问题的，使用了RSA+AES的加密方式。但是加密方式没问题，不代表业务逻辑上就没有漏洞，由于URL参数和部分加密信息可以在二进制文件中扒拉出来，导致可以模拟一个自定义密钥，从服务端获取加密信息，再解密获取铭文信息。路由器固件存在的问题主要如下：
1，固件的升级请求虽然是https，但是没有做证书校验，Https的内容也没有做二次加密，导致可以被抓包
2，固件也没有做加密处理，可以直接被binwalk解压
3，代码中存在大量调试用的日志文件，加密逻辑可以通过字符串被摸索出来
