Bitlackeys stypes Research

Releasing research and code from 2007-2014 archives
       Ryan O'Neill A.K.A ElfMaster

The Now

After years of software development, reverse engineering and coding, it dawned on me
that I have not been very forth coming with alot of the code, software and papers that
that I have worked on during my personal research in computer security. I have, put together
an official site to properly give back some of the projects I have worked on
starting in 2007. Many people have played a part in my growth through the exciting world of
the computer hacker subculture, and the security scene as a whole. I am very grateful to all of you
The #bitlackeys guys on efnet have been great, RuxCon, and Phrack staff as well.
A growing number of items will appear under the research list on this site over the next month
A collection of software, tools, research papers, etc. Enjoy... elfmaster [at] zoho [dot] com

Research & Code


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.
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


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.


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...


My incredible fiance Marilyn, who loves the dark crystal, and let me take the time to code this Virus while our 3 month old baby girl was strapped to me in her carrier :) 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.


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


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 - I-KORE (into the kcore): Advanced Linux kernel malware analysis and detection software

This project is new, only 1 month in the making. It is a complete re-write of
the original code from 2009 named Kernel Detective. This new version is significantly
better, and uses an innovative approach of automated analysis with kcore in Linux,
and the merging of my ECFS technology to produce advanced kcore snapshots for forensics
analysis. It is undetermined when and how this software will be released, but one way
or another it will be coming soon... Continue reading for a very preliminary intro
to the software and its capabilities.

ELF Kernel magic (symbol table reconstruction with vmlinux)
The kernel boot image 'vmlinuz' is gz compressed to save space. When decompressed
it is an ELF executable a.k.a vmlinux. This file, vmlinux, is stripped of its
symbol table before it is compressed into vmlinuz. Unless you compile your
own kernel manually, or download a debug kernel image (If your distro provides
that), there is no way to get a vmlinux image with kernel symbols in it--
up until now... with a suite of tools that come with I-Kore, comes the tool
'kdress'. A fitting name since it dresses the symbol table. Once you have a
vmlinux that contains a working ELF symbol table, you may use it for kernel
debugging with GDB and /proc/kcore, or as we have done with some of the I-Kcore
utilities and created an advanced and automated analysis system that uses vmlinux
as a known-good kernel signature.

*** Create our debuggable vmlinux ***

$./kdress vmlinuz-`uname -r` vmlinux`uname -r` [+] vmlinux has been successfully extracted [+] vmlinux has been successfully instrumented with a complete ELF symbol table. $ readelf -s vmlinux | grep sys_call_table 33217: ffffffff81801400 4368 OBJECT GLOBAL DEFAULT 4 sys_call_table 33370: ffffffff81809ca0 2928 OBJECT GLOBAL DEFAULT 4 ia32_sys_call_table

Extended Kcore into an ECFS (Extended core file snapshot) for forensics analysis

For those of you who are familiar with my paper on ECFS, which is an extension
of the existing ELF core format in Linux, to provide more fruitful and easily
attainable information in the core file, specifically for forensics analysis.
Such additions include full section header reconstruction, complete symbol table
reconstruction (Both dynamic and local), etc. The original paper on this technology
can be found on my website ''.

I have taken this idea and applied it to the /proc/kcore file, since it is nothing
more than an ELF core file, but of the kernel instead of a userland process. This
means that with the I-Kcore tool, which is named 'kcore_ecfs' we are able to create
file snapshots of /proc/kcore, which is slightly tricky since it is not just a regular
file, it must be parsed by its ELF headers and segments. The output file is quite large
(~100 - 200GB) and contains memory for the kernels text, data, bss, and memory for
the kernel modules, and certain areas of the vmalloc memory that are required for accessing
data structures such as the task list. This snapshot can be taken and used for
offline analysis.

*** Create an ECFS snapshot of /proc/kcore ***
# ./kcore_ecfs kcore.img ** Notice that there are section headers on our kcore snapshot *** # readelf -S kcore.img here are 6 section headers, starting at offset 0x60404afc: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .note NULL 0000000000000000 000000e8 0000000000001a14 000000000000000c 0 48 4294967295 [ 2] .kernel PROGBITS ffffffff81000000 01001afc 0000000001403000 0000000000000000 WAX 0 0 0 [ 3] .bss PROGBITS ffffffff81e77000 00000000 0000000000169000 0000000000000000 WA 0 0 0 [ 4] .modules PROGBITS ffffffffa0000000 01404afc 000000005f000000 0000000000000000 WAX 0 0 0 [ 5] .shstrtab STRTAB 0000000000000000 60404c7c 0000000000000026 0000000000000000 0 0 0

