SpyGlass3 decryption problem.

[Carmet L]

Complex case from another shop.

Notes from other shop:

The drive had a corrupted module 02 on all copies (DE-AD throughout)

Donor module edited and loaded allowings drive to boot nromally.

190 has been cleared, all copies zeroes, but SA Backup has some T2RawData.bin files that, when loaded into T2 utility, show 1.7 TB of user data.

Cannot decrypt data no matter what tried.

My first question is: does the decryption rely on anything in native module 02 ? 

If so, that would be the end of the recovery.

[Desert Data Recovery]

Is the donor 02 from exactly the same make, model and ROM FW?

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/fccb0e65-0409-4847-801d-a74b1ca1f5fen%40googlegroups.com.

[Carmet L]

Good question, I don't think I can tell.

Utility shows this for the drive:

>ROM Modules:
>ROM version............................. : 01.0CC
>Module 4F F/W version................... : 0001000C
>Overlay F/W version..................... : 01.0DC
>Servo F/W version....................... : 03.85

I have some other 01.0CC in profiles that I could use, but nothing that matches the >Overlay F/W version..................... : 01.0DC exactly.

I saw that the hidden modules are also not backed up.

[pbzcbf...@gmail.com]

Wasn't there a similar case not long ago where the ROM directories were swapped and various ROM-resident, security-related modules were empty??

Would it be appropriate to dump the ROM and SA modules 0x109, 0x129 and 0x130?

[Extreme Solutions Parthipan]

can u send your SAbackup?

On Wed, Aug 5, 2026 at 6:00 AM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

Wasn't there a similar case not long ago where the ROM directories were swapped and various ROM-resident, security-related modules were empty??

Would it be appropriate to dump the ROM and SA modules 0x109, 0x129 and 0x130?

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/4c1df034-3454-46a7-a619-5229c93f1b47n%40googlegroups.com.

[Carmet L]

I suspect that's part of the issue as I cannot get at the hidden modules 90, 129, and 130

Have attached 109 and the locked/unlocked ROM for what they're worth.

[Carmet L]

I've zipped up both copies and pasted the links below for both of the SAbackup directories (XYZ version and Full ID version)

https://drive.google.com/file/d/1FMvp1N87AhbJfLA_Q1Ng3JyEQ7e0mhlT/view?usp=drive_link

https://drive.google.com/file/d/1vzrBE7FoI5FS4FFUeBY5U6ucKddFsP1T/view?usp=drive_link

[Extreme Solutions Parthipan]

In this SABackup 25 corrupted 38 OK as per 38 Says WDV2 but D006 and 127 says there is no SED.

So someone must changed D006 and 127. Try with donor D006 and 127  from encryption enabled drives.

Also check your PCB serial ,XAYW9909RG100045205

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/84c96d55-777f-4beb-89b4-7f6c97ca860en%40googlegroups.com.

[pbzcbf...@gmail.com]

Here are the hidden modules (extracted from module 0x11):

Offset(h) 00   02   04   06   08   0A   0C   0E   10   12

00000000  1402 4000 4806 0000 0318 0000 0000 0000 0000 0000
00000014  1402 0100 4000 0000 0318 8042 0000 0000 0000 0000
00000028  1402 3500 0A00 0000 031A 0000 79CD 0B00 79CD 0B00
0000003C  1402 EF00 1E00 0000 031A 0000 CACB 0B00 CACB 0B00
00000050  1402 B511 1000 0000 031A 0000 BACB 0B00 BACB 0B00
00000064  1402 9000 2003 0000 031A 0000 20C8 0B00 20C8 0B00  <-- 0x90, ABA 0xBC820, size 0x320
00000078  1402 C000 7A00 0000 031A 0000 40CB 0B00 40CB 0B00
0000008C  1401 3B25 6400 0000 011A 0080 0000 0000 0000 0000
000000A0  1401 3B2D 6400 0000 011A 0080 0000 0000 0000 0000
000000B4  1401 001A 4000 0000 011A 0080 0000 0000 0000 0000
000000C8  1401 0506 0600 0000 011A 0080 0000 0000 0000 0000
000000DC  1401 0606 0600 0000 011A 0080 0000 0000 0000 0000
000000F0  1402 2901 C800 0000 031A 0000 E9CB 0B00 E9CB 0B00  <-- 0x129, ABA 0xBCBE9, size 0xC8
00000104  1402 3001 C800 0000 031A 0000 B1CC 0B00 B1CC 0B00  <-- 0x130, ABA 0xBCCB1, size 0xC8
00000118  1402 8801 0100 0000 031A 0000 E8CB 0B00 E8CB 0B00
               ^^^^ ****                +++++++++ =========
               ID   size                ABA #0    ABA #1

If you cannot dump these hidden modules by accessing their ABA locations, I can modify the directory (module 0x01) to include these modules and make them visible. Then you could upload my modified 0x01 directory module into RAM and dump the hidden modules in the usual way.

[pbzcbf...@gmail.com]

I have attached sorted versions of module 0x01.

[Carmet L]

PCB serial  confirmed XAYW9909RG100045205

I've tried several D006 and 127 modules from the same firmware and slightly different ones; all give the same issue.

25, 12E, 13A and 4002 are the only mods that tested bad in composite read.

T2 looks promising

Drive Translation = Zeros

Upload T2 into RAM = Encrypted garbage

HDD ID check..

