Guide: Reviving Toshiba / Kioxia PX02 & PX05 drives

[Fritz]

Can't speak for everyone but I'll never buy another Toshiba product after this unnecessary Shit Show.

 

[archiethemonger]

@Fritz Although the problem was caused by Toshiba writing shitty firmware, the lack of a fix is not their fault. Toshiba legally can't do anything to help customers since they sold off their SSD intellectual property to Kioxia. Unfortunately, Kioxia is not willing to help with vendor-branded drives on a direct-to-consumer basis.

It's likely the legal contract that Kioxia has inherited may not allow them to circumvent the vendors to release a fix for all drives (likely to avoid trademark infringement, since the firmware would have the vendor's name in the firmware header/footer).

Ultimately, the lack a fix really falls on some vendors (e.g. Dell) for waiting on individual corporate customers to pay for a service contract to "merge in" the fix on each model number so they can rake in some extra cash.

 

[Fritz]

Mine is a Genuine Toshiba, not a vendor branded drive so I not only hold them responsible for this mess but also for the legal quagmire that created it. If Dell, Lenovo and whoever else vendor branded these drives has the ability to fix this problem but chose not to because of political and/or financial reasons then they're even more guilty because their contribution was premeditated. So screw them all.

 

[archiethemonger]

You might want to try to email Kioxia's customer support. They might be willing to give you a FW update for your Toshiba branded drive (based on their excuse that they wouldn't help me strictly due to it being a vendor branded drive).

 

[user_name]

apparently 1MB is too large to attach now so here's a link https://fohdeesha.com/data/other/FMDELPX05SRB384Y_AU0F_NS.zip

the file in the zip was pulled directly from the compellent ISO, I imagine it'll prolly have some weird compellent header data you'll need to trim out if you're gunna flash with sg_utils etc

edit: just actually read your previous replies and you're already on this version lol. yes it's fixed

I'm considering trying this firmware on a working Dell PX05SMB080Y later this week. Is it expected that this firmware will contain the 70k hours fix? It seems those who have tried the PX05.bin and PX05-SED.bin firmwares on the Y variants haven't had much luck, so I'm debating between trying this versus Dell's AS10 firmware.

 

[LumpyRareHawk]

I'm considering trying this firmware on a working Dell PX05SMB080Y later this week. Is it expected that this firmware will contain the 70k hours fix? It seems those who have tried the PX05.bin and PX05-SED.bin firmwares on the Y variants haven't had much luck, so I'm debating between trying this versus Dell's AS10 firmware.

Don't botter with AS10, we already know it doesn't fix the issue.

For AU0F, my disks haven't reached 70k hours yet so can't say. Will need someone that already reached it to try it.

 

[nmap]

Trying to flash my drives with TrueNAS Core and Ubuntu Server 24 with an H710P flashed to IT mode via your other thread:

root@debian:/media/user/64gb/Toshiba-PX-Firmware#  sg_write_buffer -vvvvv -m 5 --in PX05.bin /dev/sg0
open /dev/sg0 with flags=0x802
tried to read 8388608 bytes from PX05.bin, got 1173504 bytes
will write 1173504 bytes
sending single write buffer, mode=0x5, mpsec=0, id=0, offset=0, len=1173504
    Write buffer cdb: [3b 05 00 00 00 00 11 e8 00 00]
    Write buffer parameter list (first 256 bytes):
50 4d 30 34 44 48 57 46  0d 0a 0d 0a 54 75 65 73
64 61 79 2c 20 53 65 70  74 65 6d 62 65 72 20 32
38 2c 20 32 30 32 31 20  31 39 3a 33 30 3a 30 36
20 62 79 74 73 62 67 6c  65 0d 0a 43 6f 70 79 72
69 67 68 74 20 28 43 29  20 54 4f 53 48 49 42 41
20 43 4f 52 50 4f 52 41  54 49 4f 4e 2e 0d 0a 41
6c 6c 20 72 69 67 68 74  73 20 72 65 73 65 72 76
65 64 2e 0d 0a 50 34 4d  3a 37 37 3a 30 36 3a 30
31 3a 30 30 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 0d 0a 1a
00 00 00 00 77 06 01 00  03 00 00 00 00 e8 11 00
check_file_type: file descriptor is sg device
      duration=220 ms
