Our great sponsors
-
mitmproxy
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Our main docs are built with Hugo (https://github.com/mitmproxy/mitmproxy/tree/main/docs). For our API docs we use pdoc (https://pdoc.dev), which integrates well with most static site generators. pdoc is also maintained by us. :)
Our main docs are built with Hugo (https://github.com/mitmproxy/mitmproxy/tree/main/docs). For our API docs we use pdoc (https://pdoc.dev), which integrates well with most static site generators. pdoc is also maintained by us. :)
I'd highly recommend https://httptoolkit.tech/ for that explorative GUI phase. I found it recently and the rule configuration, UI and interception setup is significantly better than Charles/Fiddler/Proxyman.
You may be able to intercept a firmware update and load a binary poisoned with your own CA cert. (Lots of factors at play here, of course.)
I'm working on a similar problem (https://github.com/elahd/esp2ino/issues/16) with a project I maintain to replace IoT device firmware (https://github.com/elahd/esp2ino).
I've been using both mitmproxy and IOXY (https://github.com/NVISOsecurity/IOXY), an intercepting proxy made specifically for MQTT. IOXY is a small, less mature project, but it's definitely worth checking out as a compliment to mitmproxy. Many devices managed via AWS IoT phone home over MQTT and, my limited experience aside, it looks like many don't bother validating certificates when authenticating over this protocol.
You may be able to intercept a firmware update and load a binary poisoned with your own CA cert. (Lots of factors at play here, of course.)
I'm working on a similar problem (https://github.com/elahd/esp2ino/issues/16) with a project I maintain to replace IoT device firmware (https://github.com/elahd/esp2ino).
I've been using both mitmproxy and IOXY (https://github.com/NVISOsecurity/IOXY), an intercepting proxy made specifically for MQTT. IOXY is a small, less mature project, but it's definitely worth checking out as a compliment to mitmproxy. Many devices managed via AWS IoT phone home over MQTT and, my limited experience aside, it looks like many don't bother validating certificates when authenticating over this protocol.