So far, no matter of the configuration changes, sectors are still zero or garbage.

[Carmet L]

Don't think the module 01 trick has worked Franc, as its not showing the hidden mods either from RAM or written to SA.

generated a report (attached)

Also, tried pulling them from utility anyway but its still missing them out.

[pbzcbf...@gmail.com]

The previous 0x01 module was your own unmodified version. My modified version is attached. I had to rename two of the other hidden modules to prevent conflict with their visible counterparts.

[pbzcbf...@gmail.com]

This is section 32 in module 0x02:

SED unlocked

Section 32     Length 9 / 0x9 bytes     Offset 0xA51

Addr  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0000  00 00 00 00 00 00 01 00 00
                  ^^
            SED flag


SED locked

Section 32     Length 9 / 0x9 bytes     Offset 0xA51

Addr  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0000  00 00 00 00 01 00 01 00 00
                  ^^
            SED flag

Your SED flag is set to the unlocked state.

[Carmet L]

I tried your previous 01 in RAM and wrote it to SA as well, but it didn't show the hidden mods

This new 01 now shows them in the mods directory, but they fail the test because they have no headers.

Should I save them out as is, recalc a new header checksum, and then rewrite them to SA ?

[pbzcbf...@gmail.com]

I wouldn't write anything to the SA. Can you just upload these new modules?

[Carmet L]

Manually saved.

[Carmet L]

Checking the SED security subsystem in module 02 against another working drive shows that they use the same settings, so I am not sure what to change to activate the SED locked option in this one.

[pbzcbf...@gmail.com]

I'm wondering whether you have two levels of encryption. The first would be SED or some other encryption at the SATA level (ROM modules and SA module 0x02). On top of that would be SmartWare encryption related to the USB-SATA bridge and SA module 0x38.

If you convert the drive to SATA, you would eliminate the USB encryption layer. The SmartWare area at the end of the UA should then be visible in plain text, mostly zeros. If you still see non-zero gibberish, then that would point to encryption at the SATA level rather than the bridge.

[pbzcbf...@gmail.com]

I can see two ROYL modules in 0x90, but 0x129 and 0x130 contain junk.

[pbzcbf...@gmail.com]

If your model is not a SED, then nothing needs to be changed.

[Desert Data Recovery]

I haven't followed this entire post so may have been suggested, but mod 25 controls encryption on these drives. 

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/754d06de-e316-48c2-8dfe-bee18002674fn%40googlegroups.com.

[Carmet L]

The native PCB has our pin adapter on it to convert to SATA since we started working with this one.

The garbage sectors end at LBA 3,360,967,743 and are zeros from that point right to the penultimate sector here: 7,813,971,631

The plastic casing shows WD Elements, so theoretically it's not SED, but that doesnt always seem to be the case in practice.

[pbzcbf...@gmail.com]

In SATA mode the last sector would be 7814037167. The difference is  65536 sectors. In any case, the zeros would suggest that the issue is at the bridge level. That in turn points to a problem with module 0x25, as others have already mentioned. That said, is there a key in the Smartware area? Can you dump sectors 7,813,971,632 to 7814037167? The key should be in that range.

[Desert Data Recovery]

Mod 25 looks bsd.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/6f2c1396-a8f9-409f-9d1d-8b67ab0ad744n%40googlegroups.com.

[Carmet L]

Every copy of 25 tested bad; just trying to read a composite one out now, ignoring errors, but its likely trashed.

I'll come back to trying to get a dump of 7,813,971,632 to 7814037167 once this has finished.

[Desert Data Recovery]

You can sometimes het lucky. While some of the module is made up of unique data. Some is just structure that can be copied from a good mod 25.  

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/978eebfc-744c-4e5e-8484-bf7d1092b2den%40googlegroups.com.

[pbzcbf...@gmail.com]

FWIW, WD's warranty page confirms that the model number is associated with an Elements Portable, model WDBU6Y0040BBK-WESN.

https://support-en.wd.com/app/warrantystatusweb

On Thursday, August 6, 2026 at 2:36:49 AM UTC+10 lc70...@gmail.com wrote:

[compos mentis]

I checked this SpyGlass3 resource dump:

https://files.hddguru.com/download/PC-3000-UDMA%20Support/WDC%20Marvell%20family%20utility/SpyGlass3/WDC%20WD40NDZW-11BCSS0-01-01A01-WD-WX52DA18DRDJ.rar

The "WD" section in module 0x38 is an exact copy of the one in module
0x25. Both modules have no other content other than the ROYL header.
Moreover, the "WD" section in this donor is an exact copy of your own
module 0x38. Also, modules 0x25 and 0x38 have the same firmware version,
so it would be easy to generate 0x25 from 0x38.

[compos mentis]

I have attached my regenerated version of module 0x25. I suspect that no
USB encryption is involved.

[compos mentis]

If sector 7,813,971,631 is the last sector of the visible user area, and
if the preceding area is zero-filled, what data lives in the last two
sectors? These sectors should contain GPT metadata, and the sectors
immediately prior should contain zeros.

[compos mentis]

Assuming the drive is partitioned as GPT, then the last two sectors
should be copies of sectors 1 and 2.

[Artem Rubtsov]

Could you elaborate on "Cannot decrypt data no matter what tried."

What exactly happens? 

[Carmet L]

Thanks Franc but despite module 25 being regenerated by your effort, it still fails header check (opens OK in utility) but hasn't made any difference to the decryption process.

