2018 - Fixing ELF static binaries with ASLR+RELRO support


	We present new research that details crucial security weaknesses in Linux software that has been statically
	linked. We also provide a solution to temporarily resolve these security issues. Finally, we conclude by
	demonstrating how to have both RELRO and ASLR security mitigations working with statically linked executables
	PAPER HERE

2016 - Another tale of ELF Origin (SunOS ELF exploitation)


	Recently I discovered a vulnerability that effects IllumOS and probably many SunOS versions and
	variants dating back to early ELF support in the mid-90's. The vulnerable code lives in the kernels
	ELF loading code, and allows the `$ORIGIN` expansion variable to be used in the `PT_INTERP` segments
	path to the program interpreter (dynamic linker) with setuid executables which can easily result in
	local privilege escalation. To read more check out my
	PAPER HERE

2016 - Learning Linux binary analysis


	My book was just released in February of 2016. The book is unique in the sense that it covers
	topics pertaining specifically to ELF binaries, Linux viruses, process memory forensics, binary
	protection, Linux kernel forensics, ECFS, and more. There is information in the book that can only
	otherwise be found by scavenging a vast array of internet sites, ELF specifications, phrack literature,
	vxheaven papers, and obscure Linux manual pages. I am proud to say that I wrote the book, however
	I am sad to say that due to a rushed final editing process, there are still a number of formatting
	issues that make the book less than perfect. I was well aware of these formatting issues and
	brought them to the attention of the editors 3 times, after which they reassured me that they were
	all fixed. At this point in time I am personally aware of the following issues, as they were never
	actually fixed.

Formatting issues

Page 21, 22, 160, 161 - Early line breaks in readelf -S output
Page 63 - Example debugger source code had '-' (hyphens) somehow removed?
Page 123 should have the image/diagram from page 131 and vice versa
Some of the C code throughout the book had its indentation/formatting lost


	Now although these formatting issues are unpleasant, they do not completely detract from the value
	of the book. The only real serious issues are the source code on page 63 (since it no longer
	will compile) and the images that need to be swapped between page 123 and 131. If any readers
	are aware of any other formatting issues, please feel free to notify me. I am currently attempting
	to get the publishing company to re-print the book with the fixed changes, until that happens
	I would recommend just being aware of these issues when reading the book. I hope that these issues
	will soon be fixed.

2016 - Skeksi Virus for X86_64 Linux

Linux X86_64 ELF Virus that just might ruin someones day in the wrong hands

Disclaimer
This Virus was not designed as a means to exact vengance on anyone. I, Ryan elfmaster O'Neill, take
no responsibility for any damage that this software may cause. Please be responsible and friendly.

Philosophy

Do not fear Viruses. They have been heavily stigmatized. If it was not for vxheaven, and other
resources that teach people about the internals of Virus design, I would not have had the understanding
necessary to invent some of the more interesting security technologies such as ECFS and Maya's Veil
Both of which rely heavily on the knowlege of binary infection (aka instrumentation). Remember...
ignorance and fear are one in the same. Knowlege is power, that can be used at both ends of the
spectrum. The Skeksi Virus was invented for fun, and educational purposes, be cautious when handling
it.

General about

This Virus is humurous, but it is also nasty and should not be executed on any system unless
it is a controlled environmnent, or an expendable Virtual machine setup specifically to host
malware. The Skeksi Virus was written merely for the sake of inventiveness, and to demonstrate
how to write a quality Virus for Linux, mostly in C. It is a work in progress and is not yet
complete.

Virus specifications

Infection techniques

* Extends text segment in reverse to make room for parasite

This technique is nice, because it is less suspicious. The entry point still points into the
.text section of the executable, and there is no modifications to the segment permissions or
segment type.

* Infects the PLT/GOT

Currently the Virus only looks for the puts() function which is used to print strings and is
often linked into an executable instead of printf(). The result is that an infected binary will
print everything to stdout in l33t sp34k, randomly with a probability of 1 in 5.

* Anti-debugging

The virus uses a combination of the ptrace system call, and prctl() to prevent users from
debugging an infected program, or from dumping the memory through /proc/pid/mem or core-dumps.

Infection behaviour

The virus will infect only x86_64 ELF ET_EXEC binaries that are dynamically linked. The virus
will soon also be able to infect shared libaries, but some adjustments must be made to take
into account the position independent type executables. The virus will mark an infected file's
EI_PAD area (9 bytes into the ELF file header) with a magic number 0x15D25. This prevents it
from re-infecting a given file.

If the Virus is launched as a non-root user, it will only infect binaries in the CWD. If the
virus is launched with root privileges it will randomly select one of four directories:
/bin, /usr/bin, /sbin, /usr/sbin. After it picks a target directory it will have a 1 in 10
chance of infecting each file as it iterates through all of them.

The Virus has a 1 in 15 chance of Displaying an ascii banner of a Skeksi :)

Points of strength

The Skeksi Virus can aggressively infect other binaries. This means that it does not rely on
section headers. Even if the target binary is stripped of its section header table, the Skeksi
virus will still prevail. For example, when infecting the PLT/GOT table, it parses the dynamic
segment found by the program header table, and uses the D_TAG's: DT_SYMTAB, DT_JMPREL, etc. to
locate the symbol table, relocations, and GOT as needed.

The Skeksi Virus is approximately 70% of C code, and 30% ASM. This makes it ideal for additional
development, and provides a good concrete example of how to write a modern Virus in C.

Nuances and notes

Notice we do store string literals, not just on the stack. This is because the text and data
segment are merged into a single segment and each time the virus copies itself, it copies
all of the string data as well.

Source code requests

Currently only a compiled binary of the Virus is available for Download. Upon special request
I may be willing to share the source code with interested parties for the sake of education.
Engineering Virus code is unlike any other type of programming...

Shouts

My 2 boys who may just one day ride in their fathers footsteps of Virus writing and hacking

JPanic - A huge inspiration for anyone interested in Virus writing, and hats off to him for writing
the best ELF Linux Virus I've seen to date.

