Team REBUG just recently released 4.84 REBUG LITE Edition just the other day. Now,since that time the team has aquired all the resources needed for the creation of 4.84.1 REBUG REX Custom firmware . Now that the testing phase has concluded, the team has now released 4.84 REX version of their famed Custom Firmware for the PS3. What makes REX different from LITE is that Lite is made of only CEX (retail) firmware and REX contains both retail firmware and then also contains debug (DEX) firmware elements as well. To create this powerful hybrid custom firmware. Which expands the feature list over any other CFW type with the included REBUG Toolbox (requires pkg installation),

The updated Cobra payload of v8.00/1 that made its recent debut in habib's 4.84 Starbuged CFW has also been bundled with this latest version of REBUG REX. One of the highlights of the version 8.0 progression of the Cobra payload has been a new feature allowing Kernel payload support via plugin developed by habib, The update to Cobra also brought a number of new improvements besides that lone feature, other feature consist of a much faster boot time on start up as in Cobra 8.00+ stage 1 has been removed. Then also in this version of REX you should note COBRA is ENABLED by default where as in previous versions of REX it has not been and required a toggled "ON" via the REBUG Toolbox, that is no more, in this version its enabled "out of the box" and ready to go

***ISO rips are required to get 100% support, for ex) after disabling syscalls, games like Call of Duty will not be able to play unless you use ISO rips, please DO NOT expect everything to be fully functional when you are disabling the built-in features from COBRA. Folder rips are NOT compatible with PSNPatch’s stealth mode due to its ability to disable COBRA’s disc-less feature for folder JB rips****

PS3MAPI support, allows you to attach process on both CEX/DEX via its own API app.

Backup Protection Removal,Add full PS3 Backup support on all multiMAN/sMAN/webMAN,IRIS manager forks and Managunz.

Allow modification on Syscall 6/7/8/9/10/11/15.

Burned/Burnt optical media support for PS1/PS3 Games on All models

Homebrew blocker– blocks homebrew access while Syscalls are disabled

new in 8.00 Run payload with Kernel privileges - Added option to run payload with kernel privileges like ps vita skprx. this is a big thing! one can make hooks, printf to socat, do whatever they feel like they need to do. at the current time only one payload is supported at a time. in the future i might increase this

New in 8.01 Added support for dynamic memory payloads, 5 of them can be started from "/dev_hdd0/boot_plugins_kernel.txt"

SET GAMEOS BOOT FLAG: Sets the GameOS boot flag. Use this if your PS3 is having trouble booting PS2 titles after running OtherOS or is accidentally sending you back to OtherOS when trying to enter recovery mode.

CREATE PACKAGES FOLDER ON PS3: Create /dev_hdd0/packages folder or your PS3 to be used with Package Manager.

EXPORT HYPERVISOR LV1 MEMORY: Save LV1 memory to dev_usb000 or dev_usb006 or dev_hdd0 if usb is not found.

EXPORT GAMEOS LV2 MEMORY: Save LV2 memory to dev_usb000 or dev_usb006 or dev_hdd0 if usb is not found.

EXPORT FLASH TO FILE: Backup your current NOR/NAND to file on dev_usb000. Takes about 45secs for NAND

SYSTEM MODE: Switches between NORMAL and REBUG mode
NORMAL mode which uses the DEBUG XMB is the default mode after installing Rebug.
REBUG mode sets the PS3 to the latest available version spoof (updatable in the future) and allows swapping between RETAIL and DEBUG XMB.

XMB OPERATION MODE: This option only works in REBUG mode and lets you select either the RETAIL or DEBUG XMB.** RETAIL MODE ensures Media Server Connection PERMA-Enabled **

Slot 0 is reserved for use for iso plugins (netiso.sprx and rawseciso.sprx).

Slots 1-6 are for boot plugins.

Plugins are loaded in the following way:

text file:/dev_hdd0/boot_plugins.txt shall contain a single plugin path per line.

How to Install a Plugin:

Copy plugin_name.sprx to you internal ps3 hdd (ex: /dev_hdd0/).

Create or Edit boot_plugins.txt in the root of the hdd (/dev_hd00/boot_plugins.txt) and add a line for the new plugin. Assuming you placed the sprx also in the root of the disk, add: /dev_hdd0/plugin_name.sprx). Add a new line for each plugin.

Software (SW)Emulation:Support for PS2 ISOs in non BC consoles was removed in Cobra 4.30 (usb), due tops2_softemu missing. It has been re-enabled now by hacking of ps2_netemu. You can use it in the same way as before, just load an ISO and launch from disc icon, Cobra core takes care of rest. No need for encrypted isos, isos patched with limg sectors, etc. Just your normal PS2 isos dumped from discs. However, there is NO SUPPORT for Optical Discs in PS2_NETEMU

