20 Aug 2020
2024
2003
015
1220

There are several others that I can't read (your photo is unclear).

_________________
A backup a day keeps DR away.

20 Aug 2020 from the HDD sticker

Now where is the other info from the pcb side? if the image is not clear, just point to the place where you wanted me to focus on and will make a better image 4u


FYI: relying on Dates is not a good idea since the hdd production line produces many on the same date right?

BUT
my findings is certain ...

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

On the component side.

Show me the ROM and MCU, without the thermal pad.

_________________
A backup a day keeps DR away.

It looks like nobody wants to play your game.

I'm guessing that simply trying each PCB to see which one starts the drive and decrypts the data is not an acceptable solution? Obviously I don't have any experience in this area, but I'll start by identifying security-related objects.

There are these 3 ROM resident ROYL adaptive modules:


The ROM boot block is digitally signed at the end of the block.

One of the ROM's PCMBlocks is a compressed 0xDDDD ROYL module. I have attached an example from a SpyGlass3. If I understand correctly, 0xDDDD is required for initialising the drive's crypto-engine.

I expect that the digital signatures may have no relationship to the MCU key. One way to find out would be to compare two drives that have identical firmware and check whether their identical boot blocks have the same signature.

Another test would be to install a donor PCB with identical firmware on a patient HDA, after transferring the ROM adaptives one by one.

Another test might be to execute an ATA 90h Execute Drive Diagnostic command and observe any error code.

_________________
A backup a day keeps DR away.

I remembered this old thread:

https://forum.hddguru.com/viewtopic.php?p=264106#p264106

It appears that 0xDDDD is not unique.

_________________
A backup a day keeps DR away.

The code that creates the MCU keys (there are 2 keys involved in data encryption) calls for a random generator inside the MCU, so unless there is a security weakness inside the random generator (very unlikely) or the keys are also copied somewhere else on the drive (possible but not likely) it would not be possible to decrypt data without the original MCU

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

Yes, it's possible with about 99% certainty.

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

I'm not sure with what you are disagreeing.
I've never said removing the keys, I said extracting the keys and writing a software decryptor (would not be easy, because the keys are salted but possible)

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

0xDDDD is a security overlay (digitally signed) that, AFAIR, checks signature of module 0x11 (main code overlay).
It's not unique

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

This is not a Game fzabkar,, A research and finding thing, you are not in DR (i wish if u were) but what you are telling about changing pcbs and figure out which is booting and so is a time wasting approach. many other easier ways to do the same work.

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

Am 100% certain of my finding (PM OTW)

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

Sure it is there somewhere (in another form)
Unique KEY which is located inside MCU is also located somewhere on the drive.

When drive powers ON drive reads & compares both if match will carry on booting IF NOT (even if same native ROM) data enc. (compare Enc. data with multiple donor PCBs and figure out the pattern).

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

One of the easier ways is to observe the date codes, at least for some cases. I can do that from a photograph.

https://www.hddoracle.com/viewtopic.php?p=495#p495

And thank you for your well wishes. Actually, my first data recovery case was during the 1980s. It was intellectually satisfying, and I do wish that my trajectory had continued on that path in later years. In fact, Ontrack's first case was during that time. Also, Steve Gibson was writing Spinrite during those years (it actually had some relevance then).

_________________
A backup a day keeps DR away.

I did not know this Thnx for the info..

btw, you are doing very well, should think about investing in DR and give it as shot

all the best.

FYI, knowing if the pcb is native or not takes 20sec. only

_________________
Kuwait Data Recovery - UNIX GTC
The only reason for time is so that everything doesn't happen at once. By: Albert Einstein

even without ROM?

_________________
Adatmentés - Data recovery

There are a few drives when PCB is changed on the factory without recertifying the drive, so far I've see only two such drives, that's why I said 99% not 100%.

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

Thanks for the info.
That means there's no constant keys located in the FW to compare with the one created randomly in MCU?. If I understand well.


???????

If the keys would have been constant there would be no point using original MCU, any MCU would work.

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

This is very doubtful.
At least I have never seen any comparison.

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.

Please excuse ignorant me for asking the obvious question, would @einstein9, or his researchers, not have tested this claim by modifying the copy of the key?

_________________
A backup a day keeps DR away.