So we know that we can't dump metldr.2 and lv0ldr.2 from software, and dumping lv0ldr.2 from hardware seems like it's not possible as well (Zer0Tolerance, me, M4j0r and MikeM64 have been trying but it never activates the TOCTOU portion of the exploit, only the NVS read one)
so, what if we just use geohot's hardware lv1 exploit together with HEN to achieve more privileges (like lv1 peek and poke) and load linux?
We know this exploit is unpatchable on all models, since it's a hardware design flaw and not a software one, even more that it's caused by introducing a glitch in the PS3's RAM data lines. We also know that HEN allows for almost all lv1 hvcalls, including root ones, so maybe we can use HEN with dangling htab pointer glitch to get both lv2+lv1 code exec? what do you guys think?
His approach is clever and is known as a "glitching attack". This kind of hardware attack involves sending a carefully-timed voltage pulse in order to cause the hardware to misbehave in some useful way. It has long been used by smart card hackers to unlock cards. Typically, hackers would time the pulse to target a loop termination condition, causing a loop to continue forever and dump contents of the secret ROM to an accessible bus. The clock line is often glitched but some data lines are also a useful target. The pulse timing does not always have to be precise since hardware is designed to tolerate some out-of-spec conditions and the attack can usually be repeated many times until it succeeds.
George connected an FPGA to a single line on his PS3's memory bus. He programmed the chip with very simple logic: send a 40 ns pulse via the output pin when triggered by a pushbutton. This can be done with a few lines of Verilog. While the length of the pulse is relatively short (but still about 100 memory clock cycles of the PS3), the triggering is extremely imprecise. However, he used software to setup the RAM to give a higher likelihood of success than it would first appear.
while you did fail once again to dump metldr2, did you really managed to at least dump lv1? @zecoxao
I'm seeing some reports of LV1 dumps for 4.x minver on ps3dev wiki
while you did fail once again to dump metldr2, did you really managed to at least dump lv1? @zecoxao
I'm seeing some reports of LV1 dumps for 4.x minver on ps3dev wiki
Raspberry Pico Used
5-10% Success Rate
Works on 4.84 CEX OFW + HEN
First lv1 dumped from a 4.84 OFW
CECHH PS3 Used but should work on all ps3 models
LV1 Peek and Poke Implemented on exploit
Proof of Concept
Need 0.1mm magnet wire or it won't boot
Same exploit as geohot's dangling htab glitch
Required pins: RQ7 RQ8 from CELL
Raspberry Pico Used
5-10% Success Rate
Works on 4.84 CEX OFW + HEN
First lv1 dumped from a 4.84 OFW
CECHH PS3 Used but should work on all ps3 models
LV1 Peek and Poke Implemented on exploit
Proof of Concept
Need 0.1mm magnet wire or it won't boot
Same exploit as geohot's dangling htab glitch
Required pins: RQ7 RQ8 from CELL
News like this fills one's hearth with joy
Also, it would seem from the repository that he successfully triggered the exploit on a SuperSlim... man how great this sounds
So from the latest commit "load lv2 kernel" it would seem that LV2 loading can be hijacked, my question would be now for the developers versed in the PS3 scene: Would this allow loading any unsigned kernel from arbitrary paths?
Like have multiple kernel variants on HDD/USB (but derived from the same OFW version) and choose which one to load?
Or one more interesting thing to implement would be to patch at boot the RSX/VRAM frequencies in LV1, and since there is the pico wireless version, modify the values from an exposed API and trigger a reboot?
BadHTAB
.This is a hardware-software based hypervisor (lv1) exploit for Sony Playstation 3. Initially invented by geohot for linux. If you pull certain RAM signal to ground for a short time, write may be skipped. If you do it while the hypervisor is invalidating a HTAB entry, it may stay valid. Giving us a full read-write permission of a small region of memory at certain location on memory. This location may be later used by the hypervisor itself, allow us to manipulate it and then later gain full access to all of memory.
This exploit has been now ported to GameOS environment, working on every models with PS3HEN. Allows full hypervisor access to non-CFW consoles for the first time ever. Gaining some of CFW-only features on non-CFW consoles.
This exploit contain two major components:
BadHTAB - Software side of the exploit. released as a pkg files running on the PS3
ps3pulldown2 - Hardware side of the exploit. Raspberry Pi Pico (RP2040) based. Communicate with PS3 through USB port
Unlike original linux version, GameOS have much more smaller glitch window than linux. This means automation is a must to get successful glitch while remain stable.
Even with that, success rate still remain low (5-10%). This means this is not for daily driver, it is for user with skill and patience only.
This exploit requires soldering, soldering isn't difficult part. Getting it to boot and stable after solder is.
This exploit is based from xorloser's implementation called Xorhack.
This exploit is not persistent and must be run again after reboot.
Supports firmware 4.70 or later Features
.After successful run, these things will be possible:
hvcall 114 everywhere allow mapping of any memory area without restrictions
New lv1_peek/poke/exec hvcall added allow lv1 peek(34)/poke(35)/exec(36) through hvcall. See below
Dumping of lv1 memory dump lv1 memory to file
Boot custom lv2_kernel.fself allow loading of ANY lv2_kernel as long as it is in fself format
Boot OtherOS allow booting of petitboot bootloader, regain ability to use OtherOS and linux
Note: If you use boot lv2/OtherOS features, New hvcall will be removed. However hvcall 114 everywhere remains. So you can use that to reinstall it again. New hvcalls
.
This guide will focused on superslim only.
These resistor can be found in following ways:
Service manual
Desolder the ram then trace it manually
Now, time to install:
Solder one wire to RQ resistor of each side. Example: first wire into RQ8 pin of left side, then second wire into RQ7 pin of right side
Solder other side of the wire into GP15/16 (bottommost) of pico: Example: first wire into GP15, then second wire into GP16
Assemble the console back, then ensure that it boot and stable
Install .uf2 file by holding BOOTSEL button while plugging your pico into your PC. New drive will appear then you can copy your .uf2 file into the drive.
Installation done
You will likely to find that your console doesn't boot, this is the difficult part. Here is some tips:
Do not let wire touch ground, motherboard or any metal. Keep wire float in the air as much as you can
Plug your HDD into the console, then power it on while your console is naked to rapid test if your console boots (HDD light should blink)
Superslim power button are very fragile, they will likely to fall off after a while. I recommends you to use screwdriver to short the button pin to ground to power it on instead.
In the end, your setup may likely to end up like this:
Installation (Software)
Now, software time.
First you start by install BadHTAB pkg file into your PS3 from Releases page.
Then, config time: Dump lv1
Create empty file and place it at /dev_hdd0/BadHTAB_doDumpLv1.txt Or /dev_hdd0/BadHTAB_doDumpLv1_240M.txt if you want to dump 240MB of memory instead of 16MB.
Run the exploit
Boot lv2_kernel.fself
You can convert your lv2_kernel.self to .fself like this:
Decrypt it to .elf first
Use make_fself.exe from Sony SDK to resign it to fself using this command: make_fself.exe -u lv2_kernel.elf lv2_kernel.fself
Then:
Create empty file and place it at /dev_hdd0/BadHTAB_doLoadLv2Kernel_Fself.txt
Place your lv2_kernel.fself file at /dev_flash/sys/lv2_kernel.fself. Tips: You can write to this through /dev_blind/. You can enable it in webman MOD. If your /dev_flash/ are full you can delete ps1emu/ps2emu/pspemu directory to clear space.
Shutdown your console gracefully.
Run the exploit
Boot OtherOS
Create empty file and place it at /dev_hdd0/BadHTAB_doOtherOS.txt
Place dtbImage.ps3.fself file at /dev_flash/sys/dtbImage.ps3.fself. Tips: You can write to this through /dev_blind/. You can enable it in webman MOD. If your /dev_flash/ are full you can delete ps1emu/ps2emu/pspemu directory to clear space.
Shutdown your console gracefully.
Run the exploit
Run the exploit
.Now it is time to run the exploit. This exploit uses beep as status signal.
Log will be stored at /dev_hdd0/BadHTAB.txt
Plug your pico into your PS3 USB port.
Run BadHTAB
You will hear one short triple beep, this mean exploit started.
Then glitching process will start, led of your pico will turn on and blink briefly. You will hear beep few times every seconds.
If beep simply stop or console shut off, glitching fails. Reboot and try again. This process may take hours to succeed.
If you hear short triple beep, short wait, then triple beep again multiple times. This mean glitch succeeded.
It will patch lv1, install hvcall then do what you configured at previous section.
If "Boot lv2/OtherOS" are used, it should happen now.
If "Boot lv2/OtherOS" aren't used, exploit will exit. You will hear 5 seconds long beep then stop.
Actually, this exploit can be "patched" very easily by software.
If sony just implement some sort of "shadow memory" aka second copy of htab buffer elsewhere then compare it some time after. Panic if mismatch. Maybe shuffle/delay write pattern too. This simple trick will made this exploit useless.
We are lucky that sony didn't bother to "patch" it instead of just simply remove OtherOS entirely.
