本帖最后由 wy1091727248 于 2011-6-30 16:19 编辑
昨天去看了MMPC的blog，看看那些最新病毒报告，想到这些报告反应了近阶段MMPC的重点所在，突然想和大家一起分享一下，今天第一次，以后这件事不出意外，我会做下去，想兴趣的也可以来帮我
好了，现在开始吧，翻译在原文后面~~
Malware packer integrates with UPX
Recently while I was analyzing a bunch of samples packed by custom packers, one of them struck me as a bit different than any others I saw before. At first glance, the outer layer of packing is a UPX stub, which is commonly used in malware. Especially when combined with a custom packer, UPX can provide an excellent compression ratio.
Since it's packed by UPX, I first unpacked it with a static unpacker and examined the dump. The heavily obfuscated code at the entry point easily leads me to think there is another layer of packing, so let's trace a bit to see what happens. The inner packing eventually ends up with a dead loop, which is calling Kernel32!GetUserDefaultLCID in each iteration.
From the above figure, it's very clear that this is a closed loop without an exit condition and the code is mainly useless. But the blackbox analysis shows it's actually doing something. Going backwards to the entry point, I carefully look through the code and find two interesting spots.
Although there is plenty of code before the 'or eax, eax' instruction in Figure 2 above, none of them change the value of register EAX, but this UPX packer assigns a pointer from the stack to EAX before jumping to OEP (see Figure 3 below). So, on the versions of Windows where the register EAX is zero when the file loads, if the file is unpacked and then run, the sample will know it and jump to the closed loop.
Another code snippet from the inner packer does additional checks against the presence of UPX. To satisfy this check, the EAX must equal to ESP + 0x11C, which matches the EAX value initialized by the UPX stub code.
If either of the checks fail, it leads to a dead loop or an unhandled exception. Now we know that to debug or emulate this sample, the UPX stub code can't be skipped by a static unpacker. By bypassing or including the UPX stub code in the execution, the malware underneath is finally revealed to be a member of the Bamital malware family. I also compared the size of UPX, packed and unpacked, and notice a big difference in file sizes, so I decide to dig more. The encrypted file underneath occupies a big portion of the file and looks to be filled with a lot of padding. By looking through the encryption this packer uses, it's clear that it appends tons of useless padding bytes (0x6A in this case) to the compressed code and re-orders the whole buffer, so that the compressed code blends into the padding, making it look like junk data that can avoid entropy checking and other similar techniques.
The malware author may have tried out this technique to avoid detection, but we're on to them. With our antivirus products such as Microsoft Security Essentials, this trick is handled well and we detect the malware underneath as Trojan:Win32/Bamital.I.
翻译：
最近当我分析一群自定义包装的样品，其中一个吸引了我，它与我以前见过的其他任何样本都不同。第一眼看，包装的外层是 UPX 存根，这常被用于恶意软件。特别是当与自定义包装相结合，UPX可以提供极好的压缩比。
因为它由UPX包装，我先解压缩到静态的文件，再检查。在入口点严重模糊处理的代码，很容易造成我认为还有另一层的包装，所以让我们跟踪定位，看看会发生什么情况。内部包装的最终以一个死循环结束了，每次迭代叫Kernel32 ！GetUserDefaultLCID。
从上面的图中，很清楚在这封闭不退出条件的情况下，代码是无用的。但黑匣子分析显示它确实在做一些东西。回到入口点，我仔细看代码，找到两个有意思的地方。
虽然在上面图 2 中有很多的代码之前有 “or eax，eax” 指令，但他们都是不更改值的寄存器 EAX，但此 UPX 封隔器在跳转到OEP（请参见下面的图 3）前指定一个指针从堆栈到EAV。如此，寄存器 EAX 是零文件加载时的 Windows 版本，如果该文件是解压缩，然后运行，此示例将知道它，并跳转到封闭环境。
另一段代码内的封隔器对 UPX 的存在没有额外的检查。为了满足这种检查，EAX 必须等于 ESP +0x11C，与由 UPX 存根 (stub) 代码初始化的 EAX 值匹配。
如果任一检查失败，它会导致一个死循环或未处理的异常。现在我们知道，调试或效仿此示例，在静态时UPX 存根 (stub) 代码不能被避免跳过。通过绕过或执行包括 UPX 存根 (stub) 代码，下面的恶意软件是最新透露的Bamital 恶意软件家族的成员。我也比较了的 包装与解压缩的 UPX的大小、，并注意很多不同大小的文件，所以我决定去挖掘更多。加密的文件下面占用了大文件的一部分，看起来像是充满了很多的铺垫。通过查找封隔器使用的加密，很显然它追加了吨的无用压缩代码来填充字节 （在本例中的 0x6A） 和 re-orders 整个缓冲区，以便压缩的代码看起来像融为一体的空白，使它看上去像垃圾数据，可以避免熵检查和其他类似的技术。
恶意软件作者可能有试用这种技术来避免检测，但我们也回应了他们。使用防病毒产品如MSE来处理好这种伎俩，我们检测到的恶意软件为Trojan:Win32/Bamital.I.
ps：终于第一次弄好了，英语荒废了，远不如前，大家凑活着看吧，有不对的地方欢迎指正。明天c语言考试，先看会书去
|
发表于 2011-6-30 14:34:23
微软用户表示无压力
楼主
所以我就把这个发了出来。
