ELF自修改UPX脱壳实践
2022-8-11 12:2:17 Author: OnionSec(查看原文) 阅读量:202 收藏

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


文章来源: http://mp.weixin.qq.com/s?__biz=MzUyMTUwMzI3Ng==&mid=2247484635&idx=1&sn=5ab78a14d1639e826bb2ed88e4e52a91&chksm=f9db5398ceacda8e25c7e7032473d3837b7beda0d82f7a988442eddcee27d141c22767c8f147#rd
如有侵权请联系:admin#unsafe.sh