vxheaven folks - The definitive source of information for education in Virus internals and engineering

Silvio - Wouldn't have known all this stuff without your awesome research from the late 90's. The
infection technique I use with Skeksi is based on your idea of backwards text extension (Which I
don't think was ever implemented publicly).

Nivenh - Recently gave me the idea to write a new virus

Others... there are others but some people are reticent to be associated with Virus technology.
I don't want to associate just anyone with the nepharious stigma attached to VX.

Usage

The following will infect only executables in the CWD. Run as root to begin randomly infecting
files in /sbin, /usr/sbin, /bin, /usr/bin. Heavy Caution is advised!

$ chmod +x skeksi_virus.elf
$ ./skeksi_virus.elf

Disinfection

The Skeksi Virus can be disinfected using the disinfector 'skeksi_disinfect.c' linked to below.
This is handy incase you find that you have infected your system.

gcc skeksi_disinfect.c -o disinfect
./disinfect executable

Here is a screenshot of the Virus in action

-Get skeksi virus binary

-Get skeksi disinfector program

2015 - Advanced Linux kernel malware analysis and detection software

Description:


    This information has been moved to Arcanacs.com

Tools that are on the way
Since this project is in early development (The first month) we still have
alot to develop. Some of the tools that are in the works involve the ability
to detect VFS layer rootkits, and more comprehensive DR rootkit detection.
Also a daemon that provides full HIDS abilities for 24/7 introspection into
live systems. For comments or questions please contact me: elfmaster [at] zoho [dot] com

ELF Binary analysis workshop with ElfMaster and Leviathan Security Group

Visit the official site

Description:
The ELF Binary analysis workshop is a two day course led by myself.
We will be covering the depths of ELF binary internals, and the many
ways in which it can be hacked, and reversed. We will also discuss Virus
engineering, analysis, and performing process memory forensics. The code projects
available on this site are a good example of the types of things we will be
teaching over the two days. For full details please visit the official website
that is linked above.

2014 - An informal analysis of the Linux x86_64 ELF Virus: Retaliation (Engineered by JPanic)

The analysis is available in text format here

Description:
This paper is an informal, but relatively detailed analysis of a progressively engineered
Virus for Linux that infects ELF executables and relocatable objects. The Virus brings together
' many of the greatest areas of research in regards to anti-debugging, polymorphic code, obfuscation
and runtime hooking of functions, into a single Virus that is very well engineered and dangerously
effective. After several months of part time analysis I have released a text document containing the
findings of this Virus. Whether or not the Virus is released into the wild is unknown, as I received
the samples directly from the Author.

2014 - Extending the ELF core file format for forensics snapshots (New Paper!)

Read the paper here

Description:
ECFS (Extended core file snapshot) is a file format based on, and backwards compatible with
ELF Core files (ET_CORE) in Linux. The ecfs-util (Described in the paper) takes snapshots of
process memory, and produces an output file, that is a cross breed between a core file and an
executable. An ecfs file has many nice luxuries not found in regular core files or raw memory
dumps such as reconstructed symbol table (.dynsym, .symtab), section headers, and access to all
relevant memory mappings via ELF section headers (I.E Elf64_Shdr's). Please read the paper for more
details, the source code for this standalone utility will be released in January 2014

Example of the ECFS utility taking a snapshot of a stripped executable


$ strip ./host
$ ./host &
[1] 8395
$ ./ecfs -p `pidof host`
Using default snapshot directory $CWD/.snapshot
[+] Taking snapshot of process 8395
[+] Processing data and creating snapshot file: .snapshot/host.8395
$ readelf -s .snapshot/host.8395

Symbol table '.dynsym' contains 7 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND puts@GLIBC_2.2.5 (2)
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (2)
     3: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND pause@GLIBC_2.2.5 (2)
     5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND malloc@GLIBC_2.2.5 (2)
     6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND rand@GLIBC_2.2.5 (2)

Symbol table '.symtab' contains 5 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 00000000004004b0   112 FUNC    GLOBAL DEFAULT    8 sub_4004b0
     1: 0000000000400520    42 FUNC    GLOBAL DEFAULT    8 sub_400520
     2: 000000000040060d   112 FUNC    GLOBAL DEFAULT    8 sub_40060d
     3: 0000000000400680   101 FUNC    GLOBAL DEFAULT    8 sub_400680
     4: 00000000004006f0     2 FUNC    GLOBAL DEFAULT    8 sub_4006f0

$ readelf -S .snapshot/host.8395

	There are 23 section headers, starting at offset 0x61000:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         0000000000400238  00000238
       000000000000001c  0000000000000000   A       0     0     1
  [ 2] .note             NOTE             0000000000400254  00000254
       0000000000000044  0000000000000000   A       0     0     4
  [ 3] .hash             GNU_HASH         0000000000400298  00000298
       0000000000000040  0000000000000000   A       0     0     4
  [ 4] .dynsym           DYNSYM           00000000004002b8  000002b8
       00000000000000a8  0000000000000018   A       5     0     8
  [ 5] .dynstr           STRTAB           0000000000400360  00000360
       000000000000004f  0000000000000018   A       0     0     1
  [ 6] .rela.dyn         RELA             00000000004003e0  000003e0
       0000000000000040  0000000000000018   A       5     0     8
  [ 7] .init             PROGBITS         0000000000400488  00000488
       0000000000000040  0000000000000000  AX       0     0     8
  [ 8] .text             PROGBITS         0000000000400000  00000000
       0000000000000834  0000000000000000  AX       0     0     16
  [ 9] .fini             PROGBITS         00000000004006f4  000006f4
       0000000000000040  0000000000000000  AX       0     0     16
  [10] .eh_frame_hdr     PROGBITS         0000000000400708  00000708
       0000000000000034  0000000000000000  AX       0     0     16
  [11] .eh_frame         PROGBITS         000000000040073c  00000740
       000000000000073c  0000000000000000  AX       0     0     16
  [12] .dynamic          DYNAMIC          0000000000600e28  00000e28
       00000000000001d0  0000000000000010  WA       0     0     8
  [13] .got.plt          PROGBITS         0000000000601000  00001000
       0000000000000050  0000000000000008  WA       0     0     8
  [14] .data             PROGBITS         0000000000600e10  00000e10
       0000000000000468  0000000000000000  WA       0     0     8
  [15] .bss              PROGBITS         0000000000601278  00001278
       0000000000000220  0000000000000000  WA       0     0     8
  [16] .heap             PROGBITS         0000000000b00000  00003000
       0000000000021000  0000000000000000  WA       0     0     8
  [17] .stack            PROGBITS         00007fff48f88000  0020dffe
       0000000000021000  0000000000000000  WA       0     0     8
  [18] .vdso             PROGBITS         00007fff48ffe000  0022bffd
       0000000000002000  0000000000000000  WA       0     0     8
  [19] .vsyscall         PROGBITS         ffffffffff600000  0022dffd
       0000000000001000  0000000000000000  WA       0     0     8
 [20] .symtab           SYMTAB           0000000000000000  00061b75
       0000000000000078  0000000000000018          21     0     4
  [21] .strtab           STRTAB           0000000000000000  00061bed
       0000000000000037  0000000000000000           0     0     4
  [22] .shstrtab         STRTAB           0000000000000000  000615c0
       00000000000000ad  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

2014 - Sherlocked - Universal script packer/protector [TR3]

-Get sherlocked source code

Sherlocked V4 released 11/30/2014 - passwd support improved, and allows for script cmdline args when using a passwd

Description:
Sherlocked is the first software I've seen that is able to encrypt/protect any type of
interpreted script, such as pythonl, perl, shell etc. It is based off the Davinci seal
source code (Also available on this site). It functions by transforming a script into
an X86_64bit ELF Executable which contains the encrypted script, anti-debugging code
and the ability to decrypt and load the script into the interpreter. Sherlocked has some
extra protection features as well such as making sure that the interpreter being called is the
one that was specified when protecting the script; otherwise it will fail to load the script
lest someone replaces the interpreter with /bin/cat. Since Sherlocked is a prototype and based
off of the Davinci source code, it currently does not use real encryption, but simple xor based
encoding. Sherlocked can also create protected scripts that requires a password in order to
decrypt and run. It would not be difficult to augment its security by dropping in a real stream
cipher such as SALSA20. In addition to the initial protection, Sherlocked strips the binary of
symbol tables, and uses UPX to compress it (Otherwise the executables are 4MB fixed). If you
want to make changes to the source code to the stub, you must use gen_shellcode.c to convert
the compiled ./stub into a stub_shellcode.h file. The output file created by gen_shellcode is
'shellcode' so make sure to change the filename to 'gen_shellcode.h' before recompiling your changes.

NOTE: Make sure that your script code has all full-path-name references (Such as when reading/writing)
files etc. This is because sherlocked changes its relative position on the filesystem, which will prevent
lines of script accessing files by $CWD/path/file from working.

Example of sherlocked protecting a python script


ryan@elfmaster:~/git/sherlocked$ ./script.py
hello I am a python script
ryan@elfmaster:~/git/sherlocked$ ./sherlocked script.py script.elf p4ssw0rd /usr/bin/python -r
[+] The user who executes script.elf must supply password: p4ssw0rd
[+] Encoding payload data
[+] Encoding payload struct
[+] Building msg program
[+] utils/stripx exists, so using it to strip section headers off of DRM archive
[+] /usr/bin/upx exists, so using it to compress script.elf
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2013
UPX 3.91        Markus Oberhumer, Laszlo Molnar & John Reiser   Sep 30th 2013

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
   5003224 ->    324236    6.48%  linux/ElfAMD   script.elf

Packed 1 file.
Successfully created script.elf
ryan@elfmaster:~/git/sherlocked$ ./script.elf
This message requires that you supply a key to decrypt
ryan@elfmaster:~/git/sherlocked$ ./script.elf p4ssw0rd
hello I am a python script
ryan@elfmaster:~/git/sherlocked$

2014 - Saruman - anti-forensics executable injector [TR2]

-Get Saruman source code

Description:
Saruman is a neat anti-forensics exec() type software, very similar to grugqs remote exec, but also
very similar to shared library injection. Saruman allows you to run a program inside of an existing
process. It injects the complete program into a process address space, and injects a thread with SYS_clone
so that the attackers program can run concurrently with the host process. This allows for things such as
persistent memory backdoors, and memory viruses that require complex parasite code. For Virus writers
saruman allows the attacker to author the parasite completely in C, and compiled as a non-static executable
The only Caveat is that it must be compiled with 'gcc -fpic -fpie', so as a PIE executable. My original
project for this 'elfdemon' works on injecting regular ET_EXEC executables, and manually relocates them
which is unreliable for real case scenarios. elfdemon did not use thread injection either; the parasite
executable would take complete execution over from the host process and pass control back when done.
Saruman can inject a PIE executable using either __libc_dlopen_mode() which is the more stable method
or by doing completely manual runtime relocations which is more stealth (Because it doesn't show as
obvious in /proc/pid/maps). Unfortunately the more stealth method has a bug or two which prevents it
from working on more complicated parasite programs (Ending in occasional segfaults). Currently Saruman
does not allow you to pass command line args to your parasite program either; this will require some
additional coding of setting up the stack and auxillary vector for the new thread in the remote process
I will add this capability soon.

Example (Injecting a remote shell backdoor into a process)

Terminal 1


ryan@elfmaster:~/git/saruman$ ./host
I am the host
I am the host
I am the host

Terminal 2


ryan@elfmaster:~/git/saruman$ ./launcher `pidof host` ./server
Parasite command: ./server
[+] Target pid: 5942
[+] map_elf_binary(ptr, ./server)
[+] Parasite entry point will be main(): 0xec5
[+] Found text segment
[+] Found data segment
[+] Found dynamic segment
[+] Found dynamic string table
[+] Found dynamic symbol table
[+] Found G.O.T
[+] PLT count: 720 entries
[DEBUG]-> get_sym_from_libc() addr of __libc_dl_*: 7f5535015ca0
[+] PT_ATTACHED -> 5942
[+] calling bootstrap
[+] base (or highest address) of stack: 0xa01b000
[+] calling exec_loader
[+] dlopen elf exec_loader
[DEBUG]-> parasite path: ./server
[DEBUG]-> address of __libc_dlopen_mode(): 0x7f5535015ca0
DLOPEN_EXEC_LOADER-> ret val: 2407030
[DEBUG] -> parasite basename: server
[+] calling launch_parasite()
[+] Entry point: 0x7f5534cdcec5
[+] Thread injection succeeded, tid: 5948
[+] Saruman successfully injected program: ./server
[+] PT_DETACHED -> 5942

Terminal 1


ryan@elfmaster:~/git/saruman$ ./host
I am the host
I am the host
I am the host
I am the host
I am the host

Terminal 2


ryan@elfmaster:~/git/saruman$ telnet localhost 31337
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Password: password
Access Granted, HEH


Welcome To Gummo Backdoor Server!

Type 'HELP' for a list of commands

command:~#

Terminal 1


ryan@elfmaster:~/git/saruman$ ./host
I am the host
I am the host
I am the host
I am the host
I am the host
I am the host
I am the host
I am the host
I am the host

Terminal 3


ryan@elfmaster:~/git/saruman$ ps auxw | grep server | grep -v grep
ryan@elfmaster:~/git/saruman$

As shown above we execute a backdoor program called './server' inside existing process './host'

SARUMAN NOTES:

You can run as many programs in a single process address space as you want. I was able
to get 3 additional executables all running in the same process (I did not test more
It is worth noting that there appears to be a bug (Which I will fix) where the executable
program you are injecting, must have a filename that is a multiple of 4 bytes

2014 - Dwarf/ELF .eh_frame parsing for function identification (IDA Plugin coming soon!)

-Get eh_frame parsing source code

Description:
I have recently been wanting to find a better way to map out and profile the functions in a binary
for Maya's Veil and other projects. I was aware of the .eh_frame section (Or GNU_EH_FRAME segment)
in ELF executables, but didn't realize that even programs compiled without exception handling
contain FDE (Frame description entries) in this section. I wrote some code to accomplish getting
each function address and size within an executable. This code requires that you install libdwarf
and libelf before compiling it. What are the implications of this code? That you do not need a symbol
table to find the location and size of functions!

Example


ryan@elfmaster:~/eh_frame$ readelf -s test | grep FUNC | grep GLOBAL
1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (2)
45: 0000000000400590     2 FUNC    GLOBAL DEFAULT   13 __libc_csu_fini
46: 00000000004004ed     6 FUNC    GLOBAL DEFAULT   13 func1
50: 0000000000400594     0 FUNC    GLOBAL DEFAULT   14 _fini
51: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@@GLIBC_
56: 00000000004004f3     6 FUNC    GLOBAL DEFAULT   13 func2
57: 0000000000400520   101 FUNC    GLOBAL DEFAULT   13 __libc_csu_init
59: 0000000000400400     0 FUNC    GLOBAL DEFAULT   13 _start
61: 00000000004004f9    26 FUNC    GLOBAL DEFAULT   13 main
65: 00000000004003a8     0 FUNC    GLOBAL DEFAULT   11 _init

ryan@elfmaster:~/eh_frame$ ./eh_frame test
Function size: 48 Function Addr: 4003d0
Function size: 42 Function Addr: 400400
Function size: 6 Function Addr: 4004ed
Function size: 6 Function Addr: 4004f3
Function size: 26 Function Addr: 4004f9
Function size: 101 Function Addr: 400520
Function size: 2 Function Addr: 400590

As you can see all of the actual functions that I wrote (main, func1, func2) are all
found when running my eh_frame parsing code. (I believe any function with stack displacement will be found)

2014 - Davinci self-decrypting seals (Self protecting data) beta release 2

-Get davinci seal source code (Protected by davinci)

davinci.tgz.dvz.sig

MD5: 51a608f18f4d2ea1fc523cf568978077 davinci.tgz.dvz

NOTE: To get davinci download the link above, and run: chmod +x davinci.tgz.dvz; ./davinci.tgz.dvz d4v1nc1 > davinci.tgz

Description:
Davinci self-seal, is a relatively simple way to protect files. Davinci generates an
output file that is an executable which protects the data, and self-decrypts.
The output executable is tamper and debug resistant using basic watermarking and
tracing techniques. Davinci was dreamed up and created in a 3 hour period and is therefore
only a POC. The idea though, self protecting files can be extrapolated upon and
augmented with more features than Davinci currently has. Data attestation and proper encryption
will be added soon, this is only a prototype. NOTE: Currently davinci can only handle
data up to about 8MB. This limitation can be easily changed by modifying the payload_meta_t attributes

NOTE: Latest version output executable isn't working with UPX so the output exe's are huge, fixing this...

Use cases:

Protecting video game data files from reversing/modification
On-the-fly at purchase time installers for software
Virus dropper (lol)

Features:

64bit Linux support (tested on ubuntu)
Creates self-decrypting data archives.
Password protection is optional (Recommended though)
Anti-debugging features (Prevents ptrace)
Anti-tamper (Very minimal)
Uses UPX to compress the davinci output executable (If UPX is available)
Allows for low overhead to easily pass files back and forth
The stub executable is compiled without any library linkings (Self contained)
Uses basic code and data watermarking to enforce resistance against cracking

Example:


ryan@elfmaster:~/dev/davinci$ ./davinci msg.txt msg.drm p4ssw0rd -r
payload_meta_t is 0x800110 bytes
[+] The user who executes msg.drm must supply password: p4ssw0rd
[+] Encoding payload data
[+] Encoding payload struct
[+] Building msg program
[+] utils/stripx exists, so using it to strip section headers off of DRM archive
[+] /usr/bin/upx exists, so using it to compress msg.drm
Successfully created msg.drm
ryan@elfmaster:~/dev/davinci$ ./msg.drm p4ssw0rd
man this is a secret msg



 Another example where we protect a tar archive

ryan@elfmaster:~/dev/davinci$ ./davinci test.tgz test.tgz.drm p4ssw0rd -r
payload_meta_t is 0x800110 bytes
[+] The user who executes test.tgz.drm must supply password: p4ssw0rd
[+] Encoding payload data
[+] Encoding payload struct
[+] Building msg program
[+] utils/stripx exists, so using it to strip section headers off of Davinci ELF file.
[+] /usr/bin/upx exists, so using it to compress test.tgz.drm
Successfully created test.tgz.drm
ryan@elfmaster:~/dev/davinci$ rm test.tgz
ryan@elfmaster:~/dev/davinci$ ./test.tgz.drm > test.tgz
This message requires that you supply a key to decrypt
ryan@elfmaster:~/dev/davinci$ ./test.tgz.drm p4ssw0rd > test.tgz
ryan@elfmaster:~/dev/davinci$ tar zxvf test.tgz
test/
test/b
test/a
test/c

2014 - Mayas Veil: Linux ELF binary protection and anti-exploitation

Description:
Maya's Veil is the new Linux software protection agent I have been designing.
Maya uses binary instrumentation for intelligent control flow and runtime security
providing both encryption/obfuscation, and anti-exploitation mechanisms that utilize
control flow integrity combined with intelligent tracing, to prevent ROP attacks.
It is still in very early design phases, but I recently just completed some of its primary
components and wanted to share. Maya may become available to interested parties in the near
future. Please contact me to schedule a potential demo.

Features:

Binary protection/hardening
On-the-fly function decryption/re-encryption; each function has a seperate crypto key (Complete [TR3])
Autonomous debugging [Intelligent self tracing instrumentation with ptrace()] (Complete [TR3])
Each ELF Section is encrypted with its own key, each key is encrypted with a master whitebox crypto algo (Complete [TR2])
A 3rd layer of encryption which can also handle loading of encrypted shared libraries (Incomplete)
Robust anti-debugging with interdependent anti-tamper mechanisms: Strong anti-ptrace/anti-debugger (Complete [TR4])
Inherent anti-emulation qualities, with optional explicit anti-emulation (Affects performance and stability some) (Complete [TR2])
Utilizes intelligent autonomous execution technology as the primary engine that is Maya's Veil
Anti Tamper technology
Maya prevents memory injection (Such as attacks done with ptrace) completely.
Self infection discovery. A maya protected binary can detect static modifications and virus anomalies in itself.
Functions and code are layered with protection, and only decrypt for the period that they are in use.
Maya's runtime engine is a self-debugger which completely eliminates userland debugging or ptrace interaction from attackers.
Maya stores sensitive runtime information such as keys, within an encrypted heap.
Maya protects sensitive function pointers (Such as those in .ctors/.dtors/.got) from being overwritten)
Anti Exploitation technology
- Control flow integrity with intelligent execution tracing to eliminate exploitability of inherent bugs (Complete [TR2])
- ROP Protection
- Encrypted shared libraries with function level decryption/encryption prevents gadgets
- Control flow integrity prevents invalid returns (Complete [TR2])
- Protects against: ret2PLT, ret2libc, etc. (Complete [TR2])
- HEAP Exploitation prevention: Enforces read-only Relocations (I.E .got, .dtors) (Complete [TR3])
Optional high level obfuscation techniques
Uniquely obfuscated section headers (For diverting/confusing static analysis) (Complete [TR4])
Uniquely obfuscated symbol table re-ordering for confusing static analysis (Complete [TR4])
Resistant to code injection attacks on-disk and in memory
- Runtime code injection attacks that utilize ptrace will not work
- Highly resistent to binary modifcations (See self-infection discovery)
Other Features/Goals
Works with dynamically linked executables (Complete)
Handles multi-threaded applications (Partial complete [TR2])
Currently works on x86_64, porting to ARM, and MIPS.
It is purely userland and requires no kernel patches.

Example:
Simple unprotected program


elfmaster@codebox:~/maya_drm$ ./test
ElfMaster
1 2 3
0 * 2 = 0
1 * 2 = 2
2 * 2 = 4
My name is: ElfMaster

The same program protected with Maya (Debug logging compiled in)


elfmaster@codebox:~/maya_drm$ ./test.maya
[MAYA] [in trace_thread()] bootstrap.rsp: 98ad818
[MAYA] Decrypting function call (__libc_csu_init)(4007f0) origByte(48) with key: 1a4b596f455d384685b546b46551e5c
[MAYA] Encrypting function call (__libc_csu_init)(4007f0) with key: 1a4b596f455d384685b546b46551e5c
[MAYA] Decrypting function call (main)(400776) origByte(55) with key: 59595c57d5a19525045783f5a515642
[MAYA] Decrypting function call (hello)(4006f7) origByte(55) with key: ec102daa12491f307191e245a125b23
[MAYA CONTROL FLOW] Safe ret instruction ocurred to expected target: 0x4007a1
ElfMaster
[MAYA] Encrypting function call (hello)(4006f7) with key: ec102daa12491f307191e245a125b23
[MAYA] Decrypting function call (test)(40069d) origByte(55) with key: 371e2e183542851115862ae5ae63718
1 2 3
0 * 2 = 0
1 * 2 = 2
2 * 2 = 4
[MAYA] Encrypting function call (test)(40069d) with key: 371e2e183542851115862ae5ae63718
[MAYA CONTROL FLOW] Safe ret instruction ocurred to expected target: 0x4007b5
[MAYA] Decrypting function call (print_name)(400711) origByte(55) with key: b493a92591c422a1e3b353927744f2c
My name is: ElfMaster
[MAYA] Encrypting function call (print_name)(400711) with key: b493a92591c422a1e3b353927744f2c
[MAYA CONTROL FLOW] Safe ret instruction ocurred to expected target: 0x4007b5

elfmaster@codebox:~/maya_drm$ gdb -q test.maya
"/home/elfmaster/maya_drm/t.maya": not in executable format: File format not recognized
(gdb) quit
elfmaster@codebox:~/maya_drm$ ltrace ./test.maya
ltrace: Couldn't find .dynsym or .dynstr in "./t.maya
elfmaster@codebox:~/maya_drm$ strace ./test.maya
WARN:P_ATTACH; The Veil of Maya shall vail still, and conceil what the debugger might reveal
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=12832, si_status=0, si_utime=0, si_stime=0} ---
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x1} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

