ST3000NC000 locked terminal FW CNS1

Hi everyone,
I've been searching trough the forum for this drive, but I find minimum posts about it.

I am trying to get terminal access, but the terminal is disabled.
This is what I get, hammering the ctrl+z:

Code:: Boot 0x40M Spin Up Trans. Spin Up SpinOK &> (1Ah)-TCG Serial Port Disabled (P) SATA Reset ASCII Diag mode F3 T> &> (1Ah)-TCG Serial Port Disabled

Then the terminal is frozen, it does not accept any keystrokes.
Anyone know how to get access to it?

Thanks!

I understand that I have to download the ROM, unlock it and upload it again to have this working.
I found this guide: https://www.dolphindatalab.com/how-to-r ... rd-drives/

Unfortunately MRT (that I am using) does not support this ST3000NC000 model.
Anyone who has done this that can share an unlocked ROM?

Thanks!

Adisa wrote:I understand that I have to download the ROM, unlock it and upload it again to have this working.
I found this guide: https://www.dolphindatalab.com/how-to-r ... rd-drives/

Unfortunately MRT (that I am using) does not support this ST3000NC000 model.
Anyone who has done this that can share an unlocked ROM?

Thanks!

Sadly, it’s not as simple as that.

Firstly, the “unlock” is only a specific unlock that needs the corresponding key from your tool (e.g. MRT or PC3000) and as soon as it’s powered off it’s locked again.

Secondly, ALL Seagate F3 architecture drives have a 100% unique ROM, so a “shared” ROM will do you no good whatsoever.

Aside from the key, a "shared ROM" could presumably be made to work after importing the patient's adaptives. That's assuming that the unlocking is done in the code segments. Or am I missing something?

Perhaps the OP could upload a locked and unlocked ROM for a supported model so that we could see how MRT does it. Then perhaps we could make similar changes to the ST3000NC000 ROM. We could also see if PC3K makes the same changes.

fzabkar wrote:Aside from the key, a "shared ROM" could presumably be made to work after importing the patient's adaptives. That's assuming that the unlocking is done in the code segments. Or am I missing something?

Perhaps the OP could upload a locked and unlocked ROM for a supported model so that we could see how MRT does it. Then perhaps we could make similar changes to the ST3000NC000 ROM. We could also see if PC3K makes the same changes.

Sadly, that won’t work.

An “unlocked” ROM using the unlock feature from PC3000 (I can’t speak for MRT as I don’t use it, but as it’s as a ripoff of PC3K then I can assume it’s the same/similar) will prompt a code in terminal (different each time) for a corresponding code from the tool before it unlocks and proceeds to initialise the drive.

Without any code being entered, the drive will just sit there BSY waiting for the code. If an incorrect code (or just “enter” a couple of times) it will initialise but still locked.

The unlocking “feature” is generally only used to allow the user to fix any firmware issues (to edit ID and disable background tasks etc. for example) before reverting the ROM back to “locked” so the drive can be cloned or whatever needs to be done.

pcimage wrote:
fzabkar wrote:Aside from the key, a "shared ROM" could presumably be made to work after importing the patient's adaptives. That's assuming that the unlocking is done in the code segments. Or am I missing something?

Perhaps the OP could upload a locked and unlocked ROM for a supported model so that we could see how MRT does it. Then perhaps we could make similar changes to the ST3000NC000 ROM. We could also see if PC3K makes the same changes.

Sadly, that won’t work.

An “unlocked” ROM using the unlock feature from PC3000 (I can’t speak for MRT as I don’t use it, but as it’s as a ripoff of PC3K then I can assume it’s the same/similar) will prompt a code in terminal (different each time) for a corresponding code from the tool before it unlocks and proceeds to initialise the drive.

Without any code being entered, the drive will just sit there BSY waiting for the code. If an incorrect code (or just “enter” a couple of times) it will initialise but still locked.

The unlocking “feature” is generally only used to allow the user to fix any firmware issues (to edit ID and disable background tasks etc. for example) before reverting the ROM back to “locked” so the drive can be cloned or whatever needs to be done.

The MRT works just like you describe for PC-3000. It promts for the unlock key right before booting.
Attached is the ROM from my drive, if someone could try with PC-3000 to unlock the disabled serial port, I could try and see if it works.
Appreciate your help!

Attachments

ROM-20171213190301.zip: (353.97 KiB) Downloaded 325 times

So the code is different for each ROM, but does a particular ROM generate different codes each time the tool is run against it?

