Finding the Instruction Pointer

Welcome to the seventh installment in our Shellcode Signature Series—a collection of blog posts where we disassemble and talk about various shellcode and obfuscation techniques, and write signatures to detect them. 

In this post, we will dive into methods of obtaining EIP/RIP. These techniques have been around for a long time and while nothing here is new information, we hope for it to be a starting point for someone who is researching shellcode to gain understanding of the methods in use today.

GetEIP/RIP

Our topic in this case is one of the core properties of shellcode.  Obtaining the value of the instruction pointer is essential to any stub of shellcode. It’s useful for a variety of reasons including:

• Calculating the offset of a payload (or encoded buffer)
• Address everything relative to the running code

While it’s technically possible to run shellcode without obtaining the value of EIP/RIP, in most cases shellcode will find and use this value to perform its tasks. 

A Note About EIP

In x86 assembly, it’s not possible to directly pull the value of the EIP register. However, shellcode authors figured out other ways to obtain the value of EIP in compact code without much overhead. 

Call $ + ?

When performing a call operation in x86/x64 the address of the instruction following the call (the return location) is pushed onto the stack.  The function will perform its task placing the return value in EAX, then a RET instruction at the end of the function will pop the return value off the stack and continue execution to it. With this technique, the call typically leads directly to a pop instruction which immediately pops the return address of the stack. This return address is the address of the POP instruction itself (EIP).

This return address (EIP) is then the anchor point that other structures (typically an encoded buffer) are addressed relative to. 

Call $+5

Probably the simplest method of obtaining the value in EIP is Call $+5, which is a CALL to the next instruction. The value of EIP is then pulled off the stack and placed into a register.

A simple form of this can be observed within the Bloxor shellcode encoder. Note: This is not Bloxor’s primary method—it uses many others as well.

Due to the encoding of the call $+5 operation (E8 00 00 00 00, meaning +0 bytes from next instruction) containing null bytes, this method isn’t as popular in shellcode encodings.

Call $+4

Call $+4 is commonly observed due to the operand for the call (FF FF FF FF == -1 bytes from next instruction) containing no null bytes. Null bytes are often avoided due to real-world cases in which the shellcode is interpreted as a c-style null-terminated string which will be cut off too early if a null byte is present.  Because we are calling 1 byte back from the next instruction, execution will actually jump inside of the call instruction starting at the last byte, an 0xFF. This is usually followed by a C0 (represents INC EAX)—unless the author wants to preserve EAX—a non-destructive operation that can be undone or accounted for in later code. This is then followed by a pop, thus allowing us to get the value of EIP in a register. 

Within the Metasploit’s x86_call4_dword encoder, some samples of this code can be generated. In a basic sample consider the following code:

The C0 is not being recognized as a valid instruction due to the length of the call instruction. After the call happens and EIP is at 0x09, the assembler recognizes the C0 as part of the FFC0 instruction.

import r2pipe
r2 = r2pipe.open('malloc://512')
r2.cmd('e asm.arch=x86')
r2.cmd('e asm.bits=32')
for i in range(0,256,1):
  instruction = "FF" + "%02X" % i
  asm = r2.cmd('pad %s' % instruction)
  if "invalid" not in asm:
    print("%s -> %s" % (instruction, asm) )

When running, the above would generate the following valid instructions (output snipped for readability):

...snip...

FFC0 -> inc eax
FFC1 -> inc ecx
FFC2 -> inc edx
FFC3 -> inc ebx
FFC4 -> inc esp
FFC5 -> inc ebp
FFC6 -> inc esi
FFC7 -> inc edi
FFC8 -> dec eax
FFC9 -> dec ecx
FFCA -> dec edx
FFCB -> dec ebx
FFCC -> dec esp
FFCD -> dec ebp
FFCE -> dec esi
FFCF -> dec edi

...snip....

In addition to Call $+5 and Call $+4, an author could call any location of their code and just jump over junk instructions or call back to them later, which would make it more difficult for signatures to find all the possible variants without the use of emulation.

In shellcode, the user can call any address (not just +4, or +5 ahead to get EIP). In some cases, this has its own advantages. We will discuss this when we look at JMP/Call.

JMP forward / Call back

Another common method of obtaining EIP (and finding the address of the encoded bytes of the payload) is to insert a call instruction right before the encoded bytes that calls “backwards” to some decoder. 