elfmaster@codebox:~/maya_drm$ qemu-x86_64 ./test.maya
Segmentation fault (core dumped)
elfmaster@codebox:~/maya_drm$

Maya uses binary instrumented control flow technology for ROP mitigation

Example of exploiting a stack overflow in a vulnerable program:


elfmaster@Ox31337:~/maya_drm$ ./exploit.sh
# whoami
root

Now with the program protected by Maya:


elfmaster@Ox31337:~/maya_drm$ ./exploit.sh
[MAYA CONTROL FLOW] Detected an illegal return to 0x41414141, possible exploitation attempt!
Segmentation fault

Illustration of Maya's ELF instrumentation method

If this technology interests you please don't hesitate to contact me.

2013 - FTRACE (ELF Function Tracing) for Linux x86_32/x86_64. (TR4)

- Get Ftrace v0.2

Features:

Function call tracing
Shows function args as strings
Shows function args as pointer to either heap, stack, or data segment
Distinguishes local calls from PLT (shared library) calls. Shows both.
Return value printed in execution sequence
Lists program dependencies
Does not rely soley on symbols, therefore working on stripped ELF Binaries.
Complete control flow displaying branches within ELF sections (Such as .plt)

Ftrace uses:

Reverse engineering complex programs
Hostile programs: Malware analysis (Although limited by its use of ptrace)
Debugging software

