Question about Firmware Tech.

[AkumaATR]

I know these ideas are probably full of holes, and sorry for not posting in Speculation, but as I've felt for a while, most people in the know don't read that crap!

What is preventing us from replacing (on 1.5, for ex., with a custom program after the PSP boots) the lib/prx functions that write out new blocks to the flash region that store the firmware with functions that will write to a specific location on the memory card? We would essentially be replacing something outside of the firmware update, which would not invalidate an update's digital signature. The theory is analagous to the way in which things like HD Loader map standard CD-Rom read calls to something else (a PS2 hard disk), except we would be redirecting write functions to some portion of a memory card.

At this point, could we possibly do the same type of replacement for code that shuts down the PSP (I think it does a software shutdown after firmware update, no?) and instead of having it truly reboot (which would cause it to load the old firmware in the traditional way mandated by the hardware), have it run some copied/modified firmware loading code? I'm not sure about the details of how the firmware loads -- like how much of the process is governed by software, and how much is governed by hardware. If a large portion of it is governed by software, could we possibly modify it so that it would attempt to load the firmware from the location we put it on the memory card (without ever truly rebooting or writing to flash), or have it all mapped from the memory card so that standard firmware functions look there instead.

Here's an idea I just had which is also prob. flawed (we are getting desperate, hehe, so stomach it) -- if we prevent that software shutdown after firmware update, none of the new, secure, firmware is loaded at that point -- couldn't we patch it inside of the flash at this point? Like patch it so that it allows allows valid eboots to run (regardless of their sig.). This idea must have been thought of before but I haven't seen it before, so I'm saying it. Obviously since we don't know the layout of the newest update(s) yet we could not go modifying things in flash. But we do know the structure of many of the newer versions don't we? Well at this point we would most certainly be burned after rebooting because the firmware block would be detected as corrupt (it is itself signed I can only assume). However, I am not sure about the details of this. Is the entire firmware block signed? Maybe only part of it is signed, so that it can be validated/loaded/booted faster (if this were the case, we might be able to make small changes here and there). I really don't know, but would like to know more about this stuff.

I realize these ideas are prob. flawed, but instead of general flames, it would be nice to learn more about the way in which firmware loads, so if anyone has links to such info. or insightful comments, please share. I am itching to play some of the new games (mostly the Street Fighter Alpha game), but don't want to upgrade as I feel it's my right to continue writing custom code for my PSP. Consider this just a brainstorming session (sounds like Speculation :icon_razz ).

[will1234]

checkout the ps2dev.org forums for all the tech info.

[AkumaATR]

Ok, I'm back this morning to bump my thread. I assume that since there was only one reply that either:

a) it wasn't a worthless post
b) it was a worthless post

After thinking about it more, one of the more exciting ideas expressed in it imo would be to attempt to patch the firmware in flash after it is written by the update, but before rebooting (by modifying the 1.5 libs/prx files outside of the signed, legit. update we are planning to run so that it won't software shutdown after installing the update, or by having a background program/thread do it's patching magic in the flash after some amount of designated time before we reboot). Since we have dumps of most of (all?) of the latest firmware revisions, couldn't we patch them to:

a) boot on eventual reboot (not fail a signature check). This could possibly be done by removing the check, not by resigning it with the key we all know that we don't have.
b) run valid, unsigned eboots (homebrew)

Feel free to shoot this down if I've made some major fallacies -- then I won't have to keep thinking about whether it could work.

[ryoko_no_usagi]

It's not possible to patch the firmware like that. A chain of trust is set up like this:

When the PSP starts up, the IPL is read from flash. It is encrypted (=signed) and is decrypted by the boot process. Without having the power to encrypt, it is impossible to replace the IPL with a custom version. That creates the initial security.

The IPL then loads a specific firmware version, which means a match and mix between IPL and firmware is not possible, say a 2.0 IPL together with a 1.5 firmware. All the important parts of the firmware are also encrypted and the IPL will not load an unencrypted firmware. And since it is only possible to patch a decrypted prx, a straight-forward patch of a higher firmware like you suggest is therefore impossible.

[AkumaATR]

Originally Posted by ryoko_no_usagi

It's not possible to patch the firmware like that. A chain of trust is set up like this:

When the PSP starts up, the IPL is read from flash. It is encrypted (=signed) and is decrypted by the boot process. Without having the power to encrypt, it is impossible to replace the IPL with a custom version. That creates the initial security.

The IPL then loads a specific firmware version, which means a match and mix between IPL and firmware is not possible, say a 2.0 IPL together with a 1.5 firmware. All the important parts of the firmware are also encrypted and the IPL will not load an unencrypted firmware. And since it is only possible to patch a decrypted prx, a straight-forward patch of a higher firmware like you suggest is therefore impossible.

Wow, great answer -- thanks!