x-> Emulation: Transposition of Control (From Anti-Virus to Virus) <-x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Released: 15 March 2012 x Zine: Valhalla #2 x Author: m0s6581/EOF x Source: win32.evenstar (released in Valhalla #2) x xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx “If I read as many books as most men do, I would be as dull-witted as they are.” - Thomas Hobbes, Leviathan xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Contents: I Synopsis II Structure of the emulator III Self-referencing IV Intercommunication V Limitations VI Afterthoughts xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [+] Synopsis [+] In the last few years, sandboxing and emulation have become vital for anti- virus detection mechanisms. By a rather shaky definition, emulation is composed of two different execution environments, one of which has a control over the other. AV emulators generally have two separated CPUs and thread contexts, despite running on only one thread. It is possible to harness the power of emulation for the purpose of securing a virus payload (or body) code. Emulation can also be used to increase the complexity of reverse engineering (especially debugging). An obvious red flag would be common decryption loops: once control is passed to the payload, it becomes easier for the AV to perform analysis on the decrypted image. Hence, it also becomes possible to reduce heuristic analysis through the use of an emulator. win32.evenstar utilizes a prototype x86 pseudo-emulator. The virus body is encrypted instruction by instruction using a basic xor algorithm, although it is certainly possible to install a more sophisticated encryption scheme. This is a basic layout of a PE infected by evenstar: [headers][section n][last seg + virus] The last segment is expanded to store both the emulator and the virus body: [original data][padding][emulator][body] xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [+] Structure [+] The evenstar dropper utilizes mlde32 to produce a table of opcode lengths, that is later used by the encrypter and emulator. An instruction is copied from the encrypted execution buffer to a temporary buffer where it is decrypted and analyzed. Any ip-manipulating instructions are not executed directly, instead only the eip of the debuggee is changed. Any other instruction is executed, followed by an exception. Here is a depiction of the emulation algorithm: (Get Instruction) -> (Decrypt Instruction) v (Analysis) (Regular Instruction)<- -> (eip-manipulation) -> (Proper Execution) -> (Call/ret) -> (Access Violation) -> ([non]conditional jmp) The decrypted and isolated execution buffer looks something like this: 0x10000 lea eax, DWORD PTR ds:[edx + 05f6h] 0x10005 e8 00 00 00 00 ; call delta 0x10009 int 3 0x1000A jmp [invalid] The first instruction was copied directly from the encrypted payload to this buffer. It will be executed in the context of the debuggee. The second instruction is a simple delta, used for an internal purpose of the emulator. Lastly, the 0xcc, interrupt vector 3 instruction is caught by the SEH, to ensure proper execution of the instruction. Just a side note: If it is required to install a custom SEH routine, then just be aware that if a binary is compiled with /safeseh, it will execute only the specific exception handlers written in the Load Config Directory of the PE header. Zero'ing this table will disable SafeSEH and the OS will call your handler. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [+] Self-referencing [+] An obviously vital component in any virus is the ability to replicate. As such, the virus must be able to copy its own body to another buffer. The scheme in evenstar complicates this problem because nothing in the payload is decrypted at one particular time, and the current execution instruction is in another buffer. Therefore, a mechanism must exist that will allow for the virus body to modify or read its own code, despite the encryption. The evenstar emulator first copies an instruction to the execution buffer (where the instruction is physically executed - isolated from the entire encrypted payload) and then sets a NO_ACCESS permission using VirtualProtect on the execution page (where the payload is). Let us assume that this is the encrypted payload code: ; Offset ; Length nop ; 0 ; 1 call delta ; 1 ; 5 delta: nop ; 6 ; 1 pop ebx ; 7 ; 1 ; ebx now contains the address 0x6 [nop] mov BYTE PTR al, [ebx] ; 8 ; Exception occurs at eip 0x8. Access Violation at address 0x6. ebx contains the address within the encrypted buffer, because the emulator injects a return address into the debuggee stack (remember that call/ret is emulated). Once an 8 bit read operation is attempted at the address referenced by ebx, an Access Violation exception is generated because of the prior NO_ACCESS set on that page. The SEH routine installed by the emulator catches the exception and routes it to the appropriate handler. The handler finds the EXCEPTION_RECORD structure at [esp + 4] and the faulting address at offset 0x18. Next, only the instruction pointed by [ebx] (in this case, nop), is decrypted. The handler then sets PAGE_READONLY on the execution page. Of course, the handler is in the context of the debuggee, not the emulator, so it then restores the debuggees pre-exception context and executes the same instruction again. This time no Access Violation exception will occur and the data will be read into al. Once the instruction is executed, the int 3 will ensure the emulator that the copy was successful. The handler will then encrypt whatever data was left exposed and set NO_ACCESS on the execution page, finally restoring the debuggees context and returning to the context of the emulator. The emulator therefore generates 1-2 exceptions per execution of instruction. This, I thought, would be slow, and it most certainly is - when a debugger is attached. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [+] Emulator/Virus Intercommunication [+] During the development of evenstar, it was required to build a communication bridge between the virus payload and the emulator. This may serve several purposes: 1) For the Virus to determine information about the environment that it is running in. For example, where the emulator code is located so that it can be copied to another binary. 2) So that the virus body does not need to resolve API, it can just ask the VM for a pointer to a structure containing functions. 3) When the virus body is completed its task and wishes to return to the host. This is made possible because the emulator knows of the return address, not the virus. Here is an example of the payload code: mov eax, signal call eax The emulator will read the signal stored in the debuggees eax register, and return some information back, either in a register, or on the stack. This allows for proper functioning of the payload, but it can also be used to make the x86 payload similar to bytecode, and to use the emulator as an interpreter. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [+] Limitations [+] A rather serious limitation and weakness of win32.evenstar is the encryption routine. The encryption routine works by using a 32-bit xor key that is rotated relative to the instruction length. However, a table must be built in order to decrypt the instructions appropriately. It is easy to script and unpack the payload, effectively bypassing the emulator. Then again, any routine, no matter how complex, can be eventually reversed by a human. Another limitation of the current emulator is its inability to use instructions like 'rep movsb', where esi is pointing to the encrypted payload. This is because the emulator doesn't contain a full disassembler, and is unable to determine the functionality of every instruction. Finally, the emulator itself is not encrypted and can thus be detected. This is only a limitation within win32.evenstar itself. The emulator is designed to be modular, so any form of encryption will work. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx [+] Afterthoughts [+] The emulation technique used in win32.evenstar shows us that the AV can never be smart enough to figure out how to decrypt the whole payload. It will, however, run the emulator code perfectly, assuming it can get past the exceptions generated by the emulator. Because only the emulator code and only one instruction is plaintext, the AV will find it impossible to ever read what is hidden in the payload. This allows for more sophisticated intercommunication that will allow for the emulator to detect sandboxing, and effectively alter the execution path of the payload. Further, it is possible to create a polymorphic code generator to build the emulator. We would receive several benefits from this: + The emulator code would be difficult to detect + The polymorphic engine would be protected by the emulator and crypter This dual operation between the emulator and mutation engine would make AVs job a whole lot harder.