A x64-based example of this can be found using the xor_dynamic encoder within Metasploit. Rather than abusing relative addressing available within x64, the encoder will do a JMP, CALL, POP sequence to obtain the value of RIP.

The first instruction is a non-conditional jump:

This will land at 0x29, a CALL instruction.

It’s important to note that the CALL instruction happens right before encoded data. This will push the index of 0x2e on to the stack which is the first byte of encoded data. When following the call instruction, it will lead to a POP which will store the location of that first encoded byte.

This method is advantageous for several reasons. Not only does it obtain the value of RIP, but it’s also an efficient method for directly locating the first byte of the encoded payload rather than having to calculate it based off offset from EIP.

FPU Based Techniques

Shikata Ga Nai and Zutto Dekiru are 2 popular encoders that both leverage FPU instructions to obtain the value in EIP. Leveraging extended instructions for FPU/GPU/MMX, etc., an attacker may find an instruction that is not supported by the emulator allowing for the detection to slip by. This method is discussed in detail in our earlier post on Shikata Ga Nai. 

X64 LEA / Relative Addressing

In x64 assembly we can now take advantage of relative addressing and read the value of RIP via a LEA instruction. Having done this, we no longer need to perform tricks to determine the value of RIP allowing for much more compact code, thus providing defenders with fewer bytes and techniques to write signatures against.

An example of this can be shown in the x64/xor encoder within Metasploit.

In this example, RIP is obtained by the instruction at 0x0a. The debugger is rendering the instruction as though it’s directly loading in address 0, but if we break the instruction up, we can see this is not the case. The last 4 bytes of that instruction, 0xFFFFFFEF (-0x11), are specifying an offset from the next instruction (RIP), which is indeed 0x00 in this example. That value is then used along with an offset (0x27) as an index into a buffer of encoded data in 0x1b. 

Rather than resorting to a sequence of instructions to find RIP, the authors used a single LEA.   

Real World Cases

Below we identify some Metasploit encoders and their methods for using GetPC.  

Interestingly, there seems to be a nice sampling of all the methods. Depending on the encoder and the payload decoding method, the authors use whatever method suits them the best. In the case where they are doing a JMP/Call/Pop, the encoded data is right after the call instruction, and the authors are using it as an index for the start of the encoded buffer. The FPU-based getPC methods are usually done right around the time that a key is loaded into a register, and right before a loop is entered that starts performing some decoding. Bloxor (which we will discuss in another post) is a very mature encoder that will perform any necessary task to avoid bad bytes. It will even randomize its method of GetPC in the case that an opcode, such as \xD9, isn’t available.

Signatures

Writing a signature for the presence of a GetPC method alone is not a recommended process. These methods are also used by many legit applications in instances where code compactness matters. While it’s not something observed in all executables, the presence of position independent code is not enough to make the judgment that the binary is “evil.”

JMP Forward / Call Back / Pop

This technique can be a bit challenging to tackle with vanilla Yara logic. Typically, when looking at a problem like this it’s easier to use a general-purpose disassembler/assembler to:

• Resolve the location of the JMP
• Check the instruction
• Resolve the destination (if the instruction is a CALL)
• Check to see if it’s a POP

In Python and using Radare2, the following logic would be a basic implementation of this check:

import r2pipe
import sys
r2 = r2pipe.open(sys.argv[1])
r2.cmd('aa')
for location in r2.cmdj('/cj pop'):
  for pop in r2.cmdj('pdj 1 @ %s' % location['offset']):
    for xref in pop.get('xrefs',[]):
      if xref['type'] == "CALL":
        call_xrefs = r2.cmdj('pdj 1 @ %s' % xref['addr'])[0]
        for cxref in call_xrefs.get('xrefs',[]):
          if cxref['type'] == "CODE":
            jmp_instruction = r2.cmdj('pdj 1 @ %s' % cxref['addr'])[0]
            if jmp_instruction['type'] == "jmp":
              print("%s->%s->%s" % (jmp_instruction['opcode'],call_xrefs['opcode'],pop['opcode']))

This is a naïve implementation that will look for the sequence of a JMP to a CALL to a POP instruction.  While it’s not the most efficient solution, it should provide some insight into a method of achieving this using Python + Radare2.

Taking this script and converting it to Yara’s logic makes for an awkward, but useable condition.