Write buffer:
Descriptor format, current; Sense key: Illegal Request
Additional sense: Invalid field in parameter list
  Descriptor type: Vendor specific [0x80]
    00 3b 01 03 01 00 00 00 00 00 00 00 79 00 00 1d 32 29 26 00 00 00 00 00
    55 09 00 00 00 00
 Raw sense data (in hex), sb_len=40, calculated_len=40
        72 05 26 00 00 00 00 20  80 1e 00 3b 01 03 01 00
        00 00 00 00 00 00 79 00  00 1d 32 29 26 00 00 00
        00 00 55 09 00 00 00 00
Write buffer failed: Illegal request, Invalid field in parameter list, type: sense key + asc,ascq=0x

 

[nmap]

Just tried on a Debian Live ISO, same results

 

[Methylzero]

Hello!
Does anyone know if the PX05SRB 500GB SERIES is also affected by this bug?
I have a PX05SRB100 and it is working perfectly at the moment, but I cannot seem to be able to find the POH counter.
Does anyone know which sg_logs page contains the power on time?
The drive has PX05SRB100 on the label but reports itself as a SLB5F-M960SS, firmware T40A

Thanks!

 

[MaHeSi84]

Hi Jon,


first off, thank you for the PX revival guide and the AU0F firmware you pulled from the Compellent ISO. It got me a lot further than the public package.


I have eight Toshiba PX05SRB096Y (960GB SAS, Dell DP/N 0CN8KY) pulled from a Dell SCv2020. Seven died with the classic ~70k POH bug, reporting 0 bytes and ASC=44/ASCQ=d1 on every command. One spare with fewer hours still works fine. Running firmware on the dead ones is AU05.


Progress so far:

• PX05.bin and PX05-SED.bin → rejected with "Digital signature validation failure" (expected, NetApp firmware)
• Your FMDELPX05SRB384Y_AU0F_NS → my model PX05SRB096Y is listed in the Dell header (ref 105732), so the firmware is correct for my drive
• I trimmed the 1024-byte (0x400) Dell wrapper so the file now starts cleanly at the Toshiba "PM04DHWF" header (verified, version P4M:41:0F)

But the flash itself won't complete:

• Mode 5: returns immediately with Sense key Hardware Error, ASC=19 ASCQ=81 (defect list error). Sense: 72 04 19 81 ... 79 00 00 1d 32 24 1f 00 00 03 e0 00 53 07
• Mode 7 (on a different drive): hangs for ~5 minutes, then DID_TIME_OUT (transport error)

It really looks like the bricked state itself blocks the write-buffer path. Is there a reset/unlock step needed before flashing on an already-bricked drive (as opposed to flashing preventively before they hit 0 bytes)? Or a different procedure for drives already in the 0-byte state?

sg_write_buffer -vvvvv -m 5 --in AU0F_clean.bin /dev/sg1
open /dev/sg1 with flags=0x802
tried to read 8388608 bytes from AU0F_clean.bin, got 1215488 bytes
will write 1215488 bytes
sending single write buffer, mode=0x5, mpsec=0, id=0, offset=0, len=1215488
    Write buffer cdb: [3b 05 00 00 00 00 12 8c 00 00]
    Write buffer parameter list (first 256 bytes):