Note 1: Don’t forget to set the memory cards in XMB, in the old memory card utility for PS/PS2, as ps2_netemu won’t let you assign them in game as long as you use the new ps2 launcher.

Note 2: Decrypted Config can now be used , place the CONFIG file in the same game path. An example below :

Hardware (HW) Emulation: PS3 Models: CECHA, CECHB, CECHC and CECHE Backwards Compatible (BC) Consoles will still use their respetive emulators(ps2_emu, ps2_gxemu), which have much better compatibility and also support optical discs, original or backup. Toggle Software Emulation is available via REBUG TOOLBOX.​

​

OTHEROS++ (LINUX) SUPPORT​

OtherOS++ is supported by all REBUG REX/LITE EDITIONS and will detect your existing OtherOS HDD partition. However none of the REBUG REX/LITE EDITIONS have emer_init.self patched(create smaller GameOS partition). We are working on a solution to this from GameOS.

In the meantime if you do want to create an OtherOS partition you have two options:​

1: Use a ANY 3.55 or 4.xx firmware that already has emer_init.self patched to the size you want.2: Patch REBUG 3.xx , 4.xx REX EDITION in PS3MFW Builder MOD by Haxxxen The related thread regarding ps3mfwbuilder MOD with this MFW Builder MOD, you can make your own CFW with the feature that allows you to create regions on vFLASH/NAND for OtherOS installation If you choose option 2 we highly recommend that you ONLY patch emer_init.self (Make sure to select BASE MFW VERSION and Create OtherOS HDD Region on mfwbuilder).​

Stage0 and stage0 base are merged, (Optimization on stage0 and stage1)

Syscall 11 is added to support full lv1 peek.

Syscall 15 is added to allow execution of any lv2 internal function.

Allow Syscall 11 to gain full access to syscall 6/7/9/10 to prevent modification from homebrews like multiMAN.

PS2 Launcher is no longer needed due to new codes in storage_ext, now COBRA can behave the same way that VSH does to apply configuration of DS3 controllers.

PS2 Launcher can still be used, which allows PS2ISO with netemu on backward compatible consoles.

PS2 Netemu toggle is added for Backward compatible consoles, it is very useful for those units with broken EE/GS chips as well.

PS2 Netemu can now use decrypted CONFIG, place the game config file in the same game path for ex) dev_hdd0/PS2ISO/GOW.ISO dev_hdd0/PS2ISO/GOW.ISO.CONFIG

HASH calculation algorithm is changed, now it uses static hashes, so the hashes will not be changed unless modules have major changes.

Stealth extension support to disable Syscall 15

Allows temporary LV1 peek from syscall 8 when "disabling COBRA" is not used

Run payload with Kernel privileges - Added option to run payload with kernel privileges like ps vita skprx. this is a big thing! one can make hooks, printf to socat, do whatever they feel like they need to do. at the current time only one payload is supported at a time. in the future i might increase this

UPDATE (5-20-2019): Version 2.1.1has been released. See below for additional Details!Here is v2 of the latest PS3 Hack to hit the PS3 Scene with the recent release of PS3HEN. This exploit for nonCFW console's provides homebrew support and a number of Custom Firmware intangibles for those console that can not install a traditional CFW, with those being lat production PS3 Slim models and all of the SuperSlim Consoles. While this is a tremendous release and breakthrough the information behind PS3HEN has been lacking and has served more questions then answers that could be provided. This is due in the way this was delivered and presented. We paused the reporting this on the frontpage until we were pleased with the documentation. So we took it upon ourselves to get the ball rolling on a newPS3HEN F.A.Q. detailing various aspects and info that will be useful for PS3HEN user's. Also we have started forming the PS3HEN Homebrew & Plugin Compatibility Chart

Version 2.x.x has come with a number of new additions for a better experience. Some of the new changes provide full PS3ISO Support ,As well as full BDISO and DVDISO support has been added, plus new improvements to PS3HEN's stabili​

