To quote: A update, I finish the FAT read support, for dev_hdd1 on NAND and NOR and dev_flash, dev_flash2 and dev_flash3 on NOR. A big THX on sguerrini97 and sinsizer for test the tool on slim-ps3, and on 3absiso for test it on fat (NAND/NOR) ps3's.

Usage: A simple on-the-fly decrypter and ufs2 reader as comandline tool for windows. To see the content of your gameos(dev_hdd0) and copy files and folders to PC. No write suport! Hdd will only read.

Put your eid_root_key file in the program folder and connect your ps3_slim_hdd to your PC. Comands are "dir" or "ls" for see a directory, e.g.:

ps3 dir /

to see the root of dev_hdd0, or

ps3 ls /home/0000000X

to see your user folder. To copy a file or folder use "cp" or "copy", e.g.:

ps3 cp /home/0000000X/exdata/act.dat

to copy act.dat to the program folder, or

ps3 copy /home/0000000X/exdata

to copy the whole exdata folder. Its not a profie app, quickly written, maybe you found bugs.

Big THX again to ALL involved! Specially to Graf, Glevand, Naehrwert and Flatz.

Glevand show it for a slim hdd, ok, but for a fat only the decryption is other.

Next is, compile the kernel for UFS write support, and mount gameOS rw. Work perfect for me. So why a maybe risky hombrew, if i can use a brilliant OS with proper coded device driver.

About: It decrypt a ps3-hdd on a windows pc. Show you the content of the partitions, and offers the possibility to dump this content to your pc.

If you have a ylod, or the ps3 is in a other way death, than all data on hdd are lost. All your game-saves, trophys, music, videos, ... Only the ps3 on which this hdd was formatted/installed can read this hdd, no other ps3 can this.

If it was a cfw-ps3, and was you clever enough to dump your eid-root-key, than you can use this tool to get your data back.

If you have a corrupted hdd, and the ps3 say, you have to formatte, than also all your data are lost. Or you put the hdd on the pc and use this tool and your root-key. If you was not clever, and have no root-key, can you use another hdd to get him.

The tool will maybe not correct work with a corrupted hdd. But there is a chance to get some data back. And if it work, be aware: A file can have the right name, size, attributes, timestamps.... but there is no warranty that the file data are correct, no tool or os can repair such
data. No tool or os can divination.

Only to clear a misunderstanding, what i add is FAT(the filesystem) support. Not fat-ps3 support. Fat-ps3 support was already implemented, weeks ago. But the tool has befor only read UFS2, gameOS.

I read that some people would read also the vflash regions and dev_hdd1, so I add FAT12/16/32 read support. I read some people have a old backup, created with dd or a hexeditor and would read this to recover data, so I add the possibility to use a file as source instead of a hdd.

Finally, from zecoxao: Today i stopped by irc as usual, and had a nice chat with 3141card , who provided me the source of his hdd reader in exchange for the community to improve it and add more features to it.. you can check the source here (linked above).

Some things that need improvement are:

fat module needs to be remade without windows dependencies

fat write support

ufs write support

As for the fat and ufs modules, a LOT of information can be obtained from www.kernel.org (linux kernel can support ufs read write and supports fat natively)

Finally, also from 3141card comes a video below of PS3 XMB Blitting as follows:

Hi sandungas, I found a way for blitting informations on the XMB screen, it is not perfect atm and work only in main XMB, not ingame.

I found some bitmap-data in main ram, and poke other RGBA values on this place. I make a simple framebuffer, print text in him and poke him on the screen. The example have only a blue background and white text, but more complex things are posible, inclusive nice interaktive GUIs.

yes, but only if you have the eid_root_key from the dead ps3. Brenza about the write feature, here is what 3141card answered:

I can you say why I not plan to do that. I simply know not enough about filesystems. Is the de/encryption a prob? No, its the easiest part on the prog. Its easy to write a fuction for on-the-fly encryption, simply a invers of my read_device(). I have no wish to write a app was kill in worst case a many ps3-hdd's. Only because i forget to set a flag or to update a special value in superblock or cylinder. And why write such a prog? There is always a better way. Linux.

