上一篇文章讲解了“熊猫烧香”病毒样本的反汇编代码入口处的分析，虽然尚未研究到病毒的核心部分，但其实我们后续的分析与之前的思想是一致的。而越到核心部分，可能会遇到越来越多的API函数，结合所调用函数的参数进行分析，反而有助于我们更容易地理解病毒的行为。应当将分析出的每一个CALL函数，改为我们能够理解的名字，这往往也有助于对后续程序的理解。
上一篇文章的最后，我留下了三个CALL没有分析，现在进入第一个CALL，即sub_408024的内部查看一下：
图1 sub_408024起始处
程序先将0x84赋值给ecx，此即为循环次数。然后使用了两个push 0，每个push能够开辟8个字节（32位）空间，所以这里每次能够获取16个字节的空间，这样的空间一共申请ecx次。那么本段代码的功能在于空间的申请。接下来有：
图2 分析函数sub_40277C
这段代码的最后出现了sub_40277C这个函数，我们跟进后可以看到这几句代码：
图3 跟进sub_40277C
可见sub_40277C主要是调用GetMuduleFileNameA这个API函数，而这个函数的功能就是获取当前进程已加载模块的文件的完整路径，那么就可以将sub_40277C重命名为：GetFilePathAndName。获取成功后，结合OD，可以看到如下信息：
图4 获取当前进程的完整路径
接下来有：
图5 分析sub_405684函数
注意第一句代码中的[ebp+var_3B8]保存的就是图4中所获取的路径地址，这个地址值赋给了eax。然后进入sub_405684分析。这个函数中有一处循环结构，是我们重点关注的对象，利用OD动态分析：
图6 sub_405684中的循环结构
仅仅进行静态分析，不容易明白这个循环的作用，但是结合OD单步执行，观察寄存器中的值，就很容易明白这段代码的功用：它利用之前获取的文件完整路径，从后向前以单字节为单位，不断循环搜索，直至遇到ASCII码值为0x5C或0x2F或0x3A，然后便跳出循环。而0x5C所表示的是字符“\”，可以知道这段程序要么是获取文件名，要么是获取不包含文件名的路径。进入最后一条语句的CALL分析，很快就能够发现：
图7 字符串拷贝
可见，程序将去除了文件名的路径拷贝到了之前申请的空间中，于是可以将sub_405684重命名为：GetFilePath。接下来有：
图8 分析sub_403ED4函数
这三句代码的第一句，是将上面所获取的不带文件名的路径的地址赋值给eax，然后将字符串“Desktop_.ini”的地址赋给edx。然后进入sub_403ED4进行分析：
图9 字符串连接代码
上图中代码的最后一个CALL，在分析sub_405684（GetFilePath）时遇到过，其作用是将字符串复制到指定的位置。对于这段程序来说，就是将“Desktop_.ini”这段字符复制到之前的路径字符后面。那么可以得知，sub_403ED4的作用是字符串的连接，那么就将其重命名为：StringCat。继续分析：
图10 分析sub_4057A4函数
第一句代码是将之前所处理完毕的路径字符串地址赋给eax，然后调用sub_4057A4函数，进入该函数可以发现：
图11 查找文件函数
这里调用了FindFirstFileA这个函数，说明它是在查找当前目录下“Desktop_.ini”文件是否存在，那么sub_4057A4函数的作用就在于检测文件是否存在，可将其改名为：CheckFileExist。接下来有：
图12 设置文件属性
由于有了之前的分析并进行了重命名，那么这一段代码的作用就很明显了，首先根据上一段代码的查找结果进行判定，即如果当前目录下Desktop_.ini文件存在，那么就将该文件的文件属性调整为NORMAL，接下来有：
图13 文件删除
停止1毫秒后，将Desktop_.ini删除。图12中有一个未知函数sub_4040CC，进去查看，则有：
图14 分析sub_4040CC函数
可见这个函数用于检测待删除的文件路径是否为空。那么就可以将sub_4040CC重命名为：CheckPath。当然，以上分析是建立在Desktop_.ini文件存在的前提下，如果文件不存在，那么程序就会直接跳到loc_408110处执行：
图15 分析sub_4078E0函数
这里最后一句调用了sub_4078E0函数，跟进去发现这个函数较长，并且也调用了很多其它的函数，乍一看，似乎不知这个函数究竟是做了什么。既然如此，我们可以先不管其具体的实现细节，只看看该函数执行完后，我们寄存器等位置产生了什么变化，主要关注该函数执行前后，程序使用了哪些寄存器。利用OD可以很容易发现变化：
图16 sub_4078E0函数执行完后的变化（部分）
由截图可以发现，在获取了当前文件的路径后，该函数利用了很大的一片区域来写入了大量看似无意义的字符。结合右边分析出的ASCII码，发现这些可以理解为是一个暴力破解字典，病毒编写者企图利用暴力破解的方式，来攻破计算机中的某些验证机制。当然截图中仅仅展示了一小部分变化，病毒还写入了很多其它信息，有兴趣的读者可以自行查看，这里不再赘述，这有助于我们获取病毒的行为信息。那么这里可以将sub_4078E0函数重命名为：WriteVirusInfoToMem。接下来有：
图17 分析sub_403C44函数
这里第一句执行完后，eax的值为ebp+var_8的地址，通过OD可以知道，这个地址中保存的是0，可以理解为没有数据。之后有一个CALL，我们进入查看一下：
图18 进入sub_403C44函数内部
这里首先取出eax所保存的地址中的值，也就是0，并赋给edx，那么edx保存的也就是0值。之后的test运算，使得ZF变为1，满足跳转条件，那么本段函数也就结束了。如果说edx所保存的不是0值，那么接下来的语句就会把eax所保存的地址中的值设为0。这么看上去，这段函数似乎并没有实现什么特别清晰具体的功能，那么不妨将这个操作理解为某种标志的设置，将sub_403C44重命名为：SetZeroFlags。继续分析：
图19 分析sub_403ECC函数
结合OD可以知道，第一句是获取文件在内存中的首地址，然后进入sub_403ECC查看：
图20 进入sub_403ECC查看
这里需要特别强调的是，由于本病毒程序是使用Delphi编写的，那么字符串的首地址减去4后，所取出的4个字节的内容就是此字符串的长度。也就是说，这段代码中的[eax-4]就是eax所指向的文件长度。于是可以将sub_403ECC重命名为：GetFileLen。在获取文件长度后，程序会跳转到loc_408163处执行：
图21 分析loc_408163
在获取了文件长度后，这段代码首先会验证文件长度是否为0，这里由于文件真实存在，所以接下来的跳转不成立。接下来，eax中保存的是文件起始地址，而ebx是文件的长度，于是可以知道，倒数第二句的对比，是验证文件的尾端数据是否为0，如果为0，则接下来的跳转不成立。经过OD的动态分析，这里文件尾端的值为0，所以不执行跳转，继续向下执行。
接下来代码的分析，留给下一篇文章。
原文地址：http://blog.csdn.net/ioio_jy/article/details/41247329