Following up after the Announcement from @TheFloW back at the End of March this year, today @TheFloW "let the cat out of the bag" by releasing his newest Jailbreak for the PlayStation Vita, which will allow you to jailbreak both your PlayStation Vita and PlayStation TV even on the newest System Firmwares 3.69 and 3.70 (which weren't able to jailbreak before). But not only that. While you can jailbreak your Devices on the specific System Firmwares mentioned before, you can also Downgrade your PlayStation Vita / TV to a lower Firmware to get the full potential of your Device like with the famous Hacks and Exploits on System Firmware 3.60 (such as HENkaku and modoru) and 3.65/3.67/3.68 (such as h-encore). So while you have been probably already prepared for this release back at the first announcement, together with the fact that @TheFloW was so kind to release his final Jailbreak even earlier as previous announced, we won't keep you on tenterhooks anymore. Here is everything you need to know.
​

Month after Month, the Great Time behind the RPCS3 PS3 Emulator shows more and more improvements in their work for their PS3 Emulator. As they did of course for March 2019, which you can check at their newest Progress Report. In fact, maybe this month is a little bit too technical when reading through their Release Notes but don't worry. You will again realize how good this PS3 Emulator became and how it is getting even better month after month. But one new improvement we have to stick out is the new Native Support for the DualShock 3 Controller when used within RPCS3. You might be wondering, why this new implementation comes so late? Well, there was already a full of third-party drivers but each of them weren't working perfectly. But the Team behind RPCS3 wanted to give you the best experience for playing your PS3 Game Titles. So, since you probably played your PS3 Games Titles with the Original DualShock 3 Controller on your Original PS3 Hardware, they thought about to allow the same on your PC while playing your favourite PS3 Game Titles using RPCS3. So they implemented a native support for the DualShock 3 Controller, as you would use it on your original PS3 Hardware. Kinda neat isn't it?​

Comments

I see, ive seen this tool before somewhere, someone wanted to make a 4.80 NoBD back in the day, unfortunately for him, it didnt work, due to something with the firmware keys (forgive my lack of knowledge on this topic).

define "don't work?" I used to build one and @haxxxen fixed most bugs.

Click to expand...

NoBD patching on this is reported not working, dont know how else you can define not working lol.... it would take me ages to find the thread it was mentioned on, but it came up in the same situation as this, some one wanted a NoBD version of 4.82.2 REX, i said to use MFW bulider but could not remember if it was NoBT or NoBD that didn't work, then was corrected with NoBD wasn't working. I think in the end they needed a NoBT and NoBD.

I'll try and find the thread to put some context to what am saying but with the amount of post I do it might take a while to find it.

I have never used it, I do patch everything manually. Only passing on whats been said.

NoBD patching on this is reported not working, dont know how else you can define not working lol.... it would take me ages to find the thread it was mentioned on, but it came up in the same situation as this, some one wanted a NoBD version of 4.82.2 REX, i said to use MFW bulider but could not remember if it was NoBT or NoBD that didn't work, then was corrected with NoBD wasn't working. I think in the end they needed a NoBT and NoBD.

I'll try and find the thread to put some context to what am saying but with the amount of post I do it might take a while to find it.

I have never used it, I do patch everything manually. Only passing on whats been said.

Click to expand...

So do I, but the result comes out the same when the script works correctly, and you can easily check if things are patched after unpack/decompress.

It did what it was supposed to and I failed to see why someone reported "not working" which was such a vague statement. it could've been because of his keys were missing and couldn't built the pup for the latest cfw or just simply didn't use the right option to build.

It did what it was supposed to and I failed to see why someone reported "not working" which was such a vague statement. it could've been because of his keys were missing and couldn't built the pup for the latest cfw or just simply didn't use the right option to build.

Click to expand...

Could of been the keys or something or maybe they just saw the option for remove bd firmware from the pup and they thought that was it, job done not realising about the the 4 part patch to the lv1.self that needed to be done, as i said just passing on whats been said, nice to know its working for other people though.

Seems I have different search strings for all of them but they get the right place each time for each part and are only ever in there once at each right place in the Lv1. But that shouldn't matter should it as long as the right part get's patched??

Seems I have different search strings for all of them but they get the right place each time for each part and are only ever in there once at each right place in the Lv1. But that shouldn't matter should it as long as the right part get's patched??

Click to expand...

However you search doesn't matter. You only patch 4 bytes per each function.

However you search doesn't matter. You only patch 4 bytes per each function.

Click to expand...

That's good to know, so with any patch as long as I am patching the right part's, I am free to search the way that best suits me..... so say if I find anymore shorter strings to search for on other patches, i am fine as long as it's the right place getting patched each time...

That's good to know, so with any patch as long as I am patching the right part's, I am free to search the way that best suits me..... so say if I find anymore shorter strings to search for on other patches, i am fine as long as it's the right place getting patched each time...

Click to expand...

Yup exactly. My search pattern result was based off of the patched bytes which explains multiple occurrences when searching original values since I didn't have my original patch notes here. Don't forget the fact that function change will affect your pattern search method when there's major changes. Luckily Sony stopped updating lv1 since 4.60 so I never had to reverse in depth.

Yeah I noticed that when comparing older OFW's, not got round to comparing every file in FW's, there's that effing many lol, but I get the general idea, and comparing patched and un-patched files in IDA helps me to understand how it gets patched and how the functions change.

Plus a side by side data comparison in HxD of any 2 of the same de-crypted file's in different OFW, say 4.83 & 4.84 versions will tell me exactly where to look for the changes if any before I go into IDA, then search that string in HEX on IDA, follow it back to its function.