The Proxy Suite is a collection of open-source software which allows intercepting traffic between a target system and its peripherals using a Raspberry Pi 4B device. It is an effort to standardize data exfiltration of (wired) connections between closed-source systems using commodity hardware. The software which is referenced under this umbrella project is a slightly modified version of well-known open-source projects by individual developers and security researchers from all over the world. We at Nesto try to enhance the existing approaches and release our efforts under the same software license as the original project.
- 👀 Gives access to (unencrypted) data passed between common wired interfaces
- 💵 Built for affordable/commodity hardware: Raspberry Pi 4B
- ⭐ Built using forks of well-known software projects
- 😎 Lets you build your own analysis layer using any high-level language due to IPC components (ZMQ + msgpack)
- ⏳ Saves you time if you want to get data out of target systems without writing emulators for client devices (e.g. virtual printer protocol stacks)
- 🙌 Many real-world use cases, such as virtual printers or human interface devices (e.g. keyloggers)
- 👅 Circumvents hardware vendor restrictions often seen with closed (source) systems - no access to software on host or client device is needed; only wiring of peripherals to be changed
- 🔬 Provides out-of-band (hardware) approaches for fully transparent, passive filtering - allowing unaltered operation of present systems
- 💂♂️ Provides in-band (software) approaches for active data forwarding - giving you full control over the data stream
- 💡 Reference for everyone who wonders how to code for all of these (retro) interfaces using a Raspberry Pi (or similar arm devices)
- 🏃 Fast dev environment setup if you want to support this project due to VSCode Remote Docker Containers integration
- Device: Raspberry Pi 4B
- OS: Linux
- Distribution: Raspberry Pi OS / Raspbian (i.e. Debian's packaging system)
- Architecture: armhf
| Component | Interface Type | Proxy Type | Status |
|---|---|---|---|
| USBProxy (based on: usb-tools/USBProxy-legacy) | USB | Software* | RTM ✔️ |
| USBProxy2 | Hardware [LUNA] | TBD 🔜 | |
| EthernetProxy (based on: simsong/tcpflow) | Ethernet | Software | TBD ⚙️ |
| Hardware [TL-SG105E][Throwing Star LAN Tap] | RTM ✔️ | ||
| SerialProxy (based on: sersniff) | RS-232 | Software* | RTM ✔️ |
| Hardware [AirDrive Serial Logger] | RTM ✔️ | ||
| LPTProxy (based on: retro-printer capture code) | IEEE 1284 (Centronics / LPT) | Software [using retro-printer module] | PoC 🔜 |
| Hardware | --- ❓*** |
** there are currently issues with the hardware when running proxy for some health check protocols
*** we are not aware of any solutions on the marked that support this feature
We distinguish between a solution which does the actual proxying purely in software (i.e. using the board's CPU) and one which does it in specialized hardware. The latter is generally more performant and robust as it is out-of-band. Unfortunately, it is not possible to achieve this with commodity hardware for all types of interfaces yet. We keep an eye on active development that is going on though, particularly the teams at Great Scott Gadgets, Keelog and Retro-Printer.
With this project, we want to contribute by...
- ...providing an IPC layer which abstracts away the details of the interface being targeted.
- ...joining forces with the global community of open-source enthusiasts, working on making common peripheral interfaces more accessible for everyone.
We are able to extract data from every non-encrypted wired communication channel between a POS system and its printers that is known to us!
We noticed that wireless connections are rarely used for thermal printers. We can probably work around Wi-Fi (IEEE 802.11) by spawning a custom access point and using EthernetProxy between the AP and the POS. Support for Bluetooth (IEEE 802.15) might be added to this project in the future as we see more and more people using Bluetooth thermal printers. In both wireless cases, we must make sure that traffic flows through the proxy device. Observing traffic passively, like in the hardware approach of the EthernetProxy component, is too risky since we cannot make sure that we see all packets between the target devices.
Most thermal printers on the market use the JetDirect or the AppSocket protocol to receive print jobs over the network. It is a simple TCP connection over port 9100, which transports data in plain text. No encryption is used for other transports over interfaces such as USB, Serial, or LPT either. Thus, the ProxySuite components gain access to all of the invoice content transferred between the POS system and its printer. Once the data is intercepted, it can be analyzed as is. The ZMQ layer provided by all ProxySuite components makes the analysis a lot easier by letting you choose the programming language you want to use. There is a clear separation between "low-level" components that extract the data for you and the final analysis, which you might code in any language that has a binding for ZMQ and msgpack.
| Component | Release | Download | Status |
|---|---|---|---|
| USBProxy | nightly v0.1.0 | bash -c "$(curl -fsSL https://raw.githubusercontent.com/nesto-software/USBProxy/master/scripts/install-from-release.sh)" |   |
| EthernetProxy | latest | bash -c "$(curl -fsSL https://raw.githubusercontent.com/nesto-software/EthernetProxy/master/scripts/install-from-release.sh)" |  |
| SerialProxy | latest | bash -c "$(curl -fsSL https://raw.githubusercontent.com/nesto-software/SerialProxy/master/scripts/install-from-release.sh)" |  |
| LPTProxy | latest | bash -c "$(curl -fsSL https://raw.githubusercontent.com/nesto-software/LPTProxy/master/scripts/install-from-release.sh)" |  |
| Component | Shared Runtime Lib Dependencies (dpkg/apt) | Programming Language(s) | Build System(s) |
|---|---|---|---|
| USBProxy |
libusb-1.0-0 libudev1 libzmq3-dev | C/C++ | CMake, Make |
| EthernetProxy |
libpcap0.8 openssl libzmq3-dev | C++ | Autotools, Make |
| SerialProxy | libzmq3-dev | C++ | CMake, Make |
| LPTProxy |
wiringpi=2.50 libzmq3-dev | C | CMake, Make |
We use the IP layer to privide inter-process communication (IPC) functionality. The ZMQ library has bindings for a large variety of programming languages and provides very easy means to pass data around.
You can write an analysis layer in any programming language you want, import the ZMQ library and start receiving data from any ProxySuite component using a ZMQ subscriber.
We chose to use ZMQ for any ProxySuite component, so you can swap ProxySuite components (i.e. wired interfaces) at will and still reuse your analysis layer code. We (almost) fully abstract away all details of the interface being targeted.
Some newer interfaces such as Ethernet and USB allow multiplexing different data channels over a single physical wire. In order to pass information about ports, IPs, interface numbers, and other metadata for the observed connection, we send structured data over ZMQ. Data is serialized/deserialized using the msgpack library.
Non-multiplexed connections such as serial and parallel do not depend on msgpack.
There is an idea to unify the ProxySuite components and increase interoperability by always using msgpack, see #8.
Each ProxySuite component consists of a CLI binary and a corresponding Greengrass binary. AWS IoT Greengrass is an open source edge runtime and cloud service that helps you build, deploy, and manage IoT software on the AWS platform. The Greengrass binary conforms to a special type of Lambda function called Lambda executable.
It is all about bringing data into the cloud nowadays.
As time to market (TTM) is crucial, we believe that - on the enterprise level - using open-source AWS technology is a secure and reliable way to accomplish it as fast as possible.
We use GPG to sign our binary releases. In order to install packages from internal repositories, you must add our key for SecureApt to work.
Download GNU Privacy Guard for Linux
Keyserver: keys.openpgp.org