PS3 dumping instructions (Page 1 of 3)

I think the problem is due to red ribbon, I have the same problem. It works fine in debian and petitboot, don't think it's been tested elsewhere.

Maybe someone with more linux knowledge can help me with this.

I've been trying to setup my ps3 for this. But i keep running into problems. I'm a linux noob so might be easy fix i dunno.
I'm running Rebug 3.55.2 Otheros++ or whatever it's called. I can boot into petitboot and acces the shell. From there i acces the usb drive with the created 3Dump.bin and the getkey files. However i cannot run them from usb as it says it's a read-only file system. Got around that by copying the needed files to /. And execute them from there. When executing it created the log. And with nano i can view it. At the botom it says something like completed succesfull so i asume it's done right. Now here is my problem.

If i do 'cp output.log /tmp/petitboot/mnt/sda1' to write the log file back to usb it complains cannot write to read only file system. So i do 'mount -o remount,rw '/tmp/petitboot/mnt/sda1'' to remount it with write permissions. I can then copy the file to that location. However it's not actually copied to the usb drive. When accesed from pc the file is simply not there...
If i goto that location in petitboot it shows the file should be there, and can even be opened with nano.

Anyone can enlighten me what i'm doing wrong?

Thanks, dunny why but once i changed to your mount line it worked. Can now write to the usb drive. Although it did already show as rw in mount with the line i posted. Why it works doens't matter as long as it works. Got a perfect match to a dump already in db so will get the logs for all my discs and put them up soon.

Not even going to bother installing a real linux package. Wont be used anyway.

EDIT:
All keyfiles dumped. Once i rebooted the problems were back, but was fixed by using both mount command, lol.
Now all left to do is de the multiman dumping that seems to take forever... 8.5MB/s... sigh.

Can anyone recommend a newer Drive for the PC dumping method?
None of the suggested drives in the first post seem to be available to me anymore.
Will new ASUS drives (e.g. BC-12D1ST) work too?

When will the missing steps / tools for the PC method be provided? Thanks!

Thanks for clarifying that.

Would it be possible then, theoretically, to extract metadata, disc_key etc. using classical PS3 homebrew applications?
Or is this not even possible technically without linux?
I don't really wanna mess with linux on 3.55. Would like to stay on 4.41 CFW.

I ported the "GetKey-r2" application by JamJam to GameOS so people should be able to run from XMB now if they wish. Install the getkey.pkg, from the attachment "GetKey-r2-GameOS.7z" file, as you would any homebrew.

Instructions:
-) Put your 3Dump.bin on the root of a usb.
     GetKey will look for it at "/dev_usb000/3Dump.bin"
a) Put a disc in your PS3.
b) Put the USB in your right-most usb slot (/dev_usb000/).
c) Launch getkey from XMB: it'll run and exit back to XMB.

You should then notice 2 new files on the root of your USB:
/dev_usb000/getkey.log
/dev_usb000/disc.pic

The log/pic should be exactly what you got before. Transfer them off via ftp/usb/etc, and then repeat.

Example "getkey.log" from GameOS/XMB

GetKey r2
Load keys
Test unit ready: return value of ioctl indicates success
Read pic: return value of ioctl indicates success
get dec key
  establish session keys:
    do send key: return value of ioctl indicates success
    do report key: return value of ioctl indicates success
    calculate session keys
    do send key: return value of ioctl indicates success
  get data
    do unknown e1:
    unknown e1 cdb: e100.....a0bf
    return value of ioctl indicates success
    do unknown e0:
    unknown e0 cdb: e0003....0b1c
    return value of ioctl indicates success
get_dec_key succeeded!


disc_key = cb66d33016a7d89308ebad7eb2379e64

disc_id = 00000000000000ff00020003XXXXXXXX
PIC:
10020000444901080000200042444f01
1101010000000000006f817f00100000
006f817e000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000

SUCCESS: Everything was correctly dumped.

Source is with the program, I tried to keep source as close to original program as possible, just do_cdb(...) has been modified for GameOS, and compiled with PSL1GHTv2.

I'll see what I can do to maybe rewrite the code so it's more simple / has the ability to dump information to screen maybe (or give some visual indications). Also ideally give you options to save pic/log files to alternate locations like net_host, and grab disc title for log filenames. Maybe edit so EID can be grabbed dynamically instead of 3Dump.bin. But for now I thought something is better than nothing for those who rather dump disc keys from XMB/GameOS instead of dual boot.