Screenshot of ftrace:

2013 - ELF Demon (Process possession) v0.1 (TR2)

-Get ElfDemon v0.1 source code

Description:
This project was stemmed from an idea I had some years ago, and I recently worked out some
code for fun. The idea is to inject a dynamically linked executable into an existing process,
and take control. Once execution of the parasite executable finishes, it passes control back to the
original program, thus 'possessing' the process. The goal being a form of anti-forensics
or data contraception, since the program that is being injected does not require its own
process ID. This is much different than shared library injection for several reasons.

1. The code being injected is not position independent code, and therefore handling manual
relocations is tricky, and requires disassembling instructions that must be changed, such as
a 'mov' instruction that moves an address into a register; if this address references the old
memory base, then it must be fixed up to handle the relocation. This is tricky and error prone,
and would be ideal with a PIE executable since they can be relocated easily. The reason relocation
is necessary is because we don't overwrite the original program that is running in memory, since
we want to pass control back to it when the 'evil' executable is done running.

2. The program we are injecting is dynamically linked, to libc at a minimum. If the program were
to be executed by execve() it would go through the full dynamic linking and loading process. The
ELF Demon software handles all of this, including the dynamic linking, by fixing up the PLT/GOT
of the 'evil' program with addresses that we resolve from the libc that is already mapped into
memory.

