2 ms·
Mitmproxy was an interesting solution to a problem I had a few weeks ago. One of my IT support gigs was trying to use "Mevo"-branded cameras to stream some live
by EvanAnderson 5y ago
Mitmproxy was an interesting solution to a problem I had a few weeks ago. One of my IT support gigs was trying to use "Mevo"-branded cameras to stream some live events to Facebook using an iPad. We had to use the venue's Wi-Fi network. We found the Mevo app would not detect that we were "connected to the Internet" and wouldn't allow us to stream.
The venue's network admin said they weren't filtering anything outbound to the Internet. We could access websites from the iPad just fine. Same w/ Facebook, Youtube, etc.
I put up Mitmproxy, an adhoc Wi-Fi network on a second Wi-Fi NIC, a DHCP server, and iptables NAT on my laptop. I set the iPad to use my adhoc SSID and my machine as an explicit HTTP proxy. My intention was to snoop on the traffic to determine what Mevo was using for criteria to consider being "connected".
For whatever reason the Mevo app just started working in this configuration. I ended up sticking a spare Wi-Fi router and a PC w/ Mitmproxy installed in the venue for the duration of the event. I never did figure out what the Mevo app didn't like about the venue's network.
- derimagia 5y agoIf I had to guess why you had issues, the app probably had certificate pinning. Apple makes it pretty easy to pin domains, but it's also not too difficult to circumvent it. This looks to cover it pretty well: https://www.guardsquare.com/blog/leveraging-infoplist-based-certificate-pinning-ios-and-making-its-shortcomings https://www.guardsquare.com/blog/leveraging-infoplist-based-...
- Forbo 5y agoIf I had to guess, there may have been some sort of captive portal in place. I've seen even the "invisible" kind that don't require user intervention cause interference with connectivity checks for some devices.