【ChinaBeta.Cn 网盟学院】
通过以上信息，我们可以推断出以下一些结论。1。二进制代码未被压缩，因为除了NicolasB，其它节的Virtual Address= the Raw Offset，Virtual Size= Raw Size。NicolasB节包含了巨大的raw数值，这将使进行逆向的工具崩溃或受到阻碍。
IDA will try to allocate a LOT of memory because it thinks that the section is THAT big, turning your computer into a very slow turtle ;-). Eventually, it will load the file, or run out of memory, depending of the computer you are using to do the analysis. This modification will also create havoc with many tools such as Objdump, PE editor, some memory dumpers etc. It is very easy to fix this problem, you need to correct the Raw Size. If you look at the section following this special one, you will find that it starts at the very same Raw Offset. This means that the other section is actually null on the disk. You can therefore, safely replace the big value by zero.
当节包含巨大数值时，IDA会分配大量的内存空间，这将使你的计算机运行缓慢。事实上，是装载文件或是内存溢出，都取决于正在用来分析的电脑性能。另外，这种修改还会对许多工具如Objdump,Peeditor,一些内存Dumper等产生严重破坏。不过修正这个问题很简单，只要修改一下Raw Size即可。尽管你发
现某个节与其它不同，但是它们仍然是具有相同的Raw Offset. 这就意味着，如果其它节是空的，处于安全考虑，你可以把特殊的那个节也取空。
Protection Weakness:
While writing this binary, i knew people were going to patch the PE header but i didn't do any integrity checks on purpose. Originally i wanted to use the value in the PE Header as keys to decrypt a few layers of the protection, and the result would have been an unworking binary if this one had been changed. I have also changed a few other things in the PE header, but nothing of real interest here. (who said Cosmetic?)
保护漏洞：
当我贴出这些代码时，许多人都会去对PE头进行修正，可我不是这样做的。最初，我想利用PE Header中的数值作为打开保护层的钥匙，但是一旦改变数值，它就变成了一段无效的二进制代码。另外我还试着修改其它地方，可都一无所获。
? Junk Code
All along the binary, i have added junk code between real instructions, in order to make the analysis a little harder. The junk code are long blocks of code that does nothing but fancy operations to disturb the analyst , especially when he choose to do a static analysis of the binary. Each block of Junk Code is different and have been generated by a personal tool. A Thrash generator which creates macros to be inserted in the code source around
real instructions. Here is how it looks inside a disassembler: The junk code starts with a pushad (save all registers states onto the stack) and finish with a popad (restore register states).Here is the end of a block of junk:
垃圾代码
在真正的代码中，我添加了一些垃圾代码，这是为了增加分析的难度。它们冗长无意义，但是可以阻止分析的进行，特别是静态分析时。而每一个又各不相同，由独立的工具产生。一个好的程序会把这种代码大量的运用于真正的代码之中。以下是我们在反汇编器中所看到的：垃圾代码以pushad开头（在堆栈中保存所有寄存器状态）并以popad（恢复寄存器状态）。这是它们的尾部：
Protection Weakness:
The thrash generator isn't perfect (at least with the options i have used here ;) and it is easy to find the start and the end of a block of junk code. The junk code is bounded by pushad/popad. When i wrote this binary i was aware of this problem, but this is a perfect real life example of protection weakness. It allows Reverse Engineers to practice IDA/Ollydbg scripting. Very interesting scripts were found in the submissions. I invite you to have a look at them if you didn't know how to write one. When i wrote the binary, i already had a better version of my Thrash generator that doesn't use any pushad/popad around the blocks of useless code, but we will keep it for another challenge, if any.
保护漏洞：
这个程序不是完美的，你很容易找到垃圾代码的头和尾。即pushad/popad。当我写这段代码时想过这个问题，但这确实是最典型的保护漏洞。逆向者用它来练习IDA/Ollydbg脚本会非常有趣。如果你不会，建议你去了解一下。当我完成这个程序后，我又写了更好的非典型漏洞的版本，这是后话了。
? SEH - Structured Exception Handling
Windows SEH were used extensively in this binary. It allows one to access the context structure of the current application, and therefore, access privileged registers such as Debug Registers. Those registers are used by Hardware Breakpoints (BPM). If you can access them, you can also erase the hardware breakpoints.
SEH-结构异常链
SEH被广泛地运用在二进制代码中。它允许你访问当前应用程序的context structure和优先级寄存器（调试器）。这些寄存器被硬件断点(BPM)所使用。因为可存取，因此这些硬件断点也可被擦除。
? Timing Detection Through SEH
Here is a little detection i invented to detect debuggers. If we merge SEH (And access to context structure) with the known Timing Detection Technique, we can detect a lot of Ring 3 debuggers and Tracers. The idea is to read the Time Stamp Counter using RDTSC (number of cycles executed by the CPU basically) and then generating an Exception.
通过SEH侦测时间
这是一个侦测调试器的程序。当我在SEH（存取context structure）中加入时间侦测技术后，可以发现：许多Ring 3级别的调试器和追踪器都可以被侦测到。原理是通过RDTSC（CPU执行数字循环）读取了Time Stamp Counter(TSC)寄存器然后产生一个异常。
In the exception handler, we can access the EAX register (previously modified by RDTSC) in the Context Structure, which contains the TSC. In the Exception Handler, we use RDTSC one more time, to get the current TSC value. Now, we can compare both TSC to see whether the program has been debugged/traced or not. If such an action has occured, the difference of cycles will be huges, thus triggering the Payload.
In this binary, i just modified EIP through the context structure. The application resumes at a different location skipping mandatory instructions.The application crashes eventually. It seems that on some version on Windows, it doesn't work as expected because of the
utilisation of the CPUID instruction, that will modify the ECX register.
在异常处理程序中，我们可以访问Context Structure中的EAX寄存器（先前被RDTSC修改），里面包含了TSC的值。在异常处理程序里，我们在执行一次RDTSC得到当前TSC的数值。现在，我们比较这两个TSC，看是否程序被调试/跟踪。如果调试/跟踪，两者值会有巨大差距，导致最终被发现。虽然我修改了context structure中EIP的数值，使得程序跳过强制指令定位到新的位置。可是最终程序仍然崩溃。可以看出Windows中的一些版本，因为CPUID指令修改了ECX寄存器而并不象我们想象中的那样运行。
The detection became less stealth because of this "bug", but it would still have been a matter of time until someone discovered it anyway. Many people wondered why i used CPUID in the program before RDTSC. The reason is that on recent CPU such as P4, there is a feature called: Out of Order Execution. The CPUID is a synchronization instruction which tells to the CPU not to use Out Of Order execution, avoiding False Positives in the debugger detection. If you don't tell to the CPU not to use OOO execution, you don't know in which order the CPU is going to execute your code. It can be different from your source code. Sometimes, it will create a false positive and your program will crash for no reason.
Here is the code of this detection: E0000h is the maximum cycles difference accepted by this detection. If the number is bigger, then a debugger is most likely running and debugging our application.
尽管此侦测的原理有了一些进展，但仍然有很多需要去发觉。许多人奇怪为什么CPUID使用在RDTSC之前。因为现在的CPU（如P4）具有被称之为“Out of Order Execution”的功能。CPUID是一个同步指令，，它会禁止CPU使用Out of Order功能。否则你将不知道你的代码执行的顺序，可能与你的原代码的执行顺序不一样，也许会使系统莫名其妙的崩溃。下面是侦测的代码：E0000H是时间差的上限。如果超过这个上限，说明可能有调试器在调试我们的程序。上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] 下一页
（责任编辑：hahack）
|
[软件应用]凤凰涅槃 驱动精灵2008归来 (01-03)