Could the OP take a particular supported ROM and unlock it with MRT, twice? Then could we see the original locked ROM plus the two unlocked copies? This would at least gives us some insight into the procedure. Otherwise we are just stabbing in the dark.

Yes, I think the code is different each time. In the terminal output, it tells the code, right before it ask for it.
Attached are the unlocked ROM and the original ROM from MRT.
This is from the unsupported ST3000NC000.

When applying the unlocked ROM, it promts for the key in the bootup, but the serial port is still disabled.

Attachments

ROM-Unocked-20171213202801.zip: (711.8 KiB) Downloaded 289 times

The changes are applied to the CFW segment (Controller Firmware). The original (locked) CFW segment has a single compressed section (CPRS) while the unlocked CFW segment has two CPRS sections.

ICBW, but ISTM that the first CPRS sections of the two ROMs have identical decompressed sizes of 0x19CC4 bytes. The compressed versions differ in size by 4 bytes (0x1427C versus 0x14280). I suspect that the actual differences in the decompressed versions amount to only 1 or 2 bytes. I'm wondering whether the original code has been hacked so that it jumps to a subroutine in the second CPRS section, in which case the "unlocking" code, and key, would be located there.

The whole-space CRCs for both CFW segments are 0x0000, so no problem there. However, the used-space CRCs are non-zero for both. This anomaly is either not significant or perhaps my interpretations are in error.

The other strange thing is that the decompressed size (0x6F0) for the second CPRS section is less than the compressed size (0x7D4). Once again it could be that my interpretation is in error.

CFW_original.bin

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 000032A0 05 F0 09 05 F0 A1 23 00 ^^^^^ 000032B0 43 50 52 53 7C 42 01 00 C4 9C 01 00 E0 1C 51 80 CPRS|B..Äœ..à.Q€ ^^^^^^^^^^^ ^^^^^^^^^^^ compressed /decompressed(?) sizes 00007680 78 A3 B2 37 CB 0A 41 49 84 81 05 70 01 56 4C 88 ^^ differences begin here ........ 0000A520 10 D7 0C 00 B1 67 87 67 C4 64 3A 0E F6 34 C0 E1 files resync here ^^ ........ 00017520 FF FF FF FF FF 03 00 00 43 50 52 53 02 00 00 00 ÿÿÿÿÿ...CPRS.... end of single compressed section ^^^^^^^^^^^ 00017530 00 00 00 00 00 00 00 00 00 00 00 00 B3 8F 00 00 used space checksum ^^^^^ 00017540 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ........ 00018790 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 000187A0 FF FF FF FF 36 38 00 00 whole space checksum ^^^^^

CFW_unlocked.bin

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 000032A0 05 00 0A 05 F0 A1 23 00 ^^^^^ 000032B0 43 50 52 53 80 42 01 00 C4 9C 01 00 E0 1C 51 80 CPRS€B..Äœ..à.Q€ ^^^^^^^^^^^ ^^^^^^^^^^^ compressed /decompressed(?) sizes ........ 00007680 78 A3 B2 8F 7A 08 00 13 50 47 EA F9 28 01 C0 02 ^^ differences begin here ........ 0000A530 08 F6 34 C0 E1 A9 42 82 D1 CF 95 27 17 63 98 10 ^^ files resync here ........ Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00017520 14 A5 FF FF FF FF FF FF FF FF 03 00 43 50 52 53 .¥ÿÿÿÿÿÿÿÿ..CPRS end of first compressed section ^^^^^^^^^^^ 00017530 03 50 1F 00 F4 3E 25 00 43 50 52 53 D4 07 00 00 .P..ô>%.CPRSÔ... start of 2nd compressed section ^^^^^^^^^^^ ^^^^^^^^^^^ compressed size = 0x7D4 00017540 F0 06 00 00 14 80 03 F0 AB 4C 90 02 00 30 18 00 ^^^^^^^^^^^ decompressed size = 0x6F0 ??? ....... 00017D00 FF FF FF FF FF 1F 00 00 43 50 52 53 02 00 00 00 ÿÿÿÿÿ...CPRS.... end of second compressed section ^^^^^^^^^^^ 00017D10 00 00 00 00 00 00 00 00 00 00 00 00 7A 68 00 00 used space checksum ^^^^^ 00017D20 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ........ 00018790 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 000187A0 FF FF FF FF C3 6F 00 00 whole space checksum ^^^^^

