So, I spend around three hours a day on Instagram Reels, which is way too much, so I decided to kill two birds with one stone: stop my doomscrolling habit and turn it into a meaningful project.
For context, I became very interested in cyber security about a month ago. As I started learning the basics and got around to network traffic about a week ago, I came across the concept of DNS and DNS sinkholes. After some deeper independent research on them, I got the idea to attempt DNS-blocking Instagram Reels and leave the rest of the app functional. Deleting the app means I won't be able to text my friends, and setting timers hasn't worked for me in the past.
Now since I only knew a bit of theory and had no idea how to approach this, I took to ChatGPT to outline what I should learn before I attempted anything. It ended up creating a very well put together plan, although it had some things that felt overkill, like when it told me to learn how CDNs work.
The first thing I figured I should do is consider buying a new phone. At the time, I was using an iPhone, which I already knew is a much more hostile environment to mess with compared to Android, even if it's jailbroken. After my last project (click here) where I compared the pros & cons of custom Android ROMs and rooting, I wanted to put my rooted Google Pixel 8 to use.
After setting up the necessary hardware and tools, I had to learn how to use them and what results I would get. To spare you the theory, these are the main things I researched:
- Regular DNS vs DoH & DoT (DNS over HTTPS & DNS over TLS)
- Wireshark and tcpdump
- Traffic manipulation techniques like blocking IPs with iptables
Upon reviewing my notes and feeling confident enough to tackle the challenge, I plugged the phone into my computer, started up the shell as superuser, and turned tcpdump on to record traffic while I scrolled through Reels.
Executed commands:
> adb shell
> su
> whoami
> tcpdump -i any -s 0 -w /sdcard/instagram_reels.pcap
After gathering enough data, I fired up Wireshark to inspect the traffic, and I was unpleasantly surprised. All of the requests were over port 443, meaning they were all DoH requests, and therefore the actual DNS request was part of a HTTPS GET or POST request on top of being encrypted.
Although it seems possible to set up an interception tool like mitmproxy and decrypt the traffic, with my current knowledge I wasn't able to decrypt it. This is where I initially planned on ending the project and revisiting it in the future, but I wasn't satisfied.
That's when I remembered another social-media-related problem in my life: YouTube ads. I had heard of people blocking them in many ways, such as with DNS sinkholes, so I decided to pivot the project to DNS-blocking them instead.
In the exact same way, I recorded the traffic using tcpdump and analysed it with Wireshark, however this time there was a caveat - I had to isolate the ads from the regular content to find which IPs served the ads. After some thought, I tried what I thought will work best:
1. To get ads-only traffic, I opened & closed videos, only watching a few seconds of the ad in order to not load the video (unsure if this is exactly how it works)
2. To get regular content-only traffic, I signed into an account with YouTube Premium, and watched a few ad-free videos
After (hopefully) isolating the traffic enough, I began analysing.
While inspecting the ads-only traffic, I saw a few domains were ad-related (like googleadservices.com), almost all were from googlevideo.com.
As for the regular content-only traffic, I pretty much only saw googlevideo.com domains, and on top of that the domains were returning the same IP addresses in multiple cases, which began to make me suspicious that either:
a) I didn't isolate the traffic correctly, or
b) YouTube's CDN delivered ads and content from the same IPs.
Initially I wasn't sure which it might be: on the one hand, googlevideo.com seemed like a regular content CDN and googleadservices.com seemed like an ads-only CDN, meaning I failed at isolating the traffic, but on the other hand, there weren't as many requests to the IPs from googleadservices.com as there should've been if I was loading so many ads by clicking on different videos over & over.
I decided to find out which one it was by running a test where I blocked the overlapping IPs and saw if anything happened.
Executed command:
> iptables -A OUTPUT -d <ip> -j REJECT
After ensuring the IPs were blocked (seeing ICMP responses in Wireshark from those IPs), I had my suspicions confirmed. When I clicked on a video, an ad would try to load and fail, getting stuck in an infinite load screen. I knew it was an ad trying to load due to the 'sponsored' text and other ad-related UI appearing, but it also didn't happen every time as I didn't block all IPs from googlevideo.com.
By then, I was almost certain that the same IPs delivered ads and content, but I Googled it just to confirm. Sure enough, on the Pi-hole forums I found a post from last year that explained exactly what I suspected, meaning it might not be possible to even block YouTube ads using DNS alone.
Since I started off wanting to do selective functionality blocking using DNS without moving onto other methods, I decided to end the project here.
Even though I didn't achieve my original goal, this project ended up being my most valuable learning experience so far. It taught me so much more about DNS as well as new protocols like DoH/DoT, QUIC, and ARP, while getting hands-on with tcpdump and Wireshark on a real device rather than an intentionally vulnerable machine like HackTheBox.
I hit real-world constraints, saw how complex it actually is, and made an informed decision to pivot my project to work around the constraints. For a first-year student new to the field, I'd call that a success.
As for next steps, for now I plan on finishing the cybersecurity course I stepped away from in exchange for this project, and after that I'll see where else my curiosity leads me. I might work on a programming-based project like a port scanner, maybe something malware-related, possibly something else.