Detect any modification to kernel memories text segment
Most all kernel malware with few exceptions (Certain DR and VFS rootkits) modify
the text (or code) segment of the kernel. Even more esoteric techniques such as
__ex_table (Exception handling) rootkits, will modify the text segment. In the I-Kcore
suite we have a tool named 'textify' that is able to test the text segment for
discrepencies between vmlinux and kernel memory. In Linux the kernel actually patches
its own code segment at runtime, so our tool intelligently parses those areas as to
not confuse them with malicious patches. Fortunately vmlinux contains several ELF
sections, namely .altinstructions and .parainstructions to show us where these
legitimate patches will take place. Many data structures that hackers tend to modify
exist in the code segment as well, such as the sys_call_table. Even with DR (Debug register)
rootkits it is common for the malware to patch the debug_stack_correct() or debug()
function which will show up with our textify tool.

# ./textify vmlinux kcore.img -a kernel Detective 2014 (C) [+] Analyzing kernel code of entire text segment. [0xffffffff81000000 - 0xffffffff81735e34] [+] No code modifications have been detected within kernel memory (Or you may look at specific areas by specifying which symbol or function to look at) # ./textify vmlinux kcore.img -s sys_call_table kernel Detective 2014 (C) [+] Analyzing kernel code/data for symbol sys_call_table in range [0xffffffff81801400 - 0xffffffff81802510] [+] No code modifications found for object named 'sys_call_table' # ./textify vmlinux kcore.img -s __start___ex_table kernel Detective 2014 (C) [+] Analyzing kernel code/data for symbol __start___ex_table in range [0xffffffff81735fb0 - 0xffffffff81735fb0] [+] No code modifications found for object named '__start___ex_table'

Finding hidden processes
Using I-Kore's kernel structure reconstruction tool, we are able to rebuild
kernel data structures, such as task_struct, in userland, and therefore view
the kernel at a most granular level. One such example is the ability the walk
the kernels task list in order to find hidden processes. I-Kcore has a tool
in the suite named 'taskverse' which is able to traverse the task list in kernel
memory, from userland, through /proc/kcore (Or a kcore snapshot).

*** A tool similar to ps that does not rely on the /proc filesystem *** # taskverse /proc/kcore | tail -n 10 [6201] [S] [evil_daemon] <- hidden process [6224] [S] [kworker/0:1] [6334] [S] [kworker/0:0] [6345] [S] [kworker/u16:1] [6365] [S] [ssh] [6414] [S] [kworker/u16:0] [6415] [S] [kworker/2:2] [6427] [S] [kworker/2:1] [6458] [R] [taskverse] [6459] [S] [tail] #

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]


ELF Binary analysis workshop with ElfMaster and Leviathan Security Group

