Unmasking btldr on NAND console

[Rip Cord]

On Nand console the hypervisor masks the bootloader.
Here is a script for patching lv1 to allow a flash dump including the btldr.
Only "tested" on my nor console for script errors.

#!/bin/bash -x
#inserting module
modprobe ps3ram
#dumping original ram
dd if=/dev/ps3ram of=ps3ram_orig.bin
#patching lv1
#3.41
#perl -e 'printf "\x39\x84\x00\x00"' | dd of=/dev/ps3ram bs=1 seek=$((0x2786A0))
#3.55
#perl -e 'printf "\x39\x84\x00\x00"' | dd of=/dev/ps3ram bs=1 seek=$((0x2786E8))
#4.21,4.41
perl -e 'printf "\x39\x84\x00\x00"' | dd of=/dev/ps3ram bs=1 seek=$((0x27B1B4))
#dumping patched ram
dd if=/dev/ps3ram of=ps3ram_patched.bin
#dumping nor
dd if=/dev/ps3nflasha of=NOR.BIN bs=1024
#dumping nand
#dd if=/dev/ps3flash of=NAND.BIN bs=1024
#removing patch
#3.41
#perl -e 'printf "\x39\x84\x02\x00"' | dd of=/dev/ps3ram bs=1 seek=$((0x2786A0))
#3.55
#perl -e 'printf "\x39\x84\x02\x00"' | dd of=/dev/ps3ram bs=1 seek=$((0x2786E8))
#4.21
perl -e 'printf "\x39\x84\x02\x00"' | dd of=/dev/ps3ram bs=1 seek=$((0x27B1B4))
#removing module
modprobe -r ps3ram

Commands to dump the ram can be commented out; only there for checking the script.
Uncomment the command to insert patch for the firmware version.
The example is uncommented for 4.21-4.41
Uncomment the command to dump Nand flash and comment the command to dump Nor flash.
There is another version of the command to dump Nand flash:
dd if=/dev/ps3vflasha of=NAND.BIN bs=1024


console log

RipCord@ps3:~/dumpflashscrpt$ su
Password:
root@ps3:/home/RipCord/dumpflashscrpt# chmod +x dump_flashx.sh
root@ps3:/home/RipCord/dumpflashscrpt# ./dump_flashx.sh
+ modprobe ps3ram
+ dd if=/dev/ps3ram of=ps3ram_orig.bin
524288+0 records in
524288+0 records out
268435456 bytes (268 MB) copied, 12.172 s, 22.1 MB/s
+ dd of=/dev/ps3ram bs=1 seek=2601396
+ perl -e 'printf "\x39\x84\x00\x00"'
4+0 records in
4+0 records out
4 bytes (4 B) copied, 0.121153 s, 0.0 kB/s
+ dd if=/dev/ps3ram of=ps3ram_patched.bin
524288+0 records in
524288+0 records out
268435456 bytes (268 MB) copied, 12.2443 s, 21.9 MB/s
+ dd if=/dev/ps3nflasha of=NOR.BIN bs=1024
16384+0 records in
16384+0 records out
16777216 bytes (17 MB) copied, 1.81354 s, 9.3 MB/s
+ perl -e 'printf "\x39\x84\x02\x00"'
+ dd of=/dev/ps3ram bs=1 seek=2601396
4+0 records in
4+0 records out
4 bytes (4 B) copied, 0.168891 s, 0.0 kB/s
+ modprobe -r ps3ram
root@ps3:/home/RipCord/dumpflashscrpt#

based on published work of ****

edit: This was "tested" on red ribbon 5 where ps3ram is a loadable module included with the distribution. If it's first time running command modprobe on your system, you may need to run depmod -a to build the database of loadable modules. Other versions or distributions may include ps3ram support built in or loaded at boot.

 

[Storm Shadow]

Great work Rip. You really Nailed the Bootldr.

 

[Kongen12]

Allways nice when someone do things in the ps3 world. But can someone els use this to some thing. I really not understand all this

 

[Rip Cord]

When getting a dump of the flash from linux or gameos, all of the Nor is dumped (including btldr) on nor console. On a Nand console the dump doesn't include the btldr. This patch is supposed to enable dumping all of the nand (including btldr). I could only test the code on my Nor console to see if the patch is applied and removed without problems.

The information was already published; I put it together in one script. It's just as easy to enter the commands at the prompt. I had already used a dirty way to apply the lv1 patch by piggybacking it on to the lv1 patch in the peekpoke module for the btldr exploit.
It's uploaded here:
http://rghost.net/47491065
password to download: zorroisafox
password to unzip: 2357239178B

I don't know if it's useful.

 

[Kongen12]