Further goals (Some nearly accomplished):

Handle injecting executables that have dependencies beyond just libc
Inject a thread with sys_clone(), that allows the malicious executable
and the host to run concurrently in the same address space.

elfdemon requires udis86 disassembler library to be installed on your system. Read the README file for more details.

2011 - VMA Voodoo (DARPA CFT) (TR2)

VMA Voodoo is a Linux userland memory forensics and monitoring software
It was funded through the DARPA CFT program, and titled 'Linux VMA Monitor'.

Features:

Process memory infection heuristics engine (Detection and disinfection) aware of:
- PLT infections
- PLT/GOT infections
- Function trampolines
- Shimmed control flow changes of many types
- Illegal code modifications
- Shared library injection (Through shellcode/dlopen/LD_PRELOAD)
- Packed executables
- Injected modules
- Misc. VMA anomalies
ELF Binary integrity checker
ELF Binary virus detection/disinfection engine aware of:
- Text segment padding, and reverse padding infections
- Data segment infections
Proces image forensics features:
- Process image snapshots
- Reconstruction of process image back into functional executable
- Unpacking of protected executables
HIDS Daemon:
- Runs 24/7 scanning all process image
- Reports malware through classification system
- Can update admins through email notifications
GTK GUI:
- Incorperates the primary detection/disinfection features
- Very simple to use (And still very incomplete)
- Logging/Messaging system for intrusion detection

