Reference to lv2diag.self in 3.55 lv2kernel.self

[Slynk]

Hey guys I thought I would look through the 3.55 files and see if I could find anything relating to the removal of downgrade potential in 3.55 and I found this:

At 002E9230:


###
### Factory diagnostic mode
###

mounting the USB mass storage (usb000) : 
 Failed (error code:0x%08x)
%s/%s
Lv2diag.self
DEH
Continue
#.# Detected USB dongle
# mounting the flash file system : 
Skipped
###.### Safe mode.###
process_utils::create_initial_system_process : ss_params::get_update_status failed (%d)
###.### Software update mode.###
mounting the builtin HDD1: 
PS3UPDATE/ps3su.self
sys/internal/sys_init_osd.self
/app_home
sys_init_osd.self
# WARNING : lv2::ss_params::get_update_status() returned an invalid value (0x%02x)
-mode=1
-mode=2
###.### creating the ps3swu process : Failed (path:%s, error code:0x%08x)
### exiting software update mode.###

I'm not that familiar with the reversing process but I believe, if you load the elf into IDA you can look for a call to the memory address containing any of these strings. You then have a general area to work with in your attempts to get downgrading back.

Or, I could just not know what I'm talking about and have wasted a thread >.<

EDIT: Also I found the same text string in the 3.50 lv2kernel.self starting at:
002E2318

So maybe someone can find the calls to the strings, compare the functions, and make an appropriate patch?

[Ben Jeremy]

Well, there's bound to be a reference to it, since it must find the file and boot when it's in Factory Service mode.

At the moment, we figure it boils down to the authid section of the self, and maybe the hash (but changing the authid also changes the hash, so that works out if it's the hash) that is used to tie the program to the revocation list. Modifying the authid and re-encrypting it should be enough, but what's odd is that Geohot used the SAME authid as the "file 2" lv2diag.self file (the one that exits service mode).

The problem at this point is that we haven't been able to properly sign it, due to the poor nature of the current tools. This is the problem with EVERYTHING at this point (including signing homebrew and pre-patching firmware), so we are eagerly awaiting Geohot's release of his tools.

If anybody knows if/where the PS3 stores bootup logs, I'd be much appreciated... as soon as we CAN sign apps to run in service mode, I would like to knock out a simple app to copy out the diagnostic logs so bricks can be fixed easier. I've got a brick that flashes great, except for the "factory firmware PUP" (just the coreos) - flashes any retail firmware you throw at it, with no issues in the downgrade log, nor any stoppages on the recovery flash screens (goes to 100% after copying to HD, then RSoD)

With the ability to grab those log files, I might finally know why the PS3 insists on going to a RSoD.

[stoker25]

Those strings appear in LV2 dumps too

They are part of the create_initial_system_process function (0x287D50 in 3.41 dump), I started to map out this function in IDA to figure out the code's flow, maybe I should take a look at it again and document it, since the PS3 has more modes than service mode.

[Slynk]

Found this in the lv2kernel.self as well, is it what you're looking for?:

/dev_hdd1/crash_report/kernel/ps3crash-kernel.dat.tmp
/dev_hdd1/crash_report/kernel/ps3crash-kernel.dat
/dev_hdd1/crash_report/kernel

[Ben Jeremy]

Found this in the lv2kernel.self as well, is it what you're looking for?:

/dev_hdd1/crash_report/kernel/ps3crash-kernel.dat.tmp
/dev_hdd1/crash_report/kernel/ps3crash-kernel.dat
/dev_hdd1/crash_report/kernel

It's a start... it should tell me if a specific app is bombing on initialization.