PS3 BadWDSD HW Exploit - With new powerful qCFW for PS3 Slim & SuperSlim NOR models on the horizon

Status
Not open for further replies.
  • Update (Jan. 30) - @esc0rtd3w has released a new beta, while not the FINAL (yet) it is the first beta HEN with the qCFW installer.
  • Update (Jan. 29) - @aomsin2526 has released the first public version of qCFW for the BadWDSD exploit, now we still need PS3HEN 3.4.1 (FINAL) for the qCFW installer to utilize the qCFW release.
  • Update (Jan. 15) - @aomsin2526 has provided a new progress report, qCFW is nearing a public release. >>>Link
  • Update (Dec. 8) - @aomsin2526 (aka chattrapat_s / kafuu) has provided an update for the project, in the form of a "To-Do" list for the project, with some reported progress like "qCFW is done" see full post >>> Link
  • Update (Sept. 11) - New video demonstration and details "qCFW will be based on Evilnat PEX from now on. This means both CEX and DEX features will be available." >>> Link
  • Update (Sept. 1) - Another exciting progress update from @aomsin2526 >>> Link
  • Update (Aug. 30) - New details and progress from @aomsin2526>> Link
  • Update (July 8) - New Video (PS3 Superslim BadWDSD Booting Petitboot and FreeBSD 14.3 from Coldboot Test) / Readme updated w/ new details (see tab below or link) via aomsin2526
  • Update (June 30) - The qCFW files released in the wild are not complete (See Post) - They can pose a brick risk beware for advanced user's only.
  • Update (June 24) - Installer for qCFW is still being developed by @aomsin2526 (see link)
  • Update (June 18) - Added latest Readme (in first tab) from aomsin2526 & Also added a tutorial from WizWiki for the modchip installation
  • Update (June 11) - Latest Progress Report from @aomsin2526 (aka kafuu) (See Link) + Wiring Diagrams via @zecoxao (See Link)
  • Update (May 20) - New README released for BadWDSD exploit (See link)
  • Update (May 18) - New PS3HEN OPEN BETA Builds (from @esc0rtd3w) supports BadWDSD with new options for developer's. (See link )

.
Original Article (May 10) Since the disclosure and release of the BadHTAB (hardware/software) exploit we have seen a number of advancements in the PS3 community. We have seen in recent weeks with PS3HEN (w/ BadHTAB) now have the ability to run PS3 Linux & OverClocking on a nonCFW model's. Thanks to the efforts lead by @aomsin2526 (kafuu) and the BadHTAB release.

Since then we have seen continued progression from @aomsin2526 and other developer's like PS3HEN developer @esc0rtd3w among other's have now confirmed even the ability to downgrade a SuperSlim (NOR) models through this new exploit that has been "superseded by BadWDSD" (replacing BadHTAB). As it also looks like this exploit can replicate a CFW experience with a new qCFW that is being worked on. It does not seems likely, we will be able to downgrade to 3.55 and install a CFW PUP for SuperSlim models (though this theory needs tested to completly rule out) but rather inject the features like PS3HEN on boot, but alot more powerful then PS3HEN without the modchip.

sddefault (1).jpg


The details are still emegring and deveolopment continiues. We hope to get more details on qCFW as this project advances in both hardware and software tweaks, but it looks like something great is coming to the PS3,.. Kafuu (@aomsin2526) has setup a github with the new BadWDSD exploit, also issuing a warning of "Do Not Use Yet". Stay tuned in the coming days/weeks as this project matures. Below you can find some the answer's to questions asked and information that @esc0rtd3w has provided the forum, also @esc0rtd3w provided us with some preview video's of the exploit general use and also a downgrade of 4.82 to 4.40.


NOTICE: READ-ME BELOW IS OUTDATED
(see links in updates above)