Limitations:

Currently works on Linux 32bit Only
Snapshot metadata system not complete

VMA Voodoo source code may be released at an undetermined date...

Many more projects coming, my goal is to add atleast one a day. It takes time
to clean code up, add README's etc.

2010 - Kprobe instrumentation based kernel patching code (TR1)

-Get Kprobe rootkit (jkit v0.1) source code

Description:
The Jkit rootkit (Meaning jprobe rootkit) is the product of a phrack paper I wrote
in 2010 called Linux kprobe instrumentation (Phrack Paper)
and is one of two pieces of code presented in the paper illustrating how the linux kernel
debugging functionality can be used for modifying kernel memory and hijacking control flow
which proves useful for both security professionals and attackers. I have at times used this
method to reliably hook functionality into the kernel while implementing different types of LKM
security patches over the years. As an example to the hacker community I wrote a small rootkit
that performs file hiding by hooking a combination of functions, and redirecting file streams.
For more information read the paper linked above titled Linux kprobe instrumentation

2008 - Quenya - Interactive ELF Binary hacking and Reversing interface (TR2)

-Get Quenya v0.1 source code

Description:
Quenya is a reversing system, similar to eresi's elfsh, but not nearly as stable.
It was a project I started and completed in a months time, and was the manifestation of my
strong desire to both learn ELF hacking better, as well as to have a simple way to modify and
analyze process images and binaries. The name Quenya is named after J.R.R Tolkeins ELF language;
One being Sindarin, and the other Quenya. Quenya has many fun and interesting features and also
comes with some code for some different viruses and infectors.

