反逆向工程揭密(试炼篇)-全文完,逆向工程,反跟踪技术 2008年06月23日 星期一 下午 02:10 Abstract Rather than doing another complete analysis of the binary, i will rather present the techniques i have used in the challenge, and how i have implemented them. The Scan of the Month 33 was released by the Honeynet Project in November 2004. I invite everyone to read the excellent submissions we received this month once they have read my paper. I am presenting the binary from the protection author point of view, while they presented it from the analyst point of view. You will learn the methods and techniques used to Protect / Unprotect a binary with this month's challenge. A lot of weaknesses were left on purpose in this binary and they will be presented here. Keywords: Software Protection; Reverse Code Engineering; Linux; Anti-Debugging; Anti-Anti-Debugging 摘要： 有人偏爱详细的分析过程，而我却喜欢从技术和实现方法的层面上去探讨。2004年的11月，The Honeynet Project发布了The scan of the month 33。 我推荐大家好好的研读一下。他们研究的就是前者。我除了对技术和实现方法进行研究外，大量的漏洞在我的文中也有披露。 关键词：软件保护；逆向工程；Linux;反调试；调试。 1. Introduction This month's challenge is to analyze an unknown binary, in an effort to reinforce the value of reverse engineering, and improve (by learning from the security community) the methods, tools and procedures used to do it. This challenge is similar to SotM 32. However, this binary has mechanisms implemented to make the binary much harder to analyze, to protect against reverse engineering. 1.简介： 最新的month 33挑战了一段未知的二进制代码，这对于我们加深逆向印象、改进方法、了解工具的使用及其整个过程具有积极的作用。这与先前发布的The scan of the month 32是相同的。唯一不同的是，此二进制代码更加难于分析。 Skill Level: Advanced/Expert All we are going to tell you about the binary is that it was 'found' on a WinXP system and has now be sent to you for analysis. You will have to analyse it in-depth and get as much information as possible about its inner working, and what is the goal of the binary. The main goal of this challenge is to teach people how to analyse heavily armored binaries. Such techniques could be used in the future, and its time to get used to them. 2. Identify and explain any techniques in the binary that protect it from being analyzed or reverse engineered 技术含量：中/高级 你将自己独立分析这些基于WinXP环境下的二进制代码。想完成挑战，你必须深刻的分析问题，搜集更多的信息去了解内部原理以及体会代码中包含 的目的。最终使你能够独立的分析一层又一层的代码。 2．鉴别并解释阻碍分析和逆向的技术。 Many techniques have been used in order to slow down analysis and break reverse engineers tools: ? PE Header Modifications Many fields of the PE header were modified in order to disturb analysing tools, and thus, the Reverse Engineer. I will quickly cover the most important changes: ->Optional Header Magic: 0x010B (HDR32_MAGIC) MajorLinkerVersion: 0x02 MinorLinkerVersion: 0x19 -> 2.25 SizeOfCode: 0x00000200 SizeOfInitializedData: 0x00045400 SizeOfUninitializedData: 0x00000000 AddressOfEntryPoint: 0x00002000 BaseOfCode: 0x00001000 BaseOfData: 0x00002000 ImageBase: 0x00DE0000 <--- "Non Standard" ImageBase SectionAlignment: 0x00001000 FileAlignment: 0x00001000 MajorOperatingSystemVersion: 0x0001 MinorOperatingSystemVersion: 0x0000 -> 1.00 MajorImageVersion: 0x0000 MinorImageVersion: 0x0000 -> 0.00 MajorSubsystemVersion: 0x0004 MinorSubsystemVersion: 0x0000 -> 4.00 Win32VersionValue: 0x00000000 SizeOfImage: 0x00049000 SizeOfHeaders: 0x00001000 CheckSum: 0x00000000 Subsystem: 0x0003 (WINDOWS_CUI) DllCharacteristics: 0x0000 SizeOfStackReserve: 0x00100000 SizeOfStackCommit: 0x00002000 SizeOfHeapReserve: 0x00100000 SizeOfHeapCommit: 0x00001000 LoaderFlags: 0xABDBFFDE <--- Bogus Value NumberOfRvaAndSizes: 0xDFFFDDDE <--- Bogus Value The "standard" ImageBase usually is 400000 for Win32 applications and Reverse Engineers are used to analyse programs with such an ImageBase. While it isn't a protection by itself, this simple modification will confuse some Reverse Engineers, because they aren't used to such memory addresses. 包括以下这些： （1）修改PE文件头： 目的：干扰工具的分析。附上重要的修改： ->Optional Header Magic: 0x010B (HDR32_MAGIC) MajorLinkerVersion: 0x02 MinorLinkerVersion: 0x19 -> 2.25 SizeOfCode: 0x00000200 SizeOfInitializedData: 0x00045400 SizeOfUninitializedData: 0x00000000 AddressOfEntryPoint: 0x00002000 BaseOfCode: 0x00001000 BaseOfData: 0x00002000 ImageBase: 0x00DE0000 <--- 非一般性基址 SectionAlignment: 0x00001000 FileAlignment: 0x00001000 MajorOperatingSystemVersion: 0x0001 MinorOperatingSystemVersion: 0x0000 -> 1.00 MajorImageVersion: 0x0000 MinorImageVersion: 0x0000 -> 0.00 MajorSubsystemVersion: 0x0004 MinorSubsystemVersion: 0x0000 -> 4.00 Win32VersionValue: 0x00000000 SizeOfImage: 0x00049000 SizeOfHeaders: 0x00001000 CheckSum: 0x00000000 Subsystem: 0x0003 (WINDOWS_CUI) DllCharacteristics: 0x0000 SizeOfStackReserve: 0x00100000 SizeOfStackCommit: 0x00002000 SizeOfHeapReserve: 0x00100000 SizeOfHeapCommit: 0x00001000 LoaderFlags: 0xABDBFFDE <--- 伪值 NumberOfRvaAndSizes: 0xDFFFDDDE <--- 伪值 400000作为Win32应用程序的一般基址，常常被逆向者在分析程序时使用。当程序不能保护自身时，这种简单的修改就可以对逆向工程造成影响， 因为程序并不使用这样的内存地址。 "Anti" OllyDbg: LoaderFlags and NumberOfRvaAndSizes were modified.. I have Reverse Engineered OllyDBG and Soft ICE to find a few tricks that could slow down the analysis of a binary. With those two modifications, Olly will pretend that the binary isn't a good image and will eventually run the application without breaking at its entry point. This could be a bad thing if you wanted to debug a mal ware on your computer, because you would get infected. 反OllyDbg: 通过修改LoaderFlags和NumberOfRvaAndSizes实现。逆向OllyDbg和SoftICE后，我们会发现这种方法可以阻碍二进制代码的分析，因为程序会认为 此二进制不是正确的基址，从而不在入口点处执行。导致直接的后果是：如果你调试一个病毒程序，你的计算机将会被感染。 Anti Soft ICE : Blue Screen of Death and no Chocolate: The NumberOfRvaAndSizes field has been modified in order to reboot any computer running a recent version of Soft ICE. While Disassembling the PE Loader of Soft ICE, i found a very critical vulnerability in Soft ICE that allows one binary to crash any computer running Soft ICE without any code execution. This vulnerability (bug) has been reported to Compuware and should be fixed in the next version. Apparently it didn't happen on some of the authors of the submissions for some reasons. Oh well. Here is the disassembly of Soft ICE PE loader to find out why it reboots your computer: .text:000A79FE .text:000A79FE loc_A79FE: ; CODE XREF: sub_A79B9 31j .text:000A79FE ; sub_A79B9 3Cj .text:000A79FE ; DATA XREF: .text:00012F9Bo .text:000A79FE sti .text:000A79FF mov esi, ecx .text:000A7A01 mov ax, [esi] .text:000A7A04 cmp ax, 'ZM' .text:000A7A08 jnz not_PE_file .text:000A7A08 .text:000A7A0E mov edi, [esi _IMAGE_DOS_HEADER.e_lfanew] .text:000A7A11 add edi, esi .text:000A7A13 mov ax, [edi] .text:000A7A16 cmp ax, 'EP' .text:000A7A1A jnz not_PE_file .text:000A7A1A .text:000A7A20 movzx ecx, [edi IMAGE_NT_HEADERS.FileHeader.NumberOfSections] .text:000A7A24 or ecx, ecx .text:000A7A26 jz not_PE_file .text:000A7A26 .text:000A7A2C mov eax, [edi IMAGE_NT_HEADERS.OptionalHeader.NumberOfRvaAndSizes] .text:000A7A2F lea edi, [edi eax*8 IMAGE_NT_HEADERS.OptionalHeader.DataDirectory] .text:000A7A33 mov eax, ecx .text:000A7A35 imul eax, 28h .text:000A7A38 mov al, [eax edi] ; CRITICAL BUG! One can force EAX EDI to be equal to zero. Reading at [0] in ring 0 isn't nice eh ;-) .text:000A7A3B .text:000A7A3B loc_A7A3B: ; DATA XREF: .text:00012FA5o .text:000A7A3B cli .text:000A7A3C call sub_15C08 .text:000A7A3C .text:000A7A41 mov byte_FA259, 0 .text:000A7A48 push eax ; Save EAX .text:000A7A49 mov eax, dword_16B56F ; EAX is modified by a saved dword .text:000A7A4E mov dr7, eax ; Debug Register 7 take the value in EAX .text:000A7A51 pop eax ; EAX is restored .text:000A7A52 mov dword_FC6CC, esp .text:000A7A58 mov esp, offset unk_FBABC .text:000A7A5D and esp, 0FFFFFFFCh .text:000A7A60 xor al, al ; AL is zeroed? Why this mov al, [eax edi] then ? .text:000A7A60 ; I don't see the point. old code? .text:000A7A62 call sub_4D2EB .text:000A7A62 .text:000A7A67 call sub_36AC1 .text:000A7A67 .text:000A7A6C xor edx, edx .text:000A7A6E .text:000A7A6E loc_A7A6E: ; CODE XREF: sub_A79B9 124j .text:000A7A6E call sub_74916 .text:000A7A6E 反SoftIce：蓝屏死机花屏： 修改NumberOfRvaAndSizes会令含SoftIce的系统重起。通过反汇编SoftIce装载器，我发现：无需代码执行，一个二进位的变动就可使一台含SoftIce的 电脑立刻崩溃。不过此漏洞已上报COMPUWARE并将在下一版本中改进。但是，由于某种原因，一些系统却运行正常。让我们来看一下反汇编后的SoftICE 装载器里到底有什么： .text:000A79FE .text:000A79FE loc_A79FE: ; CODE XREF: sub_A79B9 31j .text:000A79FE ; sub_A79B9 3Cj .text:000A79FE ; DATA XREF: .text:00012F9Bo .text:000A79FE sti .text:000A79FF mov esi, ecx .text:000A7A01 mov ax, [esi] .text:000A7A04 cmp ax, 'ZM' .text:000A7A08 jnz not_PE_file .text:000A7A08 .text:000A7A0E mov edi, [esi _IMAGE_DOS_HEADER.e_lfanew] .text:000A7A11 add edi, esi .text:000A7A13 mov ax, [edi] .text:000A7A16 cmp ax, 'EP' .text:000A7A1A jnz not_PE_file .text:000A7A1A .text:000A7A20 movzx ecx, [edi IMAGE_NT_HEADERS.FileHeader.NumberOfSections] .text:000A7A24 or ecx, ecx .text:000A7A26 jz not_PE_file .text:000A7A26 .text:000A7A2C mov eax, [edi IMAGE_NT_HEADERS.OptionalHeader.NumberOfRvaAndSizes] .text:000A7A2F lea edi, [edi eax*8 IMAGE_NT_HEADERS.OptionalHeader.DataDirectory] .text:000A7A33 mov eax, ecx .text:000A7A35 imul eax, 28h .text:000A7A38 mov al, [eax edi] ; EAX EDI=0则崩溃。权限0中读取[0]地址可不妙。 .text:000A7A3B .text:000A7A3B loc_A7A3B: ; DATA XREF: .text:00012FA5o .text:000A7A3B cli .text:000A7A3C call sub_15C08 .text:000A7A3C .text:000A7A41 mov byte_FA259, 0 .text:000A7A48 push eax ; Save EAX .text:000A7A49 mov eax, dword_16B56F ; 用双字修改EAX中值 .text:000A7A4E mov dr7, eax ; 寄存器7从EAX中取值 .text:000A7A51 pop eax ; 恢复EAX .text:000A7A52 mov dword_FC6CC, esp .text:000A7A58 mov esp, offset unk_FBABC .text:000A7A5D and esp, 0FFFFFFFCh .text:000A7A60 xor al, al ; AL取0?为什么要mov al, [eax edi]? .text:000A7A60 ; 不明白.原始代码? .text:000A7A62 call sub_4D2EB .text:000A7A62 .text:000A7A67 call sub_36AC1 .text:000A7A67 .text:000A7A6C xor edx, edx .text:000A7A6E .text:000A7A6E loc_A7A6E: ; CODE XREF: sub_A79B9 124j .text:000A7A6E call sub_74916 .text:000A7A6E As you can see from the code above, we can force Soft ICE to read at memory location [0] or something similar using a special value inside the PE header. For this binary i didn't bother calculating the exact value to read at address [0], that's may explain why it didn't crash for some people.I won't explain how to calculate this special value because it is trivial and i don't want Dark lords to use that trick without a little brainstorming. To fix this problems, one needs to patch the value in the PE Header. The standard value for NumberOfRvaAndSizes is 0x10.Just patch this value in the PE Header and the Soft ICE wrecking will be gone. The OllyDBG problem as well, because it is based on BOTH fields modifications. You can also nullify the other field if you want. 如你所见，我们可以令SoftIce读取[0]地址或其它特殊值。但我并不知道这时确切的数值，这可能与系统是否崩溃有关。我不想讨论怎样计算这 一特殊值，因为它与主题无关，另外也给大家留下讨论的空间。 你可以通过值的修改来修正这一问题。NumberOfRvaAndSizes的一般值为0x10。修改它。另外因为Olly和SoftIce都基于这种技术，因此你都可 以通过改变NumberOfRvaAndSizes的值或归0来搞定。 注：未完，有空会继续翻译，不知翻译的如何，欢迎大家提出宝贵意见，不胜感激。 ? Section Modification: Or how to kill many tools. ->Section Header Table 1. item: Name: CODE VirtualSize: 0x00001000 VirtualAddress: 0x00001000 SizeOfRawData: 0x00001000 PointerToRawData: 0x00001000 PointerToRelocations: 0x00000000 PointerToLinenumbers: 0x00000000 NumberOfRelocations: 0x0000 NumberOfLinenumbers: 0x0000 Characteristics: 0xE0000020 (CODE, EXECUTE, READ, WRITE) 2. item: Name: DATA VirtualSize: 0x00045000 VirtualAddress: 0x00002000 SizeOfRawData: 0x00045000 PointerToRawData: 0x00002000 PointerToRelocations: 0x00000000 PointerToLinenumbers: 0x00000000 NumberOfRelocations: 0x0000 NumberOfLinenumbers: 0x0000 Characteristics: 0xC0000040 (INITIALIZED_DATA, READ, WRITE) 3. item: Name: NicolasB VirtualSize: 0x00001000 VirtualAddress: 0x00047000 SizeOfRawData: 0xEFEFADFF <--- BIG Size of section on the disk. PointerToRawData: 0x00047000 PointerToRelocations: 0x00000000 PointerToLinenumbers: 0x00000000 NumberOfRelocations: 0x0000 NumberOfLinenumbers: 0x0000 Characteristics: 0xC0000040 (INITIALIZED_DATA, READ, WRITE) 4. item: Name: .idata VirtualSize: 0x00001000 VirtualAddress: 0x00048000 SizeOfRawData: 0x00001000 PointerToRawData: 0x00047000 PointerToRelocations: 0x00000000 PointerToLinenumbers: 0x00000000 NumberOfRelocations: 0x0000 NumberOfLinenumbers: 0x0000 Characteristics: 0xC0000040 (INITIALIZED_DATA, READ, WRITE) 节的修改：工具杀手。 ->Section Header Table （节头表） 条目1： Name: CODE VirtualSize: 0x00001000 VirtualAddress: 0x00001000 SizeOfRawData: 0x00001000 PointerToRawData: 0x00001000 PointerToRelocations: 0x00000000 PointerToLinenumbers: 0x00000000 NumberOfRelocations: 0x0000 NumberOfLinenumbers: 0x0000 Characteristics: 0xE0000020 (CODE, EXECUTE, READ, WRITE) 条目2： Name: DATA VirtualSize: 0x00045000 VirtualAddress: 0x00002000 SizeOfRawData: 0x00045000 PointerToRawData: 0x00002000 PointerToRelocations: 0x00000000 PointerToLinenumbers: 0x00000000 NumberOfRelocations: 0x0000 NumberOfLinenumbers: 0x0000 Characteristics: 0xC0000040 (INITIALIZED_DATA, READ, WRITE) 条目3： Name: NicolasB VirtualSize: 0x00001000 VirtualAddress: 0x00047000 SizeOfRawData: 0xEFEFADFF <--- 大容量的节 PointerToRawData: 0x00047000 PointerToRelocations: 0x00000000 PointerToLinenumbers: 0x00000000 NumberOfRelocations: 0x0000 NumberOfLinenumbers: 0x0000 Characteristics: 0xC0000040 (INITIALIZED_DATA, READ, WRITE) 条目4： Name: .idata VirtualSize: 0x00001000 VirtualAddress: 0x00048000 SizeOfRawData: 0x00001000 PointerToRawData: 0x00047000 PointerToRelocations: 0x00000000 PointerToLinenumbers: 0x00000000 NumberOfRelocations: 0x0000 NumberOfLinenumbers: 0x0000 Characteristics: 0xC0000040 (INITIALIZED_DATA, READ, WRITE) From those informations, we can conclude a few things. First, the binary doesn't seem to be compressed, because the Virtual Address and Size matche the Raw Offset and Size at one exception, the NicolasB section. This section has an extremly big size of raw data, which will crash a few tools and make a few others very very slow. 通过以上信息，我们可以推断出以下一些结论。1。二进制代码未被压缩，因为除了NicolasB，其它节的Virtual Address= the Raw Offset，Virtual Size= Raw Size。NicolasB节包含了巨大的raw数值，这将使进行逆向的工具崩溃或受到阻碍。 |
|小黑屋|最新主题|手机版|微赢网络技术论坛
( 苏ICP备08020429号 )
GMT+8, 2024-9-30 01:39 , Processed in 0.195167 second(s), 12 queries , Gzip On, MemCache On.
Powered by Discuz! X3.5
© 2001-2023 Discuz! Team.
