Thread: HDD encryption
So to get the files that were floating around the net recently they had to get the UFS2 partition itself via knightsolidus' method, mount that partition loopback on Linux and then again decrypt the files that are in there? That sounds kinda backwards considering that this method relies on putting the stuff to be decrypted into a file that is contained in that very partition - kinda like a digital matroshka puppet. Mind boggling
I'll have to take a look myself when I get to work - still have a nice little 20 GB HDD lying around there gathering dust.
Okay - like I promised I tried putting a CF card in a CF-SATA adapter into the PS3. This sort of works depending on the card.
I get the best results with a 8GB Transcend card:
SanDisk cards didn't work at all (the PS3 didn't recognize the disk). A 16GB Extrememory card also didn't work (PS3 hung with this card inserted). My old trusty 4GB Kingston card worked but is dead slow.
I use this DeLOCK adapter:
This one seems to be identical (even the silkscreening on the PCB):
This one could also work (and has an additional USB connector):
Since the DeLOCK adapter only has threads on the bottom, I had to dremel the appropriate holes into the HDD caddy of the PS3. Fortunately two holes on the bottom are already there - only the wrong size. Just enlarge those two with a > 3mm diameter drill.
The second adapter should work without any drilling since it has threads on the side as well as the bottom according to the pictures.
CF cards as little as 4GB work but then you don't have much space left to store PSN content. 8GB seems to be a good compromise between free space and small image size when dumped.
Another idea I just had is to skip the imaging step altogether. There are a few SATA cards available that support "target mode" on Linux. This means that they can mimic a SATA drive. That way we could emulate a SATA disk using a Linux PC and have the PS3 use a disk image on that PC directly as SATA disk. We then could edit this file directly on the PC with the PS3 turned off.
Cards supporting target mode seem to be Broadcom 8603 based cards and Marvell gen2e cards (supported by the sata_mv Linux driver).
Did anyone ever tried to undercover sumtin' 'bout HDD and everything else via a RAM dump ?
I do believe that a 'nix system for sure have access to the bootloader that loads (sorry for the word-joke) the XMB (formerly the console OS), is it so impossible that there could be sumtin' useful loaded into RAM ?
And how would we dump the RAM? That's quite difficult...
So you're talking about dumping the RAM from Linux? Linux doesn't see all of the PS3's RAM and most certainly not the part where the initial bootloader resides. This is enforced by both the hypervisor and hardware in the CPU (MMU and IOMMU).
The only way around this would be by using the DMA engines of the GPU for example since the GPU might be able to access more RAM than the logical partition in which Linux is running. That however would require quite a bit of coding and couldn't be facilitated by a simple dd.
On a slightly unrelated note ... would anyone care to explain to me why I got -Repd for my previous post? I just stated that it's quite difficult to dump the relevant areas of memory.
However I don't believe a bootloader could reside in RAM while I do believe it's stored into a 4MB flash instead (usually /dev/sdb) and I dont see any good reason for it to be shadowed onto RAM, at least for the alternate-os one, maybe this lack of shadowing could somehow explain the not sky-high performance of every 'nix system I've seen so far kicked into that box.
For sure many tries with a very specifically built kernel, crafted on purpose on the machine itself, have already be done, I'm sorry if my clue was pointless but I do believe the only way to decrypt HDD (and everything else before as well) is through a similar path.
Yeah, for what its worth, the PS3 Linux bootloader is stored in the cell_os_ext_area (or something along those lines) on the flash of the system. Its a 4mb area, that gets mounted as dev/sda or /dev/sdb (depends on your system). You can write to it to update the bootloader, if you so please. There are also a few flags in there, for video mode, region, and what system (PS3 or OtherOs) to boot on well, next boot.
As for getting code to survive the reboot, most chances of that were killed with 2.10, as there was preliminary hope witjh stuffing code in the GPU, but not much came from it.