Quenya Features:

ELF Header/Phdr/Shdr/Sym modifications
- Add sections, segments, symbols
Relocatable code injection
Function hijacking
Process image reconstruction
Malware unpacking (UPX, Elfcrypt, etc.)
Disassembly and code modification (Cracking software etc.)
Built-in uselrand exec
readelf features (To view and analyze headers, symbols, relocations, etc.)
Interactive command line
Utilizes libptrace (Very minimally, as it has awesome features) written by Scrippie

Example of injecting obj.o into host executable to hijack puts() with evil_puts()


[Quenya v0.1@slum.org] reloc obj.o host
0x0804854c  addr: 0x804853a
0x080484ec _write addr: 0x8048546
Injection/Relocation succeeded

[Quenya v0.1@slum.org] hijack binary host evil_func puts
Attempting to hijack function: puts
Modifying GOT entry for puts
Succesfully hijacked function: puts
Commiting changes into executable file
[Quenya v0.1@slum.org] quit
ryan@slum:/home/ryan/quenya$ ./host
HAHA puts() has been hijacked bitch!

2008 - LPV -> Linux ELF Padding Virus (TR2)

-Get LPV Virus source code

Description
This little virus was my first actual ELF virus. Its behaviour is that
once it has ran, it injects itself into the first uninfected executable file
that it sees (Within the CWD). Any file that gets infected by this virus
will infect other executables, upon runtime. It is a traditional virus in
the sense that it copies itself to other programs. It uses Silvio's original
method of utilizing a PAGE of padding between the text and data segment.
It is written in almost 100% C, and was tested on 32bit Linux years ago.
To compile: gcc -nostdlib lpv.c -o lpv

2008 - ElfScure (Section header obfuscation technique)(TR3)

-Get ElfScure source code

