ELF自修改UPX脱壳实践

Linux威胁除了后门这类恶意文件外，就是在分析后门的过程中会遇到加壳的问题，加壳与Windows平台的层级类似，也有压缩壳虚拟壳这些种类，如果遇到虚拟壳的场景，现阶段真的就没办法了，需要考虑性价比，如果脱壳花费了太多的时间，而没有解决最主要的矛盾可能是得不偿失的。换一个角度看，如果热爱逆向技术，那想办法花时间深入专研脱壳也是值得的，至少过程中是会很开心的，如果能解决那也会有满满的成就感。

Linux很常见的是UPX壳，UPX是压缩壳，不过如果黑客简单的利用UPX加壳了，那分析人员其实是非常容易就能脱壳的，毕竟攻防是相对的，黑客所投入的精力，分析人员也将投入甚至于不少于这些精力去应对。以下的64位ELF后门例子很可能利用了UPX壳（为什么说很可能呢？因为笔者之前遇到过伪装成UPX的虚拟壳，直接放弃脱壳的幻想，哈哈哈），不过由于没有出现UPX!特征字符串，很可能做了对抗，如下。

直接使用原版UPX脱壳失败，如下，不过直接利用调试去手工脱壳也是没问题的，这个笔者之前的文章里写过了，可以参考。

十六进制格式打开需要脱壳的文件，如下可以定位到原本UPX!的字符串缺失了（如果要理解原理，需要对UPX工具源码进行研读，找到解析的数据结构偏移与字段值）。

直接给它修改成UPX!，如下

如果只是简单添加最开始的一个UPX!特征字符串，直接使用原版UPX脱壳还是会失败。

除了添加最早出现的UPX!特征字符串外，还需要找到被加壳程序原本会存在的所有特征字符串，可以搜索00 00 00 21十六进制序列，将所有匹配的结果将其改成UPX!字符串。

再次利用原版UPX程序脱壳，发现确实可以成功脱壳了。

上面这种反脱壳的技巧其实是最简单的一种技巧，JPCERT也公开了一个工具进行这种反脱壳技巧的自动脱壳。首先下载二进制文件后，运行会报错，Ubuntu20.04提示libc版本不匹配，因此需要进行更新（不建议强制更新，会对Ubuntu系统造成无法预期的影响）。直接wget -nv http://launchpadlibrarian.net/531361873/libc6_2.33-0ubuntu5_amd64.deb下载到特定deb安装包后，利用sudo dpkg --force-all -i libc6_2.33-0ubuntu5_amd64.deb安装，如下。

安装之后，再次执行命令还是会提示版本不匹配，无奈只能再次进行安装新的版本。

libc6_2.34-0ubuntu3.2_amd64.deb哈希值为7C1CF9CABA9861989A6AB369FE802F55

安装命令sudo dpkg --force-all -i libc6_2.34-0ubuntu3.2_amd64.deb

再次使用工具脱壳，发现可以成功。

利用反汇编工具进行比对，由于调试脱壳后相关符号会被去掉（ELF加载的机制造成），所以会缺失原本存在的相关符号，总的来说当后门比较复杂的时候一定程度会影响分析效率，不过一般情况下黑客会提前去掉相关符号，实际最终的场景下也不影响，如下。

参考来源：https://github.com/JPCERTCC/upx-mod

例子：C3A69D7F8D07D80E923BB5B8E8AC5B92

原文始发于微信公众号（OnionSec）：ELF自修改UPX脱壳实践