The Zutto Dekiru Encoder, Explained
Written by Nick Hoffman, Jeremy Humble, Toby Taylor
Written by Nick Hoffman, Jeremy Humble, Toby Taylor
Welcome to the fifth installation in our Shellcode Signature Series—a collection of posts that disassemble shellcode and obfuscation techniques and write signatures to detect them. The fourth encoder we’ll explore in this series is Metasploit’s Zutto Dekiru payload encoder.
When looking through the code of Zutto Dekiru, it’s clear that it borrows many of Shikata Ga
Zutto Dekiru is more complicated encoders that we have encountered so far in this series. One of its first actions is to generate a compact stub that obtains the value of RIP. It then performs an XOR loop that decodes the payload.
Step 1: FPU Instructions for GetRIP
The Shikata Ga Nai encoder obtains RIP by executing an FPU instruction, then obtaining the address of that instruction via FSNTENV and POP. Zutto Dekiru uses this same technique, but it requires calling fxsave64 instead of FNSTENV.
Within the instruction fxsave64, there is an option to supply a register for the generated instruction. This option is shown in the below function which aligns registers to opcodes.
def fxsave64(reg) case reg when "rax" return "\x48\x0f\xae\x00" when "rbx" return "\x48\x0f\xae\x03" when "rcx" return "\x48\x0f\xae\x01" ...code snipped for readability... when "r14" return "\x49\x0f\xae\x06" when "r15" return "\x49\x0f\xae\x07" endend
Using a simple script written in Python and using radare2, we can verify these instructions, as shown here:
#!/usr/bin/env
import r2pipe
opcode_list = ['480fae00','480fae03','480fae01','480fae02','480fae06','480fae07','480fae4500','490fae00','490fae01','490fae02','490fae03','490fae0424','490fae4500','490fae06','490fae07']
r2 = r2pipe.open('malloc://1024')
for opcodes in opcode_list:
res = r2.cmd('pad %s' % opcodes)
print(res)
Our results align with the encoder and these are variations of the FXSAVE64 instruction.
fxsave64 [rax] fxsave64 [rbx] fxsave64 [rcx] fxsave64 [rdx] fxsave64 [rsi] fxsave64 [rdi] fxsave64 [rbp] fxsave64 [r8] fxsave64 [r9] fxsave64 [r10] fxsave64 [r11] fxsave64 [r12] fxsave64 [r13] fxsave64 [r14] fxsave64 [r15]
This logic is combined with the same FPU instructions generated in the Shikata Ga Nai code block, which is observed in the following function:
def fpu_instructions
fpus = []
0xe8.upto(0xee) { |x| fpus << "\xd9" + x.chr }
0xc0.upto(0xcf) { |x| fpus << "\xd9" + x.chr }
0xc0.upto(0xdf) { |x| fpus << "\xda" + x.chr }
0xc0.upto(0xdf) { |x| fpus << "\xdb" + x.chr }
0xc0.upto(0xc7) { |x| fpus << "\xdd" + x.chr }
fpus<< "\xd9\xd0"
fpus<< "\xd9\xe1"
fpus<< "\xd9\xf6"
fpus<< "\xd9\xf7"
fpus<< "\xd9\xe5"
fpus
end
By this time, it should be evident to the defender that there are a lot of possible permutations to account for in the signature.
If we take a generated payload and break down the instructions, we will have a nice annotated version of how the encoder works. All instructions related to obtaining RIP are commented below. The other instructions are commented in the next section.
ffree st(3) ; FPU instruction push rsp ; Push stack pointer and store in R9 pop r9 and r9w, 0xf9e0 fxsave64 [r9] ; Populates Data Structure at [r9 & 0xf9e0] xor r12, r12 mov r12b, 0x40 movabs r8, 0xe8e5b405459c9070 mov rdx, qword [r9 + 8] ; [r9+8] is lower 32bits of RIP, store in RDX
This is just one generated variant, and not all will be the same. Still, all generated samples will follow the same concept: execute an FPU instruction, then later retrieve the location of that instruction with the fxsave64 operation.
Step 2: Un-XOR the Payload
Now that step one of the encoder is complete (obtaining RIP), the next step is to load an XOR key and un-XOR the payload. The steps taken to XOR the payload are listed below.
ffree st(3) push rsp pop r9 and r9w, 0xf9e0 fxsave64 [r9] xor r12, r12 ; zero out r12 register mov r12b, 0x40 ; load block count movabs r8, 0xe8e5b405459c9070 ; load XOR key into r8 mov rdx, qword [r9 + 8] dec r12 ; decrement counter xor qword [rdx + r12*8 + 0x30], r8 ; XOR operation test r12, r12 jne 0x23
The other interesting feature of Zutto Dekiru is called the “coin flip.” This technique offers an additional—though not extensive—permutation on how the stack address is obtained and stored in a register. The section of code pictured below shows two “gadgets” that store the value of RSP into a register and perform an AND operation.
flip_coin = rand(2) ..code snipped... lea = [] if flip_coin==0
lea << ["lea", assemble("mov %s, rsp"%reg_env[0])]
lea << ["lea1", assemble("and "+reg_env[2]+", 0x%x"%sub)]
else
lea << ["lea", assemble("push rsp")]
lea << ["lea1", assemble("pop "+reg_env[0])]
lea << ["lea2", assemble("and "+reg_env[2]+", 0x%x"%sub)]
end
Zutto Dekiru has a few static components, but a majority of the shellcode is dynamically generated, making it difficult to write a detection signature.
FXSAVE64 – Generalization
Zutto Dekiru contains multiple steps. The first part of the signature is generalizing those steps into a single regular expression (if possible) or into multiple sub-rules.
Generalizing the FXSave operation will result in the following set of opcodes:
( (48|49) 0f ae (00|01|02|03|06|07) | (48|49) 0f ae (04|45) (00|24) )
FPU Instruction Generalization
The generated FPU instructions are executed over ranges of opcodes and are the same set used in Shikata Ga Nai. We can borrow the same regular expression from that rule to detect these generated instructions:
(d9 (e8|e9|ea|eb|ec|ed|ee|c?|d0|e1|f6|f7|e5) |
(da|db) (c?|d?) |
dd (c0|c1|c2|c3|c4|c5|c6|c7))
We also know that these instructions must exist before the FXSAVE64 instruction.
Loading the Stack Address
The stack address is loaded into a register and AND’d during the process of finding EIP. The coin flip function gives us two possible outcomes for this. The primary issue with trying to use this in a signature is that it is difficult to reliably determine where this logic is implemented. Sometimes it happens before the FPU instruction, other times it happens after. However, it is always implemented before the FXSAVE64 instruction.
The first permutation is:
mov <reg>, rsp and <reg_2>, constant
This can be permuted into the following instructions:
(48|49) 89 (e0|e1|e2|e3|e4|e5|e6|e7) ( 66 (25|83) ?? ?? | 66 (41|81) (83|e1|e2|e3|e5|e6|e7) ?? ?? | 66 41 81 (e0|e1|e2|e3|e4|e5|e6|e7) ?? ?? )
The second permutation is:
push rsp pop <reg> and <reg_2>, constant
This can be permuted into the following instructions:
54 ( (58|59|5a|5b|5d|5e|5f) | 41 (58|59|5a|5b|5c|5d|5e|5f) ) ( 66 (25|83) ?? ?? | 66 (41|81) (83|e1|e2|e3|e5|e6|e7) ?? ?? | 66 41 81 (e0|e1|e2|e3|e4|e5|e6|e7) ?? ?? )
Due to these instructions being split up and mixed in with the FPU instructions, it makes them unreliable for a compact signature.
XOR Loop
The XOR loop is consistent in its operations and can be generalized into a signature. At its core, the XOR loop construction is contained within the following code:
loop_code = assemble("dec "+reg_size[0])
loop_code += assemble("xor ["+reg_rip+"+("+reg_size[0]+"*8) + 0x7f], "+reg_key)
loop_code += assemble("test "+reg_size[0]+", "+reg_size[0])
payload_offset = decode_head_size+loop_code.length+2
loop_code = assemble("dec "+reg_size[0])
loop_code += assemble("xor ["+reg_rip+"+("+reg_size[0]+"*8) + 0x"+payload_offset.to_s(16)+"], "+reg_key)
loop_code += assemble("test "+reg_size[0]+", "+reg_size[0])
One important detail is that the end of the loop is hard coded to a JNE (0x75) which we can use as an anchor within our signature.
Taking an example of the loop, such as:
dec rax xor qword [rbx + rax*8 + 0x29], r14 test rax, rax
This can be generalized into the following opcodes.
(48|49) ff (c8|c9|ca|cb|cc|cd|ce|cf)
((48|49|4a|4b|4c|4d|4e|4f) 31 (04|0c|14|1c|24|2c|34|3c) (c?|d?|e?|f?) | (48|49|4a|4b|4c|4d|4e|4f) 31 (44|4c|54|5c|64|6c|74|7c) (c?|d?|e?|f?) ??)
(48|49|4c|4d) 85 (c?|d?|e?|f?)
The Jump Problem
When writing shellcode signatures, defenders often think of ways that they can be bypassed. Yara is an excellent tool for finding byte sequences, but we are going to encounter problems when the ordering of single instructions can be permuted.
In Zutto Dekiru, the authors introduce an interesting problem. In most cases, a handful of operations allow enough uniqueness to write a signature, but when the order of those instructions can be changed and order doesn’t necessarily matter, we have to start wildcarding bytes or adding padding. This, in turn, can introduce false positives or make the signature not as trustworthy.
One method to bypass many shellcode signatures is to make the shellcode execution jump around so that elements of the signature can hit, but they might hit out of order. For example, in a sample Zutto Dekiru generation, the following instruction sequence will happen:
Stack Load
FPU instruction
XOR Key Store
Block Size Store FXSAVE64
XOR_LOOP
However, a good way to mess with signatures is permuting the order of the instructions while still preserving the order of execution. One example of a payload with a modified workflow is shown below. In this example, the authors would insert jumps in between each set of instructions to keep the original flow.
FPU instruction XOR_Loop Stack Load Block Size Store
XOR Key Store FXSAVE64
Stack Load
The Signature
To account for the jump problem, we’ve made several different combinations of the sequence of events within the Zutto Dekiru encoder, as shown below. All encoded payloads generated from Metasploit (as of this writing) should only fall under one of these subrules. This will also account for future variations if someone decides to patch in random jump instructions to throw off order of operations.
rule zutto_dekiru
{
meta:
author = “Nick Hoffman/Jeremy Humble”
description = “Zutto Dekiru Shellcode Encoder”
strings:
$fpu_fxsave64_fpu_instruction_dec_loop = {((48|49)0fae(00|01|02|03|06|07)|(48|49)0fae(04|45)(00|24)) [0-50] (d9(e8|e9|ea|eb|ec|ed|ee|c?|d0|e1|f6|f7|e5)|(da|db)(c?|d?)|dd(c0|c1|c2|c3|c4|c5|c6|c7)) [0-50] (48|49)ff(c8|c9|ca|cb|cc|cd|ce|cf)((48|49|4a|4b|4c|4d|4e|4f)31(04|0c|14|1c|24|2c|34|3c)(c?|d?|e?|f?)|(48|49|4a|4b|4c|4d|4e|4f)31(44|4c|54|5c|64|6c|74|7c)(c?|d?|e?|f?)??)(48|49|4c|4d)85(c?|d?|e?|f?)75}
$fpu_fxsave64_dec_loop_fpu_instruction = {((48|49)0fae(00|01|02|03|06|07)|(48|49)0fae(04|45)(00|24)) [0-50] (48|49)ff(c8|c9|ca|cb|cc|cd|ce|cf)((48|49|4a|4b|4c|4d|4e|4f)31(04|0c|14|1c|24|2c|34|3c)(c?|d?|e?|f?)|(48|49|4a|4b|4c|4d|4e|4f)31(44|4c|54|5c|64|6c|74|7c)(c?|d?|e?|f?)??)(48|49|4c|4d)85(c?|d?|e?|f?)75 [0-50] (d9(e8|e9|ea|eb|ec|ed|ee|c?|d0|e1|f6|f7|e5)|(da|db)(c?|d?)|dd(c0|c1|c2|c3|c4|c5|c6|c7))}
$fpu_instruction_fpu_fxsave64_dec_loop = {(d9(e8|e9|ea|eb|ec|ed|ee|c?|d0|e1|f6|f7|e5)|(da|db)(c?|d?)|dd(c0|c1|c2|c3|c4|c5|c6|c7)) [0-50] ((48|49)0fae(00|01|02|03|06|07)|(48|49)0fae(04|45)(00|24)) [0-50] (48|49)ff(c8|c9|ca|cb|cc|cd|ce|cf)((48|49|4a|4b|4c|4d|4e|4f)31(04|0c|14|1c|24|2c|34|3c)(c?|d?|e?|f?)|(48|49|4a|4b|4c|4d|4e|4f)31(44|4c|54|5c|64|6c|74|7c)(c?|d?|e?|f?)??)(48|49|4c|4d)85(c?|d?|e?|f?)75}
$fpu_instruction_dec_loop_fpu_fxsave64 = {(d9(e8|e9|ea|eb|ec|ed|ee|c?|d0|e1|f6|f7|e5)|(da|db)(c?|d?)|dd(c0|c1|c2|c3|c4|c5|c6|c7)) [0-50] (48|49)ff(c8|c9|ca|cb|cc|cd|ce|cf)((48|49|4a|4b|4c|4d|4e|4f)31(04|0c|14|1c|24|2c|34|3c)(c?|d?|e?|f?)|(48|49|4a|4b|4c|4d|4e|4f)31(44|4c|54|5c|64|6c|74|7c)(c?|d?|e?|f?)??)(48|49|4c|4d)85(c?|d?|e?|f?)75 [0-50] ((48|49)0fae(00|01|02|03|06|07)|(48|49)0fae(04|45)(00|24))}
$dec_loop_fpu_fxsave64_fpu_instruction = {(48|49)ff(c8|c9|ca|cb|cc|cd|ce|cf)((48|49|4a|4b|4c|4d|4e|4f)31(04|0c|14|1c|24|2c|34|3c)(c?|d?|e?|f?)|(48|49|4a|4b|4c|4d|4e|4f)31(44|4c|54|5c|64|6c|74|7c)(c?|d?|e?|f?)??)(48|49|4c|4d)85(c?|d?|e?|f?)75 [0-50] ((48|49)0fae(00|01|02|03|06|07)|(48|49)0fae(04|45)(00|24)) [0-50] (d9(e8|e9|ea|eb|ec|ed|ee|c?|d0|e1|f6|f7|e5)|(da|db)(c?|d?)|dd(c0|c1|c2|c3|c4|c5|c6|c7))}
$dec_loop_fpu_instruction_fpu_fxsave64 = {(48|49)ff(c8|c9|ca|cb|cc|cd|ce|cf)((48|49|4a|4b|4c|4d|4e|4f)31(04|0c|14|1c|24|2c|34|3c)(c?|d?|e?|f?)|(48|49|4a|4b|4c|4d|4e|4f)31(44|4c|54|5c|64|6c|74|7c)(c?|d?|e?|f?)??)(48|49|4c|4d)85(c?|d?|e?|f?)75 [0-50] (d9(e8|e9|ea|eb|ec|ed|ee|c?|d0|e1|f6|f7|e5)|(da|db)(c?|d?)|dd(c0|c1|c2|c3|c4|c5|c6|c7)) [0-50] ((48|49)0fae(00|01|02|03|06|07)|(48|49)0fae(04|45)(00|24))}
condition: any of them }
The Zutto Dekiru signature has a lot of built-in signature resilience. By introducing coin flips and having potential branching instructions, it can be difficult for a defender to make a successful signature.
The use of fxsave64 is novel. However, for a lack of better words, it is a somewhat obscure instruction and it does not appear very often in regularly compiled software. In x64 assembly, there are still tricks to get the value of RIP, however, it’s now allowed to directly access the value via lea rax,[rip]. This technique and more will be discussed in future posts.
Tools like IRasm can make writing opcode signatures in Yara very difficult. Leveraging a tool like IRasm could allow attackers to further permute their shellcode to bypass modern detection rules. We will discuss this topic later in the series.
