Stub out ctypes structures for OSX transparent mode.
This commit is contained in:
Aldo Cortesi
parent
e039940f49
commit
21f74efa10
|
|
@ -1,12 +0,0 @@
|
|||
|
||||
All of mitmproxy's basic functionality is exposed through the __libmproxy__
|
||||
library. The example below shows a simple implementation of the "sticky cookie"
|
||||
functionality included in the interactive mitmproxy program. Traffic is
|
||||
monitored for __cookie__ and __set-cookie__ headers, and requests are rewritten
|
||||
to include a previously seen cookie if they don't already have one. In effect,
|
||||
this lets you log in to a site using your browser, and then make subsequent
|
||||
requests using a tool like __curl__, which will then seem to be part of the
|
||||
authenticated session.
|
||||
|
||||
$!example("examples/stickycookies")!$
|
||||
|
||||
|
|
@ -1,129 +0,0 @@
|
|||
|
||||
__mitmproxy__ has a powerful scripting API that allows you to modify flows
|
||||
on-the-fly or rewrite previously saved flows locally.
|
||||
|
||||
The mitmproxy scripting API is event driven - a script is simply a Python
|
||||
module that exposes a set of event methods. Here's a complete mitmproxy script
|
||||
that adds a new header to every HTTP response before it is returned to the
|
||||
client:
|
||||
|
||||
$!example("examples/add_header.py")!$
|
||||
|
||||
The first argument to each event method is an instance of ScriptContext that
|
||||
lets the script interact with the global mitmproxy state. The __response__
|
||||
event also gets an instance of Flow, which we can use to manipulate the
|
||||
response itself.
|
||||
|
||||
|
||||
## Events
|
||||
|
||||
### start(ScriptContext)
|
||||
|
||||
Called once on startup, before any other events.
|
||||
|
||||
|
||||
###clientconnect(ScriptContext, ClientConnect)
|
||||
|
||||
Called when a client initiates a connection to the proxy. Note that
|
||||
a connection can correspond to multiple HTTP requests.
|
||||
|
||||
|
||||
###request(ScriptContext, Flow)
|
||||
|
||||
Called when a client request has been received. The __Flow__ object is
|
||||
guaranteed to have a non-None __request__ attribute.
|
||||
|
||||
|
||||
### response(ScriptContext, Flow)
|
||||
|
||||
Called when a server response has been received. The __Flow__ object is
|
||||
guaranteed to have non-None __request__ and __response__ attributes.
|
||||
|
||||
|
||||
### error(ScriptContext, Flow)
|
||||
|
||||
Called when a flow error has occurred, e.g. invalid server responses, or
|
||||
interrupted connections. This is distinct from a valid server HTTP error
|
||||
response, which is simply a response with an HTTP error code. The __Flow__
|
||||
object is guaranteed to have non-None __request__ and __error__ attributes.
|
||||
|
||||
|
||||
### clientdisconnect(ScriptContext, ClientDisconnect)
|
||||
|
||||
Called when a client disconnects from the proxy.
|
||||
|
||||
### done(ScriptContext)
|
||||
|
||||
Called once on script shutdown, after any other events.
|
||||
|
||||
|
||||
## API
|
||||
|
||||
The main classes you will deal with in writing mitmproxy scripts are:
|
||||
|
||||
<table class="kvtable">
|
||||
<tr>
|
||||
<th>libmproxy.flow.ClientConnection</th>
|
||||
<td>Describes a client connection.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>libmproxy.flow.ClientDisconnection</th>
|
||||
<td>Describes a client disconnection.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>libmproxy.flow.Error</th>
|
||||
<td>A communications error.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>libmproxy.flow.Flow</th>
|
||||
<td>A collection of objects representing a single HTTP transaction.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>libmproxy.flow.Headers</th>
|
||||
<td>HTTP headers for a request or response.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>libmproxy.flow.ODict</th>
|
||||
|
||||
<td>A dictionary-like object for managing sets of key/value data. There
|
||||
is also a variant called CaselessODict that ignores key case for some
|
||||
calls (used mainly for headers).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>libmproxy.flow.Response</th>
|
||||
<td>An HTTP response.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>libmproxy.flow.Request</th>
|
||||
<td>An HTTP request.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>libmproxy.flow.ScriptContext</th>
|
||||
<td> A handle for interacting with mitmproxy's from within scripts. </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>libmproxy.certutils.SSLCert</th>
|
||||
<td>Exposes information SSL certificates.</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
The canonical API documentation is the code. You can view the API documentation
|
||||
using pydoc (which is installed with Python by default), like this:
|
||||
|
||||
<pre class="terminal">
|
||||
> pydoc libmproxy.flow.Request
|
||||
</pre>
|
||||
|
||||
|
||||
## Running scripts on saved flows
|
||||
|
||||
Sometimes, we want to run a script on __Flow__ objects that are already
|
||||
complete. This happens when you start a script, and then load a saved set of
|
||||
flows from a file (see the "scripted data transformation" example on the
|
||||
[mitmdump](@!urlTo("mitmdump.html")!@) page). It also happens when you run a
|
||||
one-shot script on a single flow through the _|_ (pipe) shortcut in mitmproxy.
|
||||
|
||||
In this case, there are no client connections, and the events are run in the
|
||||
following order: __start__, __request__, __response__, __error__, __done__. If
|
||||
the flow doesn't have a __response__ or __error__ associated with it, the
|
||||
matching event will be skipped.
|
||||
|
|
@ -3,7 +3,7 @@ import sys
|
|||
resolver = None
|
||||
if sys.platform == "linux2":
|
||||
import linux
|
||||
resolver = linux.Resolver()
|
||||
#elif sys.platform == "darwin":
|
||||
# import osx
|
||||
# resolver = osx.Resolver()
|
||||
resolver = linux.Resolver
|
||||
elif sys.platform == "darwin":
|
||||
import osx
|
||||
resolver = osx.Resolver
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
import socket, struct
|
||||
import socket, struct, fcntl
|
||||
|
||||
# Python socket module does not have this constant
|
||||
SO_ORIGINAL_DST = 80
|
||||
|
|
|
|||
|
|
@ -1,9 +1,92 @@
|
|||
import socket, struct
|
||||
import socket, ctypes
|
||||
|
||||
# Python socket module does not have this constant
|
||||
DIOCNATLOOK = 23
|
||||
PFDEV = "/dev/pf"
|
||||
|
||||
|
||||
class PF_STATE_XPORT(ctypes.Union):
|
||||
"""
|
||||
union pf_state_xport {
|
||||
u_int16_t port;
|
||||
u_int16_t call_id;
|
||||
u_int32_t spi;
|
||||
};
|
||||
"""
|
||||
_fields_ = [
|
||||
("port", ctypes.c_uint),
|
||||
("call_id", ctypes.c_uint),
|
||||
("spi", ctypes.c_ulong),
|
||||
]
|
||||
|
||||
|
||||
class PF_ADDR(ctypes.Union):
|
||||
"""
|
||||
struct pf_addr {
|
||||
union {
|
||||
struct in_addr v4;
|
||||
struct in6_addr v6;
|
||||
u_int8_t addr8[16];
|
||||
u_int16_t addr16[8];
|
||||
u_int32_t addr32[4];
|
||||
} pfa;
|
||||
}
|
||||
"""
|
||||
_fields_ = [
|
||||
("addr8", ctypes.c_byte * 2),
|
||||
("addr16", ctypes.c_byte * 4),
|
||||
("addr32", ctypes.c_byte * 8),
|
||||
]
|
||||
|
||||
|
||||
class PFIOC_NATLOOK(ctypes.Structure):
|
||||
"""
|
||||
struct pfioc_natlook {
|
||||
struct pf_addr saddr;
|
||||
struct pf_addr daddr;
|
||||
struct pf_addr rsaddr;
|
||||
struct pf_addr rdaddr;
|
||||
#ifndef NO_APPLE_EXTENSIONS
|
||||
union pf_state_xport sxport;
|
||||
union pf_state_xport dxport;
|
||||
union pf_state_xport rsxport;
|
||||
union pf_state_xport rdxport;
|
||||
sa_family_t af;
|
||||
u_int8_t proto;
|
||||
u_int8_t proto_variant;
|
||||
u_int8_t direction;
|
||||
#else
|
||||
u_int16_t sport;
|
||||
u_int16_t dport;
|
||||
u_int16_t rsport;
|
||||
u_int16_t rdport;
|
||||
sa_family_t af;
|
||||
u_int8_t proto;
|
||||
u_int8_t direction;
|
||||
#endif
|
||||
};
|
||||
"""
|
||||
_fields_ = [
|
||||
("saddr", PF_ADDR),
|
||||
("daddr", PF_ADDR),
|
||||
("rsaddr", PF_ADDR),
|
||||
("rdaddr", PF_ADDR),
|
||||
|
||||
("sxport", PF_STATE_XPORT),
|
||||
("dxport", PF_STATE_XPORT),
|
||||
("rsxport", PF_STATE_XPORT),
|
||||
("rdxport", PF_STATE_XPORT),
|
||||
("af", ctypes.c_uint),
|
||||
("proto", ctypes.c_ushort),
|
||||
("proto_variant", ctypes.c_ushort),
|
||||
("direction", ctypes.c_ushort),
|
||||
]
|
||||
|
||||
|
||||
class Resolver:
|
||||
def __init__(self):
|
||||
self.pfdev = open(PFDEV, "r")
|
||||
|
||||
def original_addr(self, csock):
|
||||
"""
|
||||
The following sttruct defintions are plucked from the current XNU source, found here:
|
||||
|
|
@ -16,39 +99,5 @@ class Resolver:
|
|||
u_int16_t call_id;
|
||||
u_int32_t spi;
|
||||
};
|
||||
|
||||
struct pf_addr {
|
||||
union {
|
||||
struct in_addr v4;
|
||||
struct in6_addr v6;
|
||||
u_int8_t addr8[16];
|
||||
u_int16_t addr16[8];
|
||||
u_int32_t addr32[4];
|
||||
} pfa;
|
||||
|
||||
struct pfioc_natlook {
|
||||
struct pf_addr saddr;
|
||||
struct pf_addr daddr;
|
||||
struct pf_addr rsaddr;
|
||||
struct pf_addr rdaddr;
|
||||
#ifndef NO_APPLE_EXTENSIONS
|
||||
union pf_state_xport sxport;
|
||||
union pf_state_xport dxport;
|
||||
union pf_state_xport rsxport;
|
||||
union pf_state_xport rdxport;
|
||||
sa_family_t af;
|
||||
u_int8_t proto;
|
||||
u_int8_t proto_variant;
|
||||
u_int8_t direction;
|
||||
#else
|
||||
u_int16_t sport;
|
||||
u_int16_t dport;
|
||||
u_int16_t rsport;
|
||||
u_int16_t rdport;
|
||||
sa_family_t af;
|
||||
u_int8_t proto;
|
||||
u_int8_t direction;
|
||||
#endif
|
||||
};
|
||||
"""
|
||||
pass
|
||||
|
|
|
|||
|
|
@ -508,7 +508,7 @@ def process_proxy_options(parser, options):
|
|||
if not platform.resolver:
|
||||
parser.error("Transparent mode not supported on this platform.")
|
||||
trans = dict(
|
||||
resolver = platform.resolver,
|
||||
resolver = platform.resolver(),
|
||||
sslports = TRANSPARENT_SSL_PORTS
|
||||
)
|
||||
else:
|
||||
|
|
|
|||
Loading…
Reference in New Issue