1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
sploit is a process interaction automation tool with software exploitation
focused utilities. It is designed to abstract and simplify process invocation
to enable exploit code reuse across target sources. It includes a limited, but
powerful and intuitive set of utilities and syntactic sugar which make writing
exploits quick and straightforward. This enables rapid prototyping workflows.
Installation
--------------
sploit can be installed to the system with
```
$ pip install .
```
Once installed, sploit can be invoked from the PATH like normal
```
$ sploit exploit.py ./target target_args
```
Usage
------------
sploit has two main modes of operation: Process and Pipes.
A sploit script can be run against a specific command in Process mode. This
will automatically connect the target's stdio into a handy io object that can
be referenced in the sploit script.
```
$ sploit exploit.py ./target target_args
```
If sploit is run omitting the target, it will launch in Pipes mode. Here, it
will create temporary FIFOs for stdio which will be tied to the same io object
in the sploit script. In this way, the same script can be used in both modes
and against any target source regardless of how it exposes its stdio.
```
$ sploit exploit.py
```
The pipe FIFOs are normally located in a temporary directory. However, if a
directory name is given, sploit will use that location instead. A particularly
useful way to use this is to store the pipes in the current directory for working
with Docker.
```
$ sploit exploit.py .
```
When running in Pipes mode, sploit will wait for something to connect on the
FIFOs before actually executing the exploit script. Once it has finished, it
will go back to waiting and run the script again the next time it connects.
This will loop indefinitely until you give a keyboard interrupt (Ctrl+C). The
exploit script can be modified between each run without any problems.
The main use case of Pipes mode is when you want to launch the target program
under another program (such as gdb). This enables a powerful workflow where you
can keep sploit and gdb running, make small alterations to the exploit script,
and re-run the target directly in gdb to see what happens. This allows for
rapid prototyping.
```
gdb> r </tmp/tmpksakkt8o/in >/tmp/tmpksakkt8o/out
```
You can also directly run sploit scripts with the following shebang
```
#!/usr/bin/env sploit
```
Docker Image
--------------
In addition to a local pip install, sploit is also deployable via Docker. Build
the image using the supplied Dockerfile with:
```
$ docker build -t sploit .
```
The container runs in the style of an application, and therefore expects to be
interactive. Also note that it is useful to mount your working directory in the
container, so that the running sploit instance can actually access your target
files or expose its pipes to you (the default working dir of the container is
/home). Therefore a basic command to run a containerized sploit would be:
```
$ docker run --rm -it -v $PWD:/home sploit exploit.py ./target target_args
```
The use of Scuba (pip install scuba) is recommended to make using ephemeral,
interactive containers more convenient. In this case it has the added benefit
of automatically creating and executing within an unprivileged user inside the
container:
```
$ scuba --image sploit exploit.py ./target target_args
```
|
