| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The import list is alphabetized and listed one per line, to prevent this
from becoming unwieldy as more modules are introduced.
__all__ has been shown to be redundant, given that explicit imports are
now done, so it is removed.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
class Payload is a tool for constructing stack-smash payloads and ROP
chains. Its design is intended to abstract away some of the more
tedious details of crafting a payload.
Payload utilizes mem.Symtbl internally to optionally manage a collection
of named offsets into its own buffer (these are usually in reference to
entities appended to the payload via its main API). Alternatively, the
API calls to append any entity will return the address of that entity as
well.
Returned (and looked-up) addresses are relative to the beginning of the
payload by default. However, when the payload is constructed with a
known base address value, these become absolute. This is useful for
reusing addresses later in the payload body.
class Placeholder is designed to be functionally compatible with
bytearrays and bytestrings. When constructed, they take the value of
'zero', according to the current arch config. This facility enables
some API's to detect whether a dummy value was passed as a required
argument when said argument _may_ be unnecessary in niche situations.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
This was the name I had originally intended to use while factoring
architecture details out to the global scope. It's not terribly
different, but I feel the new context warrants some additional clarity.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Apparently python won't run garbage collection on stuff owned by the
exec context if you define a function in the exec. This can lead to
random leaks, but it is most impactful in daemon mode. If the globals
dictionary given to exec isn't cleaned up, there will be a random
reference to comm that still exists. This holds a reference to the
Pipes object which prevents it from getting cleaned up before we try to
make a new one. Making a new one needs the fifos to have been cleaned
up, so it relies on the fact that the old one was supposed to be
cleaned up.
The most straightforward and non-intrusive way I could think to fix this
was to just manually run the garbage collector after exec. This is able
to find the leaked references and clean it all up.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
The handling from the daemon mode code will also work in the process and
pipes cases. Putting it in a common location removes the need for the
outer try/except. It is also easier to read/maintain in general.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
If the user's script contains
from sploit import *
then the exported 'comm' communication object is clobbered by the 'comm'
source module. Switching the name to 'io' avoids this issue, is more
to the point, and is even fewer characters to type.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Rather than implicitly inheriting names in scope for the user-script,
this collection is sanitized and we only export the 'comm' communication
object. This seems to be a safer way to operate and addresses an issue
with sub-scopes in the user's script not functioning properly.
(Previously, user-defined functions did not have access to globals, or
library functions.)
Additionally, the user's code is now passed through compile() to attach
the original file name. This is useful for debugging / diagnostic
situations, to make it more obvious if a crash originated from the
user's script.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Rework Sploit Tool
Rewrite core functionality with new design and UX considerations.
Organize functionality into separate modules.
Add support for various use cases including:
-pip install
-running the installed sploit command
-running the sploit.py script
-running python -m sploit
-importing the modules from the python interpreter
Add a "daemon" mode which will continue to rehost the exploit script on
the same pipes until you are done.
* tag 'pull-sploit-rework' of https://github.com/Dusoleil/lib-des-gnux: (25 commits)
Change behavior for import sploit
Add mem module for calculating memory offsets
Handle Process destr when Process constr throws
Reuse read() and readline() in the until() API
Add readall() which reads until EOF
Move comm toggles for consistency
Add arch config module
Add Config Toggles for Read/Write Extra Behavior
Rewrite interact() to be Single Threaded
Add Convenience Utility to readuntil()
readlineuntil() Operates on an Array of Lines
Correct read() Semantics
Throw a BrokenPipeError on Broken Read
Formatting
Handle Exceptions in Daemon Mode
Allow Exit with Ctrl+C without a Stacktrace
Move "Read Rest of Output" Out of Destructor
Better Shutdown Process for Pipes
Better Shutdown Process for Target Program
Better Info Messages
...
|
|
The statement import sploit will now import all of the sploit modules
under the sploit namespace.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Add Arch class which specifies wordsize, endianness, alignment, and a
nop code for an architecture.
Add a couple predefined architectures for x86 and x86_64
Add a "configured" architecture which is set to x86_64 by default.
Added btoi and itob functions which will convert to and from bytes and
ints based on the current architecture config
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
logonread can enable/disable logging the result of every read
flushonwrite can enable/disable automatically flushing every write
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
readuntil() and readlineuntil() will now automatically bind() a
predicate and given arguments to produce the single function predicate
required.
The 'until' module will provide convenience utilities for use with
readuntil() and readlineuntil(). For now, it contains functools.partial
renamed as bind(), lastline() which can call a predicate with the last
element of the array of lines given from readlineuntil(), and simplified
versions of re.search and re.fullmatch renamed as contains and equals.
These allow us to write powerful and legible statements like:
comm.readlineuntil(lastline,contains,b'Enter')
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Instead of only operating on and returning the last line read,
readlineuntil() will now check the predicate against an array of all
lines read and return that array when the predicate is true.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
The BufferedReader's .read() doesn't behave as expected. It reads
EXACTLY size bytes and will block until there are enough available to
read.
os.read() does what we expect. It will read UP TO size bytes and only
block if there is nothing available to read.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
If the user presses Ctrl+C while waiting on a connection, we want to
gracefully exit.
If the user presses Ctrl+C during the script, we want to stop executing
the script and restart the loop.
If any other exception happens during the script, we want to print out
the stacktrace as normal, but continue the loop.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
With the "read rest of output" code in the Comm destructor, it would
continue to read output even in situations where some error happened and
we expect sploit to die or when the user presses Ctrl+C to end sploit.
By moving it to the end of the script running code in main, it behaves
more intuitively.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Handle all of the edge cases when shutting down in Pipes mode.
e.g.
If the pipes are broken (tried to write after the program died)
If the fifos don't exist anymore (sometimes tempfile cleans them up
before the destructor finishes when certain errors happen)
If the object attributes for the streams and fifo paths aren't set (this
can happen if the constructor didn't finish. e.g. the user cancels while
waiting on a connection)
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
If we need to wait on the target program to die, we don't want to just
wait forever with no indication to the user. Instead, only call wait if
the program is still alive, inform the user that we are doing this, and
give them the ability to forcefully kill the target program with Ctrl+C.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Previously, you could specify a directory which must exist under /tmp.
Now, you can give the full path to a directory to be used by Pipes.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
comm.interact() will drop the user into an "interactive" mode where they
can directly control what is sent. A SIGINT (Ctrl+C) will drop the
script out of interactive mode and continue executing the rest of the
script. If the output of the program (input into our script) goes into
a broken state (such as when the target program exits), interactive mode
will automatically exit.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Both new functions check the input for a predicate and keep reading
until the predicate is true.
readuntil() will consume input byte by byte and use the entire string
read to check the predicate. It will then return that entire string.
readlineuntil() consumes input line by line and only uses the last line
to check the predicate. The line that satisfies the predicate is all
that is returned.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
First part of the MVP for the larger Sploit rework effort.
Add project structure, python packaging, basic comms, and "log" hook.
From in or out of the sploit directory, you can run the "sploit.py"
script, run python -m sploit, or import the sploit modules from the
python3 shell.
You can also pip install Sploit and from anywhere you can run the sploit
command, run python -m sploit, or import the sploit modules from the
python3 shell.
Running as a standalone application, Sploit can run in a "target" mode,
a "pipe" mode, and a "pipe daemon" mode. In "target" mode, Sploit will
launch a target program as a subprocess and run an exploit script
against its I/O. In "pipe" mode, Sploit will create named fifos and
wait for a program to connect to them to run an exploit script against
them. In "pipe daemon" mode, Sploit will run similar to the "pipe" mode,
but automatically recreate the fifos with the same name after each
execution.
Basic comm operations of read, readline, write, and writeline are
available to the exploit script.
A "log" hook is executed whenever data is read in from the target
program. This will just print the data out, but it can be configured to
decode it with a specific encoding or you could replace the function for
different behavior.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
This is content from an old repo of mine. I think it makes much more
sense to merge it into lib-des-gnux.
templates/shellcode/ will track any useful shellcode recipes and
contains utilities for building them into ready-to-use payloads.
* shellcode-templates:
Globally ignore all build artifacts
Add Makefile for shellcode templates
Refactor genhex into shelltool
Add sys_exit shellcode templates
Add generic /bin/sh shellcode templates
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
The shell*.asm files are considered the default programs and the
expected use-case for utilizing the templates is to edit these files to
implement the desired shellcode. I figure that literal shellcode makes
the most sense of what to expect by default.
'make all' will assemble and link the shellcode (so it can actually be
directly executed via the output elf files), and feed the disassembly
into shelltool for use elsewhere.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
For convenience, I've rewritten my old shellcode parser program in
Python. It is moved to the shellcode templates dir and renamed to
shelltool.
As a new feature, shelltool will now check the result for NULL bytes and
newline bytes that may cause problems in an exploit.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
