Anyone noticed this beside me?

[pepe]

that means to me that decryption is not activated with the foreign mcus at all in this case...

[fzabkar]

I would see what happens to the patient when you import those 4 modules from a donor, one at a time. Or perhaps you could zero out the signatures one by one, or flip one of the bits.

[pepe]

1B0 is not unique, 1B6 is only unique from 001E-009E, 1a2 is unique, related to SED lock, 181 is not unique, servo params.

[Doomer]

Looks like the encryption was not inited properly.
Data decryption depends on ASIC keys, Flash modules and SA modules. Changing any of these will result in decrypted data showing different patterns (there are no ways for the drive to tell if the keys are original), unless the encryption engine was not initialized.

[fzabkar]

Looks like the encryption was not inited properly.
Data decryption depends on ASIC keys, Flash modules and SA modules. Changing any of these will result in decrypted data showing different patterns (there are no ways for the drive to tell if the keys are original), unless the encryption engine was not initialized.

The two donors would have different ASIC keys, so wouldn't you expect that they would produce different encrypted data? Since they produce the same data, doesn't this suggest that the "encryption engine was not initialized", and doesn't this then suggest that they rejected the ASIC key (because that is the only thing that is different), which in turn suggests that they know that the key is foreign?

[Doomer]

The two donors would have different ASIC keys, so wouldn't you expect that they would produce different encrypted data?

absolutely

Since they produce the same data, doesn't this suggest that the "encryption engine was not initialized", and doesn't this then suggest that they rejected the ASIC key

very likely

which in turn suggests that they know that the key is foreign?

No, it's probably HOW the drive was initialized is the culprit here, not which PCB was used.
I know for a fact that there is no way for a drive to check if the keys are original.

[fzabkar]

I wrote the same ROM without any modification to those USB pcbs and as i said before and others too

Unique encryption key is located inside MCU (original pcb) not related to the ROM itself only

I understand you but you don't understand me. I'm saying that, if you want to know which ROM module is responsible for your observed behaviour, then disturb each of the possible culprits by invalidating one of its "signatures". @pepe has now told us which areas are unique, so I would concentrate on those.

[fzabkar]

There is also this:

https://forum.hddguru.com/viewtopic.php?p=263590#p263590

DDDD is a security overlay for initial security initialization and digital signature (of code modules) checking

[einstein9]

Looks like the encryption was not inited properly.
Data decryption depends on ASIC keys, Flash modules and SA modules. Changing any of these will result in decrypted data showing different patterns (there are no ways for the drive to tell if the keys are original), unless the encryption engine was not initialized.

how do i double check this process? or how to tell tell if its init. properly?
as i mentioned, i tested this on SpyG2 Ultra, looks like need to try another family to verify

Looks like the encryption was not inited properly.
Data decryption depends on ASIC keys, Flash modules and SA modules. Changing any of these will result in decrypted data showing different patterns (there are no ways for the drive to tell if the keys are original), unless the encryption engine was not initialized.

so, the enc. pattern is supposed to be different here right (sec0 for example as i uploaded) ? when we write Original (none patched ROM) to any other none-native usb?

[einstein9]

Here is sector 0 again with SATA pcb results is Same Enc. pattern

Am not sure if this exception is related to the Case itself or family?

Attachments

[fzabkar]

The capacity reported via SATA is the same as is reported via USB, namely 9767475632 sectors. The full IDEMA capacity of a 5TB drive is 9767541168. That's a difference of 65536 sectors. I usually find that removing the bridge hardware exposes the full capacity of the drive. :-?

As for the pattern being the same, that would be expected since the area where the USB key is stored has not been decrypted by the MCU key.

[pepe]

the bridge does not have anything to do with encr/decr. It does not even have a crypto engine...

[fzabkar]

the bridge does not have anything to do with encr/decr. It does not even have a crypto engine...

Aren't there 3 levels of encryption? SED + MCU key + USB key ? Why would the bridge grab 65536 sectors from the UA if not for a USB key?