Not sure how to create a dump of the area containing zeros that you want to inspect. If you tell me how to do it, I'll get it done.

Artem:

- Tried using the native PCB converted to SATA with unlocked ROM to load T2 through utility (3K - see above screenshots) for translation as direct translation from drive yields only zeros.

- Tried using PBA access through utility and associated variants (Read CHS RAW, Read CHS with Relo) - no difference

- 190 all copies are empty

- T2RawData.bin shows 1.7 TB of Data when loaded into utility, however loading that into RAM only gives encrypted sectors.

- Tried disabling and enabling SED lock in 02, no difference.

- Tried replacing 127 and D009 mods from encrypted donor firmware, no difference.

- Tried loading Francs mod 25 regeneration, no difference.

I either end up with zero's in sector edit in 3K utility or encrypted looking sectors... no 'user data, MBR, GPT etc.' looking sectors.

[compos mentis]

Sorry, I forgot to edit the module ID in the header. I've fixed it, but
I suspect module 0x25 is a red herring.

As for dumping those sectors, they should be visible via SATA. I don't
have a pro tool, so I would be using a disc editor like DMDE. You
obviously have a sector viewer. Can you not use that to save a range of
sectors to a file?

[Extreme Solutions Parthipan]

Sir can u get backup from your previous DR?

There are two serial numbers WD-WX62D84CJH80 and WD-WX92D457WT82.

129 and 130 modules need for original rom modules.

02 is not big issue. i suspect some of modules must be replaced before u get the drive

Try this if it not worked then u need backup from previous DR

On Wed, Aug 5, 2026 at 4:44 AM Carmet L <lc70...@gmail.com> wrote:

Complex case from another shop.

Notes from other shop:

The drive had a corrupted module 02 on all copies (DE-AD throughout)

Donor module edited and loaded allowings drive to boot nromally.

190 has been cleared, all copies zeroes, but SA Backup has some T2RawData.bin files that, when loaded into T2 utility, show 1.7 TB of user data.

Cannot decrypt data no matter what tried.

My first question is: does the decryption rely on anything in native module 02 ? 

If so, that would be the end of the recovery.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/fccb0e65-0409-4847-801d-a74b1ca1f5fen%40googlegroups.com.

[Extreme Solutions Parthipan]

my doubt the previous DR must changed some modules

one simple example attached image

also 2D 2E 129 130 contains most important information.

here 2D is from donor. by changing 2D from donor u can't verify the SED module informatin.

may be reason behind is QUOTATION

On Thu, Aug 6, 2026 at 2:31 PM Carmet L <lc70...@gmail.com> wrote:

WD-WX62D84CJH80 is donor firmware but does not contain 129 and 130

WD-WX92D457WT82 does not contain 129 or 130

XYZ does not contain 129 or 130

Franc modified mod 01 so we could see 90, 129 and 130 in the directory, but only 90 was proper; 129 and 130 were garbage.

Also tried replacing 127 and D006 from your attachments and from these folders, but the data still remains encrypted, regardless of the translation method variant (native is zeros).

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/fc70f304-7fbb-4a69-9a63-22f9bfae8b25n%40googlegroups.com.

[Carmet L]

Yes, understood, and ultimately it's looking like the end of the road for this recovery.

[compos mentis]

If half the user area contains zeros when viewed via SATA, wouldn't this
suggest that it's not a SED problem or ROM problem? Moreover, I'm
betting that there is an empty encryption key template (with "WD"
signature) near the end of the UA, and I expect that this template is
identical to the one in modules 0x25 and 0x38.

I think my previous suggestion regarding a comparison of the GPT sectors
at the beginning and end of the visible user area would be instructive.
These sectors should be copies of each other. If they are not copies,
then it's not a simple encryption issue, as I see it.

[compos mentis]

There are large gaps in the module directory. These gaps may be occupied
by hidden modules, and may even contain remnants from earlier firmware
builds. I can create a modified 0x01 module with a dummy module for each
gap. Then you could dump these dummy gap modules and scan them for
interesting stuff. In older drive families SA modules 0x802E and 0x802F
contained backups of module 0x02, but in your case these are empty.
Perhaps we will find other copies in the gaps?

[Carmet L]

If you think we still have some hope of finding a way to resolve this one Franc, then I'm happy to keep trying things
.

The only thing with the empty sectors at the end of the drive is that they are zeros, so I'm not sure what we can achieve from those ? 

[compos mentis]

The full capacity, via SATA, is 7814037168 sectors. The last ~65000 sectors constitute the SmartWare area that the bridge hides from the OS. Towards the end of the drive, in amongst those zeroed sectors, is a key sector. This sector exists in Elements models, even when there is no encryption. If you see this key sector, that means that the drive is not encrypting it. Basically I'm asking, how can the first part of the user area be encrypted, but not the last part? That's the kind of thing that would normally happen at OS level, not firmware level.

[Carmet L]

Ok, so what do you want me to do next ?

[compos mentis]

I would break the problem down into smaller parts. Several people have
suggested that SA module 0x25 is a possible culprit. I have examined a
set of donor resources and found that there is an empty encryption key
template in SA modules 0x25 and 0x38. The identical template exists in
both modules and also in your own 0x38 module. I'm now suggesting that
you dump the last 65536 sectors of your patient in SATA mode. If you
find the same empty template, this will prove that there is no encyption
happening at the USB level.

