前不久，学弟突然找上了我，说学校分配的服务器被人种了挖矿木马，心中一听顿时一惊。内网一台服务器的沦陷的话，可能其它服务器也遭黑手了（可惜我不是应急响应大神，加上学校对网安这块不太重视，我也没资格上人家的服务器看一看情况，只能让学弟把软件发给我。）
但是由于学弟那边排查占用率最高的是python2.8文件，所以先用ida打开，查找字符串发现：
可以发现就是xmrig6.21.3 版本，于是我问了问被入侵的时间，结果是6月9号左右，那个时候xmrig还没更新6.21.3版本，好家伙，到被发现快有1个月了，既然确定了python2.8的真身，接下来就要开始分析-bash文件了。
网上搜了搜，大多都是在说修改了upx特征，如果不看upx源码找到被修改的特征就只能找到oep之后dump下来，想了想后者比较快，于是先试了试后者，
脱壳操作参考了Linux逆向之加壳&脱壳 - 先知社区 (https://xz.aliyun.com/t/6881?time__1311=n4%2BxnD0DRDyBeAK4GNnm0WY4D50QKQDgeRYD&alichlgref=https%3A%2F%2Fcn.bing.com%2F)。
然而ida打开搜索字符串发现了go语言特有的字符串：
这样的话oep dump会丢失很多信息，而且调试符号本身也被去除了。
在尝试了go_parser和IDAGolangHelper工具恢复符号失败后，不得已开始研究pclntab和moduledata,这里参考了安全客一位师傅写的文章（https://www.anquanke.com/post/id/215419#h2-4）,在其中发现gopclntab Section 就对应于 pclntab 结构，由于-bash软件没有开pie，所以gopclntab不会被删除，这下必须研究upx源码并尝试恢复特征进行工具脱壳了。
源码的研究参考了[原创]UPX 4.0.2 源码分析（https://bbs.kanxue.com/thread-278288.htm）
简单说一下研究过程，首先全局搜索哪个函数爆出错误信息"NotPackedException: not packed by UPX"。
可以发现visitAllPackers是关键函数，继续定位，这里给出部分代码，但可以确定核心是func(pb.get(),user),结合刚刚传递的参数，确定核心为try_can_unpack。
核心是pb->canUpack,这下要跟进类方法了，不过很容易就确定是：
里面的printf都是我后来加的，是为了确定哪个条件出了问题。
虽然不知道为何会多次调用，不过看样子感觉是为了尝试不同平台，这里主要解决父类canUnpack的问题，因为第一次调用e_machine是对的上的。
核心在于find_overlay_offset，跟进
由于find_overlay_offset并未抛出下面两种异常，所以问题只能在第一次条件判断，经过调试后得知是getPackHeader的问题，由于其篇幅过长，只给出核心地方，可以看见在解码时爆出错误，继续跟进。
这下问题一目了然，在解码时，没有找到UPX的magic字段，而根据前面的代码得知upx是从文件倒过来开始解码的，所以16进制打开文件看一看。
原来文件末尾硬编码一段数据upx也脱不了壳，网上那些各种改特征虽然很牛，但第一次觉得没有这个快捷方便。
/var/tmp/.x就是之前学弟找到的位置，不过前后的信息就有点迷惑了
这下就能快速定位gopclntab,然而这份样本上来就给我上了一课。
magic字段为16B867D6h，我在网上看了很多go样本混淆的，但magic字段都是FF开头，从来没见过这种。这下我也就知道了为什么go_parser和IDAGolangHelper不行了，因为这两个工具找magic的前提是0xFF开头的
这下只能手动写脚本恢复符号了，这里参考了[原创]2021 CISCN gift题解（恢复符号+逆向算法）（https://bbs.kanxue.com/thread-267813.htm）
from ida_bytes import del_items, DELIT_SIMPLE
from ida_funcs import add_func
from ida_name import set_name, SN_NOCHECK
from idc import get_strlit_contents
import idaapi
moduledata = 0x642240
func_table = idaapi.get_qword(moduledata + 0x80)
func_table_size = idaapi.get_qword(moduledata + 0x88)
string_table = idaapi.get_qword(moduledata + 0x8)
start_addr = func_table
end_addr = start_addr + func_table_size * 8
i = 0
while start_addr < end_addr:
func_entry = idaapi.get_dword(start_addr) + 0x401000
start_addr += 4
func_struct = func_table + idaapi.get_dword(start_addr)
string_addr = string_table + idaapi.get_dword(func_struct + 4)
string_name = get_strlit_contents(string_addr).decode('utf-8') if get_strlit_contents(string_addr) else "unknown_"+str(i)
print('Renaming ' + hex(func_entry) + ' to ' + string_name)
del_items(func_entry, DELIT_SIMPLE, 1)
add_func(func_entry)
set_name(func_entry, string_name, SN_NOCHECK)
start_addr += 4
i += 1
这里说以下为什么不用func_struct里第一个字段entry，这里我计算两个func_struct地址。
第一个func_struct为0x6026A0 + 0x56B0 = 0x607D50
我们要的前两个数据都是没问题的，第一个是相对于基址的偏移，第二个是相对于字符串table的偏移。
然后再看第二个func_struct为0x6026A0 + 0x5708 = 0x607DA8
这个func_struct第一个字段就完全对不上了，如果有知道原因的大佬还请指出
在逆到这后突然就没多少力气继续逆下去了，本人在go语言方面并没有多少经验，要继续下去得花很大的时间才能搞懂究竟做了哪些事情，路漫漫其修远兮，吾将上下而求索。
看雪ID：Ghost_196615
https://bbs.kanxue.com/user-home-835864.htm
*本文为看雪论坛优秀文章，由 Ghost_196615 原创，转载请注明来自看雪社区
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
点赞
https://cn-sec.com/archives/2953490.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论