bitw1ze / pyxie Goto Github PK

Currently there is no way to properly handle binary data in the UI for manual interception. There are two options:

1. Easy: Make the user specify a hex editor program to launch when they want to edit binary data. This is somewhat clunky, but could be the best solution.
2. Harder: Implement hex-editing functionality in the GUI itself, or find an open-source implementation that could be used in the application.

When protocol data is received, there are two ways to deal with it in the UI: raw or parsed. Right now you can only view and edit raw data. However, the UI should also be able to take data parsed into a dict and display that in a somewhat-friendly manner to the user, allowing them to modify individual fields in the protocol.

I'm starting to think it's not a great idea to limit oneself to one kind of proxying. Some applications can be configured (or even forced) to tunnel binary data over an HTTP CONNECT or SOCKS proxy. This is usually easier to set up than transparent proxying, so why not support it?

These proxies could probably be implemented as wrappers.

Certificate generation is currently done with a very janky shell script. This was done because it was a quick and dirty way to generate SSL certificates on the fly without having to deal with convoluted APIs. This needs to be reimplemented cleanly in Python with proper error handling.

When intercepting traffic with a VPN or arp spoofing, transparent proxies should be able to forwarding traffic with kernel interfaces like netfilter rather than configuration options or application-level data like HTTP host headers. The current code to do this is commented out in utils.py because it doesn't work on some Linux kernels. Find a way to do this reliably and add some good error-handling so it's possible to fall back into other forwarding modes.

Make it possible to have multiple proxy listeners at once, configurable either in the GUI, a config file, or command-line arguments in the CLI. It should be very easy to add support for multiple proxy listeners, but making it configurable in the GUI will take some more time.

The Protocol class design should provide what is needed and not get in the way. Currently, it is kind of a pain to work with because of communication with the UI and other reasons.

For message-based protocols,

• implement send/recv of full messages both inbound and outbound
• on receive: parse headers and payload from raw data into a dict
• on send: serialized the dict back to raw data

Pyxie should send the raw and parsed data from the Protocol to the UI without the Protocol implementer having to worry about it. Likewise, the Protocol should block when traffic data is sent to the UI and receive the (potentially modified) data, serialize it, and send it along its merry way.

Create a Macro base class and create some example implementations. Create a GUI interface to create and edit simple macros and to load custom ones.

This may be a better idea than a GUI, actually...

It would be nice to see each message of the protocol in the traffic tab rather than the entire conversation in the stream. If desired, it should be possible to view all traffic in the stream (like "Follow TCP Stream" in Wireshark), but by default it should only show one message at a time.

The Streams table has a couple problems with it. It should not be editable (this was actually a regression and will be fixed soon), and it should not be possible to select more than one row at a time. I have not been able to figure out how to make the latter possible, despite following documentation and using functions that are supposed to make that work.