This is a summary of my original writeup, for the complete technical aspects, including the hardware investigation, UART access, bootloader exploration, firmware limitations, and the decisions that led to the final network architecture, read the original article: https://medium.com/@hiruthicsha/i-tried-to-hack-my-isp-router-it-turned-into-a-very-expensive-lesson-86cbdbba1fe7
It started with a fairly ordinary problem: random ping spikes while gaming.
Whenever someone at home started streaming 4K videos, my gaming experience would take a hit. The ISP-provided router offered practically no control over bandwidth allocation, device prioritization, or traffic shaping.
I could change the Wi-Fi name. That was about it.
Naturally, instead of buying proper networking equipment, I decided to repurpose an old ISP router that had been lying around after the ISP discontinued the service and told us we could dispose of it.
The plan was simple: install custom firmware, unlock the device, and turn it into something I could actually control.
What followed was a rabbit hole involving hardware hacking, embedded Linux, bootloaders, serial consoles, and a few questionable engineering decisions.
Getting Inside the Router
The first challenge was understanding what I was dealing with.
The router wasn't running some ordinary, easily replaceable Linux distribution. It used a heavily customized firmware built around Realtek's proprietary SDK.
There was no straightforward OpenWRT installation or convenient firmware image waiting to be flashed. So I opened the device, identified the UART pins, soldered headers onto the board, and connected a USB-to-TTL adapter to access its serial console.
After a fair amount of trial and error, I managed to get readable boot logs, interact with U-Boot, investigate the partition layout, and eventually gain deeper access to the device.
There were plenty of small victories along the way, including bypassing restrictions that prevented even basic operations such as resetting the router.
But getting inside the device was only the beginning.
The Difference Between Access and Control
One of the more interesting discoveries was how much control the ISP retained over the device.
The firmware supported remote provisioning, allowing the ISP to push configurations that could overwrite locally configured settings.
This made sense from an ISP's operational perspective, but it also highlighted how little control the end user actually had over hardware sitting inside their home.
Even with elevated privileges, I wasn't necessarily in control of the entire system.
The deeper I investigated, the clearer the limitations became.
The device relied on proprietary drivers, closed-source components, vendor-specific configurations, and a very particular boot and partition structure.
There was no compatible custom firmware available that I could simply install.
Getting OpenWRT or another custom distribution running would require considerably more work, potentially including reverse-engineering missing components and rebuilding significant parts of the firmware.
I had managed to get access to the machine, but that didn't mean I could make it do what I wanted.
The Actual Problem Wasn't the Router
After spending several days investigating the hardware, I stepped back and reconsidered the original problem.
The issue wasn't really the router. It was bufferbloat.
When multiple devices started consuming bandwidth, network queues filled up, increasing latency and causing those frustrating ping spikes.
The router was doing what many consumer routers do: maximizing throughput without providing meaningful traffic fairness or queue management.
What I actually needed was:
- Traffic shaping to manage network congestion.
- Per-device bandwidth controls.
- Traffic prioritization for latency-sensitive applications.
- Firewall rules and DNS-level filtering.
Trying to force all these capabilities into a locked-down ISP device was the wrong approach.
Moving Network Control Somewhere Else
Instead of replacing the ISP router's firmware, I decided to introduce a dedicated network management layer.
The plan was to let the ISP ONT continue doing what it was designed for: providing internet connectivity.
The actual network management would move to a separate machine running OPNsense.
Fortunately, I already had a mini PC running as a home server, so I could reuse existing hardware rather than purchase an entirely new router.
This approach would give me a proper firewall, traffic shaping, bandwidth management, and more flexibility without having to fight the proprietary internals of the ISP device.
There was one more complication: my mini PC had only a single network interface.
I explored VLANs and router-on-a-stick configurations, but couldn't get the setup working reliably. Eventually, I decided to buy a network switch to make the physical topology more practical.
Interestingly, the old ISP router wasn't entirely useless after all. It could still serve as a wireless access point, while the second router I had initially planned to repurpose as a switch remained an open question.
What I Took Away From This
The project didn't end with custom firmware running on the old router. In that sense, the original objective failed.
But it taught me a few things that I probably wouldn't have learned by simply buying a better router.
- Access doesn't equal control.
Getting root access, understanding the bootloader, and manipulating flash partitions doesn't mean you can freely modify a system built around proprietary components.
- Understand the actual problem before choosing the solution.
I spent days trying to modify a router when the underlying problem was network congestion and bufferbloat. The right solution was at a different layer of the network.
- Sometimes the correct engineering solution is less exciting.
A dedicated firewall and a network switch aren't nearly as interesting as reverse-engineering an ISP router. But they solve the problem without requiring me to rebuild half the vendor's firmware.
- Hardware is cheaper than engineering time. Sometimes.
I spent hours trying to avoid buying a switch and ended up ordering one anyway. Whether that was a waste of time or a learning experience is still up for debate.
What's Next?
The next step is to put the new network topology together, get OPNsense running properly, and see whether the proposed setup actually fixes the latency problems.
There are still plenty of things to experiment with: traffic shaping, VLANs, DNS filtering, wireless access points, and network monitoring.
The original plan didn't work, but the project turned into a much deeper exploration of how home networks actually operate.
And perhaps that's the point of tinkering with hardware in the first place. Sometimes you set out to fix one annoying problem and end up learning an entirely different part of engineering.
Again, For the complete technical aspects, including the hardware investigation, UART access, bootloader exploration, firmware limitations, and the decisions that led to the final network architecture, read the original article: https://medium.com/@hiruthicsha/i-tried-to-hack-my-isp-router-it-turned-into-a-very-expensive-lesson-86cbdbba1fe7
Stay curious. Adios.
Top comments (0)