glevand has it show (on psdevwiki.com/ps3/Mounting_HDD_on_PC). It is easy to mount a ps3 hdd on linux.

He show it for a slim hdd, ok, but for a fat only the decryption is other.

I have a similar question, I have a dead ps3 on which I want to recover the hard drive contents but I did make a flash dump before it died. Can the eid root key be obtained from the dump? That's how I believe it works unless there is some other step

To quote: I found a way for blitting information on the XMB screen, it is not perfect atm and work only in main XMB, not ingame. I found some bitmap-data in main ram, and poke other RGBA values on this place.

I make a simple framebuffer, print text in him and poke him on the screen. The example have only a blue background and white text, but more complex things are possible, inclusive nice interactive GUIs.

Here is the sprx+source, it is very simple, not perfect only a quickly written test app... I test it only on rebug 4.46, after booting hold R2 and press Start, it will only work after bootup!!! Not after leaving a Game or App.

Copy PIC1.PNG from download (blitting_xmb_test_PIC1_PNG.rar) in e.g. multiman dir. In XMB go on multiman and press select. Simple example, draw only one frame if select was pressed.

Furthermore, it is a stupid method, but if no better way arises... in principle:

IO module is running all the time the ps3 is running.
IO module awaits input from many devices, not only pad, also Kb and mouse.

The system (XMB, in Game XMB), hombrew like multiman and also in background running prx, need a struct for handle the input.

This is a ram dump from my rebug 4.46C ps3. At offset 0x10389F4 is the pad-data struct.

The point, if you are in game and press O on your pad, to set this value in the pad-data struct of the running game to 00 20 or use a in backround running plugin to set this value with poke to 00 20 if you press a special Keyboard button, it is the same.

If you have rebug 4.46C running, here (linked above) is a simple ram viewer prx, based on the blit into PIC1.PNG. Look at offset 0x8000000001038800 and 0x8000000001038A00 for the pad-data struct, press e.g. O and you see the altered values...

I use it only on 4.46C with Users prx loader. Work only in XMB, is not stable, only some playing for me, not a release !

Go in games column on the app with the special PIC1.PNG, press select to toggle the hex-viewer on/off.

Use R1 and L1 to go one sector up or down,

Hold R2 and use R1 und L1 to go 1 KB up or down,

Hold L2 and use R1 und L1 to go 1 MB up or down.

EDIT: fixed a stupid copy-past error in source code of prx

Blitting in XMB Background PNG Example (see video and files above):

The background png must be 1920x1080 and set 100% (no scaling!) Select button start/stop blitting, work only in XMB, kk

Its a simple example, no event checks, blitting stop not automatically! Use select to stop blitting before you start a app/game or shutdown the PS3, Otherwise your PS3 crashes.

Update: May 5, 2014: Two freezing bugs fixed.. new sprx+src (linked above) and please notice, its a example, a concept, not really an app.

Will not work, it need the background png (say png, mean the ARGB area in local memory for the bg) to see the blitting area.

I have tried several things, but nothing stop fast enough, the prob are the short time to write a finished frame in local mem. In XMB there are 0x0FE00000 (254MB) accessible, the bg area begins at 0x00C80000, the raw ARGB data 0x200 later. If a eboot.bin starts, only 0x00500000 (5MB) are now accessible, so r/w offset 0x00C80200 and higher = freeze. say it again, blitting is stupid time to look at gcm...

Hhmm, found a more cooperative mutex, now blitting stop automatically by game/app start or shutdown. I also lock now the gcm_lwmutex during r/w processes to local mem.

I use furthermore 4.46 CEX rebug + User's prx-loader for testing a prx, keep that in mind if use other MFW's.. same link as before (write no change log or make revisions, is not a app and simple source code say all, if someone will use the method)

Another change, skip the mutex stuff and stop blitting now each time the X button is pressed, that stop blitting also if you go on trophies or a sub-menu under setting, don't like it but better than a freeze.

I don't know how the power-button can be checked, so if you shutdown over power-button during blitting, PS3 will freeze.