Description
ElfScure is a simple tool I designed along time ago (Same as the 'sht randstrtab'-
feature in Quenya. It does a high level obfuscation technique that randomly orders the
strings of the section header string table. After one elfscures a binary, readelf -S
will reveal that the sections are in completely random order which leaves a reverse engineer
confused as to where things are at, I.E the .plt section will not longer appear to reflect the PLT code.
This trick can also be used to randomize symbol names, which is one of the high level tricks
used as an option in a neat Software Protection agent I am writing right now.

2008 - AVU (Anti Virus UNIX) (TR2)

-Get AVU 32bit source code

Description
AVU is my first attempt at Linux ELF malware detection software. When I decided to write it
I had the firm belief that something of this nature was sorely needed. Viruses in Linux usually
come complimentary to system compromise, and can therefore me a good metric for knowing whether
' your system has been rooted. UNIX Virus technology is often utilized to backdoor programs such
as an LDAP daemon, or some type of program that authentication or credentials data might be passed
through, therefore hijacking functions on-disk or in memory can be useful to an attacker trying
to acquire more information about the network. There are myriad reasons behind a UNIX Virus, but
no matter the reason, AVU is very effective at finding and possibly disinfecting some of these.
AVU is prototype code, and a mere trifle compared to VMA Voodoo (DARPA CFT project), which is
listed above. AVU has nevertheless served me well over the years. I will release the 32bit version
since the 64bit has some issues, please feel free to port or extend.

AVU Features:

Runs on 32bit Linux (Can be modified for other UNIX like OS's)
ELF Binary integrity checker
ELF virus heuristics detection engine
ELF virus disinfection engine
- Text segment padding and reverse padding parasite detection/disinfection
- Data segment parasite detection/disinfection
Unpacks UPX, and other protected binaries.
Detects memory infections that modify the program code (text)
Upon disinfection will Quarantine the original file into a password protected zip.

AVU example, disinfecting a program 'VirtualBox' containing a malicious parasit


sh-4.2$ ./avu ~/bin_dir/
-= warning =-
executable: /home/ryan/bin_dir/VirtualBox
entry point 0x80628cc may not be in .text
Found entry point in section: .eh_frame
Detected A parasite between text & data segment
Type: Text segment padding virus (padding infection)
Infected section: .eh_frame
Parasite Offset: 108748
Found original entry point: 0x804c1b4
Attempting to reverse infection and rewrite the binary

Successfully backed up and quarantined /home/ryan/bin_dir/VirtualBox into .avu/
Sucessfully disinfected the binary

Malware analysis Summary:

AVU discovered 1 virus-infected binary
AVU Sucessfully removed the parasite from 1 file

2009 - ELF Packer v0.3 (Software protection for static ELF executables) (TR1)

-Get ELF Packer v0.3 source code

Description
This is one of several early packers that I coded, and is nothing real unique
It encrypts an ELF executable using RC4 encryption, and wraps the executable in a stub which loads
and decrypts the program at runtime, userland exec style. If I recall it works on both 32bit and
64bit executables, and will work with dynamic linked executables in some instances, as the code that
sets up the auxillary vector is flaky. On the topic of software protection, I am currently designing
a very hardened Linux ELF software protector that works with all 64bit executables, and provides highly
effective anti-debugging techniques, control flow integrity, and function level encryption/re-encryption.
More information on Maya will be revealed soon. Meanwhile this ELF Packer is a general example of polymorphic
executable wrapping for those who are interested in such things.

2009 - kD (kernel Detective) Linux/FreeBSD kernel rootkit HIDS (TR2)

-Get kernel detective source code

Description
This software is a host intrusion detection system for Linux and FreeBSD that uses myriad techniques
to detect kernel rootkits. Its abilities range from detecting syscall table modification, to the
notorious debug register rootkits. It has a daemon called kmtd (Kernel malware tracker daemon)
that runs 24/7, scanning kernel memory, and utilizing safe copies of vmlinux and System.map as known good
code and memory data. Another daemon kmond runs hidden and does not show up in the process list
and serves the purpose of monitoring kmtd to make sure that it isn't altered or killed. It restarts kmtd
upon a crash or failure of the daemon. Forensics details are emailed (insecurely as of now) to the sysadmins
listed in the configuration file. The configuration process and also live monitoring sessions are performed
by a GUI (jKMT) written in Java by Sean Harney (chrak), who is skilled and talented friend of mine; all
communication between GUI and Daemon happen over SSL. The daemon kmtd periodically runs an external set of
custom programs that each are designed to investiage a specific aspect of the kernel. Here is a list of
the special functionality tools.

Kernel forensics tools used by kD

/dev/kmt_mem driver
- Gives read access to kernel memory, and will only allow the PID tied to the inode of kmtd to access it.
- Can give write access for disinfection process.
- Is an LKM driver for Linux (FreeBSD has unrestricted /dev/kmem)
kmemstat
- Resolves alternative runtime patching info (.altinstructions)
- Applies alternative code patch knowledge to heuristics
- Compares text segment of kernel memory to text segment of vmlinux
- Can analyze kernel datatypes and functions by address or symbol name
- Displays infection code upon detection, and can disinfect through custom kpatch.
dr_chk
- Debug register rootkit detection
- Detects patched do_debug (int1) handler
- Can detect many, but not all DR rootkits.
ktraq
- Detects (And disinfects) sys_call_table modification
- Utilizes /proc/kallsyms or System.map
dps
- Detects phony sys_call_table's such as those used by suckIT
- Simple, but effective
ksymstat
- Kernel symbol interception detection
- Detects trampolines/hooks
- Scans every single function in the kernel for hooks

ExploreConsciousness

About

Bit Lackey - A servile follower of bits
Bitlackeys research is an independent group of entities who's interest reside in the idea/paradigm
that computer security is an Art, a philosophy, and a beautiful representation of freedom
of thought, information, and collective forces that drive technology with computer science
to revolutionary propulsions. These philosophies, and research principles result in software
and technology that allows us as institutions or individuals to secure our privacy so that it
is possible to harden our systems, and strengthen our minds towards the myriad forces of wicked
that daunt our prospects and threaten our chance of enlightenment.

Philosophy
Explore consciousness, research our minds, propogate research, write code, and take care of our own.
Kwizatz Coderack - 2014 (aka elfMaster)

Bitlackeys Research

The Now

Research & Code

2020 - Arcana Technologies: Linux threat detection

2020 - Modern ELF Infection Techniques of SCOP Binaries

2019 - Linux/ UNIX ELF binary infections / injectors

2018 - ELF Binary voodoo workshop, October 27th-28th

2018 - Fixing ELF static binaries with ASLR+RELRO support

2016 - Another tale of ELF Origin (SunOS ELF exploitation)

2016 - Learning Linux binary analysis

2016 - Skeksi Virus for X86_64 Linux

Disclaimer

Philosophy

General about

Virus specifications

Infection behaviour

Points of strength

Nuances and notes

Source code requests

Shouts

Usage

Disinfection

Here is a screenshot of the Virus in action

-Get skeksi virus binary

-Get skeksi disinfector program

2015 - Advanced Linux kernel malware analysis and detection software

ELF Binary analysis workshop with ElfMaster and Leviathan Security Group

Visit the official site

2014 - An informal analysis of the Linux x86_64 ELF Virus: Retaliation (Engineered by JPanic)

The analysis is available in text format here

2014 - Extending the ELF core file format for forensics snapshots (New Paper!)

Read the paper here

Example of the ECFS utility taking a snapshot of a stripped executable

2014 - Sherlocked - Universal script packer/protector [TR3]

-Get sherlocked source code

Sherlocked V4 released 11/30/2014 - passwd support improved, and allows for script cmdline args when using a passwd

2014 - Saruman - anti-forensics executable injector [TR2]

-Get Saruman source code

Terminal 1

Terminal 2

Terminal 1

Terminal 2

Terminal 1

Terminal 3

As shown above we execute a backdoor program called './server' inside existing process './host'

SARUMAN NOTES:

2014 - Dwarf/ELF .eh_frame parsing for function identification (IDA Plugin coming soon!)

-Get eh_frame parsing source code

2014 - Davinci self-decrypting seals (Self protecting data) beta release 2

-Get davinci seal source code (Protected by davinci)

davinci.tgz.dvz.sig

MD5: 51a608f18f4d2ea1fc523cf568978077 davinci.tgz.dvz

NOTE: To get davinci download the link above, and run: chmod +x davinci.tgz.dvz; ./davinci.tgz.dvz d4v1nc1 > davinci.tgz

NOTE: Latest version output executable isn't working with UPX so the output exe's are huge, fixing this...

2014 - Mayas Veil: Linux ELF binary protection and anti-exploitation

Maya uses binary instrumented control flow technology for ROP mitigation

Illustration of Maya's ELF instrumentation method

2013 - FTRACE (ELF Function Tracing) for Linux x86_32/x86_64. (TR4)

Screenshot of ftrace:

2013 - ELF Demon (Process possession) v0.1 (TR2)

-Get ElfDemon v0.1 source code

2011 - VMA Voodoo (DARPA CFT) (TR2)

2010 - Kprobe instrumentation based kernel patching code (TR1)

-Get Kprobe rootkit (jkit v0.1) source code

2008 - Quenya - Interactive ELF Binary hacking and Reversing interface (TR2)

-Get Quenya v0.1 source code

Example of injecting obj.o into host executable to hijack puts() with evil_puts()

2008 - LPV -> Linux ELF Padding Virus (TR2)

-Get LPV Virus source code

2008 - ElfScure (Section header obfuscation technique)(TR3)

-Get ElfScure source code

2008 - AVU (Anti Virus UNIX) (TR2)

-Get AVU 32bit source code

AVU example, disinfecting a program 'VirtualBox' containing a malicious parasit

2009 - ELF Packer v0.3 (Software protection for static ELF executables) (TR1)

-Get ELF Packer v0.3 source code

2009 - kD (kernel Detective) Linux/FreeBSD kernel rootkit HIDS (TR2)

-Get kernel detective source code

Screenshot of kernel Detective GUI detecting a debug register rootkit!

2009 - PAPER: Modern day ELF Runtime infection via GlobalOffsetTable poisoning