Visit the official site

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

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

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

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$ ./ hello I am a python script ryan@elfmaster:~/git/sherlocked$ ./sherlocked 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

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 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'


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

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!


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)


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

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)

  • 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

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


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.

  • 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$ ./ # whoami root

    Now with the program protected by Maya:

    elfmaster@Ox31337:~/maya_drm$ ./ [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
  • 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

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

    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'.

  • 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
  • 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

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

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] reloc obj.o host 0x0804854c addr: 0x804853a 0x080484ec _write addr: 0x8048546 Injection/Relocation succeeded [Quenya] 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] 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

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

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

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

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

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 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
  • 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

      Story behind kD:
      This project was alot of fun, and only endured for 2 months. I had to cease working on it
      because I went to work at a company to work on a product that was extremely similar.
      Therefore kD is in a TR2 prototype stage. I wrote the code 5yrs ago, and
      have since improved much as an engineer, but the right technology is in the code to successfully
      detect and identify kernel rootkits in Linux and FreeBSD (Minimal fBSD testing)

      kernel Detective, detects kernel rootkits in Linux. For many obvious reasons this is diffcult
      since the compromised kernel has override control on possibly any functionality that a HIDS
      is using to detect that very compromise. kD takes many precausions, such as
      persistently checking the hash sum of files that it uses for the integrity of finding code
      and memory discrepency. I believe the most confusing challenge I ran into was upon realizing
      that the Linux kernel pathes its own text segment at runtime with alternative runtime
      patching for runtime memory barriers
      . The vmlinux (Which is compressed in vmlinuz)
      can have its section header table rebuilt, and a section called .altinstructions exists which
      contains the code instructions that will be used to in replacement of other code in the kernel
      This decision allows the Linux community to pump out many stock kernels that will run on many
      CPU types, with better tailoring towards specific CPU functionality. kernel Detective must analyze
      the ELF vmlinux altinstructions section (And .altinstr_replace) in order to make sure that any
      discrepencies it finds when analyzing memory, are really hostile and not just modifications made
      by the kernel itself. Many other fun challenges existed as well, it has been many years sine I even
      looked at this code.

      Screenshot of kernel Detective GUI detecting a debug register rootkit!

      detect DRR

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

      -Read paper here on vxheaven!

      Not all of the topics in this paper were new, but it presents a technique to bypass PaX
      mprotect()/mmap() restrictions that prevent attackers from injecting code into a process image.
      The result of the paper is a shared library injector that is able to inject a shared library
      into a process image without using ptrace() to inject shellcode into the target program image.
      Instead we manipulate the vsyscall table into executing the necessary syscalls to
      map a custom shared object into the process image, and then perform function hijacking through the
      global offset table. Improvements definately could have been made by handling relocatable
      code and applying the relocations in memory, but the goal of the paper was really to introduce
      fiddling with the vsyscall table, although there are strong intro sections to ELF, dynamic linking
      and ptrace, as well.

      2008 - ELF Reverse padding injector (A technique for ELF binary patching, or virus)

      -Get reverse text-infector source code

      This small piece of software injects a parasite into an executable using what I feel is
      the best approach when needing to inject large amounts of code. Infact you can inject as much
      as you want. Quenya is capable of this as well, but this is the first code I experimented with.
      The idea is to extend the text segment in reverse (backwards) so that the parasite code exists
      right after the initial ELF file header, and right before the program header table. This allows
      one to inject shellcode, or a relocatable object, or whatever into an executable, and since the
      code is being injected into the text segment, there is no need to mess with the segment permissions
      whereas data segment injections require adding execute perms to the data segment (On NX bit systems).
      This code works on 32bit ELF executables, but I recently used the same algorithm on a 64bit project
      where I really test the limits of advanced instrumentation concepts.

      2008 - Lavren's Quest (32bit Linux RPG Video game) (TR1)

      <-Get Lavrens Quest source code

      When I was about 24 I got kind of interested in video game dev. I was playing alot of
      Fallout 3, and thought it would be fun to design video games instead of security software.
      I spent nearly 2 months writing 'Lavren's Quest' which is a top down RPG that uses mostly
      open source graphics; 3D Rendered into 2D sprites. It uses libSDL for sound and video.
      I hired someone to do the hero graphics, twice. The second guy flaked out, so the main character
      graphics switch between a guy that looks one way (More cartoony) and then another guy who looks more
      professional, depending on what angle you are walking. The game engine is mostly done, but I don't
      have enough graphics to complete it, and I got bored after a shortwhile. There is a spell system
      and an inventory system. You can purchase potions, and receive quests. There is a soundtrack,
      and attack sounds. The game often crashes unexpectedly and is nearly unplayable, and the code
      is a good example of lazy security practices, and poor runtime complexity. But c'mon, it was my
      first video game... oh and I did create a simple scripting interpreter to easily add NPC's, Enemies
      and quests, as I soon realized that hardcoding these in C were a pain in the ass. Here are some
      screenshots, enjoy! NOTE: Run ./ on ubuntu to apt-get necessary sdl stuff, then
      type make (Which uses g++).

      Do not run Lavrens Quest as Superuser!

      The game starts here The village A store The inventory

      Stay tuned for more projects. Atleast 1 daily will arrive over the next month. Cleaning up
      old code and writing README's etc. -Elfmaster



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.

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

Please feel free to contact elfmaster. BitLackeys founder 2006

elfmaster [at] zoho [dot] com