PS3 PS3HEN w/ Linux & Overclocking Support? BadHTAB A hardware-software based hypervisor (lv1) exploit

UPDATE 4 - (May 2 / June 9): @esc0rtd3w has created a fork of the BadHTAB Exploit with some changes such as an "Automatic reboot if glitch crashes ps3" feature among other changes to make it easier for testing the new exploit. (June 9) - ReadMe Updated in link below

UPDATE 2 & 3: Now, not only Linux but also Overclocking on PS3HEN is now possible w/ BadHTAB exploit & PS3HEN (beta builds) that are currently supporting the exploit. This is still considered an experimental exploit & features so Use at your Risk. (See update tabs/links) for additional details and information on these advancements for the PlayStation 3.
.Original Article: Could Linux Support on PS3HEN be a reality with new exploit? Yes, and also other features but its not going to be for everyone. There is a new Proof of Concept released for the PS3 that has been implemented by Kafuu (@aomsin2526) using Geohot's old htab glitch on PS3HEN. Developer @zecoxao first started posting about this idea and the concept in Jan. of 2023 here in the forum's and has shared various thoughts and progress, with the latest progress being Kafuu's implementation.

BadHTAB is a hardware-software based hypervisor (lv1) exploit, The exploit has a very low success rate of (5-10%) as GameOS has a much smaller "glitch window". As the readme states this not meant "for daily driver, it is for user's with skill and patience only.". See more details in the snippet below from the readme & the links provided.(update, @bguerville has provided some additional info in Post #2 below)

428664953-20fc9f39-b23a-43f3-9067-c0c686b4bc2b.jpg

About (portion of ReadMe) Update - petitboot kexec patched Update 2: Beta PS3HEN (Official) Update Update 3 - Overclocking/UnderClocking Update 4: esc0rtd3w forks project
  • 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.

  • Original kexec for ps3 can't handle elf that have loadable segment more than one (such as seperate code and data segment) Causing "Overlapping memory segments" or "sort_segments failed" error.
    Code: 
    readelf -l kernel-bad

Elf file type is DYN (Shared object file)
Entry point 0x148a220
There are 4 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000010000 0x0000000000100000 0x0000000000100000
                 0x0000000000fefb1d 0x0000000000fefb1d  R E    0x10000
  LOAD           0x0000000001000000 0x00000000010f0000 0x00000000010f0000
                 0x0000000000451748 0x000000000082a4c0  RW     0x10000
  DYNAMIC        0x0000000001451648 0x0000000001541648 0x0000000001541648
                 0x0000000000000100 0x0000000000000100  RW     0x8
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x8

readelf -l kernel-good

Elf file type is DYN (Shared object file)
Entry point 0x147c498
There are 3 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000010000 0x0000000000100000 0x0000000000100000
                 0x00000000014335e0 0x000000000180edc0  RWE    0x10000
  DYNAMIC        0x00000000014434e0 0x00000000015334e0 0x00000000015334e0
                 0x0000000000000100 0x0000000000000100  RW     0x8
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x8


    By simply merge those segment into one at load time it is now possible to load such elf.
    One of iso that affected is FreeBSD-12.2-RELEASE and FreeBSD-12.4-RELEASE.
    Click to expand...

  • via esc0rtd3w
    .3.4.1 Open Beta Test #11 (04-01-2025): (4.80 - 4.92 CEX / 4.82 & 4.84 DEX)
    • Added minimal support for BadHTAB LV1 Exploit
    • Enabled LV1 Peek(11)/Poke(9) in PS3HEN payload (will change in the future to be toggled)
    • Added options to HFW Tools (xai) menu for easier testing LV1 exploit glitch.

    Huge thanks to @aomsin2526 for his excellent work with getting this working on newer firmware
    .3.4.1 Open Beta Test #12 (04-12-2025): (4.80 - 4.92 CEX / 4.82 & 4.84 DEX)

    New Changes:
    - Fixed lv1_peek and lv1_peek32 notify values
    - Added 32-bit and 64-bit lv1 peek and poke options to xai

    Older Changes:
    - Added minimal support for BadHTAB LV1 Exploit
    - Enabled LV1 Peek(11)/Poke(9) in PS3HEN payload (will change in the future to be toggled)
    - Added options to HFW Tools (xai) menu for easier testing LV1 exploit glitch

    Huge thanks to @aomsin2526 for his excellent work with getting this working on newer firmware :triumphant:

    Please see this thread for info on using the exploit: https://www.psx-place.com/threads/p...-software-based-hypervisor-lv1-exploit.47282/

  • 3.4.1 Open Beta Test #13 (04-19-2025): (4.80 - 4.92 CEX / 4.82 & 4.84 DEX)

    The overclock and underclock settings are split into matched, core, and memory. They are here for testing purposes only currently. You can set matched speeds (100/100, 500/500, 750/750, etc), core speeds, and memory speeds from 100MHz to 1000Mhz. These are mostly untested, but i have tried some. The 1000/1000 crashed my superslim, but more testing is needed and tweaks to the speed options will be refined in the next beta.

    The HV Dump options are taken from the talk page about hypervisor reverse engineering and some of them will crash the ps3. The accuracy may not be 100% for offsets in xai code. Needs more testing and is just for experimental purposes currently.

    New Changes:
    • - Added support for over/underclocking RSX core and memory clock in HFW Settings (xai) (thanks to @aomsin2526 for his work discovering this)
    • - Added HV Dump menu in HFW Settings (xai) to dump mapped areas documented at psdevwiki

    Older Changes:
    • - Added minimal support for BadHTAB LV1 Exploit
    • - Enabled LV1 Peek(11)/Poke(9) in PS3HEN payload (will change in the future to be toggled)
    • - Added options to HFW Tools (xai) menu for easier testing LV1 exploit glitch
    • - Fixed lv1_peek and lv1_peek32 notify values
    • - Added 32-bit and 64-bit lv1 peek and poke options to xai

    Huge thanks to @aomsin2526 for his excellent work with getting this glitch working on newer firmware :triumphant:

    Please see this thread for info on using the exploit: https://www.psx-place.com/threads/p...-software-based-hypervisor-lv1-exploit.47282/

    upload_2025-4-19_11-36-53.png upload_2025-4-19_11-34-5.png
    upload_2025-4-19_11-34-58.png​


  • Update 4: May 2nd ​
    See comment below (link) by @esc0rtd3w with new progress on his fork of the project
    IMG_20250503_204518_278.jpg


Forum Discussion & Release's

Project Links
 
Last edited:
Click to expand...
bguerville
Just for info.

The trigger success rate is still very low at the moment ie many boots, many crashes before it may glitch successfully and boot GameOS/Linux, moreover the current hardware setup is still being tweaked and tuned up daily.

It's only the start of that R&D work, the success rate via hardware might yet improve drastically.

There might also eventually be a way to abuse the htab stuff from LV2 itself using HEN without hardware setup at all to exploit lv1 in a similar way.
Much testing needs to be done also on that matter imho.

Things are looking better and better everyday one way or another!!! [emoji6]
And Linux will help test and hack a lot of things on metldr.2 consoles...

Everyone involved in the group is doing a wonderful job so far, so kudos to all involved.. [emoji3590]
 
Last edited:
dracinn
Can't say I understand this stuff but could this lead to OtherOS support for slims on CFW that currently don't support it?
 
RinMaru90
all we need is software underclocking. not sure why its not possible if OC is. Idk I was just told on yt it was impossible.
 
esc0rtd3w
I forked the original project and made some changes to pico code for "easier" testing. Currently no changes to ps3 code.

I will update documentation soon.

Changes include:
  • Automatic reboot if glitch crashes ps3
  • Enabled UART0 for pico
  • Enabled UART1 for ps3 sb_uart input
  • Monitoring PSU standby
  • Monitoring Power ribbon connector
  • 4 status LEDs
The glitch is much easier to do over and over again if it crashes, and it will ;), without having to pull power cord or flip switch on power strip.