It has been tested with REBUG 4.46.1 LITE EDITION, but, it should work on any CFW fine. If someone else wish's to add any of the above features, etc, feel free to do so.

One question to JamJam/Someone. I notice the "disc.pic" is 4100 bytes (which seems corret based on the source code). I have done a few verifies, and the begining/log dumped PIC matches exsisting database items, so I'm sure it's fine, however, I always notice some data in the disc.pic at the next page boundary (800h). Example:

000h: 10 02 00 00 44 49 01 08 00 00 20 00 42 44 4F 01 11 01 01 00 00 00 00 00 00 6F 81 7F 00 10 00 00 00 6F 81 7E 00 00 00 ...AllZeros...
800h: 00 00 00 00 45 42 01 00 00 00 00 00 FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...AllZeros...

Is this 800h information to be ignored? Does it exist for the original program (I don't have a dual boot to test with)?

EDIT: The attachment system doesn't seem to work, so uploaded to external: http://www.mediafire.com/download/g9pvt … -GameOS.7z

Well done modifying the source and making a pkg, I didn't expect anyone to modify it otherwise I might have made it a little cleaner

The PIC is a bit of a question mark. 3k3y gets 0x73 bytes, redump gets 0x84, and things can always change. The full PIC is dumped just in case we want more of it in the future.

Hey guys,

recently this has come to my attention: http://www.3k3y.com/ripp3r/.

The provider claims "It is the only software capable of creating accurate PS3 ISO images".

Even though I do not own any 3k3y-Hardware I checked out the Ripp3r-Software.
Since the application includes ISO encryption/decryption features, I wanted to know what it can do with my (Redump) PS3-ISOs, dumped following the guide in this very thread.

Well ... I wasn't too surprised to find that my ISO files were being rejected as "invalid ISO" when trying to use the built in ISO crypto feature, for instance.

So I am wondering, are my ISOs really accurate dumps?

I believe that I have read somewhere that 3k3y ISOs have the disc_key included, even though it doesn't really belong in the disc image. Could this be the reason why redump ISOs do not match, thus 3k3y ISOs being not accurate after all?

3k3y Ripp3r Software can be found here for your investigation: http://www.3k3y.com/ripp3r/Setup.msi

Also here is the documentation including some interesting PS3-Disc crypto-information: http://www.3k3y.com/index.php/download_ … ew/41/128/

Cheers. :-)

Hi gents,

I got a new PS3 (CECH-2001A). It's setup with Rebug 4.65.1. I installed NvrBst GetKey, but I need to get a dump of the drive. My question is what is the easiest way to get a 3dump.bin file? And can I use the 3Dump.bin file that I had in the PS3 FAT that I had previously (it had to go back to it's rightful owner)?

I have Little Big Planet 3 in hand at the moment and I would like to post it.

Bummer.

Ok, so downgrade back to Rebug 3.55(?)
Install 3k3y Key Dumper v1.00 app
Dump the key
Upgrade back to Rebug 4.65.1

Will that work?

Also keep in mind you can generate the 3Dump.bin yourself from almost any CFW version (including 4.65) if you really want to (just the official 3k3y app only works on 3.55). However downgrading and re-upgrading is fine too.

### Generating it Yourself Brief Summary ###
3Dump.bin is just the "EID4(48 bytes)+EID Root Key(48bytes)". EID4 you can get by making a NOR or NAND dump (typically via multiMan), and EID Root Key you need an app.

* EID Root Key Dumper Link: http://store.brewology.com/ahomebrew.php?brewid=228
* EID4 offsets inside your NOR or NAND dump: http://www.psdevwiki.com/ps3/Flash:Encr … _eEID#EID4

I've generated the 3Dump.bin manually on 4.46, and it matched my 3.55 3Dump.bin. If you havn't already downgraded, and need more detailed instructions I can try to help, just let me know.

EDIT: Also, more so for your own information, if you run the official 3k3y app on a non 3.55, the 3Dump.bin file that is generated is typically just 48bytes (EID4). However, it is probably best to only run the official 3k3y app on 3.55 CFW, especially since you can just get the EID4 from your NAND/NOR dump and who knows what the root key logic does if not run on 3.55 (very unlikely to brick your system, but, isn't the cleanest thing to do).