As part of the phone privacy project, I am on a quest to determine whether LineageOS, without Google Apps, does any spying for Google. Below are preliminary instructions on what I'm doing to try to answer that question.
I'm routing all packets from a phone through my Ubuntu Linux desktop. The desktop has no wired access. I am using a Netgear wireless repeater to get to the DSL modem and a Tenda N300 wireless router for the phone to access. The two wireless devices are bridged such that all packets go through my desktop.
Note that the following does not survive reboots (including my usage of /tmp), and reboots are recommended if stuff goes wrong. Yes, rebooting is so SNL 1980s. Perhaps I'll figure out a better way one day.
If you're doing this for real, set up the 3 devices--Tenda, Netgear, and your modem--such that the phone can only access the Tenda. Put passwords on 2 or 3 of the devices. Either no password on the Tenda or 3 different passwords so the phone can only access the Tenda. Make sure the Tenda does not have the password to the other devices (even if it is in AP mode).
Below, Tenda (for phone access) is enp36s0. Netgear (for desktop access) is enp6s0. My "ups" and "downs," literally, are odd. I'm not saying it's optimal. It's what works.
Part one of two is the bridge:
sudo brctl addbr br0 sudo brctl addif br0 enp6s0 sudo ifconfig enp6s0 down sudo ifconfig br0 up sudo ifconfig enp6s0 up sudo dhclient br0 sudo brctl addif br0 enp36s0 sudo ifconfig enp6s0 down sudo ifconfig enp6s0 up route -n
The result should be your IPv4 local address equivalent of:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 br0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
Now the MITM:
sudo sysctl -w net.ipv4.ip_forward=1 sudo sysctl -w net.ipv6.conf.all.forwarding=1 sudo sysctl -w net.ipv4.conf.all.send_redirects=0 sudo iptables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 8080 sudo iptables -t nat -A PREROUTING -i br0 -p tcp --dport 443 -j REDIRECT --to-port 8080 sudo ip6tables -t nat -A PREROUTING -i br0 -p tcp --dport 80 -j REDIRECT --to-port 8080 sudo ip6tables -t nat -A PREROUTING -i br0 -p tcp --dport 443 -j REDIRECT --to-port 8080 sudo ebtables -t nat -A PREROUTING --logical-in br0 -p ipv4 -j redirect sudo ebtables -t nat -A PREROUTING --logical-in br0 -p ipv6 -j redirect cd ~/Downloads/mitmproxy-4.0.4-linux export SSLKEYLOGFILE="/tmp/mi/sslkeylogfile.txt" ./mitmproxy --mode transparent --showhost -w /tmp/mitm_0619_1.txt
One your phone, go to mitm.it to get their certificate
Now HTTPS traffic should be in the clear in the mitmproxy desktop program
The mitm -w option saves data to a log file.
I found out the hard way that you need the ebtables commands in order to get the iptables commands working when you're bridging. Also note that I give some of the ip6 commands, but I am NOT using IPv6 at all. I don't think it's working at all given my setup. I may not tackle that problem; I'm not sure it's relevant.
At the same time I'm running MITM, I'm running Wireshark on br0 as Linux root and I'm running
sudo tcpdump -i br0 -w /tmp/tcpdump.pcap
When you're done, run this to turn either Wireshark's and / or tcpdump's pcap file into an XML file:
tshark -r some.pcap -T pdml > netcapture.xml
You can look up instructions to try to decrypt data in Wireshark using the SSLKEYLOGFILE, but I've decided not to worry about that. I did get it working to a degree, and I didn't try to debug it very hard when it didn't work. My plan is to use the MITM program and Wireshark to give me guidance, to tell me what to look for. Then I'll use the MITM log and the XML file to be completely thorough. I'll write scripts to thoroughly analyze them.
Soon--the rest of June, 2019 or a bit later, I hope--I should come back through this document to add references, explanations, more info, etc.