[pepe]

nope, 1 encryption, within the MCU and MCU key is used in SED at some stage.
check the specs of those bridges, none of them mention encryption as a feature.
no idea why the bridge grabs that area, ... i wasn't interested enough, probably, got the data off my patient drives and it was pretty much enough for me I will check next time if i do not forget.

pepe

[Doomer]

Why would the bridge grab 65536 sectors from the UA if not for a USB key?

it's for the Virtual CD that contains the unlocker program on it (in case the user sets the password)

[fzabkar]

Why would the bridge grab 65536 sectors from the UA if not for a USB key?

it's for the Virtual CD that contains the unlocker program on it (in case the user sets the password)

I know that, but it's @pepe who thinks this area is not used. In any case, if the bridge IC doesn't support encryption, as @pepe claims, then what? And why isn't this small region exposed to a SATA host when the bridge is removed, as is the case for My Books?

[einstein9]

fzabkar, Those NEW MCU locked pcbs are completely different than the old encryption types... totally new

something (unique key probably) stored inside the native MCU (USB3 pcb)... without it NO DATA

My point here or question is: Why the hell no matter what pcb i use (sata/other usb3) the data is encrypted with the same pattern?
does this means something????

Doomer says: "encryption engine was not initialized."

[fzabkar]

Doomer says: "encryption engine was not initialized."

Doomer also says that ROYL module 0xDDDD is responsible for initializing the encryption engine. You have PC3000. PC3000 can decompress the ROM segments. I suspect that one of the smaller compressed segments will be module 0xDDDD.

[fzabkar]

I suspect that if you compare your ROM against others of the same version (0000000A), there will be a difference in the compressed 0xDDDD segment, assuming that it does exist.

Code:

LDSC   LDSC    Att   PCMBlock          RAM         size      PCMBlk CS
Start  ID CS        Start -  End     address     RAM / ROM    Exp/Act
-----  -- --   --   -----   -----   --------   ------ -----  ---------
    0  5A CA   04     160 -  2287      55688     2124  2124  000CEC35 000CEC35 OK (not digitally signed)
   20  01 9B   11    2288 -  64C8   30080000 c   5798  4240    D4   D4   OK
   40  02 2B   0C    64C9 -  68D1   24000000      408   408    47   47   OK
   60  03 A2   40    68D2 -  C5BE   FFE00200     5CEC  5CEC    55   55   OK
   80  04 89   01    C5BF -  D0D3   382D4800 c    D54   B14    6F   6F   OK
   A0  05 7C   01    D0D4 - 12180          0 c   66C0  50AC    0A   0A   OK
   C0  06 82   01   12181 - 1259D      15F94 c    4EC   41C    99   99   OK  <--  could this be the compressed 0xDDDD module ?
   E0  07 9A   03   1259E - 15026      402E0 c   3698  2A88    2D   2D   OK
  100  08 5B   03   15027 - 153E3   602D6800 c    9A8   3BC    18   18   OK
  120  09 98   01   153E4 - 2E628   383CA400 c  21AC0 19244    7D   7D   OK
  140  0A 4C   01   2E629 - 51D99   38008230 c  30930 23770    76   76   OK

LDSC   = PM Loader Config String (32 bytes)
ID     = ID byte of LDSC (byte #0)
CS     = Checksum byte or word
Att    = Attributes
PCMBlk = Program Code Memory Block
Exp    = Expected checksum for PCMBLock
Act    = Actual checksum for PCMBLock
c      = compressed PCMBlock
size   = size of decompressed (in RAM) and compressed (in ROM) PCMBlock in bytes


Firmware Version = 01.01A01
World Wide Name = 50014EE2BEBE6238
Model Number = WDC WD50NDZW-11A8JS1

ROM version = 0000000A

[pepe]

Doomer says: "encryption engine was not initialized."

that's what i was trying to say, pattern is the same no matter if SED is on or off, this means decryption is not active and you see the encrypted data with whatever pcb you try.
you need to find the reason why.
pepe