Western Digital - Media Cache

[Amarbir[CDR-Labs]]

what that button did to 148

this button erases the contents of the file

I will look it up and let you know what it did myself ,Thanks for the feedback

[Yustik]

Why RAW? What is the problem with the file system?

[northwind]

Why RAW? What is the problem with the file system?

My question exactly while I was going through this thread...

[pepe]

If it works as i think the Lba space gets shifted by large number of sectors when u clear 148. That might be the reason for the file system being unaligned while raw recovery still gives some result.
pepe

[fzabkar]

If it works as i think the Lba space gets shifted by large number of sectors when u clear 148. That might be the reason for the file system being unaligned while raw recovery still gives some result.
pepe

I was thinking the same thing, although I would expect that the tail end of the user area would now be inaccessible.

One could test this hypothesis by writing a predefined signature to each LBA of a working drive (eg signature = "LBA x"). Clearing module 148h would then merge the cached regions into the visible user area. We would now scan the LBAs until we find a discontinuity, eg <LBA 10000> <cached data> <LBA10001>.

[DR-Kiev]

I was thinking the same thing, although I would expect that the tail end of the user area would now be inaccessible.

One could test this hypothesis by writing a predefined signature to each LBA of a working drive (eg signature = "LBA x"). Clearing module 148h would then merge the cached regions into the visible user area. We would now scan the LBAs until we find a discontinuity, eg <LBA 10000> <cached data> <LBA10001>.

And just a hint how to make it easy with UFSExplorer_Pro

Attachments

[Doomer]

Doomer ,
I Am Neither Fighting With anyone Nor Saying anything to anyone ,I had a Case Everything Was Fine ,No Sector Access ,Acelab Called This Feature " Media Cache Removal " ,

Yes, that what I was trying to get from you.
The thing is "Media Cache" name on WD was not invented by Acelab, they got it from somebody else. That somebody(actually it was a group of 2-3 somebodies) made a mistake naming the feature because he didn't think of a better name that time.
That name is incorrect and there is no Media Cache on WD drives.
Also IDK why would anybody would want to remove it(or add it for that matter), because it would lead to data shift on a drive.

But I can assure you that "no sector access" was not related to the " Media Cache Removal ", probably cleaned some other stuff along the way but it definitely wasn't the root cause.
I think Acelab would need to remove that feature from the tools but it's up to them.

[Amarbir[CDR-Labs]]

Guys ,
I have hooked up that drive to the tool @ my office .Once i am a little fresh as its now night here i will post whatever i have done or learned in The Discussion .Including the fact of reversing the So called " Media Cache " effect and checking the drive .Might be i could learn something new .

[Amarbir[CDR-Labs]]

Hello everyone ,
Please find the Mod 148 before and after i applied the function ,As i have user data access now if i restore this module i should loose acesss to user data ,This i will try tomm ,The Mod 148 is attached for you Frank to figure the jumbo bumbo

PS : Frank i tried not to write in title case

Attachments

Mod 148 Copies.zip

(786 Bytes) Downloaded 860 times

[Amarbir[CDR-Labs]]

Doomer ,
I Am Neither Fighting With anyone Nor Saying anything to anyone ,I had a Case Everything Was Fine ,No Sector Access ,Acelab Called This Feature " Media Cache Removal " ,

Yes, that what I was trying to get from you.
The thing is "Media Cache" name on WD was not invented by Acelab, they got it from somebody else. That somebody(actually it was a group of 2-3 somebodies) made a mistake naming the feature because he didn't think of a better name that time.
That name is incorrect and there is no Media Cache on WD drives.
Also IDK why would anybody would want to remove it(or add it for that matter), because it would lead to data shift on a drive.

But I can assure you that "no sector access" was not related to the " Media Cache Removal ", probably cleaned some other stuff along the way but it definitely wasn't the root cause.
I think Acelab would need to remove that feature from the tools but it's up to them.

Hello,
By Changing Mod 148 Back To Older Non Modded Version i Loose Sector Access And By Using The Mod 148 that acelab modded i can access sectors ,And acelab does not complete clean the module like someone on top pointed out ,So might be your statement is not correct you want me to make a video on this and post do you

