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)

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.
  
• 
  
  

  
  image via aldostools
  

  ---

  .https://github.com/aomsin2526/ps3-petitboot-kexec-patched​

  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.
  

  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.

• 
  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
  
  
  

  

  
  
  
  See Link for Additional Details & BETA files
  https://www.psx-place.com/threads/p...advanced-users-only.37363/page-11#post-411167
  ​

  ---

  .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
  
  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
  
  Please see this thread for info on using the exploit: https://www.psx-place.com/threads/p...-software-based-hypervisor-lv1-exploit.47282/
  
  
  
  ​
  
  
• 
  
  Update 4: May 2nd ​
  See comment below (link) by @esc0rtd3w with new progress on his fork of the project
  
  • https://www.psx-place.com/threads/p...sed-hypervisor-lv1-exploit.47282/#post-411901
  
  
  

Forum Discussion & Release's

• Original Discussion started from @zecoxao
  • (update) Fork of BadHTAB project (via @esc0rtd3w)
• PS3HEN Open Beta Builds (Testing & Supporting BadHTAB Exploit)

Project Links

• https://github.com/aomsin2526/BadHTAB
• https://github.com/aomsin2526/BadHTAB/releases
• https://github.com/aomsin2526/ps3-petitboot-kexec-patched
• https://github.com/aomsin2526/ps3vram-freebsd
• https://github.com/esc0rtd3w/BadHTAB (Fork)
  • Note: updated Readme in link (June '25)

 

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

 

By this new exploit, is it finally possible to remarry bd drive on super slim models?

 

By this new exploit, is it finally possible to remarry bd drive on super slim models?

There's no need. On super-slims (as well as 25xx and 30xx slims) the Blu-Ray drive isn't married at all to begin with. You can switch it with any drive of the same model and it will work without any extra steps.

 

There's no need. On super-slims (as well as 25xx and 30xx slims) the Blu-Ray drive isn't married at all to begin with. You can switch it with any drive of the same model and it will work without any extra steps.

This is because the bd drive controller on those models is on the motherboard. But my intention is to replace the bd drive with one from a fat model, which the drive controller is involved with the drive itself. Those older bd drives output SATA signal to the console. So I want to connect it to the SATA pins on my super slim. Therefore, it needs to be remarried l believe.

 

This is because the bd drive controller on those models is on the motherboard. But my intention is to replace the bd drive with one from a fat model, which the drive controller is involved with the drive itself. Those older bd drives output SATA signal to the console. So I want to connect it to the SATA pins on my super slim. Therefore, it needs to be remarried l believe.

Fat PS3 BD drives are not compatible with Slim and SuperSlim models.

https://www.psdevwiki.com/ps3/Bluray_Drive

 

Fat PS3 BD drives are not compatible with Slim and SuperSlim models.

https://www.psdevwiki.com/ps3/Bluray_Drive

Of course, they're not.

 

Of course, they're not.

Then why the question?. It doesn't make sense, you already know the answer.

But my intention is to replace the bd drive with one from a fat model, which the drive controller is involved with the drive itself. Those older bd drives output SATA signal to the console. So I want to connect it to the SATA pins on my super slim.

 

Then why the question?. It doesn't make sense, you already know the answer.

Well, if it was a regular work of replacing, then you were right.
The question, as I've explained in my first post, is to connect SATA signals of a bd drive from a fat ps3 to an SS SATA port.
The SATA port on the SS mobo is connected to the drive controller using 4 bypass capacitors. So there ARE electrical compatibility. I can power the fat drive externally and even control the eject mechanism using a micro controller. But the question that does make sense is that is it gonna work? Is remarriage the only thing left to do to make a fat bd drive work on an SS model?
It's easy to simply say they're not compatible. But have someone ever tested it? Most likely NO.
How do experts think?

 

I doubt anyone has tried it, honestly. Not sure how feasible it actually is, but I wouldn't rule it out completely.

 

So, back to the first question.
Is this new exploit going to make SS models remarriable?

 

So, back to the first question.
Is this new exploit going to make SS models remarriable?

It will give you access to do that functionality afaik, yes. But again, for 3k and ss the bd controller is on motherboard. So if anything, it would take a lot of reverse engineering, hardware modifications most likely, and code modifications to even confirm or deny that its possible to do what you want.

 

Well, if it was a regular work of replacing, then you were right.
The question, as I've explained in my first post, is to connect SATA signals of a bd drive from a fat ps3 to an SS SATA port.
The SATA port on the SS mobo is connected to the drive controller using 4 bypass capacitors. So there ARE electrical compatibility. I can power the fat drive externally and even control the eject mechanism using a micro controller. But the question that does make sense is that is it gonna work? Is remarriage the only thing left to do to make a fat bd drive work on an SS model?
It's easy to simply say they're not compatible. But have someone ever tested it? Most likely NO.
How do experts think?

That's what I've said before, Fat PS3 BD drives are not compatible with Super Slims because the hardware was never designed to be fully compatible among all the PS3 revisions.

Leaving the BD daughterboard aside and assuming that the Super Slim integrated controller works the same with every BD drive, the connector pin-out varies with every revision, as stated on the Dev Wiki: https://www.psdevwiki.com/ps3/Bluray_Drive#BD_Drive_Connectors

If you sort that out, remarrying is not necessary because the controller is already binded to the motherboard on the Slims and Super Slims.

But again, it's not only a matter of pins, connectors and currents. Each BD controller only knows how to interact with the models it was developed for.

 

That's what I've said before, Fat PS3 BD drives are not compatible with Super Slims because the hardware was never designed to be fully compatible among all the PS3 revisions.

Leaving the BD daughterboard aside and assuming that the Super Slim integrated controller works the same with every BD drive, the connector pin-out varies with every revision, as stated on the Dev Wiki: https://www.psdevwiki.com/ps3/Bluray_Drive#BD_Drive_Connectors

If you sort that out, remarrying is not necessary because the controller is already binded to the motherboard on the Slims and Super Slims.

But again, it's not only a matter of pins, connectors and currents. Each BD controller only knows how to interact with the models it was developed for.

Remarry should only be for a specific model like superslim blu rays that come in separate, same goes for slim, and fat models. makes me curious about putting a hackable slim blu ray inside a CECH 3000 for remarry though.