[MRDOTB]

Sorry for *n topic about this but others which I already perused are too old or are wall of offtopic. ;]

- - -

First, quoting Graf_chocolo:

Guys, take a look at “ps3dm_sm set_del_def_encdec_key” command. You can disable/enable virtual FLASH/internal HDD encryption with that And by patching HV process 9 (which sets ATA keys before loading GameOS) you can disable it permanently. It means you could swap your internal HDD and use it on another PS3. But you have to restore the content on it after disabling encryption because all data will be encrypted of course. Soon i will implement ENCDEC device driver for PS3 Linux and you will be able to experiment with ATA encryption. ENCDEC device is responsible for VFLASH/HDD encryption on PS3. For more details, see my HV page here: http://www.ps3devwiki.com/index.php?...se_Engineering ps3dm-utils GIT repository: git://git.dukio.com/ps3dm-utils.git linux hv scripts GIT repository: git://git.dukio.com/linux_hv_scripts.git And thanks to PS3 Linux fans who help me to test my ps3dm-utils Huge thanks to you guys. I can have fun with PS3 even without having one actually.

So as I understand, I need:
1. CFW with SS services (for working ps3dm-utils)
2. Installed Linux on otherOS++

And what I do not understand:
3. Nonexistent CFW with patched (?) syscall9.

Or maybe the no.3 is for only permanently disable HDD encryption and using only ps3dm-util changing keys for something more friendly like all 0x00/0xFF?

If yes, how can I decrypt in on PC? I found on devwiki:
http://www.ps3devwiki.com/index.php?...us_AES-256-XTS

So, still we even don't know which algo is used?

And still we don't know for sure which fs Sony use?
http://www.ps3hax.net/showpost.php?p...7&postcount=12

[euss]

disabling encryption will only corrupt the system. it has been tried and tested many times now, both by famous developers and others. it simply will not work as planned, for many interwebbed reasons which will backfire on the user and makes normal usage pretty hard.

algo is AES256CBC (XTS uses CBC too, but 256 is optional, as 128 is default and Intel Sandybridge has implementation problems with 256 keysizes)

key/seed is mixed mode, software (even before lv1/hypervisor is initialised, but also after that, see HV page) and hardware (which traces back to syscon and southbridge) crypto based

filesystem is UFS 2.5 (neither UFS1 nor UFS2), based in roots on proprietary reimplementation of UFS 1.0 from the BSD era with persector encryption and modified journaling.

[MRDOTB]

Have you any details about these *problems*? As I understand, SS services is only one of them?

What about changing this key to another? I was thinking about solution for YLOD/RSODed PS3 data recovery from HDD (from i.e image).

So it's some custom implementation. Anyway, still it's our slightest problem.

[euss]

One problem is that it works fine (that was the graf_chokolo/glevand's reimplementation in 5 variants) without reboot, once rebooted, it bricks and needs to be reflashed and reformatted, loosing all data on it.