| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Rename all affected files, references to file paths, and module imports
within the code. Since this line of development represents a fork from
the original sploit, a name change is seen as necessary to distinguish
the projects, as well as allow them to be installed side by side.
What does the "n" mean? Great question! You can think of it as meaning
"new sploit" if you want, though that's not quite intended. The name is
simply distinct and easy to pronounce. I had originally settled on
"msploit" (something along the lines of "Malf's sploit"), but this name
is too close to "metasploit" for me - and N is right next to it on the
keyboard.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
This completes the overarching package reorganization changes. The
contents of the top-level "sploit" package's direct children modules are
exported via the package. Explicit imports for sploit's subpackages are
not necessary.
Other package __init__.py files are using relative imports. However,
doing so here causes the hatchling build process to fail. Fortunately,
since this is the top level, absolute paths aren't too long.
The last few modules left in this package have been kept back since they
lack any specific niche, are considered "universally relevant", or are
typically imported so frequently that it makes sense to provide them to
scripts automatically.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
This follows in the package contents export change. Additionally, the
builder package is renamed to "payload".
"payload" is actually the preferred name of this package. It was
previously renamed due to the absurdity of importing
"sploit.payload.payload.Payload()", and the fact that additional modules
were being bundled together so a more broad name _seemed_ desirable.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
This is a package to contain the related Payload and ROP modules, as
well as utility classes. Payload is moved into the new package.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
I assume that the preferred style is to leave one major class each to a
file. In this case, synchronize the names of the Symtbl class and its
containing module. Per PEP8, the module is lowercase, and the class
remains Pascal case.
If other memory-oriented utilities are introduced in the future, we may
wish to move them, as well as Symtbl, back into a subpackage named
'mem'.
Signed-off-by: Malfurious <m@lfurio.us>
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Instead of hard-coding the version into the pyproject.toml, we can
dynamically source it at build time. Ideally, we want to use git
describe as a single authority source on the version. The version is
stored in sploit.__version__ and can be consumed during sploit runtime
or during a build/package to populate the project's core metadata
version in the toml file.
hatchling provides a tool.hatch.version plugin that can read out the
variable during a build/package. Because this variable is populated
from a git command, if the source tree isn't in a git repo, it will
fail. In this case, sploit will report a PEP 440 compliant fake version
"0+unknown.version" to let the user know.
Because a packaged distribution doesn't exist in a git repo, we want to
bake in the version at build time into the package. hatchling provides
a plugin to help with this, but it had some technical limitations that
didn't quite work for our use case. Instead, I added a custom build
hook which will take the version sourced from the package (and by proxy
the git command), and overwrite the __init__.py with a hard-coded
version in the __version__ variable. This means that built/packaged
distributions of this project will have a fixed version hard-coded in
rather than dynamically sourcing from git.
The build hook operates just before the build executes. It seems that
most build/packager front-ends (e.g. build, pip) will just run it in the
current source tree rather than making a temp copy. This means that
when we modify the __init__.py, it is modifying our git tree. Ideally,
we want this to be restored at the end of the build. The build hook
interface allows us to write a hook that happens after the build, but it
won't run in the case of a crash or failed build. Instead, I added a
custom solution to this using a member variable deconstructor. If the
build ends in any way, the original contents of __init__.py are written
back out.
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
Reviewed-by: Malfurious <m@lfurio.us>
|
|
rather than cacheing ELF instantiations, just cache the results of
external commands
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
Signed-off-by: dusoleil <howcansocksbereal@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
