A couple of weeks back we received in the first "SpyGlass2" disk, with model number WD50NDZW-11MR8S1. Whilst this uses the same PCB as SpyGlass it appears that there are some important modifications to the SED functionality and access to the SA. Those people I've spoken already to in the DR industry have not seen any/many of these in yet.

As is expected, there is not proper mod 02 support in PC3K, and as a consequence 'slow responding' faults can not be resolved in the normal way (as per 'Charger' and 'Palmer' etc).

On the positive side, the SA can now be accessed without the need of blocking ROM and using matching saved resources. Using a SATA PCB with appropriate ROM will allow access to the SA immediately.

There is potentially a big negative. This was noticed on the two donor HDDs which were used. The donors were used only to read a copy of their SA, to potentially help resolve relo list mod 32 issues in the patient HDD. It is likely that the donor HDDs were powered on at some point with a foreign ROM, and then when the disk reached RDY the native ROM was written to the PCB.

However, what I noticed afterwards when the native USB PCB was swapped back on to the donor HDD (with the original ROM), was that the original data was encrypted. Obviously a check was made to see if SED had been turned off in Drive ID. It has not been. It appears that either in the action of reading the SA, or using a foreign ROM to power on the HDD, has triggered the drive now only provided encrypted data.

One person in the DR industry in the USA confirmed that he had noticed a similar outcome when working on the HDD.

I've not had a chance for further research and testing on these disks, but I would be interested to hear of other people's experience with them as they start coming in for recovery. Ace TS were not aware of this issue, but did acknowledge the possibility of it.

Regards
John

_________________
CDR - Manchester Data Recovery Services
0161 408 4857
http://www.cheadledatarecovery.co.uk/

You would need original PCB (not to confuse with original ROM) to decrypt data on these

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

The original PCB does not work eventually. I had a similar case a few months ago. My case was unrecoverable because it contained forensic images. The drive had too many unreadable sectors to produce solid recovery. The zones are very large, i think 75gb before switching surfaces and the clients data was around 50GB so it all resided on surface 0. When reassembled, the drive with the original PCB and original rom would spin up, but no further access. SA or otherwise. These drives appear to have some extra security mechanisms in place. I did not investigate further since he wanted it back for warranty.

FYI: pc3k cannot build correct head map for WD smr drives bellow V6.7, which is about to be released. So the assumption of 75GB from one surface is almost surely false.

pepe

_________________
Adatmentés - Data recovery

@Doomer - I'll check to see if the two PCBs of the two donors were swapped back on to the correct drive. I know that the ROM content is correct for each. But I understand what I think you are suggesting - that there is a form of encryption key controlled by the native PCB itself rather than at a ROM or SA level. Interesting if this is the case.

Regarding Head maps in this new "SpyGlass2" disk - there was full support for this in PC3K when I used the SATA PCB. Whether the zones were correct is a different matter. All of the disks I had in had decent read capability across all 10 heads so hard to tell.

John

_________________
CDR - Manchester Data Recovery Services
0161 408 4857
http://www.cheadledatarecovery.co.uk/

Hello John,

yes, pc3k was able to build head map but it was incorrect. You probably haven't noticed it because heads were ok. But the drive Wksk talked about was probably having some bad heads and the unreadable areas were located on these surfaces.
The nice thing about wd smr drives is that 10 neighbouring LBAs can be located on 10 different surfaces (if we are talking about SpyGlass that has 10 heads of course).
pepe

_________________
Adatmentés - Data recovery

Hello, this is a very interesting post.
I have noticed that these drives can accept changes in 0b/20b as described by Spildit on one of the posts while explaining the procedure to bypass 411 or 02.

I have tried to by pass certain mods and I have observed that SED is ir-respective of 02 and 411.
Also, bypassing 11 causes the same symptopms that the drive goes into when TV9 and TV10 are shorted.

Essentially, I believe that TV9 and 10 technique used to not allow 11 to be loaded into SA (please correct me here)
Also bypassing 11 in such drive results in the same behaviour.
Similar stuff was observed with 411.. Like the Drive would fail to ID. but there would be clear indication that 11 has been loaded into the ram. ( This is observation equivalent of actually bypassing 411 in some other drive, we can make changes in SA without actually loaders,no PERM_OVERLAY errors etc)


now thats that. I was wondering if some one could share the RAM dump from a unlocked PCB and we could eliminate a few mods....I know it would be alteast a years time killing trying to bypass every possible doubt-ful mod.

However the next question in my head is, if we consider the entire "Chain Of Trust" issues with ARM chips.
We are very well making changes in the area which can be considered as the external non secure zone (ROM is accessable, can be userchanged so i believe it falls under the non secure world abstraction.) Yet things are being executed. Just that it looks like SED is kept in some other module possibly ?

experts, please help guide.

Thanks
--

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

Respected Simran ,
Your answer is totally different to Mr johns question ,Its very interesting to read Mr johns submissions and then wksk updates .Both my seniors Doomer and Pepe Both of you might not have access to MRT etc tools ,But i would like to tell you that MRT ver 2141 cannot make a headmap of charger drives ,Its starts and then ends up at 50 odd percent with a error .I had a head swap case few days back were i was able to clone entire drive without too many issues , I really do not understand why tool manufacturers release a update without any proper testing ,How many family of wdc are really out there if we talk of usb drives palmer , charger , pebbleb and spyglass even they are not properly supported ,I mean why release and start yapping about a release when support is not proper ,I will appreciate a tool what says this can be done and this cannot be done and this process in in beta .

PS : Interesting post Mr john

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