Update: @aomsin2526 has provided additional detail about qCFW & new video.
  • via aomsin2526's Readme @ https://github.com/aomsin2526/BadWDSD

    .
    447522096-0287c52b-2bc0-4ac3-ac79-802790cfb90b.png
    This is a hardware modchip for Sony Playstation 3. By abusing a "feature" called WDSD serial register inside XDR ram. We can override what data to be written to memory through serial pin (32 bytes max). But not where and when. So if we do it while first boot loader (bootldr/lv0ldr) is decrypting lv0 (second boot loader) and writing decrypted data to memory. In reality, our code will be written to memory instead. If it hit address 0x100 (Reset vector), when PPU core starts our code will get executed instead. Gaining custom code execution very early on.
    It is patchable by Sony with new hardware by simply read and verify the data after write. But it is too late for them now since ps3 is no longer made.

    I avoid calling this modchip a "glitch" because XDR ram itself is working perfectly as intended. Every command we send to it is valid. WDSD register are for initialization purpose. But we "abuse" it to do benefit thing for us.

    This modchip replace and unrelated to previous BadHTAB exploit. While both are exploiting XDR ram. Method it uses is completely different.

    This modchip then allow full access to lv1 hypervisor and ability to run new variant of persistence CFW called qCFW. Unlock many features of CFW that HEN can't do. It can also used to recover console such as exit FSM, or updating consoles with dead BD/BT module. Downgrading also possible.

    With proper solder and wiring, this modchip is very stable (100% success rate) and should get you to XMB within 30 secs.


    This exploit contain three major components:
    • BadWDSD - Hardware modchip. Raspberry Pi Pico (RP2040) based. It handles WDSD register writing part. 32 bytes long jump code (Stage0.S) to address 0x2401F031000 will be pushed to memory by it.
    • Stagex.bin - Main software payload of this modchip. It will be stored at address 0x31000 (NOR flash) / 0x2401F031000 (MMIO)
    • BadWDSD-SW - Software utilites, was used for Stagex.bin/CoreOS.bin installation (now legacy). Now only used to boot OtherOS.

    Supported models
    • All 2500/3000 Slim.
    • 4000 Superslim with NOR flash.
    • 4000 Superslim with eMMC flash (12GB) is NOT supported.

    Operation Mode




    .This modchip supports two operation mode: OFW and qCFW

    OFW Mode
    • This is pretty much HEN + lv1 peek/poke. It is very safe since it doesn't modify any files. So you can just disable modchip and console will work just like before. But feature will be more limited than qCFW. And you will still need HEN to be useful. This mode is required to install qCFW so everyone must start here. You can downgrade/exit FSM/Overclock/OtherOS under this mode.

    Supports firmware 4.70 or later. You only need Stagex.bin to run this mode, since
    Stagex.bin stay even after firmware update, you only need to install it once.



    You can take Stagex.bin from any qCFW releases.​

    qCFW Mode
    • You can't install any existing CFW or any custom PUP, so new variant of CFW must be made. This variant will be called qCFW (quasi-CFW). It is persistence, stable and much more powerful than HEN/OFW Mode. It use fork of Cobra called Cobra-qCFW. Vanilla Cobra won't work here! Installation method also different.

    Once installed, modchip must be active at all times until you reinstall OFW again.At its peak, it should be capable of everything CFW can except one thing: Dump eid_root_key.

    It's not at its peak yet at current state, but it is powerful and stable enough for daily uses.​

    Quirks:
    • Cobra must be active at all times no matter what, if you lost it by some reason, it can be loaded from USB.
    • PS1 Emu can't be modified
    • VSH modules (self/sprx) at /dev_flash/vsh/module/ can't be modified, Don't modify these files or you will brick
    • If you turn on your console through PS button on your controller, it won't sync until you power cycle the controller by holding PS button until it turn off, then press it to turn on again. This is caused by load Cobra from USB.
    Stagex.bin and CoreOS.bin will be released in pair. So ensure that you install both of them and they're matched!

    qCFW (Petitboot)
    • Special variant of qCFW. In this version, lv2 kernel will be replaced with Petitboot bootloader.
    So you will be always boot into petitboot right after power on. It is for those who wants to use the console as permanent OtherOS machine. No internal HDD required even on NOR.

    To go back to OFW, use BANKSEL pin.​

  • Explanation of qCFW
    Question via @aldostools: I'm guessing that "qCFW" stands for "quasi-CFW". Since quasi- means "resembling," "having some, but not all of the features of,"

    via aomsin2526 (kafuu) 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.

    Question's & Answer's

    .Quotes from this thread
    Question via @NiQ - Any way we can decrypt metldr.2 with this?
    via esc0rtd3w said:
    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


    Question via @NiQ - I was really hoping that with such early peek/poke access we could maybe just NOP out the firmware signature check, allowing full CFW.
    via esc0rtd3w said:
    Kind of. Can't install by pup though. @aomsin2526 can explain better, what he calls qCFW.


    Downgrading a SuperSlim (NOR)
    via 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.


    Question via @GuilloteTesla- I think that SuperSlims can not go below minVerChk value as has always been the case, right?
    via esc0rtd3w said:
    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.


    Question via @chronoss - Just to know : why downgrade the SuperSlim?
    via 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.

    Question via @Rock77 - Is this possible on late slim models? If so, is the process of making it work the same as with super slim models?
    via GuilloteTesla said:
    As long as it has a NOR memory, it will work. But everything is still in diapers, and most of the work now is improving and getting the proper features working on non-CFW capable PS3s.

  • Demostration Video by @aomsin2526 (BadWDSD Modchip with qCFW )
    Demostrartion Video's by @esc0rtd3w

    BadWDSD Exploit PS3 NOR Superslim Test

    BadWDSD PS3 Superslim NOR Downgrade Firmware 4.82 to 4.40

    .Tutorial's (Potential Brick RIsk incomplete qCFW is being used)
    web-miniatutas-min-1280x640.png




