PS3 Thoughts on fully decrypted internal hard drive?

I'm naively thinking of pre-decrypting the internal hard drive on Linux and NOPing out the encrypting/decrypting instructions of sb_iso_spu_module.self.

Would probably brick if I tried, would other stuff like lv0, lv1 have built in decryption dealing with the encrypted drive in the early stages as well?

Thinking of that it must waste thousands of cycles for each to transfer and decrypt each 512B block off the hard disk, wasting energy and losing performance. Getting rid of that would improve performance and energy efficiency.
 
I'm naively thinking of pre-decrypting the internal hard drive on Linux and NOPing out the encrypting/decrypting instructions of sb_iso_spu_module.self.

Would probably brick if I tried, would other stuff like lv0, lv1 have built in decryption dealing with the encrypted drive in the early stages as well?

Thinking of that it must waste thousands of cycles for each to transfer and decrypt each 512B block off the hard disk, wasting energy and losing performance. Getting rid of that would improve performance and energy efficiency.
I'm not exactly sure whether that would be a good idea. First of all, you can only do that in CFW, so it won't allow you to access HDDs that can't already be decrypted. I guess it could help if your PS3 dies and then you find out that you lose the ERK backup, but that's pretty much it. Also it has the huge disadvantage that if you flash it over non-patched firmware or vice versa, you'll have to decrypt / encrypt (or reformat) the drive each time.

If you want to do it for science, I'd recommend first testing it on the RPCS3 emulator before you try it on a real PS3. That way it's way less likely you'll brick anything.
 
I think @haxxxen already did it , or at least I remember some messages talking about disabled disk encryption

no idea if it brings any improvements, but I think it can be done
 
so far, it seems these patches only work for Slims (screw you S0ny!!!), cause of flash double encryption on FATs. will try to break it though

also, this is kind of chicken and egg situation, where you have to completely format hdd, so it is kind of impratical

hm, how to mount an unencrypted PS3 hdd on Windows?
 
Last edited:
@haxxxen On Windows You cannot. Nothing supports PS3PT (but it is easy to handle: https://www.psx-place.com/threads/t...decryption-on-linux.23308/page-13#post-375423), only GPT and MBR. Nothing BSD nested slices (VFLASH). And nothing UFS2. No drivers for that. 3141card's PS3 HDD Reader does, but it expecting encrypted disk or image (so You need mess with src which fortunately is open).

On Linux, easy via my toolkit.

BTW: Do You know maybe if eMMC (of course in already decrypted form, due to no lv1 access) can be read sector by sector to USB - on those models with HEN? I would like to see such dump.

@disc-kuraudo.eu On NAND models HDD is encrypted by ATA Key, eFlash on NAND by ENCDEC Key (in toolkit named as "flash key"). On NOR models HDD by ATA Key but one of partitions is nested, the VFLASH which is by ENCDEC Key (in toolkit named as "vflash key") like eFlash on NAND, additionally to first layer. Both derived from ERK so I believe it is not an easy task to disable this encryption because on NAND needs eFlash preparing on PC and write modified that way NAND image to PS3 via hw flasher, and on NOR models dealing with cascade encryption.

Scheme: https://www.psx-place.com/threads/t...decryption-on-linux.23308/page-12#post-372613
 
Last edited:
OK, I'm guessing in lv1 you can get around even triggering the decryption functionality inside sb_iso_spu_module? That would be even better.

Yes it introduces a bootstrapping problem, but one could think of a CFW line that works only on top of a fully decrypted HDD.

I'm just thinking about how many layers of (unnecessary) encryption and signature checking there is to get programs up:
  • Loading SELF from HDD: decrypting raw HDD data through SPU with lots of DMA calls
  • Dealing with the SELF -> verify signature, decrypt, decompress
  • Repeat for all linked libraries
Meaning any 16 byte block of data is just unnecessarily moved around and folded hundreds of times.

Whenever an EBOOT or SELF starts up there's this 1-2s after XMB disappreaing until it fades to black, my bet is the overhead above makes its contribution.
I could think of a fully decrypted HDD with all FSELFs to already have a noticable difference in general responsiveness and bootup/back to XMB time.

Tried converting some SELFs on flash (BD Player) with FSELFs but it failed with some error code, probably did something wrong or there's other checks.
If a CFW properly replaces SELFS on flash with FSELFs and on HDD with decompressed FSELFs it would be a good start already.
I wonder why it's not a thing yet for CFW to internally go all unsigned and where possible uncompressed (flash storage is limited).

All this stuff costs power as well, meaning slightly higher temps when streaming data off HDD (high bitrate BD movie, 50GB game).

I'm currently just scratching the surface on PS3, lv1 stuff would be a deep dive for me. Can't contribute much yet.
 
I love the idea. However I see future army of CFW newcomers which will happily formatting drive and spreading misinformation that CFW installation wiping HDDs (not this particular one with such kind of patches but all).
 
I love the idea. However I see future army of CFW newcomers which will happily formatting drive and spreading misinformation that CFW installation wiping HDDs (not this particular one with such kind of patches but all).
yeah, you probably right. haters will do so, no doubt. on a FAT NOR, you will be stuck in a formatting loop with current patches, cause vflash cannot be read. hope I can improve my reversing skills and break the FAT NOR double-encryption :(

too bad, glevand has preferred only Slim models
 
Back
Top