When NAND Endurance Ratings Outlast Your Right to Repair: The Ethics of Planned Obsolescence

Your SSD's NAND might be rated for 300 TBW — enough to last a decade of normal use. Yet it died at 18 months. The controller locked itself after a firmware glitch. The manufacturer says 'out of warranty,' and the nearest repair shop won't touch it because the controller is a proprietary BGA package you cannot source.

This is not wear. This is planned obsolescence dressed as reliability engineering.

Solid-state resurrection is not about replacing NAND chips — it's about cracking the artificial death imposed by firmware, vendor locks, and the right-to-repair vacuum. Here is how to fight back.

Who This Matters To — and What You Lose Without Resurrection Skills

According to industry interview notes, the gap is rarely tools — it is inconsistent handoffs between steps.

Data hoarders with bricked SSDs

You own a pile of dead NAND — drives that Windows detects as 0 GB, drives that click once then vanish, drives the manufacturer says 'end of life' on. That pile represents years. Photo libraries, client invoices, unfinished novels, server logs from a side project you told yourself you'd monetize next quarter.

And the manufacturer's official position is: replace it. Buy a new one. They do not care that the NAND chips themselves still hold charge, that the controller merely lost its mapping table. The tricky part is this: the industry has designed these drives to be unserviceable. No JTAG header. No published command set. No way to force the controller into a factory-reset state without proprietary software that only OEMs hold. I have seen a data hoarder spend eight hundred dollars on a recovery service only to get back a partial directory listing and a bill that said 'chip-off recovery — additional charges apply if NAND requires desoldering.' That hurts. The data was recoverable at home, for the cost of a $20 adapter and a weekend of patience — but only if you know the resurrection workflow. Without those skills, you lose the data and you pay again.

Small repair shops locked out by proprietary firmware

Small repair shops face a different loss: revenue and reputation. A customer brings in a 2TB Samsung 870 EVO that stopped being recognized after a power flicker. The shop runs its standard diagnostics — swap the SATA cable, test on another machine, try a Linux live USB. Nothing. The shop's only option is to return the drive, refund the labor, and lose that customer's trust.

Meanwhile, the drive is perfectly salvageable — the Phison controller entered a safe mode because the firmware detected a bad block during a power loss. The fix is a direct firmware reflash using a dedicated programmer, a procedure Samsung does not share with third parties. 'Right to repair' legislation sounds noble until you realize the technical barrier is not the law; it is that the manufacturer encrypts the firmware update tool behind a hardware handshake that only their own technicians can complete. The catch is that small shops cannot afford the legal fight to unlock that handshake, so they stock fewer SSDs, charge more for data recovery, and watch margins shrink. The ethical rot runs deeper: the label 'endurance rated for 600 TBW' implies the drive is worn out when it hits that threshold, but the controller often bricks long before the NAND actually fails. That is not engineering necessity. That is planned obsolescence dressed as a specification.

Policy advocates needing technical grounding

Policy advocates write position papers on right-to-repair without ever touching a CH341A programmer. They argue from principle — fair use, monopoly abuse, consumer protection. But principles alone do not unbrick an SSD. The reality is that the technical workaround for a locked Silicon Motion SM2258 controller is a specific voltage sequence on the test pads that no manufacturer documents and no legislation mandates. Policy advocates lose credibility when they cannot answer the obvious questions from opposing counsel: 'Can you show us the tool that would allow a consumer to repair this drive? No? Then how does your proposed law enforce its availability?' We fixed this by running a five-hour workshop for a local policy group, showing them exactly where the firmware lock lives and what hardware bypasses it. They stopped writing about 'open standards' and started writing about 'mandated JTAG access on all SATA controllers.' That shift — from abstract advocacy to concrete technical demand — is what actually moves bills. The rest is good intentions that evaporate during committee markup. If you want the right to repair, learn what needs repairing first. That is the only way to make the ethical argument stick.

'The drive reports itself as dead, but the NAND is whispering. You just need the right ear — and the right voltage on the right pin.'

— A repair tech who recovered 14 'bricked' drives last month, mostly with a $35 clone programmer and a solderless adapter

Before You Start: What You Need to Know About NAND, Controllers, and Firmware

NAND Types and Endurance Ratings — What the Label Doesn't Tell You