.Project Links ("Do Not Use Yet")
PS3HEN (OPEN BETA Supporting BadWDWD)
Forum Discussion: @ psx-place.com/forum....
 
Last edited:
Correct Louis Garry, I also replaced the dev_blind files, I forgot to mention it... It is clear that if someone installs something without an official tutorial and on their own, they risk getting a brick and it is only their responsibility... Yesterday I did my tests under my own responsibility... Even so, I recommend waiting for the official tutorial and files from the official repository
 
Considering the architecture of the PS3's boot sequence, how does the BadWDSD exploit achieve early code execution by targeting the WDSD register during the bootldr → lv0 decryption phase, and what implications does this have for hypervisor-level access compared to traditional software-only exploits like HEN or WebKit-based chains?
 
Considering the architecture of the PS3's boot sequence, how does the BadWDSD exploit achieve early code execution by targeting the WDSD register during the bootldr → lv0 decryption phase, and what implications does this have for hypervisor-level access compared to traditional software-only exploits like HEN or WebKit-based chains?

Github readme should explain it already, WDSD is a register of ram to override data that is being written to PHYSICAL RAM, you just use it at right time (while bootldr is decrypting "OFW" lv0). So that you can replace lv0 code with your own code.

Hypervisor access give you "true" full access to your console. HEN isn't. It just give you just enough power to pirate games.

Kernel only exploit like HEN shouldn't be able to exist at all. But yet it is because Sony didn't do it right, appldr lv2 check is very effective on paper, but execution is bad so you can bypass it. Because appldr is only called and used though hvcall by lv2 itself, so you can just hook that call inside lv2, so we know exactly when check is run, unpatch kernel, wait a bit for check to pass, repatch.

If only they check it with random interval from inside lv1 itself which is still secure, HEN will dead PERMANENTLY WITH NO WORKAROUND EXCEPT HYPERVISOR ACCESS.

Yet they somehow don't so here you have HEN.

As unlikely as it sounds, Sony can still do this in future firmware if they want to. And if that happened, BadWDSD is the only thing that will save you.

Yeah I'm not surprised much, I'm Xperia user after all. Sony always do this, smart idea on paper, yet not use it to full potential.
 
Last edited:
Good morning, after installing the modchip, can it no longer be removed? I installed it, the modchip lit up and flashed as expected, and the console restarted in a loop. I removed the modchip, but now the console stays green for 50 seconds without displaying an image and then goes blackout.
 
Good morning, after installing the modchip, can it no longer be removed? I installed it, the modchip lit up and flashed as expected, and the console restarted in a loop. I removed the modchip, but now the console stays green for 50 seconds without displaying an image and then goes blackout.
It should boot normal if you are using ofw. Maybe you damaged something while soldering?
 
I did a clean install on my super slim. The rp2040 tiny fits nicely under the raised parts of the rf shield. Thank y'all for making cool stuff
Looks cool. May I know what rpi2040 pico board name do you use? I see it has flex cable slot instead of usb-c port.
UPD: found it, it's Waveshare RP2040‑Tiny‑Kit

Is that OK if I solder flashed RP2040 board on PS3 with HEN 4.86 installed and only then install PS3HEN OPEN BETA Supporting BadWDWD and do all the stuff?
 