Supports automatically rebooting when it detects errors. This requires sb_tx from ps3 and soldering the PSU 5v "always on" to the vsys on the pico. This way the pico will stay on when ps3 shuts off. I currently use a small toggle slide switch for that.

Monitors ps3 sb_uart for messages to control pico behavior.

Many other changes included.

There are still a few bugs to iron out, as far as sometimes the ps3 still gets into a crash condition where the pico cannot automatically recover and you must manually power cycle the ps3.

Wires will need soldered to appropriate locations on ps3 and pico.

UART will also need to be enabled in SYSCON.

Mullion SYSCONs starting with CXR713 = w 7202 02
Mullion SYSCON CXR713120-203GB = w 4202 02
Mullion SYSCONs starting with CXR714 = w 4202 02
Sherwood SYSCON = w 1202 02

*** DO NOT ENABLE THE EXTRA UART OUTPUTS OR GLITCH WILL CRASH WHEN RETURNING TO XMB ***

PS3 Resistor Connections for glitch (only one required)
pulldown1_pin_id (RQ7) -> GPIO15
pulldown2_pin_id (RQ8) -> GPIO16

PS3 Monitoring pins
pwr_on_ribbon_pin (PS3 ribbon connector 3.3v) -> GPIO10
sb_uart_rx_pin (PS3 SB_TX) -> GPIO5
psu_standby_pin (PSU Standby Pin 3) -> GPIO18
Optional: hdd_activity_pin (PS3 HDD LED Anode) -> GPIO22

Pico status pins
error_led_pin (Red) -> GPIO6
yellow_led_pin (Yellow) -> GPIO2
green_led_pin (Green) -> GPIO21
blue_led_pin (Blue) -> GPIO27

Pinout for pico and PS3
IMG_20250505_025623_240.jpg


https://github.com/esc0rtd3w/BadHTAB

Successful glitch
IMG_20250503_204518_278.jpg


Failed glitch attempt
IMG_20250503_205245_680.jpg


Test setups. Yours can look prettier :-p

Test NOR Superslim (1 wire glitch)
IMG_20250503_210509_933.jpg


Test eMMC Superslim (2 wire glitch)
IMG_20250503_211623_271.jpg


Note: The green and blue wires are reversed because I didn't pay attention when doing the second one, and originally used green as ground, and blue as PSU standby, but on other one I used blue as ground and green as PSU standby. It makes no difference, except if following standards, in which case the green to ground would be appropriate.
 
Last edited:
N
esc0rtd3w said:
Not likely. This has now been superseded by BadWDSD, for NOR. Even with BadWDSD having lv0 privileges at boot, it is not just as easy as that, from what I understand from much smarter people than me in the chat :)

I think moving forward, there is now a path to actually accomplishing that though now, thanks to @aomsin2526
Click to expand...
Sorry, I'm dumb I thought we were talking about BadWDSD.
Somehow I was really hoping that with such early peek/poke access we could maybe just NOP out the firmware signature check, allowing full CFW.
 
You must log in or register to reply here.

Similar threads

Featured content

Trending content

Latest posts

Back
Top