Request for Multiman to support DRL/CRL hash fix to restore Blu-ray Playback

[sumolx]

Hi Deank,
Would it be possible to update Multiman to regenerate the DRL/CRL hashes in order to restore BluRay Playback for consoles that were downgraded in factory service mode. I did try this fix and it worked for me and I assume it will work for others. However, since nothing above 3.55 supports OtherOS++ I was hoping you could perform this patch to the flash VTRM region.

http://www.ps3devwiki.com/wiki/Fixin...and_CRL_Hashes

Thank you for your time.

Root Cause:
When performing a factory service mode downgrade we all know that flash3 is wiped out. This means the following required files and directories are lost:

/dev_flash3/data-revoke/crl/CRL1, CRL2
/dev_flash3/data-revoke/drl/DRL1, DRL2
/dev_flash3/data-revoke/srm

These files are regenerated by the installation:
/dev_flash3/data-revoke/ocrl/OCRL1, OCRL2

Now here is some good news...

CRL(s):
CRL1 seems to be a constant, after performing an endless amount of searching I found that in every case where I was able to obtain CRL1 and CRL2 they were always the same. Therefore, obtain a copy of these two files and copy them to /dev_flash3/data-revoke/crl/
sha1sum: 96791f41f9a76f4d895dd5820db108ec03d19250

DRL(s):
DRL1 needs to be acquired and they do not have to match the drive's HRL. Using MultiMan extract MKB_RO.inf from you Blu Ray movie and use DRLTools DRLGen v0.90 to create the DRL files. Copy these two files to /dev_flash3/data-revoke/drl/

Double check srm directory exists and ocrl directory contains the OCRL1 and OCRL2 files.

Final Steps (Refer to link above):

How to get correct DRL and CRL hashes:

sudo mount /dev/ps3flashe /mnt

sha1sum /mnt/data-revoke/drl/DRL
18f0652bc6162a240362f90f1b2e5405bb82ee502 /mnt/data-revoke/drl/DRL1

sha1sum /mnt/data-revoke/crl/CRL1
96791f41f9a76f4d895dd5820db108ec03d19250 /mnt/data-revoke/crl/CRL1

Write current DRL and CRL SHA1 hashes to FLASH using VTRM service:

sudo ./ps3dm -l 0x0 -p 0x1070000034000001 vtrm store_with_update \
8f0652bc6162a240362f90f1b2e5405bb82ee50296791f41f9 a76f4d895dd5820db108ec03d19250

Conclusion:
This method has worked for me and I did not need to know my drive's HRL. This means i can use any Blu Ray in my collection. However, you will loose playback if you change CFW to OFW/CFW. This is why I'm asking Deank if he can make this part of this MultiMan application. This way if you decide to try another CFW you can easily restore your Blu Ray Playback with his tool.

Expectation:
What MultiMan should do is the following...
1. Perform sha1sum against DRL1
2. Perform sha1sum against CRL1

if they are not equal to what exists in VTRM, then write new values. Once this has been performed... you will have Blu Ray playback restored.

[lynzoid]

Yes please. Personally got CECHG01 here, it's hella stubborn. Will not give me my BluRay playback.. back.
Thanks Deank for your great efforts.
Updating MM to 4.10 as i type.

[deank]

Since there is OtherOS support for 4.21REX firmware I guess it can be done from linux, too, but i'll see about that.

[lynzoid]

Just tried to do it again with 10 more blurays. Still no luck. Used linux method as well as external bluray and even directdiskaccess in MM (retrieves MKB_RO perfectly!).
Tried Remarry - goes thru but no file structure generated is fsm or ever.
Restored files from someones' flash but it's still no go.
That method posted above would be long awaited salvation for thousands of unlucky lv downgraders.
Thanks again in advance. I can volunteer as a tester as i got most stubborn US CECHG01 fat (nand 256).
Cheers

