[cb22] Under the hood of Wslink’s multilayered virtual machine en by Vladislav Hrčka
•Als PPTX, PDF herunterladen•
0 gefällt mir•8 views
In October 2021, we published the first analysis of Wslink – a unique loader likely linked to the Lazarus group. Most samples are packed and protected with an advanced virtual machine (VM) obfuscator; the samples contain no clear artifacts and we initially did not associate the obfuscation with a publicly known VM, but we later managed to connect it to CodeVirtualizer. This VM introduces several additional obfuscation techniques such as insertion of junk code, encoding of virtual operands, duplication of virtual opcodes, opaque predicates, merging of virtual instructions, and a nested VM. Our presentation analyzes the internals of the VM and describes our semi automated approach to “see through” the obfuscation techniques in reasonable time. We demonstrate the approach on some bytecode from a protected sample and compare the results with a non-obfuscated sample, found subsequent to starting our analysis, confirming the method’s validity. Our solution is based on a known deobfuscation method that extracts the semantics of the virtual opcodes, using symbolic execution with simplifying rules. We further treat the bytecode chunks and some internal constructs of the VM as concrete values instead of as symbolic ones, enabling the known deobfuscation method to deal with the additional obfuscation techniques automatically.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie [cb22] Under the hood of Wslink’s multilayered virtual machine en by Vladislav Hrčka
Ähnlich wie [cb22] Under the hood of Wslink’s multilayered virtual machine en by Vladislav Hrčka (20)
Mehr von CODE BLUE
Mehr von CODE BLUE (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
[cb22] Under the hood of Wslink’s multilayered virtual machine en by Vladislav Hrčka
- 1. Under the hood of Wslink’s multilayered virtual machine Vladislav Hrčka | Malware Researcher
- 2. Vladislav Hrčka Malware Researcher at ESET @HrckaVladislav
- 3. Agenda •Intro to VMs in general and symbolic execution •Internals of the VM used in Wslink •Our approach to dealing with the obfuscation •Demonstration of the approach
- 4. Process VMs basics • Interpreter executes the bytecode • Bytecode contains instructions with: • Opcodes • Operands • Handlers define individual opcodes
- 7. Symbolic execution in Miasm • Expresses the code in mathematical formulas • Registers and memory are treated as symbolic values • Summarizes the code’s effects on the symbolic values • We will frequently use it • Original ASM: MOV EAX, EBX MOV ECX, DWORD PTR [EDX] XOR ECX, 0x123 MOV AX, WORD PTR [ESI] JMP ECX • Performed symbolic execution: EAX = {@16[ESI] 0 16, EBX[16:32] 16 32} ECX = @32[EDX] ^ 0x123 zf = @32[EDX] == 0x123 nf = (@32[EDX] ^ 0x123)[31:32] ... EIP = @32[EDX] ^ 0x123 IRDst = @32[EDX] ^ 0x123
- 8. Symbolic execution in Miasm • Allows us to simply apply known concrete values • Concrete values can simplify the expressions • Performed Symbolic execution: EAX = {@16[ESI] 0 16, EBX[16:3… ECX = @32[EDX] ^ 0x123 zf = @32[EDX] == 0x123 nf = (@32[EDX] ^ 0x123)[31:32] ... EIP = @32[EDX] ^ 0x123 IRDst = @32[EDX] ^ 0x123 • Applied EDX = 0x96 and @32[0x96] = 0xFEED: EAX = {@16[ESI] 0 16, EBX[16:3… ECX = 0xFFCE zf = 0x0 nf = 0x0 ... EIP = 0xFFCE IRDst = 0xFFCE EDX = 0x96 @32[0x96] = 0xFEED
- 11. • A virtualized function • Virtualized functions contain: • Prologue • Call to VM entry • Gibberish code Wslink: First contact
- 12. Junk code
- 13. Overview of the VM’s structure
- 14. Overview of the VM’s structure
- 15. • Prepares the next virtual instruction • Increases VPC (virtual program counter) • Zeroes out a register • RBP_init is context pointer • Instruction table at offset 0xA4 • VPC at offset 0x28 VM2: The first executed virtual instruction
- 16. •Instruction 2 • Zeroes out several virtual registers •Instruction 3 • Stores RSP in a virtual register VM2: Virtual instructions 2 and 3
- 17. VM2: Virtual instruction 4 • Multiple basic blocks:
- 18. • Multiple basic blocks: VM2: Virtual instruction 4 • Summary of the first block – memory assignments and IRDst:
- 19. • Multiple basic blocks: VM2: Virtual instruction 4 • Summary of the first block – memory assignments and IRDst:
- 20. • Multiple basic blocks: VM2: Virtual instruction 4 • Summary of the first block – memory assignments and IRDst: • Rolling decryption – encryption of operands • Values of virtual registers at offsets 0x0B and 0x70 were set earlier
- 22. VM2: Virtual instruction 4 - deobfuscation • The first original block
- 23. VM2: Virtual instruction 4 - deobfuscation • The first original block
- 24. VM2: Virtual instruction 4 - deobfuscation • The first original block • Application of known values of the rolling decryption registers • Application of known bytecode values reveals POP IRDst = (-@16[@64[RBP_init + 0x28] + 0x4] ^ 0x3038 == @16[@64[RBP_init + 0x28] + 0x6])?(0x7FEC91ABD1C,0x7FEC91ABCF6) @64[RBP_init + {-@16[@64[RBP_init + 0x28] + 0x4] ^ 0x3038, 0, 16, 0x0, 16, 64}] = @64[RSP_init] IRDst = @64[@64[RBP_init + 0xA4] + 0x5A8] @64[RBP_init + 0x28] = @64[RBP_init + 0x28] + 0x8 @64[RBP_init + 0x141] = @64[RBP_init + 0x141] + 0x8 @64[RBP_init + 0x12A] = @64[RSP_init]
- 25. • Virtual instruction 4 summary: VM2: Deobfuscating bytecode chunks IRDst = @64[@64[RBP_init + 0xA4] + 0x5A8] @64[RBP_init + 0x28] = @64[RBP_init + 0x28] + 0x8 @64[RBP_init + 0x141] = @64[RBP_init + 0x141] + 0x8 @64[RBP_init + 0x12A] = @64[RSP_init]
- 26. • Build a graph from summaries • Treat some values as concrete: • Rolling decryption registers • Memory accesses relative to the bytecode pointer • Preserve only decryption registers’ values between blocks VM2: Deobfuscating bytecode chunks • Virtual instruction 4 summary: IRDst = @64[@64[RBP_init + 0xA4] + 0x5A8] @64[RBP_init + 0x28] = @64[RBP_init + 0x28] + 0x8 @64[RBP_init + 0x141] = @64[RBP_init + 0x141] + 0x8 @64[RBP_init + 0x12A] = @64[RSP_init] virtual_instruction2_1(vpc) virtual_instruction2_2(vpc) virtual_instruction2_1(vpc) virtual_instruction2_3(vpc) virtual_instruction2_4(vpc)
- 27. VM1: Deobfuscated virtual instruction structure CFG
- 29. VM1: Deobfuscated virtual instruction structure OUTRO CFG INTRO
- 30. OUTRO CFG INTRO
- 31. CFG INTRO Legend: Yellow – Push virtual registers Red – Pop virtual registers; switch context Green – Jump to register OUTRO
- 32. • Virtual instructions 1, 2, 3 • The same behavior as in VM2 VM1: Initially executed virtual instructions
- 33. VM1: Virtual instruction 4
- 34. VM1: Virtual instruction 4 • Instruction merging – contains, e.g., POP and PUSH operations • Operands decide which instruction is executed • PUSH:
- 35. VM1: Virtual instruction 4 • Instruction merging – contains, e.g., POP and PUSH operations • Operands decide which instruction is executed • POP:
- 36. • Instruction merging – contains, e.g., POP and PUSH operations • Operands decide which instruction is executed • PUSH/POP • Can be simplified by making the operands concrete VM1: Virtual instruction 4
- 37. VM1: Deobfuscating bytecode chunks • Use the same approach as in VM2: • Build a graph from summaries • Treat certain values as concrete • Preserve certain values between blocks • Process both VMs at once: • Additionally make the entire VM2 concrete • Ignore assignments to the VM2 context virtual_instruction2_1(vpc) virtual_instruction2_2(vpc) virtual_instruction2_1(vpc) virtual_instruction2_3(vpc) virtual_instruction2_4(vpc)
- 38. Resulting graph contained unexpected branches instead of a series of POPs VM1: Issue with opaque predicates during deobfuscation
- 39. VM1: Issue with opaque predicates during deobfuscation •The branches check a known value • We can apply the value and simplify it • This is a sort of opaque predicates
- 40. Does the approach work?
- 41. Analyzing results Bytecode block VM1 VM2 Size in bytes 695 1,145 Total number of processed virtual instructions 62 109 Total number of underlying native instructions 3,536,427 17,406 Total number of resulting IR instructions (including IRDsts) 192 307 Execution time in seconds 382 10
- 42. NON-OBFUSCATED SAMPLE* Processed ServiceMain bytecode OBFUSCATED
- 43. DEOBFUSCATED
- 44. ORIGINAL SAMPLE DEOBFUSCATED SIMPLIFIED mov R0, [R0] mov R1, 28
- 45. lea R2, BASE+0xE3808 ORIGINAL SAMPLE DEOBFUSCATED SIMPLIFIED
- 48. ORIGINAL SAMPLE DEOBFUSCATED lea R2, BASE+0x2FB0 mov R3, R0 SIMPLIFIED
- 49. ORIGINAL SAMPLE DEOBFUSCATED SIMPLIFIED lea Rdest, BASE+0x8C038
- 50. ORIGINAL SAMPLE DEOBFUSCATED lea Rdest, BASE+0x8C038 ... jmp Rdest RETaddr = &vm_pre_initX()
- 51. •Symbolic execution cannot process unbounded loops Limitations • Instructions using such loops need to be addressed by other means
- 52. Symbolic execution can help devirtualize advanced unknown VMs in a reasonable time if we treat the right values as concrete Takeaway
- 53. Links You can read the whitepaper at WeLiveSecurity.com Full source code is available in ESET git repository
- 54. www.eset.com | www.welivesecurity.com | @ESETresearch Vladislav Hrčka Malware Researcher vladislav.hrcka@eset.com | @HrckaVladislav Questions?
Hinweis der Redaktion
- Subsequently to starting our analysis found a non-obfuscated sample – we weren’t motivated to fully deobfuscate the code
- Since 2017 been focusing on reverse engineering challenging malware samples Computer Science student at the Comenius University in the first years of master’s degree BlackHat Arsenal, AVAR
- Work like standard machines – machine code is bytecode here PC is offset to the bytecode here – not necessary Transfer of control from one virtual instruction to the next during interpretation needs to be performed by every VM. This process is generally known as dispatching Centralized interpreter – dispatcher – called direct call threading; can be also simple switch case Can be also inside of handlers – direct threading
- Stored in sep.arate section Need context switch Bytecode is generated from a function Original function starts interpreter Interpreter is embedded in the executable Context switch needs to be performed Stored in a separate section Need context switch Bytecode is generated from a function Original function starts interpreter Interpreter is embedded in the executable Context switch needs to be performed
- The strength of this obfuscation technique resides in the fact that the ISA of the VM is unknown to any prospective reverse engineer – a thorough analysis of the VM, which can be very time-consuming; Additionally, obfuscating VMs usually virtualize only certain “interesting” functions
- SE in IR IRDst 1. stands for 2. is IR instruction pointer, e.g. cmov multiple blocks X bit value dereference Self explainable dereference
- SE engine in Miasm automatically performs common optimization techniques
- The VM used in the Wslink is a variant of CV (themida) that supports multiple VMs and polymorphic layers of obfuscation techniques. We found this out subsequently to publishing our research
- The right side contains a part of the function
- Why 1071? They are duplicated! Vm_init – Sync – shared virtual context in the memory Virtual program counter (VPC) register Base address register Instruction table register
- Zdorazni nested VM – zacneme VM2
- Rolling decryption – present in a blog about VM Protect’s structure
- Make values relative to the bytecode ptr concrete
- We’ve just deobfuscated one of the VM1 instructions
- Let’s start with CFG
- Reminder – atomic operations in blocks
- Laser point – These IR blocks are effects of VM2 virtual instructions, they represent one VM1 virtual instruction together
- Zeroes out a register, stores the RSP, initializes rolling decryption registers
- A part of the instruction. When we inspected the code, we realized what the problem is
- Memory range of the VMs is known – separate section
- Let’s take a closer look at one of the branches <CLICK>
- The branches check a known value We can apply the value and simplify it This is a sort of opaque predicates
- We will show the results on the first executed bytecode, but before that show statistics
- Before we look at the devirtualized bytecode, let’s see what the execution time is approximately like Let’s look at the deobfuscated bytecode block of VM1 <CLICK>
- *We discovered the sample after starting our analysis
- No ARM R0! – pseudocode close to assembly
- Advanced – use junk code, duplicate and merge handlers, encrypt operands Right values – operands and registers for encryption