Damn u wild thanks

 

[Rip Cord]

I guess not much interest in this, but I compiled a gameos pkg to do the same thing. Just a flash dumper, dumps flash for nor or patches lv1 and dumps flash for nand. I tested all the code, including the lv1 patch, from gameos on my nor console. Course it only tested for coding mistakes. Needs a real test on nand console to check if the patch actually produces the result.

I prefer if someone with nand console and hardware flasher has a chance to test it; any volunteers? Else I'll just post it with dire warnings.

 

[Storm Shadow]

Ill twitter it

 

[Rip Cord]

uh, okay, thanks. as long everyone knows it's only typical flash dumper plus graf's lv1 patch.

I used glevand's code for the dumping, it's way nicer than my crappy code for nor flash dump that I started out using, so it's a bit Frankenstein to look at. :angrybird7.gif:

 

[Storm Shadow]

hehe i allready blew my console up, els im would be the first to try it out.:arghh.png:

 

[Rip Cord]

dumps flash for nor or nand to usb stick. TESTED ONLY ON A NOR CONSOLE!
saves log file to same usb stick.
Tested on rebug 4.21, but the lv1 section that is patched is the same in 4.30, 4.41 and 4.46.
No gui, beeps when finished dumping, exit to xmb.
Takes about a minute or so on NOR, course it would take longer on NAND.

testing the nor code gives 16MB flash.bin and this debug output:

log path:  /dev_usb000/dbg_log.rtf
started logging...
 
checking vflash flag...
vflash is on
opening NOR Flash...
 
checking dump path.../dev_usb000/flash.bin
path.../dev_usb000/flash.bin
 
storage_device_info
 
uint8_t res1[32]:  756E6E616D650001E5FA26600000000000000028000000FE0000000000000000
uint32_t vendor_id:  00000000
uint32_t device_id:  00000000
uint64_t capacity:  0000000000008000
uint32_t sector_size:  00000200
uint32_t media_count:  00000001
uint8_t res2[8]:  0100000000000000
 
 
closing dump file...
 
beep, beep...
closing log file...

patching 2 lines of code allows to run the nand section of code on nor console:
#define NAND_FLASH_DEV_ID 0x100000000000001ull change to 0x100000000000004ull
if (vflash_on) change to if (!vflash_on)

of course still gives 16MB flash.bin and this output:

log path:  /dev_usb000/dbg_log.rtf
started logging...
 
checking vflash flag...
vflash is on
 
preparing to patch lv1...
current value at first address is 0x7C7F1B7839840200
current value at second address is 0xF8010090FBC10070
patched value is 0x7C7F1B7839840000
 
opening NAND Flash...
 
lv2_storage_open...
 
checking dump path.../dev_usb000/flash.bin
path.../dev_usb000/flash.bin
 
lv2_storage_get_device_info...
 
capacity (0x0000000000008000)
 
sector:  0x0
sector:  0x1000
sector:  0x2000
sector:  0x3000
sector:  0x4000
sector:  0x5000
sector:  0x6000
sector:  0x7000
 
checking restored lv1 value 0x7C7F1B7839840200
beep, beep...
closing log file...

It checks the bytes in lv1 that will be patched, if they do not match, then no patching.
If correct bytes are there, it will change 0200 to 0000.
It checks to see if lv1 was patched correctly, dumps flash, restores original bytes, exits.
As a precaution I suggest to turn off the ps3 immediately after app exits back to xmb.

Includes the source code. Examine for yourself before deciding to use.
NOT TESTED ON NAND CONSOLE! USE AT YOUR OWN RISK!

Here also is glevand's original source code for dumpflash. You can see his code for reading the flash sectors is bullet proof and much nicer than what I was using

 

[Rip Cord]

hehe i allready blew my console up, els im would be the first to try it out.:arghh.png:

that sucks, won't your parents let you get another one? I'm slowly wearing mine down for a ps4.

 

[Rip Cord]

Here's the ps1ight header files; seems like everyone's are different. Put them in the project folder; don't use them to replace the ones in your toolchain. Most only have a couple of things commented out but a bunch in lv2_syscall.h. I got tired of watching the warnings scroll by every time it's used to compile something. Some versions of lv2_syscall.h don't have this definition for the storage_device_info structure:

struct storage_device_info {
    uint8_t res1[32];
    uint32_t vendor_id;
    uint32_t device_id;
    uint64_t capacity;
    uint32_t sector_size;
    uint32_t media_count;
    uint8_t res2[8];
};

There's a couple other header files, mainly standard C files, but one might be toolchain dependent. If that one causes compile problem, comment out line 39 in the main source file. I didn't use glevand's Makefile; it might need adjusting.