pebbleb does not fall into this category.
I think they did not realise at the time of release that the good old method of head map building will not work for these. Coz it actually works, just the result is not what we would expect. They just added the new family just like any other.

pepe

_________________
Adatmentés - Data recovery

Sir ,
Why not pebbleb ?

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

coz it does not have 2nd level translator
pepe

_________________
Adatmentés - Data recovery

Alright ,
I did not have that info ,So is that working like older series drive ? ,In SA ,Mod 02 Structure Etc Etc

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

See, people who know what I am indicating, know it very well... Please start the ARM-TRM and actual lower level work in to really know what I am speaking of. I am sorry, but i have to mention , you have a very long learning curve in terms of figuring ARM and x86 systems at a very lower level.

Thanks.
--

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

Well,
In That Case i would like to tell you that since 3rd class till i can remember electronics has been my hobby ,I have been playing around with mircocontrollers since donkey ages ,More Then 75% Traffic Lights In Punjab state run on our silabs x86 microcontrollers ,Your statement was not off track ,You sometimes have no clue what you are talking about ,You need to learn to read a post a few times before you start taking .




Well what are you trying to state here ,If you short the tv9 and tv10 you are actually blocking the read channel of the hdd directly ,Resulting in non loading of SA mods ,Go trace the damn this in the PCB .So Mod 11 " The Code Overlay " Mod never loads and if you block Mod 11 by the way spildit says it does the same thing ,No overlay code module loads to ram off hdd cos its blocked .When Mod 411 is blocked essential mods do load in HDD ram .




Well this makes no head or tail what you are trying to state ,by sharing a ram dump you will get zero nothing cos you need to disassemble the code starting fom pcb level till final boot of the drive to understand how the damn thing is actually working ,Mods can and might bot be dependant on each other ,It depends ,I actually Do not get time to do reverse engineering on any hdds due to no of cases we get

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

some one keep him away man.
--

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

to add, the person who dissed about DeepSpar so much has 2 units...
wonder how he purchased them? Ripped off money?

_________________
THERE IS ALWAYS HOPE TILL YOU LOSE IT.

I had a bizarre experience with one SpyGlass2 (e.g. WD50NDZW-11MR8S1) drive a couple of weeks ago. Dropped EasyStore external drive with heads problem.
It is the only damaged Spyglass2 drive I have worked on so far.

Did head swap and SATA adaptation to unlocked SATA PCB.
PC3K utility had access to SA, saved resources fine.
In DE in PC3K, for some reason, it would not clone. It would strangely power cycle itself with every block read attempt
It felt like the VSC command for reading from within PC3K isn't correct. I don't know why or how this applies, just my interpretation. I am curious if other people have experienced this in DE! Please share if you have or have not.

Then I soldered ROM back to its native USB PCB. Prepared drive for cloning with HDDSuperClone in Lubuntu - this is on a fully running machine, not running from a bootable flash drive. In the meantime, I installed R-Studio, so I can open the volume and check the data as the cloning process progressed.
R-Studio could see the patient's NTFS volume, but it could not parse it. It would run into reading errors. So, left it alone.

Started HDDSuperClone in forward direction with skips enabled and so on. It was running into a lot of errors in the beginning, so it was skipping a lot. Then at about 30% mark, it began being more stable and it begin cloning blocks successfully more consistently. Some more skips passed the 30% mark, but larger chunks of blocks cloned successfully.

So, the clone finished, with the front 30% pretty much unread.
Out of curiosity, I launched R-Studio, to see if the volume on the clone drive is recognized. It recognized the NTFS volume, just like the patient, but still cannot open the volume. It gives error. A quick scan in R-Studio, only results in RAW files being produced.
Stopped messing with the scanning process.

Resumed cloning in HDDSuperClone in reverse with smaller block skip settings. Interestingly, it started cloning successfully more blocks in reverse from 30% mark going toward the beginning. After a couple more passes, it cloned 100%, at least based on the legend map on HDCViewer log and HDDSuoerClone stats.

Again, once completed, ran scans with multiple tools (R-Studio, R-Explorer, Reclaime) they all produced only a RAW recovery, with about 150GB worth of files, all good files. Was scratching my head...

Not sure what made me do this next, but after all this scanning on the clone drive, I mounted the patient drive back in Lubuntu, opened R-Studio to scroll through the data in hex view, and to my surprise, the patient drive showed all 00s through out the drive without encountering any bad blocks while scrolling. Not sure what this was about or how that happened. So, I was really scratching my head...

Anyways, my brain was too fried to look more into it at that time and have not touched it since. Will probably look at it later again for more investigating.

Will probably get a new drive, dump data on it and attempt.tonreceeate the scenario. Or will do that with donor drive once putting back.together mechanically.

Delivered the customer a RAW recovery, most files retained their file names, just not folder>subfolders names. He was happy given the circumstances.

_________________
Hard Disk Drive (HDD), Solid State Drive (SSD, SATA, NVMe, etc), USB Flash Drive and RAID Data Recovery Specialist in Massachusetts

don't be surprised if smr drives return 00s for all sectors. It means the 2nd level translator is not loaded for some reason. Moreover, it is pretty easy to screw these drive up after 'just' swapping heads ...
pepe

_________________
Adatmentés - Data recovery

Pepe And Labtech ,
So in Your Case Labtech I think We See Another Sub Revision of These SMR With even more complicated fw structure .Labtech i am sure this has something do do with Mod 189 and 190 ,I am also sure peeps at ace would be working on these ,The other folks i am not sure

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

Just recovered SMR translator for a Spyglass2 drive that was returning all zeros.
It was insanely hard thing to do but I can read data now.

Backup SA properly people! These drives are nightmare to work with.

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