This is the empty template:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000200  57 44 76 32 6F 22 00 00 00 B8 BF D1 01 00 00 00 WDv2o"...¸¿Ñ....
00000210  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000220  01 00 00 00 00 00 46 50 00 00 00 00 00 00 00 00 ......FP........
00000230  00 00 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 ..ÿ.............
00000240  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000250  00 00 00 00 00 00 00 00 00 00 00 00 57 44 76 32 ............WDv2

Your previous screenshots are showing a capacity of 7,813,971,632
sectors. A 4TB drive's full capacity is 7814037168 sectors. That's a
difference of 65536 sectors. This means that you are accessing the drive
via USB rather than SATA. In USB mode those extra sectors are reserved
by the bridge for its own use and cannot be seen by the OS.

For these tests, I would allow the drive to power up as normal, without
manipulating the T2 translator. That just adds an extra level of complexity.

After you have eliminated USB encryption as a possible culprit, you can
ignore modules 0x25 and 0x38 and focus your attention elsewhere.

[Artem Rubtsov]

Does the drive kill 02 each time you power it up?

[Carmet L]

@Franc 

Not sure how the USB bridge can be active, though, as I've removed the 4 caps and have a SATA adapter connected to the solder points on the patient PCB.

I could remove the patient PCB altogether and try it on a native SATA PCB to double-check LBA numbers, but beyond that the sectors will show as encrypted from start to finish. 

I'm still at a loss on how to dump the sectors 65536 though. I'm guessing we need to directly hook the drive up to a SATA port and then use something like WinHex to create the dump ?

@Artem

No, it's fine every reboot cycle; it's a bit slow to come ready but gets there with full ID etc.

[pbzcbf...@gmail.com]

Your capacity number is strange, but it might be just a red herring, and I now believe it to be OK. In any case, I don't understand it.

I found this thread about a 4TB My Book with a similar capacity discrepancy, although it turned out to be normal:

https://forum.hddguru.com/viewtopic.php?f=11&t=38894&mobile=desktop

That drive is reporting 7813971633 sectors via SATA, which is 1 more than yours.

It is reporting 7813969920 sectors via USB.

  7813969920 -- USB capacity
  7813971633 -- reported SATA capacity
  7814037168 -- full IDEMA capacity

Module 0x02 has 5 identical capacity values. The same values are present in that other HDD Guru resource dump.

Section 2     Length 48 / 0x30 bytes     Offset 0x157

Addr  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0000  00 01 10 3F D8 35 9F 00
                              AF BE C0 D1 01 00 00 00
0010  AF BE C0 D1 01 00 00 00 AF BE C0 D1 01 00 00 00
0020  AF BE C0 D1 01 00 00 00 AF BE C0 D1 01 00 00 00
      ======================= ^^^^^^^^^^^^^^^^^^^^^^^

    0x1D1C0BEAF = 7814037167  <-- IDEMA max LBA

This is the template for the encryption key:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000200  57 44 76 32 6F 22 00 00 00 B8 BF D1 01 00 00 00  WDv2o"...¸¿Ñ....

                                  ^^^^^^^^^^^^^^^^^^^^^^^

00000210  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000220  01 00 00 00 00 00 46 50 00 00 00 00 00 00 00 00  ......FP........
00000230  00 00 FF 00 00 00 00 00 00 00 00 00 00 00 00 00  ..ÿ.............
00000240  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000250  00 00 00 00 00 00 00 00 00 00 00 00 57 44 76 32  ............WDv2

The capacity seen via USB is 0x1D1BFB800 = 7813969920, which matches that other thread.

This means that sectors 7813969918 and 7813969919 are the last two sectors of the visible user area. They would probably contain GPT metadata. The key sector should be somewhere beyond this point.

[Extreme Solutions Parthipan]

If Possible read all tracks both copies even tracks errs

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/f8726221-b254-41f4-9cbf-d9b0b4120be4n%40googlegroups.com.

[compos mentis]

I have added all the hidden modules and gaps to mod 01.

Can you dump modules 188, ff35, ffef, 11b5, c0, ff01, ff02, ff03, ff04,
ff05, ff06, ff07?

Some will be very large.

[Carmet L]

Thanks Franc

Took a while to get ff07 as there were some read errors on it, but everything else was saved ok

Zipped them all into a file you can download from the link below.

https://drive.google.com/file/d/10fupl9A5BxRg4QobwMMfPfd6FcN5SBmM/view?usp=drive_link

[pbzcbf...@gmail.com]

I couldn't find a backup of module 0x02 in those hidden areas. I did find many other backups, though.

Dummy module 0xFF07 contains backups of the following visible modules:

        ID    size      attribs   RLBA1     RLBA2     Gap