Code:: Directory of C:\Downloads\Seagate\Firmware\ST3000NC000 ROM-20~2 BIN 524,288 12-13-17 7:04p ROM-20171213190407.bin ROM-UN~1 BIN 524,288 12-13-17 8:28p ROM-Unocked-20171213202801.bin CFW_OR~1 BIN 100,264 12-16-17 8:29a CFW_original.bin CFW_UN~1 BIN 100,264 12-16-17 8:25a CFW_unlocked.bin CFW_OR~2 BIN 95,552 12-17-17 7:08a CFW_original_used_space.bin CFW_UN~2 BIN 97,568 12-17-17 7:08a CFW_unlocked_used_space.bin

Code:: CFW_unlocked.bin: CRC16 = 0x0000 CFW_original.bin: CRC16 = 0x0000 CFW_original_used_space.bin: CRC16 = 0x0086 CFW_unlocked_used_space.bin: CRC16 = 0x3B43

Attachments

CFW.rar: (356.18 KiB) Downloaded 355 times

Adisa wrote:Yes, I think the code is different each time.

Could you please provide a second unlocked ROM (for the same original ROM)? We could then compare the two unlocked ROMs to see where the different "codes" are stored.

fzabkar wrote:
Adisa wrote:Yes, I think the code is different each time.

Could you please provide a second unlocked ROM (for the same original ROM)? We could then compare the two unlocked ROMs to see where the different "codes" are stored.

Thanks for helping me out!
Here are another unlocked ROM.

Attachments

ROMChange-20171218082807.zip: (357.84 KiB) Downloaded 320 times

The differences between the two unlocked CFW segments are confined to the second CPRS section, so that's where the key must be located. Unfortunately I don't know how to decompress these CPRS modules, so I've reached a dead end. The decompressed size in both cases appears to be 0x6F0, which is less than the compressed size. This leads me to wonder whether the data are incompressible, in which case further compression would only add overhead. Of course this is assuming that my assumption is correct.

second unlocked ROM (CFW)

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00017530 03 30 1F 00 F4 3E 25 00 43 50 52 53 CC 07 00 00 .0..ô>%.CPRSÌ... ^^ compressed size ^^^^^^^^^^^ 00017540 F0 06 00 00 14 80 03 F0 2B 16 8F 01 00 30 18 00 ^^^^^^^^^^^ ^^^^^^^^^^^ diff ........ 00017620 60 30 C2 E1 C6 AA 73 FC 42 B5 88 D1 6D 56 BE 53 ^^ start of differences ........ 00017CF0 29 F7 04 D8 14 BE FF FF FF FF FF FF FF FF 00 00 00017D00 43 50 52 53 02 00 00 00 00 00 00 00 00 00 00 00 CPRS............ 00017D10 00 00 00 00 7A 68 00 00

first unlocked ROM (CFW)

Code:: Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00017530 03 50 1F 00 F4 3E 25 00 43 50 52 53 D4 07 00 00 .P..ô>%.CPRSÔ... ^^ compressed size ^^^^^^^^^^^ 00017540 F0 06 00 00 14 80 03 F0 AB 4C 90 02 00 30 18 00 ^^^^^^^^^^^ ^^^^^^^^^^^ diff ........ 00017620 60 30 C2 E1 C6 AA 73 81 86 08 1A 92 E6 D0 AB 68 ^^ start of differences ........ 00017CF0 D6 D8 F9 92 E3 8F 83 55 5B FE 00 22 E4 F0 FF FF 00017D00 FF FF FF FF FF 1F 00 00 43 50 52 53 02 00 00 00 ÿÿÿÿÿ...CPRS.... 00017D10 00 00 00 00 00 00 00 00 00 00 00 00 7A 68 00 00

Hmm, I was hoping this was a standard procedure for those with the tool that supports this model. In MRT there is a “one click solution” to unlock supported drives. If anyone could spread some light over this for me I would appritiate it!

Thanks!

FWIW, this is my take on the patch.

Code:: .---------. | CPRS_1 | | start | |_________| | | | | |_________| | |->--. .-->| hack | | | |_________| | | | | | | | | | | | | | | |---------| | | | CPRS_1 | | | | end | | | '---------' | | _________ | | | | | | | CPRS_2 | | | | start |<---' | |_________| | | | | | new | | | code | | | + | | | key | | | | | |_________| | | | | | CPRS_2 | '-<-| end | '---------'

ISTM that the original single section (CPRS_1) has been "hooked into" by the added section (CPRS_2) .

Would it make sense to import the patient's adaptives into an unlocked ST3000DM001 donor PCB and/or ROM?

ST3000NC000 locked terminal FW CNS1

ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1

Re: ST3000NC000 locked terminal FW CNS1