ps. just to be perfectly clear - by 'Used linux method' i meant PS3SAK access to BD to retrieve MKB files. The instructions posted above (manual sha1 etc) is well above even my expertise And i cannot run OtherOS on latest REX. Had to downgrade to 3.15 to do it. Thanks again.

[sumolx]

Since there is OtherOS support for 4.21REX firmware I guess it can be done from linux, too, but i'll see about that.

Deank,
Though I have no problems using linux, I would still like to see MultiMan support such a fix. It then becomes a non-issue when changing from CFW to CFW. MultiMan is the only app that is consistently used through out different CFW(s) and I want to thank you for all your hard work!

Just tried to do it again with 10 more blurays. Still no luck. Used linux method as well as external bluray and even directdiskaccess in MM (retrieves MKB_RO perfectly!).
Tried Remarry - goes thru but no file structure generated is fsm or ever.
Restored files from someones' flash but it's still no go.
That method posted above would be long awaited salvation for thousands of unlucky lv downgraders.
Thanks again in advance. I can volunteer as a tester as i got most stubborn US CECHG01 fat (nand 256).
Cheers

ps. just to be perfectly clear - by 'Used linux method' i meant PS3SAK access to BD to retrieve MKB files. The instructions posted above (manual sha1 etc) is well above even my expertise And i cannot run OtherOS on latest REX. Had to downgrade to 3.15 to do it. Thanks again.

If your drive is already married you don't need to re-marry it again. The key is to generate the proper hashes (CRL/DRL) to VTRM. Once that is accomplished you will be able to playback your movies.

On a side note...
I know my HRL is not set to any BluRay (stock values)... not sure how this happened but it is the default HRL for both buffer 4 and 5 on the drive. Could this be because i re-married the drive too many times? Or because I converted to DEX? Or because I downgraded via Factory Service Mode? I don't know the answer to why my drive is set that way.... but I do know the comparison between HRL and DRL is not necessary if VTRM contains the proper hashes.

[lynzoid]

Lets just hope, that Deank will implement this fix and/or provide a tool.

[lynzoid]

Thanks. Will wait for possible solution from deank soon.
BTW, can you please explain me, why playback will be lost if changed back to OFW/another CFW? flash3 should remain intact as BD flash region (VTRM right?). Or did you mean lv2diag downgrade (which will format flash3).
Sorry if i'm being too stupid.
Thanks

[sumolx]

I don't know why the hash is lost. But if I were to guess... that region of flash probably gets flushed out when a software update is performed via XMB or System Recovery. Since the HRL on the drive and the DRL within flash do not match, the function that generates the CRL/DRL hash is never executed. Thus leaving that area uninitialized. It might be that code (validation of HRL/DRL) is specific to only NAND based PS3(s) and not NOR based PS3(s) since the NOR based PS3(s) never update the HRL on the drives. That is probably why downgraded NOR PS3(s) don't have this problem.

But these are just guesses...

[lynzoid]

Pretty good explanation, thanks. I am wondering if it's possible to write to the drive's HRL...

[sumolx]

I tried to update the HRL using this tutorial: http://www.ps3devwiki.com/wiki/Remar...Drive_on_Linux

But i was never able to successfully acquire EID2 IV and key in order to decrypt EID2 and gain the proper privileges to update buffer 4 or 5 on my drive. I even generated a new HRL by hand that was compatible with MKB v9 "The Dark Knight". I had spent over a week without any success and my pblock_des.bin and sblock_des.bin files never matched this portion of the tutorial:

# First 16 bytes in pblock_des.bin and sblock_des.bin should be equal to:# 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I gave up and then tried the original post's tutorial about hashing CRL/DRL and found that worked to my surprise. Especially since my HRL does not line up with my DRL. The hashing is a fix for those who run CFW, though the real fix is to update the HRL to match the flash's DRL but I was not capable in decrypting EID2.

If someone was able to provide a mechanism to write a new HRL.bin to the drive that would be then end all solution. After the drive has been updated, I would think performing a software update via XMB or System Restore would regenerate the CRL/DRL hashes. Then you could move back to a OFW without losing BD Playback.