--------------------------------------------------------------
14  02  019B  00000001  42881803  00000000  00000000
14  02  0123  00000001  42881803  00000001  00000001
14  02  0124  00000001  42881803  00000002  00000002
14  02  0125  00000001  42881803  00000003  00000003
14  02  0126  00000001  42881803  00000004  00000004
14  02  D002  00000001  42881803  00000005  00000005
14  02  D003  00000001  42881803  00000006  00000006
14  02  D004  00000001  42881803  00000007  00000007
14  02  D005  00000001  42881803  00000008  00000008
14  02  D000  00000001  42881803  00000009  00000009
14  02  D001  00000001  42881803  0000000A  0000000A
14  02  0127  00000001  42881803  0000000B  0000000B
14  02  D006  00000001  42881803  0000000C  0000000C
14  02  0035  0000000A  40801803  0000000D  0000000D
14  02  00EF  00000384  00841803  00000017  00000017
14  02  0102  00000001  00101803  0000039B  0000039B
14  02  0104  00000001  00101803  0000039C  0000039C
14  02  0106  00000004  00101803  0000039D  0000039D
14  02  01B8  00000004  00101803  000003A1  000003A1
14  02  0062  00000001  40801803  000003A5  000003A5
14  02  FEEF  00000112  40801803  000003A6  000003A6
14  02  2529  000002E4  00001C03  000004B8  000004B8
14  02  2500  00000080  00001C03  0000079C  0000079C
14  02  0103  00000006  00101803  0000081C  0000081C
14  02  0105  00000002  00101803  00000822  00000822
14  02  01A4  00000001  00901803  00000824  00000824
14  02  01B9  00000001  00101803  00000825  00000825
14  02  0146  00000101  40801803  00000826  00000826
14  02  00E7  00000020  00801803  00000927  00000927
14  02  012B  00000002  40801803  00000947  00000947
14  02  0108  00000044  40909803  00000949  00000949
14  02  0109  00000401  40901803  0000098D  0000098D
14  02  0033  000005E1  40881803  00000D8E  00000D8E
14  02  0031  000005E1  40881803  0000136F  0000136F
14  02  000C  0000000D  42881803  00001950  00001950
14  02  0034  0000006E  40C81803  0000195D  0000195D
14  02  0183  000004B0  40881803  000019CB  000019CB
14  02  0032  0000003C  42C81803  00001E7B  00001E7B
14  02  0036  00000126  40881803  00001EB7  00001EB7
14  02  0029  0000000F  40881803  00001FDD  00001FDD
14  02  0040  0000060C  40881803  00001FEC  00001FEC
14  02  0041  0000060C  40881803  000025F8  000025F8  <-- only the first portion is backed up

The other dummy modules contain the following respective backups:

0xFF01 - 0x80FE
0xFF02 - 0x190  <-- empty apart from header
0xFF03 - 0x115
0xFF04 - 0x1400, 0x801C, 0x801A, 0x8018, 0x8016, 0x8014, 0x8012, 0x8010, 0x800E, 0x800C, 0x800A, 0x8008, 0x8006, 0x8004, 0x2D00, 0x8001, 0x00FD
0xFF05 - 0xFC
0xFF06 - 0x2E, 0x120, 0x2530

[Carmet L]

Thanks for your effort, Franc, and like always, I learned a new thing from you.

But I think it's time to let this go now and accept defeat.

It's so frustrating because it's so close... but something is too wrong with it to fix.

[pbzcbf...@gmail.com]

It bugs me that PC3K is reporting a capacity that is 65536 sectors less than the full capacity. I'm wondering if this is a symptom of the problem or perhaps Ace may be hiding that area to prevent the operator from accidentally trashing the key sector.

I would suggest that you connect the drive directly via SATA to your motherboard, bypassing PC3000. Use DMDE (freeware disk editor) to copy the hidden SmartWare area and the GPT metadata to separate files.

https://dmde.com/

In DMDE you would ...

  select Tools -> Copy Sectors
  Starting sector = 0
  End Sector = 33

... and ...

  select Tools -> Copy Sectors
  Starting sector = 7813969886
  End Sector = 7814037167 (or max LBA)

[Desert Data Recovery]

I think the OP has to load too much into RAM to make that happen.

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/b7811463-0af6-48e7-9f10-34c025fc84a6n%40googlegroups.com.

[compos mentis]

I don't understand what you mean.

I'm suggesting that the OP remove PC3K from the equation and use the OS and DMDE as a normal end-user would. I've been through this simple task with several users, all of whom have managed to dump the key sector and GPT metadata. 

The purpose of my approach is to eliminate USB encryption as a potential culprit, and to confirm whether the GPT metadata at the end of the visible user area matches the same metadata at the beginning.

I can't understand why that should be so difficult. :-?

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/CAOasWzsW9s78%2BtEjbzo-wm_8C-3ucRjJ%2BBkaqyBB9S-Y4eurDw%40mail.gmail.com.

[Carmet L]

I have it connected to the system, but Device Manager shows odd characters in its details, and it dropped out of the DMDE menu when I selected it.

Trying to refresh device manager is just hanging the system

[compos mentis]

I would have thought Device Manager gets its info from the ATA Identify
Device command. That's what Ace calls the "passport". Most (all?) of the
parameters are supplied by module 0x02.

One other thing you could try is to dump the SMART and Identify Device
data with CrystalDiskInfo. Select Edit -> Copy Options and tick all the
boxes. Then select File -> Save (Text). This will save the raw SMART and
Identify Device data in a text file.

https://crystalmark.info/en/software/crystaldiskinfo/

[pbzcbf...@gmail.com]

This is the "passport" for my Crucial SSD. You can see the actual capacity reported by the drive.

-- IDENTIFY_DEVICE ---------------------------------------------------------
        0    1    2    3    4    5    6    7    8    9