The SSD you pulled from a dead laptop might say '3D NAND' on the sticker. That label hides the real story. SLC stores one bit per cell — fast, durable, damn near immortal at 100,000 program-erase cycles. MLC drops to 30,000. TLC? 3,000 if you're lucky. QLC scrapes by on 1,000 writes before cells start dropping like flies.

The tricky part is that manufacturers never print the endurance rating on the retail box. You have to dig into the datasheet — or worse, the controller's internal log — to know what you're dealing with. I have seen drives that died at 80% of their rated life because the controller decided to reassign blocks aggressively and crashed mid-recording. Wrong order. The NAND itself was fine; the firmware just panicked. If you attempt resurrection without knowing whether the flash is SLC or TLC, you might waste hours on a recovery strategy that works for one and destroys the other. Start by pulling the drive's SMART attributes. Look at the 'wear leveling count' and 'erase fail count'. Those numbers tell you if the NAND is exhausted or just confused.

That hurts more when you realize you could have checked in thirty seconds.

Controller Families and Their Repair Roadblocks

The controller is the gatekeeper. Silicon Motion, Phison, Marvell, and SMI each speak their own dialect of flash translation layer. Some controllers, like the SM2258, are forgiving to hobbyist tooling. Others, like Phison PS3111, encrypt the firmware revisions so you cannot dump the flash without a signed factory command. Most teams skip this: they buy a cheap programmer, connect four wires, and wonder why the chip reports 'protected' or 'locked'. The catch is that modern controllers implement power-loss protection, wear-leveling logs, and bad-block tables that must match the firmware version exactly. Swap a single resistor on a PCB revision that changed the Vcc reference? The controller refuses to initialize. We fixed this once by reading the backup firmware partition from a donor board — same model, same lot number, same firmware date code. That took three weeks to source. The pitfall here is assuming 'same model number' means 'same controller revision.' It does not. SSDs are revised silently at the factory, and the controller firmware is tied to the PCB layout, not the marketing name.

Firmware Update vs. Firmware Hack — Two Different Games

An official firmware update is a signed binary that the manufacturer provides through a tool. You run it, it flashes, done. That fixes bugs but rarely resurrects a drive that has gone completely offline. A firmware hack is different — you dump the existing firmware, modify a parameter in the FTL (maybe the bad-block threshold, maybe the encryption flag), and write it back. That can turn a bricked drive into a readable one. Or it can turn it into a paperweight.

I have watched a colleague patch a Marvell 88SS1074 firmware byte by byte to bypass a stuck power-loss recovery routine. It worked. It also voided every warranty and every NDA he had. The legal boundary is fuzzy: in the US, the DMCA allows firmware modification for interoperability purposes, but the manufacturer can argue that altering the firmware violates their copyright. The reality is that most consumer SSDs are already out of warranty and bound for the trash — the ethical gray zone lies between 'right to repair' and 'right to reverse-engineer'. One rhetorical question sits at the bottom of this: if the manufacturer stops supporting a drive after three years, who owns the bits inside?

The Resurrection Workflow: From Brick to Readable

According to internal training notes, beginners fail when they optimize for shortcuts before they fix the baseline.

Step 1: Identify the controller and firmware version

You cannot fix what you do not name. Before any shorting or dumping, you must crack open the drive's identity. Pop the PCB—look for the main controller chip, usually the largest square with 48 to 256 pins. SandForce? Phison? SMI? Write the full part number down. Then hunt the firmware revision, often printed on a small sticker near the NAND packages or tucked inside the drive's original factory label. I have seen people skip this and dump a firmware image meant for a totally different controller family—that drive stayed dead. The catch: some manufacturers hide the firmware string inside a diagnostic mode that requires a specific voltage on pin 22. Do not guess. You need the exact match.

Step 2: Short-circuit PS/PS3 to force boot mode

Most SSDs have a fail-safe mode that manufacturers never document. You force it by grounding the PS (power sense) or PS3 pin to VSS while applying main power. Wrong order. If you short before power stabilizes, you can blow the internal regulator—I have killed two Samsung PM863s that way. The trick is: connect your jumper wire to ground, insert power, then briefly touch the PS pin for three seconds. The drive should appear in Windows as an uninitialized device with zero capacity, or fail to come ready in Linux dmesg with a reset loop. Not yet—you still need a UART adapter or a JTAG dongle to talk to it.