50 4d 30 34 44 48 57 46  0d 0a 0d 0a 54 68 75 72
73 64 61 79 2c 20 41 75  67 75 73 74 20 32 39 2c
20 32 30 31 39 20 31 34  3a 30 34 3a 31 31 20 62
79 74 73 62 67 6c 65 0d  0a 43 6f 70 79 72 69 67
68 74 20 28 43 29 20 54  4f 53 48 49 42 41 20 43
4f 52 50 4f 52 41 54 49  4f 4e 2e 0d 0a 41 6c 6c
20 72 69 67 68 74 73 20  72 65 73 65 72 76 65 64
2e 0d 0a 50 34 4d 3a 34  31 3a 30 46 3a 30 31 3a
30 30 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20  20 20 20 20 20 0d 0a 1a
10 00 00 00 41 0f 01 00  03 00 00 00 00 8c 12 00
check_file_type: file descriptor is sg device
      duration=4 ms
Write buffer:
Descriptor format, current; Sense key: Unit Attention
Additional sense: Microcode has been changed
  Descriptor type: Vendor specific [0x80]
    00 3b 41 0f 01 00 00 00 00 00 00 00 79 00 00 1d 32 24 20 00 00 00 00 00
    53 07 00 00 00 00
 Raw sense data (in hex), sb_len=40, calculated_len=40
        72 06 3f 01 00 00 00 20  80 1e 00 3b 41 0f 01 00
        00 00 00 00 00 00 79 00  00 1d 32 24 20 00 00 00
        00 00 53 07 00 00 00 00
Write buffer failed: Unit attention, type: sense key

Hardware: LSI SAS 9300-8i in IT mode (FW v8.37), SystemRescue 13. Happy to provide any logs and report results back for the thread.


Thanks a lot

 

[MaHeSi84]

Hi everyone, hi fohdeesha,

Update:

Hardware:
- LSI 9300-8i IT-mode, Debian Live, sg3-utils
- sg0: AU05, 894GB (unlocked, identical hardware available for testing)
- sg1-sg6: AU05/AU0F, 0B (locked)
- sg7: AS0E, 0 Byte AS0E does not recover already-bricked drives

Key findings:

1. Lock bypass confirmed
Only PM04DHWF + FirmHeader format (flag 00 00 00 00 at offset 0xF0 + "Firm Header" magic at 0x110) bypasses the lock check.
Old PM04DHWF (flag 10 00 00 00) and ISE format are blocked immediately (Hardware Error, ASC=0x19, ASCQ=0x81). The value at
0x120 does not matter for bypass.

2. All Dell DUPs for PX05SRB-Y analyzed none work on locked drives
AS0B, AS0C, AS0E, AS10 all use old PM04DHWF format + model code 0x53 (SMB/SVB-Y) internally. They never pass the lock check
and are also for the wrong model. AS0E's ISE header confirms it's preventive: it contains a 105,734-hour POH threshold and
rejects drives already above it.

3. Two-step verification on locked drives
Once the lock is bypassed (FirmHeader format), the drive does:
Step 1 (~168ms): Content integrity check against ROM-stored hash. Any single modified byte gives f2 (ASC=0x26). No hash or
RSA signature is embedded in the firmware file itself verification data is in drive ROM.
Step 2 (~48ms): RSA signature verification using key stored in drive ROM.

4. PX05.bin (non-Y, model 0x77) passes Step 1 on SRB-Y drives
It reaches Step 2 and fails there with ASC=0x74 ASCQ=0x08 (Digital Signature Validation Failure) expected, wrong key. This
confirms Y-model drives use a separate RSA key from non-Y.

5. Model code 0x41 never reaches RSA
Any firmware with model 0x41 in the FirmHeader fails at Step 1 with f2 (168ms) the drive's ROM has no content hash
registered for any Y-model firmware in FirmHeader format.

What's needed:
A PM04DHWF+FirmHeader format firmware signed with the SRB-Y key (model P4M:41). This doesn't need to be a new firmware
even a recovery stub that just unlocks the drive would be enough.

fohdeesha I know you have recovery working for SMB-Y/SVB-Y. Does your tooling cover SRB-Y (model 0x41) as well, or is that
a different signing key? I have an unlocked AU05 drive available for any testing you need.

Thanks to everyone working on this.

 

