Exploiting zero days in abandoned hardware | Hacker News Reader

Exploiting zero days in abandoned hardware

blog.trailofbits.com

113 pointsingve35 comments

> 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.

This was my baseline 20 or so years ago starting from the WRT54G. Now, it's just a bullet point in the miscellaneous section of my cv.

I find the EOL aspect of this discussion out of place. These devices shipped like this. They didn't gain these vulnerabilities due to aging or something like that.

You can have a device that is 100% supported by everyone from the chip vendor, board assembler, and an OEM that is still trivially vulnerable.

If it's supported, then as soon as somebody finds a vulnerability (and notifies the vendor) it should get fixed.

or they sell them to blackmarket as 0 day exploit

Why would I care if I have already been compromised? It's like I was murdered and the prosecutor leaves a "got em!" note on my grave after a conviction. I don't think I'm going to care very much.

It would matter quite a bit to the next person on the murderer's hit list, just like it matters to people whose devices haven't been compromised yet.

My thought too. They are not insecure because they won't be patched, they are just insecure. Even if patched, what's to say there are not 99 other vulnerabilities lurking, even in their supported products?

I seem to remember at least one case where a manufacturer attempted to patch an issue like this and managed to actually introduce another one in its place.

It's probably relevant due to companies usually dump EOL hardware, and some of it gets a new life in a non-business environment. But if it needs a firmware update for a security vulnerability you're out of luck. There is legitimate commercial market for used EOL hardware as parts for people that keep old hardware a bit longer, but that's probably short term until it can be replaced.

But no one should be buying or using these devices when they are brand new. Why would I care about them when used?

I bought a TV on deep discount. The Android TV OS was already trailing-edge and soon went unsupported. Being just a little paranoid, I monitored the network for continued activity after I removed the network configuration from the built-in software, which I replaced with an external device that's fully supported. I doubt many of the other customers for this cheap TV are as vigilant.

There really ought to be an “open source your drivers or offer a refund” law for companies that want to EOL devices. It isn’t the 90’s anymore, hardware innovation has really slowed, a chip could be good for decades.

The differences are vulnerability disclosure, vulnerability class, and patch availability. The device is most-vulnerable between the moment common hackers know how to exploit it and when a patch (or mitigation) for that vulnerability is applied.

Older hardware has had longer for vulnerabilities to be found. Some might not mitigate new classes of vulnerabilities. The EOL hardware will not receive patches for any vulnerabilities. So, they're at higher risk of attack.

From there, the attack will be either malicious input to that machine over the network or a file that embeds an attack. Many problems can be mitigated by running secure software, esp for input validation, on that hardware. One might also use them offline or on trusted networks with software that's hand-chosen for them. (That's what I do.)

I'm wondering if not upgrading from Win 10 to Win 11 will be considered EOL

I have a powerful gaming desktop but says not eligible to upgrade to win 11

After Oct 14, yes. You won't receive security patches

sucks gotta dump the box, excuse to get an SFF I guess

It's only really the CPU and motherboard that need updating, right?

Uh I mean if you're gonna throw a big GPU in the trash I'll haul it away for only ten bucks...

I thought it was some TPM thing

My rig is not that impressive, i9 with 4070 what sucks is the ram is locked for some reason at 2400mhz even if I buy ram that is faster than that so idk. I swear it that was the specific cpu (10th gen)

I did go through a bunch of steps checking trying to get it to work, stuff in bios enabling settings

I think the TPM lives in the mobo somewhere. Might as well reuse the HDD, SSD, GPU, PSU, and chassis

Good point, find same size/socket

You can have my Windows 10 from my cold dead hands ha

Make sure to dump via eBay or such so us Linux users can take advantage of the cheap hardware:)

Yeah idk, I need a windows computer, I do use all 3 to develop on but yeah

I'm not a PC builder myself, nice to see the designs people come up with

That's my point: You might need Windows, but some of us don't have that problem and would like to take that hardware off your hands.

10th gen intel should be compatible with windows 11. Might need to change a bios setting

You can upgrade to Windows 11 LTSC Enterprise IoT - it has leaner hardware requirements, but also less bloatware

I will check that out thanks

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?

> So why should abandoned hardware be any riskier than a brand new router, whose vulnerabilities haven't yet been discovered?

The time value of money is at play here. Vulnerability researchers are either black hats or they are something else. Most folks who research vulns don’t exploit devices they don’t own, and those who do are mostly black hats. Most folks with the skills to be black hats if they so desired definitionally have the “skills to pay the bills” but they may be using them in the legal market, so they would need a large return on the time invested, as well as a premium for doing illegal things due to the downside risk of being caught.

Vulnerabilities that can be exploited pay more than hypothetical ones, so proof of concept is worth less than a fully operationalized exploit chain. The larger the install base, the larger the pool of vulnerable target devices, and the larger the payout to the researcher.

A bird in the hand is worth two in the bush because the sure thing is worth more than uncertainly. A demonstrated capability that exploits a vulnerability in a widely distributed device is worth more because it does more than a hypothetical vulnerability in a brand new device that doesn’t already have market penetration or saturation.

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.

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.

I feel like there are better ways to make it hard to push malicious updates, while still allowing a user to flash their own devices.

For example: manufacturer bakes in their public key and a per device public/private key pair. The bootloader checks firmware updates against the manufacturers public key and the per device public key. The per device private key is only readable with hardware access via serial or USB etc. The user can extract their device’s private key to be able to sign their own firmware updates. Additionally, the bootloader could support adding new public keys to verify firmware with, so long as the payload to add the new public key was signed by the per device key. This would simplify getting updates from e.g. OpenWRT if they have their own key pair they sign with, vs requiring each user to sign each firmware update with their personal key.

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?

Reply on news.ycombinator.com