PS : Acelab rectified / modded modules has 240 byte differences to older non modded mod 148

[Doomer]

By Changing Mod 148 Back To Older Non Modded Version i Loose Sector Access And By Using The Mod 148 that acelab modded i can access sectors ,And acelab does not complete clean the module like someone on top pointed out ,So might be your statement is not correct you want me to make a video on this and post do you

Some people are amusing
I have an example for you (not 100% related to module 148)
Let's say you have a bug in background scan module that points to an area that is beyond drive's translation
And then you have a table that has a task that asks background scan to perform some operations
When it happens drive hangs or not-initialized

Now you clean the table with the task - drive works
You put it back - drive stops working

What was the cause of the problem: the table with the task or background scan module with the bug?

[pepe]

Yes, of course the buggy one, but as long as DR is concerned either solution is acceptable provided it does not affect data access in a negative way. Sometimes there are multiple ways of achieving the same goal, one is more elegant than others but who cares as long as the DATA IS OK?
Well, this case is somewhat different, since, as i understood, the data is shifted after the repair, so it is NOT ok at all.
pepe

[fzabkar]

Offset 0x30 appears to be some kind of count or size value. If module 0x148 is a log or "to do list", then it could be that this dword reflects the size of the list, in which case the default (?) value of 0x81 would imply that there is nothing to do (ie no active background tasks ?).

Code:

Offset(h) 00       04       08       0C       10       14

00000030  AB010000 00000000  - before

00000030  81000000 00000000  - after

00000030  81000000 00000000  - WD30EZRX - Diablo 3D

The next section appears to be a table of LBA regions, as described previously. Since the number of regions is the same for the 1TB and 3TB models, they cannot be related to the number of heads.

Strangely, there are differences in the before-and-after tables, which would imply (to me at least) that Ace is replacing the module with a template rather than modifying the module itself. If so, then I'm wondering whether this produces undesirable results? The "template" is very similar to the 3TB example.

148-Before Function Applied.rpm

Code:

Offset(h) 00       04       08       0C       10       14

00000030                    00806700 00000000 01000000 00000000
00000048  00000000 00000000 01806700 00000000 90149306 00000000 *
00000060  191D0000 07000000 9194FA06 00000000 34C31105 00000000 *
00000078  A1050100 07000000 C5570C0C 00000000 88AF4917 00000000
00000090  29EE0100 07000000 4D075623 00000000 88AF4917 00000000
000000A8  17850300 01000000 D5B69F3A 00000000 88AF4917 00000000
000000C0  9F6D0400 01000000 5D66E951 00000000 5387EE22 00000000
000000D8  27560500 01000000 ----------------- ^^^^^^^^^^^^^^^^^
          *****************
          +0xE888           current 08 = previous 08 + previous 10

148-After Function Applied.rpm

Code:

Offset(h) 00       04       08       0C       10       14

00000030                    00806700 00000000 01000000 00000000
00000048  00000000 00000000 01806700 00000000 E26BD205 00000000 *
00000060  08000000 00000000 E3EB3906 00000000 E26BD205 00000000 *
00000078  90E80000 00000000 C5570C0C 00000000 88AF4917 00000000
00000090  18D10100 00000000 4D075623 00000000 88AF4917 00000000
000000A8  A0B90200 00000000 D5B69F3A 00000000 88AF4917 00000000
000000C0  28A20300 00000000 5D66E951 00000000 5387EE22 00000000
000000D8  B08A0400 00000000 ----------------- ^^^^^^^^^^^^^^^^^
          *****************
          +0xE888           current 08 = previous 08 + previous 10

Adding the region sizes in column 10 gives ...

0x06931490 + 0x0511c334 + (3 x 0x1749af88) + 0x22ee8753 = 0x74706DAF

0x74706DAF x 512 bytes = 1.000 TB

Edit:

Column 04 is non-zero in the "before" module. I don't know what this means.

[fzabkar]

ISTM that, if the LBA regions were associated with corresponding cache regions, then they would be organised on a per-head basis. As this does not appear to be the case, then they are most likely not cache related.