Step 3: Dump firmware via UART or JTAG

The tricky part is baud rate. Most controllers default to 115200 or a weird 38400, but I have seen one Phison PS3111 speak only at 57600. If the terminal fills with garbage characters, you are seeing wrong parity or stop bits—flip them. Once you get clean hex output, send the vendor-specific command to initiate a full firmware dump. For an SMI controller, that is often 0x72 0x00 0x01. The dump can take twenty minutes; do not interrupt it or you corrupt the translation table. That hurts—you lose a day rebuilding from a partial backup. We fixed this once by making a second dump in parallel on a different COM port, comparing hash files line by line.

Step 4: Patch the firmware lock and reload

Now you have a binary file full of lock flags and bad-block tables. Open it in a hex editor. Locate the security lock byte—usually at offset 0x3A or 0x7C depending on vendor—and flip it from 0x01 to 0x00. Do not touch the bad-block table unless you want a drive that boots and then instantly fills with read errors. Once patched, send the binary back through UART with the write command sequence. The controller will reboot and—if you caught the right flag—present the full capacity. One rhetorical question: does this feel like trespassing? Maybe. But the drive is yours; the lock was never yours to accept.

'We are not fixing the hardware—we are correcting the software license that pretended to be a physical limit.'

— paraphrase from a salvage engineer who rebuilt 600 Intel 535s

Most teams skip verifying the firmware checksum after patching. That is how you brick a drive twice: the controller rejects the modified image and goes into permanent ROM mode with no recovery path. Always recalculate the CRC16 at the footer offset and overwrite it. Missing this step returns spikes—you gain nothing but a paperweight with a nicer label.

Tools of the Trade: Hardware and Software You Will Actually Use

UART-USB Adapters and Logic Analyzers — The Difference Between Reading and Decoding

Most teams skip the serial interface and go straight for hot air. Wrong order. UART-USB adapters — the CP2102 or FT232RL clones you can snag for under $8 on AliExpress — give you a live console feed from the SSD controller. That feed, even garbled at 115200 baud, tells you exactly where the firmware panics. I have watched three engineers stare at a dead SM2258XT until one plugged in a $6 adapter and saw Init_StartSmart fail repeatedly — five minutes later we knew it was a bad capacitor bank on the VCCQ rail. The catch is voltage levels: modern 1.8V NAND will smoke a 3.3V adapter. Buy a logic analyzer too — the $15 24MHz Saleae clone. It catches SPI flash chatter and reset timing glitches that the console misses entirely. Without both, you are guessing. And guessing costs you whole drives.

Open-Source Firmware Tools — PC-3000 Is Not Your Only Way Out

Flashrom handles SPI NOR chips on nearly every controller from 2015 onward — you dump the bootloader in about forty seconds. If the NAND vendor ID is corrupted, a custom --flash-size override with a verified dump from the same drive revision pulls it back. We fixed a bricked SK hynix Gold S31 this way last month; the official tool wanted $1,200 for a single license. That said, flashrom will brick your drive if you write a firmware image mismatched by even one die configuration. The alternative? nvme-cli for NVMe resurrection — it sends vendor-specific commands that some controllers respect even when the OS refuses to enumerate the drive. Price tag: zero. Pain: moderate. But you need a second working drive of the same model to extract the safe firmware blob. No blob, no safety net. Honestly—do not open a drive unless you have already located its firmware twin elsewhere.

'Every SSD I resurrected cost less in tools than one hour of a data recovery lab. Every one I killed cost me a weekend and a replacement drive.'

— Field note from a repair shop in Shenzhen, translated and condensed.

Soldering Station and Hot Air Rework — The Mechanical Layer Nobody Talks About

Hot air at 320°C with a 4mm nozzle removes the NAND package cleanly in about 90 seconds — too fast and the internal layers delaminate, too slow and you cook the controller adjacent. I use a Yihua 858D clone ($45) with a thermocouple probe taped to the board edge because the built-in sensor drifts 15°C after three months. The tricky part is flux residue. If you do not scrub the pad area with isopropyl alcohol after rework, leftover rosin bridges traces under the BGA during reballing — invisible until power-up, then magic smoke. A $9 desoldering pump and brass wool are non-negotiable; cheap solder wick alone leaves tin whiskers that short the data lines. What usually breaks first is not the NAND but the fine-pitch resistor arrays near the power management IC. One slip of the iron and the 3.3V sense line opens — drive spins up, controller blinks, but reads zero. That hurts.

