Our great sponsors
-
privaxy
Privaxy is the next generation tracker and advertisement blocker. It blocks ads and trackers by MITMing HTTP(s) traffic.
-
-
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.
-
This reminds me of a now-dockerized Privaxy, which is a UBlock-origin blocklist compatible MITM proxy. It’s crazy to see how many ads and tracking scripts are on smart products, especially my TV where so far in my testing it’s over 40% unnecessary traffic. Its been pretty fun to try and strip out ads on my smart-tv apps.
https://github.com/deetungsten/webui-privaxy is the dockerized fork of https://github.com/Barre/privaxy
Not a CF employee but I am pretty sure it's working as intended as they built and use this:
https://github.com/cloudflare/mitmengine
This reminds me of a now-dockerized Privaxy, which is a UBlock-origin blocklist compatible MITM proxy. It’s crazy to see how many ads and tracking scripts are on smart products, especially my TV where so far in my testing it’s over 40% unnecessary traffic. Its been pretty fun to try and strip out ads on my smart-tv apps.
https://github.com/deetungsten/webui-privaxy is the dockerized fork of https://github.com/Barre/privaxy
Adguat is working on something similar too.
https://github.com/AdguardTeam/urlfilter
How does this compare to adguard home [ https://github.com/AdguardTeam/AdguardHome ] ??
> without the C++ source proto files
Shameless plug: I wrote a project to generate source proto files from binaries called protodump [1] - it regenerates all the fields (including original field names, etc). It would just require pulling the binary off the AppleTV box,
[1]: https://github.com/arkadiyt/protodump
The trickiest part of decoding protobufs blind is how embedded messages and strings have the same tag type, but that's pretty easy to handle.
You can write a simple protobuf decoder in a couple hundred lines of code if you don't want to pull in the full protoc dependency: https://github.com/kubernetes/test-infra/blob/master/guberna... https://github.com/kubernetes/test-infra/blob/master/guberna...
A few points...
If you've got a Raspberry Pi 4 as your proxy, aren't you already struggling to pump more than 600Mbps over your network? Even if so, are you really pulling down more than 300Mb/s over a single TLS connection?
Even in that scenario, AES encryption/decryption can be parallelized (https://github.com/gurupunskill/parallel-aes).
To me, it seems like a pretty narrow set of scenarios where you'd not have the processing power to decrypt/encrypt at the speed of your network.
It looks like it is in fact universal. Just glancing at the code here, it looks like the tool searches any arbitrary file for bytes that look like encoded protobuf descriptors, specifically looking for bytes that are plausibly the beginning of a FileDescriptorProto message defined here:
https://github.com/protocolbuffers/protobuf/blob/main/src/go...
This takes advantage of the fact that such descriptors are commonly compiled into programs that use protobuf. The descriptors are usually embedded as constant byte arrays. That said, not all protobuf implementations embed the descriptors and those that do often have an option to inhibit such embedding (at the expense of losing some dynamic introspection features).