[Balteck]

Hi everyone, I have a customer that have a server DELL with 3 SSD drives:

Part Number PH05VHHGTB30077I0TL2A00
Manufacturer TOSHIBA
Product ID PX05SMB040Y
Revision AS10


With perccli I got that they have about 58000 hours each.
Does it mean that they will work for other 500 days?
Or the Y variant has not the firmware bug?

I hope that someone could help me to avoid a dated disaster...

 

[ccxxzz]

AS10 is the latest firmware for many Dell-branded Toshiba drives, 70k hour bug has been fixed in it.
But that doesn't mean you should skip backups! )

 

[Balteck]

AS10 is the latest firmware for many Dell-branded Toshiba drives, 70k hour bug has been fixed in it.
But that doesn't mean you should skip backups! )

Are you sure? @LumpyRareHawk and others wrote that it is not fixed on AS10.
Anyway I'm not worried about backup, I'm worried that suddenly every SSD will die in the same time, the server will stop every VM and DB, and my customer needs to buy the whole SSD storage and to restore the VMs from the previous backup (that surely it is not at one minute before) with the obviously technical times.

 

[MaHeSi84]

@ccxxzz
This specifically concerns the Y-models. The AS10 firmware (and other publicly available versions) does not work on drives that are already locked.
They require a signed recovery firmware capable of cracking the final chunk of the process. I managed to flash the initial segments onto one drive using a bypass method, but I couldn't unlock it. The lock resides in the final chunk, which requires a specific signature to unlock the drive and restore its original capacity.

I’ve spent days and weeks on this, but—at least in my case with my eight 960GB Y-models—I’ve hit a dead end without physically reading the drive via an adapter.

If the hardware key doesn't match, you can't flash anything more than firmware fragments onto a drive that is already bricked.

 

[ccxxzz]

I'm worried that suddenly every SSD will die in the same time

You want me to give you guarantees, on a forum, and for free? ))
The firmware is the latest version, just as I wrote. I’ve been working with servers for over 27 years and my clients have dozens PX05 drives - mostly 3.2TB and 3.84TB models.
I’ve mapped out the POH for each drive, so I know exactly when they’ll hit 70k.
Most of these drives were manufactured back in 2017. My drives haven’t reached the 70k threshold yet, once they do, I’ll verify it myself and decide on the next steps from there.
Many of the servers and storages under my management have uptimes of 2 to 5 years, so I’m not particularly worried about having to restore from backups, even if this firmware actually has a bug.

 

[ccxxzz]

I’ve spent days and weeks on this

Thanks for your time and for sharing your experience, but you probably don't know for sure if the AS10 firmware was already installed there and whether the drive locked up with that exact version.

 

[ccxxzz]

I have some HPE-branded PX05 drives (MO003840JWFWV), and they run the HPD5(H) firmware from 2024, which is exactly the same as the HPD5 firmware from 2019.

 

[MaHeSi84]

Thanks for your time and for sharing your experience, but you probably don't know for sure if the AS10 firmware was already installed there and whether the drive locked up with that exact version.

That is precisely the crux of the matter.
After all, only the Y-models have an internal signature that determines success during the final chunk.

If no one else has a solution at hand, I’ll likely have to sacrifice a drive and solder onto the ROM to read out the appropriate signature. :-/

 

[dvno42]

That is precisely the crux of the matter.
After all, only the Y-models have an internal signature that determines success during the final chunk.

If no one else has a solution at hand, I’ll likely have to sacrifice a drive and solder onto the ROM to read out the appropriate signature. :-/

I'd be curious to hear how that goes. I have one of these dell models also on AS10 and tried to tap the "CN5" pins under the hood but couldn't get it to talk to me.

I tried 1.8v UART at all speeds, sending break signals at power on, but NOTHING.The pins near sas/power offered, GND, 1.8V, 1.8V, NC (not connected). I couldn't pick up serial traffic on those either.

Few pics if you haven't already seen the inside.