rule jump_forward_call_back {
  meta:
    author = "Nick Hoffman/Jeremy Humble"
    description = "JMP Forward / Call Back POP Shellcode Logic"

  strings:
    /*
    012C1000  | EB 19                      | jmp x32dbg.12C101B
    012C1002  | 5E                         | pop esi
    012C1003  | 8B FE                      | mov edi,esi
    012C1005  | 83 C7 4C                   | add edi,4C
    012C1008  | 8B D7                      | mov edx,edi
    012C100A  | 3B F2                      | cmp esi,edx
    012C100C  | 7D 0B                      | jge x32dbg.12C1019
    012C100E  | B0 7B                      | mov al,7B
    012C1010  | F2 AE                      | repne scasb al,byte ptr es:[edi]
    012C1012  | FF CF                      | dec edi
    012C1014  | AC                         | lodsb al,byte ptr ds:[esi]
    012C1015  | 28 07                      | sub byte ptr ds:[edi],al
    012C1017  | EB F1                      | jmp x32dbg.12C100A
    012C1019  | EB 51                      | jmp x32dbg.12C106C
    012C101B  | E8 E2 FF FF FF             | call x32dbg.12C1002

Condition for this rule is a bit complicated, but is necessary to keep FP levels manageable. It checks that the initial offset in the first jmp leads to the call and that the call leads back to the pop after the first jump.

    */
    $jmp_fwd_call_back = {eb ?? (58 | 59 | 5A | 5B | 5C | 5D | 5E | 5F) [10-200] e8 ?? ff ff ff }
  condition:
    for any i in (1 .. #jmp_fwd_call_back): ((((256 - uint8(@jmp_fwd_call_back[i] +
uint8(@jmp_fwd_call_back[i]+1) + 3)) -        int8(@jmp_fwd_call_back[i]+1)) == 5) and
uint8(@jmp_fwd_call_back[i] + uint8(@jmp_fwd_call_back[i]+1) + 2) == 0xe8)
}

Call $+? / Pop

Call + Pop is one of the most common mechanisms and not very difficult to write a signature for.  However, we need to be cognizant of the register that we’re popping the value into, as this is a single opcode and it will change depending on register.

In x86 all possible permutations of “pop <register>” end up being generalized into the following Yara regular expression: {(58|59|5a|5b|5c|5d|5e|5f)}. Pairing that with a call instruction (in this case Call $+4) will yield the Yara rule below.

rule getpc_method_call_pop
{
  meta:
    author = "Nick Hoffman / Jeremy Humble"
    description = "Shellcode CALL/POP GetPC methods"

  strings:
    $call_4_pop = {e8 ff ff ff ff ?? (58|59|5a|5b|5c|5d|5e|5f)}
    $call_5_pop = {e8 00 00 00 00 (58|59|5a|5b|5c|5d|5e|5f)}

  condition:
    any of them
}

FPU Based Instructions

The shellcode generators pivot around 2 primary instructions, FXSAVE64 and FNSTENV. Triggering on just the opcodes for these instructions is not the best way to write a standalone signature. Knowing that they depend on a separate FPU instruction being executed prior to their execution, we could pair these with the other FPU instructions’ signatures (like the Shikata Ga Nai and Zutto Dekiru encoders). It’s an option, but it’s not an ideal solution, as there may be any number of instructions in between the initial FPU instruction and the call to GetEIP.

Conclusions

Many of the advancements in shellcode were made roughly 20 years ago. Some of the methods that we discussed in this post were added to Metasploit in 2005, which just happened to be during its re-write.  Digging back into older exploits, many of these techniques can be found in single one-off exploit scripts that predate the Metasploit Framework. With x64 now allowing for relative addressing, creative methods of obtaining the value of the instruction pointer may be going away. We do, however, look forward to the next shellcode encountered in the wild to leverage some new obscure instructions and methods of obtaining EIP.

Creating signatures and triggering on GetEIP/GetPC techniques is simply not robust enough for modern detection methods. While they can add strong contextual data, running a single Yara rule will not be enough. Combined with another rule, however, (e.g., a generic XOR followed by a LOOP), GetPC can be used to find evidence of shellcode existing within any data.

In many cases these signatures can be defeated by inserting junk instructions or obfuscating the flow of the program once the value of EIP is pushed on to the stack. The authors don’t need to immediately POP it off for storage, it’s just usually more convenient for encoders to store that logic in a compact function.  JMPing to a CALL and then back for a POP highlights the shortcomings of static signature tools and highlights the need for emulation or tracing. As one can imagine, this would only make it more challenging for the defender by inserting more jumps in between instructions.