Last edited by a moderator:
Is that OK if I solder flashed RP2040 board on PS3 with HEN 4.86 installed and only then install PS3HEN OPEN BETA Supporting BadWDWD and do all the stuff?
He is testing qCFW, which is not released yet. The payload needs manually built to even test. Lower versions other than 4.92 should work down to 4.76.

You can install latest hen beta on forums, but there is no qcfw options yet, only in private builds has minimal testing support, which is broken currently.

You can test BadWDSD options and lv1 stuff though.
 
Some progress update here, I actually stopped working on this for two months because of burnout and just come back to it recently.

One thing that annoys me is that the boot time is very long due to decryption/decompression.
The side effect of this is that you can't enter safe mode anymore, the console will shut off before lv2 is loaded. So if you want to downgrade you need to use RECOVERY pin to force the console to boot into recovery mode ("The system software cannot be run correctly.") which is quite annoying process.

So I ended up learning spu programming and then succeeded. Now boot time is much much faster. Now only around 5 secs slower than normal (no modchip). Previous was 20-30 secs.

And you can now downgrade easily by just enter safe mode normally then install lower fw on it.
No special steps needed.

With these new spu knowledge, I may try custom appldr again, previous attempt failed because my metldr knowledge / spu debug utils isn't enough. Now success chance is a bit higher (but not 100% of course).

If succeed, qCFW will be much more powerful than before, you can now replace all of dev_flash files from CFW, FSELF support (aka DEX fw on CEX console) will be possible, no more blackscreen (like HEN). It's pretty much 99% of evilnat now (minus metldr/erk dumping).
 
Je souhaite qu'un jour, nous puissions passer ces consoles PS3 Slim et Super-Slim en vrai CFW car là sera le summum plus ultra.
Merci à vous tous les DEVs ici présents.

I hope that one day we can turn these PS3 Slim and Super-Slim consoles into true CFW, because that would be the ultimate.
Thank you to all the DEVs here.

Algol "le papy".
 
I actually couldn't get into the recovery menu either because the mod chip ended up deactivating when I tried to go to the menu. But with this fix it's unbelievable
Some progress update here, I actually stopped working on this for two months because of burnout and just come back to it recently.

One thing that annoys me is that the boot time is very long due to decryption/decompression.
The side effect of this is that you can't enter safe mode anymore, the console will shut off before lv2 is loaded. So if you want to downgrade you need to use RECOVERY pin to force the console to boot into recovery mode ("The system software cannot be run correctly.") which is quite annoying process.

So I ended up learning spu programming and then succeeded. Now boot time is much much faster. Now only around 5 secs slower than normal (no modchip). Previous was 20-30 secs.

And you can now downgrade easily by just enter safe mode normally then install lower fw on it.
No special steps needed.

With these new spu knowledge, I may try custom appldr again, previous attempt failed because my metldr knowledge / spu debug utils isn't enough. Now success chance is a bit higher (but not 100% of course).

If succeed, qCFW will be much more powerful than before, you can now replace all of dev_flash files from CFW, FSELF support (aka DEX fw on CEX console) will be possible, no more blackscreen (like HEN). It's pretty much 99% of evilnat now (minus metldr/erk dumping).
 
Some progress update here, I actually stopped working on this for two months because of burnout and just come back to it recently.

One thing that annoys me is that the boot time is very long due to decryption/decompression.
The side effect of this is that you can't enter safe mode anymore, the console will shut off before lv2 is loaded. So if you want to downgrade you need to use RECOVERY pin to force the console to boot into recovery mode ("The system software cannot be run correctly.") which is quite annoying process.

So I ended up learning spu programming and then succeeded. Now boot time is much much faster. Now only around 5 secs slower than normal (no modchip). Previous was 20-30 secs.

And you can now downgrade easily by just enter safe mode normally then install lower fw on it.
No special steps needed.

With these new spu knowledge, I may try custom appldr again, previous attempt failed because my metldr knowledge / spu debug utils isn't enough. Now success chance is a bit higher (but not 100% of course).

If succeed, qCFW will be much more powerful than before, you can now replace all of dev_flash files from CFW, FSELF support (aka DEX fw on CEX console) will be possible, no more blackscreen (like HEN). It's pretty much 99% of evilnat now (minus metldr/erk dumping).
Big news indeed qCFW will turn superslim ps3 into a powerhouse
 
Status
Not open for further replies.

Similar threads

Featured content

Trending content

Back
Top