When doing wireless security research, you need enough devices to test and confirm your findings. Results have to be practical, after all. Due to COVID-19, this became more tedious: access to the lab is being limited, making it harder to test many devices.
Because I wanted some extra devices tohack play around with, I realized that I still had a router from my ISP. The problem is that I bricked that router more than a year ago: stuck in an infinite reboot loop, after accidentally including a backtick ` into the wrong field. This menacing backtick likely caused some start-up process to fail, trigger a reboot of the router. I didn't want to bother with calling the ISP and explaining that yes, I already rebooted it — in fact it rebooted a thousand times already — before getting it replaced. So I simply used my own router instead.
But now it became interesting to get that router working. So how can we revive it? Pressing the reset button in various ways, and for more than 30 seconds, had no effect. That's not good... On the bright side, the router did seem to briefly be operating before it reboots. Maybe that gives enough time to quickly navigate to the management interface and reset the field? Unfortunately not, the management interface is operational for just one second.
My solution was to make a script to detect when the router is operational, and within the available section automatically navigate the management interface, reset some options, and hope that will fix it. To immediately detect when the router is being (briefly) operational, I wrote the following scapy script:
The above script rapidly sends ARP requests for the IP of the router. Once an ARP reply is received the scrip exits. This needs to be run as root because we're using raw packet injection.
Because I wanted some extra devices to
But now it became interesting to get that router working. So how can we revive it? Pressing the reset button in various ways, and for more than 30 seconds, had no effect. That's not good... On the bright side, the router did seem to briefly be operating before it reboots. Maybe that gives enough time to quickly navigate to the management interface and reset the field? Unfortunately not, the management interface is operational for just one second.
My solution was to make a script to detect when the router is operational, and within the available section automatically navigate the management interface, reset some options, and hope that will fix it. To immediately detect when the router is being (briefly) operational, I wrote the following scapy script:
The above script rapidly sends ARP requests for the IP of the router. Once an ARP reply is received the scrip exits. This needs to be run as root because we're using raw packet injection.
One the router is accessible, we need to rapidly navigate to its management page, log in, and try to reset it from there. Luckily, with selenium we can do exactly that:
The above code only worked after tweaking the sleep calls. If the were even a tiny bit longer, the router would already be rebooting. If they were shorter, the page wouldn't have loaded yet. After a few attempts, this managed to reset the router!
The router did behave unusual after this reset. Wi-Fi was working in the 5 GHz band, but not in the 2.4 GHz band, and some other strange behaviour. This was fixed by manually resetting the router a second time. Probably when we reset the router for the first time it rebooted in the middle of resetting its configuration, which resulted in an inconsistent configuration. Anyway, now everything worked, without having to make annoying calls to the ISP.