Update #2: Finally, in related news haxxxen shared a mod that allows users to reboot from the PS3 XMB (via User Category without the need of loading a plugin) on Custom Firmware with details below.

To quote: I have been using this in past already, when cobra and its testplugin was released, before i have run cobra cfw myself. with cobra functions and webman there was no need and i discarded the usage of it.

Now i was doing some mods lately and i have thought about its usage again, cause using the reboot pkg from xmb takes too long for my impatience, lol.

I have added a new entry in user category and the reboot function can be used from there (german strings)

It makes usage of official xmb function in main xml and it is disguised as "xai_plugin.sprx" signed 3.30, which is an official plugin by sony for these widgets functions and was removed from flash since 3.40 ofw. though, the plugin name itself still remains in xmb_plugin.sprx and can be called from xml.

It only has the reboot syscall included and it is a non residential plugin, which unloads itself. the way i have made it, it does not work work with prxloader or cobra loading from plugins.txt, and besides, it is not needed and would cause problems on autoload and you can directly start the plugin from xmb without. it is built like official plugins and you can find templats in sdk prx samples for it, so no source needed.

I have made a hard reboot version and a soft reboot version, which one would prefer and you have to copy the plugin itself to "dev_blind/vsh/module" and those xml to "dev_blind/vsh/resouce/explore/xmb". better to make backup of original, even though not really needed.

I only have added new entry for the plugin under user category and it can be used from there. i had to make an extra folder and disabled it from ingame, cause the item icon cannot be viewed ingame and it would only show this spinning icon.

This will not work for other things and is only good for immediate reboot.

From atreyu187: Awesome but when you say German strings can this be used by me as is or do I need to do something. As always you come up with some really nifty unique ideas. Thanks a ton.

You can translate the strings in category_user.xml yourself to English, and there would be no side-effect if you use the uploaded one.. the strings are directly put into xml.

From aldostools: This file contains the xml with english labels and the Restart action is not in a sub-menu as in the german version. I also removed the "info" string as eXtreme suggested.

From bitsbubba: I think to make this a permanent modification for CFW we'll need some rco editing (add icon in-game, proper title string, etc.), translations (all languages supported XMB), etc.. as is being done with ☆Package Manager.

From Joonie86: The issue with multiMAN not being able to return to mmCM is currently fixed with some changes developed by habib.

Compiled binaries for REBUG 4.75.3 REX/D-REX are available on my repository of github, however I have no plan to release another fw update. I will just wait till the new ofw update then start work on it later.

CoD BO3 is around the corner, I expect the newer fw update any time soon along with new twitch tv app support for PS3.

This will make an extra folder, where you can have friend category functions under user tab.

On friends root you have to remove them of course, to not have them twice.. then you can add to friend root what you want to have there. for my example, i have a package installer and xmbman+ as already mentioned.

From sandungas: Mysis did his magic to add an interface to the custom xai_plugin.sprx (to accept the 2 custom action names for softreboot and hardreboot). Here is the new version uploaded by mysis:

The .rco is needed because after creating the custom interface... the firmware will try to locate it, so it needs to be there.
Is a bit special dummy, i kept some of the original info inside the .rco to avoid problems with the firmware, has been made by using this layout: pastebin.com/raw.php?i=GbLmryX8

One of the files included in mysis release was the official xai_plugin.rco from 2.00 firmware or so... is a container for images and texts, but because the xai_plugin.sprx is 100% custom code the contents of xai_plugin.rco are not accessed.

The dummy is the xai_plugin.rco i uploaded separately, is separated because i made it after mysis release but has been tested and is working.

The reason why the xai_plugin.rco is needed is because is indexed together with xai_plugin.sprx inside xmb_plugin.sprx... when enabling the interface for xai_plugin.sprx it seems the firmware makes a check for the presence of xai_plugin.rco so it needs to be there.

We are not sure what exactly is checked from xai_plugin.rco so i made a special dummy that keeps a bit of the info from the original (just a few labels names, is a valid rco structure that looks like the original but is empty).