Analysis of BPE32 polymorphism Engine

Autor: nEINEI
E-mail: neineit@gmail.com
Date: 2008-11-10

1. BPE32 Introduction
Ii. Technical Details Analysis
2.0 -- Overall Process Design
2.1 -- random number Design
2.2 -- code encryption Solution
2.3 -- SEH design against VM
2.4 -- Random Number Generation and register Selection
2.5 -- generation of junk commands
2.6 -- encryptor Design
2.7 -- re-build command process
3. Code Parsing
IV detection plan

1. BPE32 introduction:
BPE32 (Bennys Polymorphic Engine for Win32) is a virus polymorphism Engine released by Bennys/29A in #4, and then compiled in the virus, such as (such as Win32.Vulcano) and shell programming (such as ASProtect) have been used, BPE32 is a very good multi-state engine, here we will analyze the engine from the design perspective.

According to Bennys, The BPE32 engine has the following features:
1. You can create a SHE to interfere with some AV
2 random use of registers for code obfuscation
3. The same function code is dynamically generated by different commands.
4. The function code has a random spatial distribution.
5. Simulate CALL and jmp commands
6. Insert junk commands between codes (including using undisclosed SALC commands)

Let's take a look at the input parameters for BPE32 calls,
ESI -- point to the virus data to be encrypted.
EDI-points to a piece of memory data, which is used to store the encryptor generated by BPE32 and encrypted data.
ECX: the count of the encryption and decryption data. The encryption and decryption operations are performed in 4 bytes. The data is obtained by the formula (_ end-start + 3)/4.
EBP -- used for relocation.
Output parameters,
EAX-the size of the decoder plus encrypted data, which is not aligned and accurate to 1 byte instead of a DWORD
The call method is simple, for example:
Mov esi, vir_body; Virus
Mov edi, pmem; memory space
Mov ecx, 6c0h; decryption count
Call BPE32
In this way, after the call, pmem contains a re-built virus code.
The following describes the detailed technical details.
Ii. Technical Details Analysis
2.0 Process Design:
After BPE32 is called, the following three functional codes are generated in the memory:
/------- + -------------------- +
| Call decryptor | ---------> @ 1
| + -------------------- +
|
| Encryptvirus body | ---------> @ 2
|
------> | -------------------- +
|
| Decryptor |
| ---------> @ 3
+ -------------------- +
@ 1 is a call constructed by computation, because the call location must be determined by @ 2.
@ 2 is an encrypted virus.
@ 3 is an encryptor used to decrypt @ 2, which is transformed by code obfuscation.
In this way, every time other files are infected, the re-generated code will no longer have a fixed feature, which will invalidate the feature scanning mechanism.

2.1 random number design:
The random number part of BPE32 is designed very easily. The RDTCS command is used to generate a random number. The parameter X in the stack generates a 0 ~ A number between X-1, Which is returned directly when the parameter is 0.
Random proc
Push edx
RDTCS
Xor edx, edx; nulify EDX, we need only EAX
Cmp [esp + 8], edx; is parameter = 0?
Je r_out; yeah, do not truncate result
Div dword ptr [esp + 8]; divide it
Xchg eax, edx; remainder as result
R_out: pop edx; restore EDX
Ret Pshd; quit procedure and destroy pushed parameter
Random endp

2.2 code encryption scheme:
BPE32 uses the encryption scheme to generate two random numbers, one as the key B _key (constant number), and the other as the incremental key I _key (added after each operation). Each time the B _key + I _key, then, xor implements a DWORD for the data to be encrypted as follows:

Push 0; generate a random number without index range
Call random
Xchg edx, eax
Mov [ebp + xor_key-mgdelta], edx; storage base key
Push 0; generate a random number without index range
Call random
Xchg ebx, eax
Mov [ebp + key_inc-mgdelta], ebx; stores incremental keys
X_loop: lodsd; encrypt virus body
Xor eax, edx
Stosd
Add edx, ebx
Loop x_loop

2.3 SEH design against VM:
The @ 3 Section mentioned in the preceding section is actually composed of the following parts:
+ ------------------ + <--------
| Seh handler |
+ ------------------ + |
| Deleta geter |
+ ------------------ + |
| Decryption |
+ ------------------ + |
| Loop decryptor | ---------/
+ ------------------ +
Seh handler -- install a seh processing process.
Deleta geter -- because the @ 3 part is randomly filled by spam instructions, a relocation is required after each loop.
Decryption-decryption part, which is also surrounded by junk commands.
Loop decryptor -- jump to seh handler.
The following code is generated for SEH BPE32:
Start:
Call end_seh_fn
/----> Mov esp, [esp + 8]; --> equivalent to push seh-> handler
| Jmp seh_rs
| End_seh_fn:
| Sub edx, edx
| Push dword ptr fs: [edx]; --> equivalent to push seh-> prev
| Mov fs: [edx], esp
----- Inc byte ptr [edx]; --> this exception is thrown and jumps to the preceding statement.
Jmp start
Seh_rs: xor edi, edi
Pop dword ptr fs: [edi]
Pop edi
In this way, if the server guard that uses the vm technology does not perform seh simulation, the simulation will fail and detection cannot be completed. The jmp start statement is also very important, some aver will implement the command prefetch function (For details, refer to the article anti-heuristic Code Simulation Detection Technology Analysis), which will cause another aver to fall into an endless simulation loop.

2.4 Random Number Generation and register Selection
BPE32 generates a random register index through the get_reg function, that is, 0 ~ If EAX (0) and ESP (100b) are not used, EBP (101b) is used outside the call:
Get_reg proc
Push 8; generate a random 0 ~ Integer between 7
Call random
Test eax, eax
Je get_reg; eax cannot be used
Cmp al, 100b; esp cannot be used
Je get_reg
Ret
Get_reg endp
2.5 Generation Method of spam commands:
BPE32 generates spam commands by calling the rjunk function. This part can generate 1 byte, 2 byte, 3 byte, and 5 byte spam commands, and jmp call simulation commands (without doubt the addition of such commands makes junk look more like a real command), and in order to make the generation of junk more randomized, BPE32 has a simple ing relationship.
0 = 5, 1 = 1 + 2, 2 = 2 + 1, 3 = 1, 4 = 2, 5 = 3, 6 = none, 7 = dummy jump and call
The left index (eax, random number) = the right side (number of junk instruction bytes), that is, rjunk first generates a 0 ~ The Random Number of 7 is generated based on the index ing list. For example:
When eax is 0, 5 byte junk is generated.
When eax is 1, 1 byte junk and 2 byte junk are generated.
When eax is 2, 2 byte junk is generated first, and then 1 byte junk is generated
When eax is 7, jmp or call is generated
According to the above ing relationships, and so on, the following describes how to generate spam code with 1 byte junk code.
1 byte junk example:
Esi --> data to be encrypted
Edi --> memory buff
Generates 1 byte junk command to the memory buff
J1:
Call junx1; one byte junk instruction
Nop
Dec eax
SALC
Inc eax
Clc
Cwde
Stc
Cld