Locked HGST drives

Some time ago, we purchased ~25x 1.2TB HGST HUC101212CSS600 drives off eBay for use in our servers.

These disks have three primary issues:

1. They are formatted with 520-byte sectors. This prevents them from working with Dell PERC and HP Smart Array controllers, even when the controllers are set to "HBA-mode". They are only usable with a true HBA (or a controller flashed to the 3rd-party "IT mode" firmware).
2. They have Hitachi Vantara firmware [1] that locks them to Hitachi VSP systems and doesn't let them work with normal servers.
3. They have a lock preventing them from being reflashed with the Dell [2] firmware that would allow them to be used in generic systems.

Problem 1: (520-byte sectors)

This is a very common problem with decommissioned enterprise SAS drives and also typically very easy to fix.

All you need is a "true" HBA in the server that is reformatting the disks. Dell PERC cards and HP Smart Array controllers cannot communicate with 520-byte sector disks whatsoever, even when put into "HBA mode".

The cards inside the Kurisu and Okabe servers have been flashed with the "IT mode" firmware, as their PERC cards were old enough to be flashed using a script).

The sector size of a disk can be reformatted to 512 bytes using sg3utils with the command below:

sg_format -v --format --size=512 --six /dev/sgX

Of note, formatting with the ten-byte variant of MODE SENSE+MODE SELECT (the default) versus the six-byte variant (toggled with --six) will depend on what brand of disk you're using.

• Netapp needs ten-byte, while our drives should need six-byte (based on a comment from someone in a ServeTheHome thread, find the link for this)
• We probably won't know for sure until we unlock the firmware ourselves though.

Problem 2: (Hitachi VSP firmware)

The primary issue with these drives is the firmware only allows them to work with Hitachi VSP systems.

• They will experience I/O errors when used on a regular system, even when reformatted to 512-byte sectors.
• Apparently it is related to the firmware only accepting SCSI_WRITE_WITH_VERIFY commands [3]

These exact physical drives are also sold as OEM variants that work in generic systems without issue.

• The only difference between our drives and those drives is the firmware.
• It should be possible to put OEM firmware onto the disks to allow them to work in our servers. (this leads into problem 3)

Problem 3: (Firmware lock)

In addition to the previous problem, the drives also have a lock that prevents rewriting the firmware.

• They require a specific command be sent before they will allow overwriting the firmware.

Russian dude (WD Niagara)

There is a Russian dude who, for the price of ~$10/drive, will RDP into a Windows environment and flash the drives for you. [4]

He runs a custom script he made that uses WD Niagara (an internal Western Digital tool intended OEMs for advanced HDD operations) to unlock the drives, then uses Niagara's built-in "firmware download" to flash the firmware.

He has uploaded a video of the process to YouTube [5]

If we had the money, this would be the easiest route to solve the problem. However, it'd make more sense to just buy new drives.

Hydata SCSITools

According to a Chinese dude who paid for Hydata SCSITools in another ServeTheHome thread, this program can also send the command to unlock the drives and flash the firmware.

A SCSITools license is $2800. Same as with the Russian dude, at that price it makes more sense to buy different drives.

• SartenX recommended asking them for a free license as students, I seriously doubt they'd give us one though.

Poking at the Windows program, the check for a license key seems really basic.

• It just pulls in hasp_windows_102966.dll which is the Sentinel HASP (Hardware Against Software Piracy) all-in-one check that looks for a valid USB hardware key plugged into the computer.
• I doubt fiddling with Sentinel HASP would be easy, it has checks for VMs, emulated dongles, and even WINE for some reason
• However, the SCSITools binary itself could probably be modded to ignore the HASP check

Hardware

We also considered flashing the drives via the hardware, with a Pomona SOIP8 clip (SOIP8 is the same form-factor as SOP8)

There are pictures of the mainboard in this HDDGuru thread [6]

We identified the following chips on the drive's mainboard:

1. Smooth L7228
   1. Drive Spindle controller?
2. Samsung K4T51163QJ-BCF8
   1. DDR2 memory
3. LSI TNNKU873 BJR12034
   1. Microcontroller
4. MAXIC 25U40325 M1-126
   1. SOP8 ROM (this is the big one)

Apparently only disk-specific calibration information is stored on the ROM and not the actual firmware.

^ (Josh found a forum post from someone trying what we planned, and came to this conclusion. Josh plz post link here)

So the hardware route is a dead-end :(