000: 0040 3FFF C837 0010 0000 0000 003F 0000 0000 0000  .@?..7.......?......
010: 3231 3130 4536 3138 4231 4346 2020 2020 2020 2020  2110E618B1CF        
020: 0000 0000 0000 4D33 4352 3034 3320 4354 3130 3030  ......M3CR043 CT1000
030: 4D58 3530 3053 5344 3120 2020 2020 2020 2020 2020  MX500SSD1          
040: 2020 2020 2020 2020 2020 2020 2020 8001 4001 2F00                ..@./.
050: 4001 0000 0000 0006 3FFF 0010 003F FC10 00FB BD01  @.......?....?......
060: FFFF 0FFF 0000 0007 0003 0078 0078 0078 0078 0D98  ...........x.x.x.x..
070: 0000 0000 0000 0000 0000 001F 850E 0084 014C 0040  .................L.@
080: 07F0 006D 706B 7409 4163 7069 B409 4163 207F 0001  ...mpkt.Acpi..Ac ...
090: 0001 00FE FFFE 0000 0000 0000 0000 0000 0000 0000  ....................
100: 6DB0 7470 0000 0000 0000 0008 6003 0000 500A 0751  m.tp........`...P..Q
     ^^^^^^^^^
     capacity = 0x74706DB0 (1953525168) sectors

110: E618 B1CF 0000 0000 0000 0000 0000 0000 0000 411C  ..................A.
120: 401C 0000 0000 0000 0000 0000 0000 0000 0029 4372  @................)Cr
130: 7563 6961 6C20 0000 0000 0000 0000 0000 0000 0000  ucial ..............
140: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
150: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
160: 0000 0000 0000 0000 0000 0000 0000 0000 0003 0001  ....................
170: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
180: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
190: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
200: 0000 0000 0000 0000 0000 0000 0031 0000 0000 4000  .............1....@.
210: 0000 0000 0000 0000 0000 0000 0000 0001 0000 0000  ....................
220: 0000 0000 11FF 0000 0000 0000 0000 0000 0000 0000  ....................
230: 6DB0 7470 0000 0000 0001 0200 0000 0000 0000 0000  m.tp................
240: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000  ....................
250: 0000 0000 0000 0000 0000 48A5                      ..........H.

[pbzcbf...@gmail.com]

I have extracted copies of these two modules from the "gaps" in the SA region. They match the visible modules.

On Wednesday, August 5, 2026 at 8:11:07 PM UTC+10 gpsp...@gmail.com wrote:

In this SABackup 25 corrupted 38 OK as per 38 Says WDV2 but D006 and 127 says there is no SED.

So someone must changed D006 and 127. Try with donor D006 and 127  from encryption enabled drives.

Also check your PCB serial ,XAYW9909RG100045205

[Carmet L]

The drive will not stay connected to the system via a SATA cable, though, so I can't do anything with it unless it's via PC3K Franc :(

[compos mentis]

Can you use your sector viewer to show us the contents of sectors 7813969918, 7813969919, 1 and 2?

[Carmet L]

It just hangs the computer every time, Franc; can't get any tools near it.

[compos mentis]

I mean the sector viewer in PC3K.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/12563e50-5f56-437a-acfb-985791b70dfcn%40googlegroups.com.

[Desert Data Recovery]

Have you tried linux. Much better at handling bad drives than Windows. 

[compos mentis]

I have one more idea, but it's a bit wild. I'm thinking that the stuff
in 0xFF07.bin could be junk that was left in memory during a firmware
build. If so, then perhaps the copy of FF07 on head #1 will contain
different junk, possibly a copy of module 0x02.

[Carmet L]

@ Tim, not with this drive but it could be an idea to try.

@ Franc, I'm working on pulling both copies of ff07; will share once they're saved out.

[Extreme Solutions Parthipan]

In this case module 02 no issue. u can use from donor

Doubt is 1A2 and 1B6 original or not.

if 129 or 130 found then it can be confirmed.

Previous DR must changed some modules including 2D (the available one is from another firmware Version - So not OG)

2D contains two serial numbers WD-WX62D84CJH80 and WD-WX92D457WT82.

Without the confirmation of 1A2 and 1B6 any work is waste

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/e32aa00e-4661-4569-9679-d388ca2c1549n%40googlegroups.com.

[compos mentis]

Serial Number	Warranty Status	Model Number	Description	Warranty Expiration Date*
WX62D84CJH80	OUT OF REGION	WDBPKJ0040BBL-WESN	MY PASSPORT 4TB BLUE WORLDWIDE	-
WX92D457WT82	OUT OF REGION	WDBU6Y0040BBK-WESN	WD ELEMENTS PORTABLE 4TB BLACK WORLDWIDE

[Carmet L]

Still pulling copy1 Franc, taking quite some time but it will get it.

As for the different models, correct my wrong, but if this elemnts was loaded up with a working 02 from a passport... thats why the data is showing as encrypted ? So, we need a working 02 from a elements to rule that out right ?

[pbzcbf...@gmail.com]

I was just following up the two serial numbers alluded to in the previous post by  @gpsparth. I don't know what to make of them.

[pbzcbf...@gmail.com]

Let me first say that I'm just an observer, and I don't understand the function or significance of module 0x2D. However, I examined this module in a HDD Guru resource dump and found it to be empty apart from the ROYL header.

In your case there is plenty of data. For example, I found this section which appears to be security related:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000B59A0                                      F0 1F 1E 1D
000B59B0  1C 1B 1A 19 18 17 16 15 14 13 12 11 10 0F 0E 0D
000B59C0  0C 0B 0A 09 08 07 06 05 04 03 02 01
000B59C0                                      38 E4 C1 11
000B59D0  4D 87 D7 2A 35 59 40 0D DA 63 00 E5 C1 21 D3 77
000B59E0  0C 28 55 4F D4 0B DD E0 BB 4E D7 70 B7 62 AA 28
000B59F0  D3 6D B0 89 24 8A 07 E3 07 04 DC 70 45 7B 12 3A
000B5A00  44 99 7D 0D A5 03 60 DB 91 43 04 A3 9C 09 C2 16
000B5A10  52 87 23 90 F3 B7 5D 0A 3F A2 BE FD 40 04 AF 39
000B5A20  04 32 38 31 64 4D 98 65 52 1D 31 2D C6 D0 18 9E
000B5A30  DD 7D E1 8D 3B 70 0E D9 2C 42 25 26 57 C5 64 31  <-- 0x100-byte key or signature ??
000B5A40  7D A8 14 76 F1 CF 2C 9D 6A 8F EB 2F 24 A7 CD 43
000B5A50  5E 76 49 3B B8 E4 D3 6C 94 E9 47 87 3A 66 6B AF
000B5A60  DD CE 9B E0 3A 60 F6 B8 6F 95 06 1B AA 68 F7 4A
000B5A70  3D 5E C5 A7 31 F7 53 59 52 9D FA F8 9E 48 DF A6
000B5A80  42 B0 01 50 01 AA BE 04 8F 49 54 74 ED 89 E6 40
000B5A90  E6 83 6F 02 20 29 C8 9F A2 AF 54 80 64 3A 6E 1F
000B5AA0  16 7D 99 6F 10 7A 6E 69 C6 46 82 8D D7 8F 64 59
000B5AB0  53 B6 D6 90 8D 3B 6E E0 1A 35 6C 9A F6 6E 42 47
000B5AC0  E0 E4 37 A9 23 83 8E BB C5 7C 4E 3A
000B5AC0                                      00 00 00 00
000B5AD0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000B5AE0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[Carmet L]

Trying to figure out the serial thing, and I have found the same one in the HDD Surgery firmware database.

So have purchased it and uploaded it for what it's worth here https://drive.google.com/file/d/1APgNnxxAvmSOlCSqZ0XBwGtWG41sHFK-/view?usp=drive_link

Maybe this is the source of the 02 and 2D that's loaded into the SA now

@gpsparth says the issue is whether 1A2 and 1B6 are original or not.

But if we can pull 129 or 130, then that could be confirmed.

Anything else is useless.

Copy1 FF07 still saving out, about 60% so far.

[pbzcbf...@gmail.com]

Interesting. If I understand correctly, the other shop used a 0x2D donor from a Passport (S/N WX62D84CJH80) on your Elements. Passport is encrypted whereas Elements is not encrypted.

The HDD Guru SPG3 resource dump that I examined was for an Elements, S/N WX52DA18DRDJ. Its 0x2D module was empty. Is that all you need to do? I mean, is it sufficient to zero the whole module apart from its ROYL header?

I understand why you guys hate to handle jobs that have been elsewhere.

[Carmet L]

According to @gpsparth, 2D isn't native to the drive.

Copy1 took a long time (download links for both below)

https://drive.google.com/file/d/1ssQLM5RbR37f5ACzzOnbs6apTfilQaUI/view?usp=sharing

https://drive.google.com/file/d/1CANTYF1TdimEa-8iGCcr7nJ45ODDKHRF/view?usp=sharing

Not sure where we can go from here... 

[pbzcbf...@gmail.com]

There are plenty of differences, and lots of identical data, but no backups of ROYL modules.

Maybe you could try reading copy #1 of 0x129 and 0x130?

0x2D doesn't look native. Should a native module be empty? If so, then one can be easily regenerated.

[pbzcbf...@gmail.com]

0x2E seems to contain data that is similar to 0x2D, if it isn't empty.

[compos mentis]

In your patient, 0x2E is empty and 0x2D contains data. The serial number
in module 0x02 is WX92D457WT82. There are two serial numbers in module
0x2D in your patient's resource dump, WX92D457WT82 and WX62D84CJH80.
One is an Elements, the other is a Passport.

The data in 0x2D and 0x2E are similar.

I don't know what to make of the following. Maybe it's a red herring?

Serial number   Model      0x2D   0x2E source

------------    --------   -----  -----  ----------

WX52DA18DRDJ    Elements   empty  empty  HDD Guru

WX62D84CJH80    Passport   empty  data HDDSurgery

WX92D457WT82    Elements   data   empty  patient

[Extreme Solutions Parthipan]

sir every encrypted WD SMR drive 1A2 and 1B6 and 123 124 D002 D003 in some D004 contains unique data for decryption.

if 129 or 130 read properly (In MRT it read by ID mode and manually enter module number) it surely contain 1A2 but 1B6 in some case available in 129 130, in some cases it blank with only header). then no other source to

get correct 1B6.

but in ALL SMR drives either 2D or 2E contains the bytes of 1A2 and 1B6 in different Address. So in order to get correct 1B6 and 1A2 we need original 2D or 2E. in this case 2E is empty that is normal. then surely we need original 2D from previous

DR persian. ( I think he might know this so only changed)

without confirming 1A2 and 1B6 every steps will be waste

This is my opinion and experience if it wrong leave this

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/eb15807e-23ff-4571-83bb-60f9ea6852d2%40gmail.com.

[Carmet L]

2D from copy1 in XYZ profile (other DR shops SA backup) only has the original serial number inside  WX92D457WT82

[Carmet L]

Both copies in drives SA only contain the drive's serial number though; no others    WX92D457WT82

[Extreme Solutions Parthipan]

This 2D is not belong to this drive

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/d6a5dd39-4a77-4653-9661-946716e6a02en%40googlegroups.com.

[Carmet L]

So this is a real sabotage case, then, and it can't be fixed, as they have edited/replaced 2D with junk.

[Artem Rubtsov]

The problem you're having is relatively common, it could be worsened by other issues but the general problem is the CPU. Some hardware issues prevent the CPU from initializing crypto-engine properly and your drive just does not decrypt the data at all, or does it incorrectly.

It would have been an easy check if PC3000 would show ALL ATA registers on the drive power up but from what I understand it does not. We can check it by connecting any good SATA drive and powering it up in PC3000 without sending any commands.

Check if the marked AMN indicator lights up, if it does, then we can check your problematic drive the same way, if it does not then PC3000 unfortunately ignores some registers on a a power up.

Another way I believe is sending a diagnostic command to the drive.

Here is a screenshot from the ATA Standard

[Artem Rubtsov]

Also,

when this CPU problem happens the drive usually kills 02. 2D, 12D, and 32D modules.

2D, 12D, 32D are debug modules and have no critical information in them, the fact that the serial number is different in 2D could indicate that somebody tried to fix the drive by writing a 2D from another drive (you can do that, it's not an issue) or it could indicate that 02 has this incorrect serial number (also not a big problem).

[Carmet L]

Artem, you're right; the AMN light does not come on for this drive's power cycle or even a standard FBLite, and neither shows AMN activity.

[Artem Rubtsov]

Unfortunately the diagnostic command relies on correct interpretation of the Error register (which PC3000 ignores when ERR bit is not set), confirming the problem would be hard.

[compos mentis]

Perhaps the OP could use an ATA terminal, eg HDDSuperTool, or any number
of others. I wonder if MHDD can do it?

[Artem Rubtsov]

If we assume that the problem is the CPU then one option would be moving the CPU to another board, in hopes that the issue was cracked PCB. 

Sometimes the issue is the CPU itself then this is currently an unsolvable problem. 

[pbzcbf...@gmail.com]

Do you have any idea about @einstein9's claim?

https://forum.hddguru.com/viewtopic.php?p=317229#p317229

[Extreme Solutions Parthipan]

u can request original locked rom from previous DR

On Tue, Aug 11, 2026 at 8:50 AM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

Try hdparm. The first line sends an ATA 0x90 command to the drive. The second line is a NOP which returns the state of the task file registers.

# Syntax for ATA Pass-Through via hdparm:
# hdparm --Iio <command>:<features>:<lba_low>:<lba_mid>:<lba_high>:<device_head>:<sector_count> /dev/sdX

sudo hdparm --Iio 0x90:00:00:00:00:a0:00 /dev/sda
sudo hdparm --Iio 0x00:00:00:00:00:a0:00 /dev/sda

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/datarecoverycertification/f51b666d-8746-4dc2-a579-0ba66c598792n%40googlegroups.com.

[Carmet L]

The only unlocked ROM that's available is the one attached here.

I will set up a Linux box tomorrow and get this thing hooked up to it.

[pbzcbf...@gmail.com]

I was hoping my post would remain unseen. I got these "undocumented" hdparm commands from Gemini. Subsequent attempts to find a source have been unsuccessful.

[Artem Rubtsov]

>>Do you have any idea about @einstein9's claim? 

I'm waiting to see an actual proof that it works.

THEORETICALLY it's possible it's just requires a lot of R&D time. 

[Artem Rubtsov]

Also if we could read the keys from the MCU then we can software decrypt the data.

[pbzcbf...@gmail.com]

ISTM that @einstein9 has a large war chest for hiring R&D specialists. I doubt very much that he is able to do any of this work himself.

On Wednesday, August 12, 2026 at 1:47:22 AM UTC+10 arub...@thedigilab.com wrote:

>>Do you have any idea about @einstein9's claim? 

[Artem Rubtsov]

He isn't.

He also does not fully understand what he posts on the forum.

But it does not change the fact that with enough R&D it's possible.

If I had the time I would look on a possibility of a stack injection on the 0xDDDD security overlay loading  to the secure core. If the injection is possible we could modify 0xDDDD so it would read the keys inside the secure core and pass it to the host core.

Sounds simple enough but it only sounds simple :)

[compos mentis]

40 years ago I repaired minicomputer PCBs. In those days a CPU was an
entire 15" x 15" PCB consisting of discrete logic ICs. Memory mappers
and floating point units were separate PCBs.

One particular 16-bit CPU consisted of 4 x 4-bit AM2901 ALUs, 1 x AM2910
microsequencer, about 20 x 2Kx8 control store PROMs, 4 x 4-bit SRAMs, 
plus TLL and ECL support chips. We could access and single-step the
microcode through a control panel. I'm talking about the code underneath
the higher level opcodes. I can't imagine how one would troubleshoot a
modern MCU at that level, but it must be possible, otherwise how could
one debug new designs?