The following section of mod 0x148 would suggest that the "before" state of the module is more closely aligned with the 3TB example ???

Code:

Offset(h) 00       04       08       0C

WD30EZRX_original_0148.bin

000000F0                    00000000 00000000
00000100  00000000 00000000 00000000 00000000
00000110  00000000 00000000 00000000 00000000
00000120  00000000 00000000 00000000 D77ACD5D
00000130  01000000 38640500 10270000 581B0000
00000140  20A10700 00000000

148-Before Function Applied.rpm

000000F0                    9C410000 3F806700
00000100  82597074 00000000 00000000 00000000
00000110  00000000 00000000 00000000 00000000
00000120  00000000 00000000 00000000 D735ED74
00000130  00000000 38730500 10270000 581B0000
00000140  20A10700 FC5D7E00

148-After Function Applied.rpm

000000F0                    00000000 00000000
00000100  00000000 00000000 00000000 00000000
00000110  00000000 00000000 00000000 00000000
00000120  00000000 00000000 00000000 D735ED74
00000130  00000000 38730500 00000000 00000000
00000140  00000000 00000000

The following section is zeroed in the templates:

148-Before Function Applied.rpm

Code:

Offset(h) 00       04       08       0C

00000150  F0C05823 00000000 780C0000 7123E800
00000160  F03BA33A 00000000 A8080000 00000000
00000170  C4D7A40B 00000000 6023E800 00000000
00000180  E0A35823 00000000 78030000 00000000
00000190  902BFC06 00000000 A0070000 00000000
000001A0  00806700 00000000 B06D7074 00000000
000001B0  07000000 00000000 00000000 00000000
          ^^^^^^^^          ^^^^^^^^
          offsets?          sizes?

[Doomer]

Mod 148 is not a to do list, it's alignment list.
Basically it's part of translation level

If one would want data recovered then Mod 148 should not be touched, period.

Put back Mod 148, figure out the real reason why drive does not work and fix the problem.

[fzabkar]

Mod 148 is not a to do list, it's alignment list.
Basically it's part of translation level

So this module remains static throughout the life of the drive?

[HaspHL]

Mod 148 of this 1 is almost completely empty

[fzabkar]

So is this one (WD20EFRX):

Code:

Offset(h) 00       04       08       0C

00000000  524F594C 03003000 48010200 FC430A49  ROYL..0.H...üC.I
00000010  30303031 30303339 07070700 00000000  00010039........
00000020  00000000 00000000 00000000 00000000
00000030  00040000 00000000 00000000 00000000

[HaspHL]

I found some more that has nothing inside it but 0x04 @ 0x31
interesting though the drives who do have mod 148 and do have data inside
there is scattered a copy of it in mod 2E

[Amarbir[CDR-Labs]]

By Changing Mod 148 Back To Older Non Modded Version i Loose Sector Access And By Using The Mod 148 that acelab modded i can access sectors ,And acelab does not complete clean the module like someone on top pointed out ,So might be your statement is not correct you want me to make a video on this and post do you

Some people are amusing
I have an example for you (not 100% related to module 148)
Let's say you have a bug in background scan module that points to an area that is beyond drive's translation
And then you have a table that has a task that asks background scan to perform some operations
When it happens drive hangs or not-initialized

Now you clean the table with the task - drive works
You put it back - drive stops working

What was the cause of the problem: the table with the task or background scan module with the bug?

Doomer Sir ,

I said might be ,You can see both the Mod 148 tables before and after .If you think this is ok ,then what the hell is the issue ,I am also not a jerk in WDC Hard drives ,My 90++ Percent data recovery is on these drives ,But i am not into reverse engineering ,I am Going to upload the entire firmware that was there as is i got this drive .I am interested to know what i have missed .I never heard of Mod 148 before this as no one ever documented it .Dr Kiev was boasting around thats its written in documentation ,Which documentation is it written ,i have never seen such a documentation ,Might be that documentation is classified ,cos if some of you have access to such classified info you should be generous enough in helping and not boast around ,I am not stating this to you but just trying to put across my thoughts .Yustik was making fun , whereas i have complete firmware from every step i did .