The Zutto Dekiru Encoder, Explained

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 Nai’s  techniques with a few modifications. Zutto Dekiru is the most robust of the two publicly available x64 encoders, and it provides a nice template from which other encoder authors can draw inspiration. 

Understanding the Zutto Dekiru Encoder: A Tree with Many Branches

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

Yara Signature

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?)

This can be generalized into the following opcodes.

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
}

Conclusions and Suggestions

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.