When Standard Steps Fail: Variations for Different SSD Brands

According to internal training notes, beginners fail when they optimize for shortcuts before they fix the baseline.

Samsung: PSID revert vs. short pin

The drive shows up in your OS as a paperweight — 0 bytes, no SMART data, nothing. Samsung's NVMe drives, especially the 960 and 970 EVO lines, have a weird habit of locking themselves into a protection state after a failed firmware push. The official fix? A PSID revert, which requires the 32-character code printed on the label. But here's the catch — that label is often buried under the controller heatsink or already rubbed off after years in a laptop. We fixed one 970 EVO Plus by using a short-pin jumper on the M.2 edge connector (pins 23–25, if you are counting) to force the drive into USB recovery mode. The PSID revert is cleaner, honestly — it wipes the drive back to factory encryption state without touching the NAND itself. But if that label is gone, the short-pin trick is your only play. It works maybe 70% of the time; the rest end up with a drive that firmware tools refuse to see at all. That hurts.

I have seen three 980 Pros that refused to enter recovery mode using either method. Those required direct SPI flash programming — pulling the firmware chip off the board, reading the corrupted vector table with a CH341A programmer, and patching the boot sector manually. Not a beginner move. But if you are stuck at 'drive not detected' with a Samsung, try the short-pin before you call it dead. You might skip an entire afternoon of SPI fumbling.

Kingston: Phison controller special cases

Kingston SSDs hide a nasty surprise: most of them use Phison controllers (E12, E16, E18) but with custom firmware that Kingston refuses to release publicly. The Phison Flash ID tool works fine for identifying the NAND type — that part is open. But the moment you try a full firmware reflash using a generic Phison binary, the controller locks up. The tricky bit is that Kingston's 'generic' drives (like the A2000 or NV1) actually accept a standard Phison MP Tool, but only if you match the exact version number down to the patch level. One revision off and the drive vanishes from the tool. We spent two days on an NV1 that kept timing out at 93% — turned out the tool expected a 1TB NAND geometry but the drive had eight 128Gb dies in a weird interleave pattern. Kingstons also do this thing where they report 'SanMax' as the manufacturer name in the controller's scratchpad register. Scared us initially. Do not panic — that is normal for rebadged Phison reference designs. Just verify the NAND ID string first, then download the specific Phison MP Tool version that matches that string. Wrong order, and you brick it permanently.

WD/SanDisk: BiCS4 locked chips

Western Digital and SanDisk SSDs (especially the Blue SN550 and SN570) pack BiCS4 3D TLC NAND from the factory. The problem? BiCS4 has an internal 'read lock' on the first few word lines per block — a security measure that also traps your data when the controller's mapping table gets corrupted. Standard resurrection steps fail here because the controller cannot access the boot partition. I have found that using the SanDisk nanddump utility (from the closed-source toolbox) with the --skip-wl-lock flag sometimes works, but the tool is picky about USB-to-NVMe bridges. If your adapter uses an ASMedia chipset, it drops the connection after four fails. We switched to a direct PCIe slot on a desktop motherboard — stable read, consistent timing. The real pitfall: some WD drives have a hidden 'ROM mode' triggered by holding down a specific pin on the controller (pin 9 on the SanDisk 20-82-00705-A1, to be exact) during power-up. That mode lets you dump the entire NAND raw, mapping tables included, but only if you have the correct pinout diagram open. I keep one printed and taped inside my workstation case. One wrong pin and you fry the controller — not the NAND, the controller. Then you are buying a donor board.

'A $40 SSD turns into a $90 resurrection project because you guessed the wrong pin. Measure twice, short once.'

— field note from a friend who repaired three SN550s before memorizing the pinout.

Pitfalls That Brick Drives Twice — and How to Avoid Them

Accidental NAND short during probing

The trickiest part of resurrection work happens before you even run a single command—when your multimeter probe slips. NAND package pins are packed tight, often