DDexec is a Technique To Run Binaries Filelessly And Stealthily On Linux Using Dd To Replace The Shell With Another Process. In Linux in order to run a program it must exist as a file, it must be accessible in some way through the file system hierarchy (this is just how execve()
works). This file may reside on disk or in ram (tmpfs, memfd) but you need a filepath. This has made very easy to control what is run on a Linux system, it makes easy to detect threats and attacker’s tools or to prevent them from trying to execute anything of theirs at all (e. g. not allowing unprivileged users to place executable files anywhere).
But this technique is here to change all of this. If you can not start the process you want… then you hijack one already existing.
Pipe into the ddexec.sh
script the base64 of the binary you want to run (without newlines). The arguments for the script are the arguments for the program (starting with argv[0]
).
Here, try this:
base64 -w0 /bin/ls | bash ddexec.sh /bin/ls -lA
There is also the ddsc.sh
script that allows you to run binary code directly. The following is a “Hello world” shellcode.
bash ddsc.sh -x <<< “4831c0fec089c7488d3510000000ba0c0000000f054831c089c7b03c0f0548656c6c6f20776f726c640a00”
or
bash ddsc.sh < <(xxd -ps -r <<< “4831c0fec089c7488d3510000000ba0c0000000f054831c089c7b03c0f0548656c6c6f20776f726c640a00”)
And yes. It works with meterpreter.
Tested Linux distributions are Debian, Alpine and Arch. Supported shells are bash, zsh and ash over x86_64 and aarch64 (arm64) architectures.
This script depends on the following tools to work.
dd
bash | zsh | ash (busybox)
head
tail
cut
grep
od
readlink
wc
tr
base64
If you are able to modify arbitrarily the memory of a process then you can take over it. This can be used to hijack an already existing process and replace it with another program. We can achieve this either by using the ptrace()
syscall (which requires you to have the ability to execute syscalls or to have gdb available on the system) or, more interestingly, writing to /proc/$pid/mem
.
The file /proc/$pid/mem
is a one-to-one mapping of the entire address space of a process (e. g. from 0x0000000000000000
to 0x7ffffffffffff000
in x86-64). This means that reading from or writing to this file at an offset x
is the same as reading from or modifying the contents at the virtual address x
.
Now, we have four basic problems to face:
This problems have solutions that, although they are not perfect, are good:
mem
file of the sell with write permissions… so child processes that use that fd will be able to modify the shell’s memory.maps
file or any other from the procfs in order to gain information about the address space of the process.lseek()
over the file. From the shell this cannot be done unless using the infamous dd
.The steps are relatively easy and do not require any kind of expertise to understand them:
execve()
:syscall
file the address to which the process will return after the syscall it is executing.mem
we can modify unwritable pages).read()
by said “shell”code).Oh, and all of this must be done in shell scripting, or what would be the point?
SpyAI is a sophisticated form of malware that leverages advanced technologies to capture and analyze…
The Proxmark3 is a versatile, open-source tool designed for radio-frequency identification (RFID) security analysis, research,…
The "Awesome Solana Security" collection is a comprehensive resource designed to help developers build more…
The "IngressNightmare" vulnerabilities, disclosed in March 2025, represent a critical set of security issues affecting…
AdaptixC2 is an advanced post-exploitation and adversarial emulation framework designed specifically for penetration testers. It…
Bincrypter is a powerful Linux binary runtime crypter written in BASH. It is designed to…