PlayStation 3 lv0ldr - Teensy in the Middle: write up how to exploit lv0ldr w/ hardware by MikeM64

STLcardsWS

Administrator
ps3-slim-arty-teensy-final.jpg

PlayStation 3 - lv0ldr: Teensy in the Middle

by MikeM64


  • Table of Contents of Write-Up (see link at bottom for full write up)
    • Introduction
    • Acknowledgements
    • Abbreviations
    • History: Where did we leave off?
    • PlayStation 3 SPI Architecture
    • Syscon/Cell SPI Bus
      • Overview
      • Bus Transfer Protocol
      • Syscon SPI Packet Protocol
    • Juan Nadie's lv0ldr Software Exploit
    • Working backwards from outside to inside
      • Arbitrary SPI Read and Write
      • Dynamic Controller Selection
      • Priming lv0ldr
      • Replacing SPU Interrupts with Luck
    • CECH-2500 Exploit Setup

    Introduction


    NOTE: I do not condone or endorse piracy. As such, neither this exploit or write up will contain anything to enable piracy on the system.​

    Welcome to my write up on how to exploit lv0ldr using hardware on most PlayStation 3 systems. You can find the full source for the exploit in the repository here. The full setup required to use the exploit is described below in the section "CECH-2500 Exploit Setup". This exploit is a hardware-based implementation of the one released by Juan Nadie and the Three Musketeers back in 2012.

    Acknowledgements

    • Thanks to Jestero and M4j0r for your assistance and knowledge in getting this exploit running
    • Thanks to Victor for your assistence in tracing the Slim 3000 syscon pinouts
    • Greets to those in the assorted chat rooms that welcomed me back from retirement with open arms and patience while I got back up to speed again
    • Thank you N. for your unyielding support in my hobbies.

  • History Lesson: Where did we leave off?

    The PlayStation 3 has had very long homebrew story. At the initial release of the PS3, Linux support was baked in on day 1! People had the ability to install any PowerPC based distribution with full kernel support for the assorted system devices. This enabled all sorts of interesting uses like supercomputing clusters and a cheap PowerPC development box. There was some poking and prodding done from Linux to the hypervisor but nobody really bothered to dig too far until OtherOS support was removed from slim consoles. After the release of GeoHot's HTAB exploit, OtherOS was removed from all consoles in 3.21. This was the catalyst which opened the floodgates to complete exploit of the console. I've summarized the current state of many exploits released for the PS3 console below:

    Exploit Version Enabled in LV1 Enabled in LV2 Notes
    GeoHot HTAB Glitching Any? R/W Arbitrary HV Memory N/A FPGA used to glitch memory address lines
    PSJailbreak Dongle 3.41 N/A Homebrew and run backups in GameOS, OtherOS support restored Dongles exploited USB device descriptor parsing to get code execution in LV2.
    fail0verflow Sigfail <= 3.55 Custom-signed LV1 Custom-signed LV2 Works on all consoles with a minver of <= 3.55.
    Post 3.55/Sigfail Era
    lv0ldr Syscon Packet TOCTOU - Linux Dumping Any? N/A N/A Dumped the lv0 root keys to allow decrypting of all LV0 executables and signing on <= 3.55 minver consoles.
    HEN <= 4.89 N/A Homebrew and run backups in GameOS No OtherOS support
    lv0ldr Syscon Packet TOCTOU - HW Remix Any? Custom code in LV1 Custom code in LV2 Should work on all consoles with HW. This is today's topic!
    After the release of the sigfail exploit, Sony attempted to re-secure the bootchain by moving all loaders into lv0 as that had yet to be dumped or exploited. (Insert picture of bootchain from PS3DevWiki.) This was a good stop-gap solution until Juan Nadie and the Three Musketeers dumped lv0ldr and their exploit and keys were leaked. Once the LV0 keys were available, it was now possible to modify and re-sign all updatable code on older consoles. Consoles manufactured after the sigfail release were updated with new lv0 metadata (lv0.2) which is not vulnerable to the sigfail exploit.
    • Cell BE Bootrom -> lv0ldr (per-console encrypted) -> lv0
      • Pre 3.60: lv0 -> metldr -> lv1ldr -> lv1 -> lv2ldr -> lv2 -> appldr-> vsh
      • 3.60+: lv0 -> Scrambled loaders stored in lv0 -> metldr -> lv1ldr -> lv1 -> lv2ldr -> lv2 -> appldr -> vsh
    For all consoles which were not vulnerable to sigfail, HEN was released which exploited both the built-in web browser and LV2 kernel to enable both homebrew and run backups in GameOS. This still does not allow for OtherOS support or hypervisor modification to this day.

 
Last edited:
Btw @zecoxao please tell to MikeM64 to review the syscon pin/function names 2 and 3 in the documentation he published
https://github.com/MikeM64/Exploit-Writeups/blob/main/PS3/lv0ldr-spi-mitm/lv0ldr-spi-mitm.md
There is a mistmatch with the pinout in wiki
https://www.psdevwiki.com/ps3/Template:Syscon_pinout_LQFP_128_pins

Long story short... syscon have 8 pins dedicated to CELL, and only 2 of them are interrupts (CELL output--to-->syscon input), that 2 interrupts are named BE_INT/ATTENTION ...and... SYS_THERM_ALERT/THERMAL_OVERLOAD
It can be seen better in this other pinout (because all the CELL pins are found)
https://www.psdevwiki.com/ps3/Template:Syscon_pinout_LQFP_100_pins
Got my point ?... we have only 2 interupts from CELL ---to--->syscon and one of them is used fot the thermal alerts (not related with this hack)... so the only interrupt required in this hack is the other signal named BE_INT/ATTENTION

