本节我们结合前面的知识点，通过动手实践来分析一个”恶意“程序。这次我们使用的例子具有极强的动手实践性，它也非常能代表恶意程序入侵系统的很多流程步骤，跟着做下来你一定收获颇多。
首先我们需要获得要分析的程序对象，其下载地址为：
链接:https://pan.baidu.com/s/1ygGvONkmdeD7d9YJ9plajw密码: w855
通过上面链接下载相应文件后上传到Linux系统上，我们就可以开始分析流程。首先你会发现它是一个没有后缀的二进制文件，所以我们无法通过后缀来判断文件类型或内容，其实不管后缀如何，我们都不能仅仅通过后缀来识别文件类型，因为病毒作者很容易通过修改后缀来隐藏真正的文件类型。
因此面对这种没有后缀的二进制文件，我们首先要做的是搞清楚它是什么文件。最常用的方法是读取文件开头一定数量的数据，然后检验这些数据是否满足特定文件的格式，例如ELF文件头64字节是ELF头，是一种固定格式的二进制数据，特别是如果我们读取前64字节后发现它包含ELF对应的magic number部分，那么就能有信心的肯定其是ELF类型的可执行文件。
因此我们需要先读取其开头一部分数据看看数据是否遵守一定的二进制规范。在Linux上的命令行工具file能满足我们的需求，于是我们使用如下命令读取文件开始的一部分数据：
···
file payload
···
执行后所得结果如为：payload: ASCII text，这表明文件的内容包含ascii字符，因此可以直接打印出来，于是我们使用head来输出其头部的一部分数据：
head payload!
从输出结果看，虽然内容是字符类型，但显示出来的信息对人而言根本没有任何意义，这其实透露出一个重大线索，那就是极有可能这些信息实际上是二进制数据经过base64编码后的结果。因此我们只要对输出内容进行base64翻编码就能得到原来内容，linux上有现成的编码工具叫base64可以直接使用：
base64 -d payload > decoded_payload
file decoded_payload
上面命令运行后结果显示内容为：
从显示结果不难看出，payload文件其实是一个压缩包，因此我们可以使用Linux附带工具对其进行解压：
tar xvzf decoded_payload
命令执行后可以发现本地目录多出两个文件，一个名为ctf,一个名为67b8601，这两个文件同样是没有后缀，因此我们还需执行相同步骤去解析这两个文件的真正类型。于是同理我们使用file命令来检验一下两个文件的数据类型：
file ctf
上面命令执行后可以看到如下内容：
这回不难看到ctf文件其实就是一个ELF类型的可执行文件，注意到输出内容的最后有一个stripped，这表明该执行文件的符号表被专门剥离了，其目的很明确，如果它包含符号表，那么代码就很容易被别人通过符号表进行调试解析从而完全掌握该程序的运行机制。当前我们不知道这个程序到底想干什么，要想知道这点最好的方式就是运行一下它。
当然如果它是恶意程序的话，你一运行电脑就有可能被它感染或劫持，由于现在我们处于研究阶段，同时运行环境又是虚拟机，因此我们这次就大胆运行一次看看，于是执行命令：
./ctf
运行结果输出如下：
也就是说程序运行时出错，原因是缺少了链接库lib5ae9b7f.so，一眼看上去这个链接库就不可能是正规的系统动态链接库，基本上是该恶意程序的‘私货’，现在问题是这个东西到底在哪。这时我们回想起在前面解压时有两个文件，由此有理由怀疑另一个名为67b8601的文件可能有问题，如果你使用file 67b8601命令来查看它的内容，你会发现该文件是一个bitmap图像文件。
这里又涉及到恶意程序常用的一种手段，那就是将一些关键文件私藏在某些难以感觉有问题的普通文件中，例如隐藏在bitmap等图像文件中。于是我们要侦查67b8601这个表面上看起来是图像的文件到底是否有猫腻。由于在Linux上，动态链接库的类型同样是ELF，而前面我们看到ELF文件里面的头部magic部分就包含了字符串”ELF”，因此如果链接库藏在67b8601中，那么该文件就应该包含字符串”ELF”，于是我们使用下面命令查找：
grep 'ELF' 67b8601
命令运行结果得到的输出是”Binary file 67b8601 matches”也就是说解压出的67b8601文件里面包含了ctf程序运行所需要的动态链接库，现在我们要想办法将链接库抽取出来。这就需要我们读取67b8601里面的二进制数据，同时在查看过程中要注意从哪里开始，数据的模式能够与ELF头部64字节的数据结构匹配上。
首先我们需要将67b8601的内容以16进制字符串的形式展现出来，这样我们才能肉眼查找，在Linux上的XXD工具能提供我们需要的功能，执行如下命令：
xxd 67b8601 | head -n 15
上面命令执行后所得结果如下：
由于一行对应16字节，ELF字符出现在第三行，也就是从第48字节再数4个字节，于是ELF出现在整个文件偏移52字节处。回想前面描述过的ELF文件头部结构，我们知道ELF头部由若干个字节组成magic部分，其中开头就对应ELF三个字符，因此我们可以推论出从ELF开始出连续64个字节就是ELF文件对应的头部结构，由此我们从该文件偏移52字节处专门读出64个字节就能获取链接库的头部数据,我们使用下面命令行来实现目标：
dd skip=52 count=64 if=67b8601 of=elf_header bs=1
其中dd 是Linux上读取文件数据的工具，count表示要读取数据的长度，if对应要读取的文件名，of对应数据读取后写出的文件名，bs对应读取的单位，当前表示单位为1字节，上面代码运行后在本地目录就会多出一个叫elf_header的文件，然后使用命令readelf -h elf_header看看读出来的数据是否真的符合ELF文件的头部结构，相应命令运行后结果如下：
从输出看，截取的64位数据的确构成了ELF文件的头部信息，接下来我们就得根据这些信息继续从67b8601里面将整个ELF文件的信息抽取出来，相关内容我们再下一节介绍。
扫一扫
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
