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...
esc0rtd3w
Downgrading works with BadWDSD, and its easier than normal once pico modchip is installed anyways :)

I successfully downgraded my NOR superslim last night from 4.91 to 4.40, and I think @aomsin2526 downgraded his from 4.92 to 4.82.

Currently, from my understanding is this will only work with NOR and not eMMC though.

Another shoutout to kafuu for his awesome work with all of this

We will need a BadWDSD thread soon enough.
 
GuilloteTesla
esc0rtd3w said:
Downgrading works with BadWDSD, and its easier than normal once pico modchip is installed anyways :)

I successfully downgraded my NOR superslim last night from 4.91 to 4.40, and I think @aomsin2526 downgraded his from 4.92 to 4.82.

Currently, from my understanding is this will only work with NOR and not eMMC though.

Another shoutout to kafuu for his awesome work with all of this

We will need a BadWDSD thread soon enough.
Click to expand...

Awesome news!. I think that SuperSlims can not go below minVerChk value as has always been the case, right?.
 
esc0rtd3w
GuilloteTesla said:
Awesome news!. I think that SuperSlims can not go below minVerChk value as has always been the case, right?.
Click to expand...
I think we can with exploit, as kafuu set version to 4.00 in recovery with patches.

We talked about it a bit, but have not yet confirmed, but most likely will result in a brick if lower pup installed. But it could also not install it. If it did install it and it was bricked, idk if exploit would be able to recover it or not. Might need hardware flasher. I think we would have to try it to confirm.
 
aldostools
esc0rtd3w said:
Kind of. Can't install by pup though. @aomsin2526 can explain better, what he calls qCFW.
Click to expand...

I'm guessing that "qCFW" stands for "quasi-CFW".

Since quasi- means "resembling," "having some, but not all of the features of,"

chronoss said:
Just to know : why downgrade the Super Slim if we can install a CFW in the future with this exploit ?
Click to expand...

Downgrade is not a commonly used feature. However there are situations where a new firmware release make the payloads unstable due a feature removal or unexpected changes in system files like happened in 4.89. Until the issues are fixed by the devs some CFW users preferred to go back to a previous stable version (e.g. Rebug).

Downgrade is also helpful for developers that want to test their software in various firmware versions.
 
A
aldostools said:
I'm guessing that "qCFW" stands for "quasi-CFW".

Since quasi- means "resembling," "having some, but not all of the features of,"
Click to expand...

Correct. My end goal of qCFW would be load cobra from coldboot. Unfortunately, appldr must be patched to run custom lv2. Just found that out. This mean this feature never works on BadHTAB because if you change lv2 code even just one byte it won't boot. So expect long time for it.

It if goes well, i plan to based it from evilnat (lv2/vsh part).

At its peak, it should be able to do ALL of CFW features except one thing: Dumping eid_root_key.

Just different installation method, you can't install custom pup normal way (and it's a good thing because if you install existing CFW you will brick.)

Also this is hardware mod only, you just run software installer one time (and maybe when installing/upgrading qCFW). Then it is permanent. if you don't mess with fw anymore it will stay with you forever.

The loaders still secure, so on CoreOS, lv0(for bootldr) and lv1.self(for lv1ldr to init ATA) must be untouched. But then we just add .diff files to it to apply patches on memory after loaded at boot (also can whole file not diff but its too big). So there is no different from CFW in end results.

Modchip also supports OFW, in this case you will get only downgrading + lv1 peek/poke through hvcall 114. And also slower boot (30 secs). But it is more safe because you don't touch CoreOS. So you can always recover.
 
Last edited:
chronoss
aldostools said:
Downgrade is not a commonly used feature. However there are situations where a new firmware release make the payloads unstable due a feature removal or unexpected changes in system files like happened in 4.89. Until the issues are fixed by the devs some CFW users preferred to go back to a previous stable version (e.g. Rebug).

Downgrade is also helpful for developers that want to test their software in various firmware versions.
Click to expand...
Ok i see, thanks a lot !!!
 
Jaxpet1233
aomsin2526 said:
Correct. My end goal of qCFW would be load cobra from coldboot. Unfortunately, appldr must be patched to run custom lv2. Just found that out. This mean this feature never works on BadHTAB because if you change lv2 code even just one byte it won't boot. So expect long time for it.

It if goes well, i plan to based it from evilnat (lv2/vsh part).

At its peak, it should be able to do ALL of CFW features except one thing: Dumping eid_root_key.

Just different installation method, you can't install custom pup normal way (and it's a good thing because if you install existing CFW you will brick.)

Also this is hardware mod only, you just run software installer one time (and maybe when installing/upgrading qCFW). Then it is permanent. if you don't mess with fw anymore it will stay with you forever.

The loaders still secure, so on CoreOS, lv0(for bootldr) and lv1.self(for lv1ldr to init ATA) must be untouched. But then we just add .diff files to it to apply patches on memory after loaded at boot (also can whole file not diff but its too big). So there is no different from CFW in end results.

Modchip also supports OFW, in this case you will get only downgrading + lv1 peek/poke through hvcall 114. And also slower boot (30 secs). But it is more safe because you don't touch CoreOS. So you can always recover.
Click to expand...
Would there be a way to get this working without modchip or thats not on your agenda.
 
You must log in or register to reply here.

Similar threads

Featured content

Trending content

Latest posts

Back
Top