The probems are...
Syscon pin 3 (from sherwood pinout 128 pins) is named BE_INT in wiki, and the description tells is connected to CELL
But in mike64 documentation he is telling BE_INT is pin 2

Syscon pin 2 (from sherwood pinout 128 pins) is named SB_INT in wiki, and the description tells is connected to SouthBridge
But in mike64 documentation he is telling SB_INT is pin 3

Also, there are some sentences where it seems he is telling the delays of the communications are achieved using the SB_INT signal, but i think the name is wrong and is really the BE_INT/ATTENTION
This signal is used for many tasks, its meaning depends of the time frame when is triggered, if is triggered when the whole firmware is loaded and running the syscon "translates" it into an error code, but as far i understand, in this case at the lower steps of the bootchain CELL is using it to help in the syscon ping/pong communications

In other words... im not going to discusss his wiring because after reading the documnentation in github is obvious he was playing around with this since many time ago and he nows very well where he is soldering each wire :D
But it smells like either he swapped the function names... or we have some mistake in that sherwood pinout tables in wiki




*And btw... remember the CELL--> syscon interrupt named SYS_THERM_ALERT/THERMAL_OVERLOAD is not even mapped in the sherwoods 128 pins
This could be the wire mentioned in his documentation that is pointless... because yeah, is not related with this hack at all.... is just intended to shutdown the PS3 for safety reasons
 
Last edited:
Hi master @MikeM64, "The door is now open for the community to build on this work to create modchips and CFW on late-model slims and super-slims", does this mean late-model slims and super-slims have to install a special modchip or can use a special CFW?

Thanks.
 
Thanks for the edit @sandungas! I've updated the write up to reflect the correct pin numbers between SB_INT and BE_INT.

BE_INT isn't crucial to the exploit as it only seems to be used during bootup per the HIG.
SB_INT is the important one as it's used whenever Cell has a packet ready for syscon to read.
Ok, then the description of pin 2 and 3 in wiki is right, btw, as far i remember that 2 descriptions was added by you (or zerotolerance) many time ago, right ?

The detail from the writeup that is making me doubt is... the SB_INT is a southbridge output, and you are telling CELL uses it to indicate when a package is going to be sent, this means CELL needs to request Southbridge to send the SB_INT signal to syscon ?
I mean... the function of southbdridge doest seems neccesary

But if we consider the package control is made with the BE_INT it makes more sense, because is a direct connection in between CELL and syscon, and the southbridge is not involved in it
Coincidentially, yesterday i was talking about this signals with @RIP-Felix https://www.psx-place.com/threads/f...nd-error-reporting.30100/page-147#post-338342
Take a look at the posts he wrote of the "power control topology", he (and me) was focusing our attention in the syscon error codes, but he made a resume of how many different ways is used the BE_INT/ATTENTION signal, he even mentioned some stuff related with SPI initialization, etc...

Actually im sure @RIP-Felix could comment something about this
 
Ok, then the description of pin 2 and 3 in wiki is right, btw, as far i remember that 2 descriptions was added by you (or zerotolerance) many time ago, right ?

Yes, the wiki pinouts are correct.

I thought the same when I first started looking into this exploit. I would have thought that the signalling from CELL to Syscon would not have involved SB at all but it seems Sony decided otherwise for whatever reason. I've attached an archive containing the raw SPI captures from my logic analyzer (DSView required to view the files). You'll see that BE_INT follows the HIG per pages 34 and 35, named ATTENTION in that doc. After lv0ldr has started, ATTENTION ins't used during the boot sequence at all. From the first SPI transfer, SB_INT is the pin used. Weird, but that's Sony for you :confused3:
 

Attachments

Yes, the wiki pinouts are correct.

I thought the same when I first started looking into this exploit. I would have thought that the signalling from CELL to Syscon would not have involved SB at all but it seems Sony decided otherwise for whatever reason. I've attached an archive containing the raw SPI captures from my logic analyzer (DSView required to view the files). You'll see that BE_INT follows the HIG per pages 34 and 35, named ATTENTION in that doc. After lv0ldr has started, ATTENTION ins't used during the boot sequence at all. From the first SPI transfer, SB_INT is the pin used. Weird, but that's Sony for you :confused3:
Thx, i dont pretend to understand everything now but this solved my doubts, the "problem" is the concept of CELL using southbridge as some kind of "relay" to send the package control signal is not intuitive
It looks like they could do the same without the southbridge, but as you said, thats sony :D
Probably there is some reason why is made that way but thats another story, in the practise we dont care why is made that way
 
Hello. could you also explain to the "users" what it is doing?
i have some question
1 my console is 3.21 slim. i use sigfail for install the firts cfw/hfw?
2 this hack is for the famous/infamous metldr 2 console? slim/superslim ?
3 in the past I see a ps3 superpc with tons of console. why we not use all our console for do lot of mathematics calculations and defeat metldr2? with botnet ps3 homebrew?
4 if this guy reach the goal we need a new mod chip?
 
Ad1. All CFW users using it. ;]

Ad2/4. It is for all but of course this method mainly is for new boot loaders as we cannot mess with it by other ways (at least for now) like on older environments. This exploit open the doors for those CECH-25xx with new shit and all CECH-3xxx/4xxx to have CFW (currently confirmed only for tested CECH-25xx) but required hardware solution (like modchip which must be developed first of course, not to mention payloads etc.). Today consider it as orphan stage but awesome things can future brings for all those cursed models (CFW, QA flagging, ERK dumps, HDD/eMMC decryption outside PS3 etc. - not possible on HEN alone). It is absolutely fantastic news for all users of those models!

Ad3. I don't understand You. If You have in mind bruteforcing key needed to encrypt it, there is not enough time on this planet for doing that, using current PC's processing power.
 
Last edited:
Back
Top