Exploiting zero days in abandoned hardware

> If you have an EOL device, it may not be necessary to throw it away, but you should consider the risks of continuing to use it. For consumers, this necessitates careful consideration not just of a device’s features but its entire security lifecycle, including manufacturer support commitments and community firmware options.

Which I read as "Don't buy it in the first place, if it's not already supported by OpenWRT."

Simple enough.

In case anyone is looking for them, here are the exploits for these EOL devices. I avoided allowing Trail of Bits to release exploits for 13 years, but I decided it was finally time for a policy change. We'll be dropping a lot more as time goes on now.

Here's the exploit for the Netgear WGR614v9: https://github.com/trailofbits/exploits/tree/main/junkyard-2...

Here's the exploit for the BitDefender Box 1: https://github.com/trailofbits/exploits/tree/main/junkyard-2...

There's a lot of included detail so you can learn how to write your own and really understand every decision we made in writing them.

I have mixed feelings about the message "no updates -> vulnerable". The vulnerabilities have been in these devices all along. Some techniques for uncovering them got better over time, but I would guess not substantially. So why should abandoned hardware be any riskier than a brand new router, whose vulnerabilities haven't yet been discovered?

If they support OpenWRT or similar, fair enough - maturity does bring some additional safety. But in general this is not the case. Or am I missing something?

This is why my routers are dell computers with an intel quad port nic and openbsd installed. Dell gives bios updates far past most other vendors, intel nics just work, and openbsd is trivial to upgrade and gets updates.

Excellent write-up on the DistrictCon Junkyard competition! Your research beautifully illustrates a critical blind spot in consumer security: the "digital archaeology" problem,m where vulnerabilities become permanently fossilized in EOL devices. The bashsledding technique is particularly clever—using bash's whitespace handling as a reliability mechanism rather than traditional CPU instruction slides shows real creativity in exploit development. It's a great example of how understanding the target environment beyond just memory corruption can lead to more robust exploits. What strikes me most is the irony you highlighted with the Bitdefender Box: a security appliance that becomes a security liability once support ends. The firmware downgrade attack really drives home why cryptographic signatures alone aren't sufficient—without proper version monotonicity enforcement, you're essentially signing your own death warrant. For practitioners reading this, I'd add that this research has immediate practical implications beyond competition learning. Many organizations unknowingly operate EOL network infrastructure, and your methodology here (hardware teardown → firmware extraction → service enumeration → vulnerability research) provides a solid framework for internal security assessments of legacy devices. One question: did you explore whether the UPnP vulnerabilities in the Netgear router might be exploitable from the WAN side in certain network configurations? Given how common UPnP misconfigurations are, there might be broader attack surface implications. Looking forward to seeing what targets emerge for the 2026 competition—and hopefully more researchers following your example of responsible disclosure through detailed technical writeups like this one.

Is Android TV OS planned obsolescence for Sony (et al) TVs?

I do want to note about the secure, update claim that there is a tension between providing systems that can't receive false updates and giving users control of their hardware. Solutions for the former often prevent the latter.

An alternative would be to have the firmware show a description of the signed content, like version information, that the user must OK. It might show it along with the current version with a warning if versions are downgrading or the whole thing is changing. The warning might tell you to be sure of the source of this update. If it's the same software, and another version, it might be set to automatically update.

If it's the lowest-level, unrecoverable firmware, I like it being hard for attackers to change it. One idea I used to push was putting that in EEPROM with a jumper (or switch) required to update it. The software will have already performed numerous checks from the kernel state to the payload with external inputs (eg networking) shut down. If malicious, it can't do anything without that physical interaction.

The regular, update mechanism which uses other storage is in that EEPROM. It has highly, security-enhanced mechanisms for updates. It might even have it's own partition if it's a microkernel-based system. So, we have one that's hard to attack with software while the other takes physical attack or social engineering. Also, I think a Chromebook or something implemented a ROM/flash combo.