00000000 53 48 52 53 01 13 91 5D 01 13 91 60 67 C6 69 73 SHRS‘]‘`gÆis
这种固件格式及加密方案已经被公开记录。一位名叫0xricksanchez 的研究者，发布了一篇非常棒的writeup，记录了如何创造SHRS固件镜像（包含DIR-3060，我们已经发布了一篇干系advisory）中密钥的过程。他们从imgdecrypt二进制文件中提取出了加密密钥和初始向量IV，此二进制文件可以通过类似系列型号中的URAT shell得到。
然后，最近我们碰着了DIR-X系列的路由器，它们的固件头有一点不同。
00000000 65 6e 63 72 70 74 65 64 5f 69 6d 67 02 0a 00 14 |encrpted_img....|
头部便是一个encrpted_img字符串，然后紧跟其后的是镜像大小字段（32位大端模式）。
SHRS固件镜像的key不适用于这些encrpted_img 镜像，因此我们须要找到另一种方法，将解密密钥从这种加密格式的设备中提取出来。
二、密钥在哪里?显然，我们无法从加密的固件镜像中提取加密密钥，由于它是加密的。以是，我们须要找到另一种方法来获取密钥key。
如果我们能够在设备上以某种办法实行代码，那么就很大略了。如果有足够确当地权限，我们可以在设备运行时，访问设备上的所有内容。这是解密后的固件镜像。
如果设备制造商最近才引入固件加密，则可以追踪尚未加密的老版本固件镜像（很可能是引入加密之前的固件版本），并检讨是否可以从中提取出密钥key。
直接读取设备的flash内存，是我们可以采取的另一种技能。在flash中固件不太可能被加密。拆开个中一个设备，卸掉flash内存芯片，转储内存后再读取文件系统。但是这样的毁坏性太大了，设备很昂贵，一旦破坏将大大摧残浪费蹂躏。
在这里，我们不会深入磋商这些问题，由于其他人已经做过了。关于这个问题Zero Day Initiative有一篇详细的文章，当你在办理固件加密时，可以考虑这个方法。
三、Shell中的操作在我们的例子中，通过UART调试接口可以轻松得到DIR-X1560设备的shell。获取到交互式shell后，就可以轻松dump出全体文件系统。利用内置的busybox tar和nc命令可以很随意马虎地做到这一点。首先在设备上设置监听器：
nc –nvlp [PORT] > filesystem.tar.gz
然后在设备上运行以下指令，只写明想要传出的根目录即可。
tar -cvz /bin/ /data/ /etc/ /etc_ro/ /lib/ /libexec/ /mnt/ /opt/ /sbin/ /usr/ /var/ /webs/ | nc [IP ADDRESS] [PORT]
终极，将得到tar.gz压缩文件，包含文件系统中任何你想要的部分，然后通过网络传输出来。
四、创造在何处解密不同于“SHRS”固件镜像，没有明显的imgdecrypt二进制文件可供关注。因此我们可以跟踪固件上传过程，看是否可以定位到在哪里解密。
幸运的是，固件头部的字符串，可以作为独特的关键字，帮助我们在文件系统中找到干系程序。
$ grep -r encrpted_imgBinary file bin/fota matchesBinary file bin/httpd matchesBinary file bin/prog.cgi matches
在此我们找到了两个二进制程序 prog.cgi 和fota，二者可能以某种办法来处理加密过的固件镜像。
在progl.cgi中，根据字符串encrypted_img，我们可以很随意马虎地追踪到固件上传的地方。
通过跟随固件被加密部分的指针变量，创造函数FUN00033144被调用，此指针是其第一个参数。
在这个函数内部，涌现一个极有可能是固件解密的函数： gj_decode()
五、深入库文件
gj_decode()函数被定义在libcmd_util.so文件中，此函数代码不多，但关键的是，其内部调用了两个加密干系的函数： aes_set_key 和aes_cbc_decrypt。这两个函数也被定义在上述文件中，但我们没必要穷究这二者。由于它们的函数名已经给予了很多信息：像是CBC模式下的AES加密。
我们可以看到，aes_set_key()的第二个参数可能是AES密钥，而 aes_cbc_decrypt 的第二个参数可能是初始向量IV。
这里的翻译代码有点乱，但不要太在意细节，直接看代码逻辑就行。有两个do-while循环，将数据从全局变量复制到本地缓冲区，这些循环在全局地址的字节上迭代，直达到到某个特定的结束地址。
key_loc 和key_loc + 4是指向本地缓冲区的指针变量，在第一个循环中，00031ba3地址处的数据拷贝到key_loc+4直到00031bc3地址，而第二个循环，00031bc5地址处的数据拷贝到key_loc直到00031bd5地址（还把稳到：这两个本地指针分别是aes_cbc_decrypt()和aes_set_key()的第二个参数）
的确如此，在地址00031ba3处，可见有一个字节数组。
同样在00031bc5地址处，也可见类似的形式。
因此，我们可以假设AES密钥位于 00031ba3，而初始向量IV位于 00031bc5。
本日我们在这不会公布真实的密钥，但是那些关注且跟随者该当有能力将密钥提取出来，如他们而言，这是留给有兴趣读者的练习。
六、节省韶光和脑力通过利用CyberChef，我们可以快速、轻松地验证假设。大多数情形下，当我想要快速办理密码学干系问题时，我都会打开这个工具。它由英国GCHQ编写，如果对公务员写的东西持疑惑态度，大可不必，它只是用纯JavaScript编写，可以在你想要的任何浏览器中运行。
复制加密固件镜像中的第一个0x1000旁边字节的数据，作为16进制的ASCII粘贴到CyberChef输入中，再结合我们提取的密钥和IV，通过CyberChef的“AES Decrypt”操作，就可以得到一个空想的结果。
在这里我们可以看到UBI数据块的头部数据，解释我们正在完备的解密全体固件更新包。
一旦我们知道密钥和IV是有效的，那么很随意马虎就可以编写一个完全的解密脚本。在这种情形下，在我们得到一个完全且精确的镜像之前，还有几个小的问题须要战胜，比如数据对齐，但这些都很随意马虎办理。
七、结论在许多情形下，嵌入式设备中的固件被加密并不是一个很难办理的问题。一旦可以获取到物理设备，解密过程就可以大大简化。值得记住的是，嵌入式设备的固件加密紧张在固件更新包中实现，而很少在存储级别实现，这一点与移动电话和条记本电脑的最新实现相反，这二者常见的加密方法是全磁盘（至少是磁盘的主要部分）加密。
这种设置在未来可能会改变，至少是部分改变。例如，Android从4.4开始就支持 全磁盘加密 ，从7.0开始支持基于文件的加密。自Android 10以来，就须要基于文件的加密。然而该当把稳的是，术语“完全磁盘”加密在Android中具有误导性，即加密的只是data/userdata分区。
