PS3 4.81.1 REBUG REX / D-REX + COBRA v7.31 (w/ Rebug Toolbox v02.02.11)

thanks for the reply. It's what I do but I thought they used something else.
Regads
Nothing else to use really.
Psnpatch is best.
SEN Enabler does not yet support 4.81 DEX (EvilNAT announced an update for the near future).
WebMAN-MOD could do the job as well but psnpatch is still the best option.
Any other brew developed for ban protection that you find will be outdated & will offer inferior psn ban protection.
 
Last edited:
For me FTP is pain in the ass across all firmwares and apps. It's often freeze connections and have strange speed peeks (cable is unbroken, ftp client also works ok with other devices ;]). Sending huge games through it it's a horror. So I'm glad to hear that Habibs want look into it.
 
@Joonie

What about this?

FTP speed changes between firmwares
http://www.psdevwiki.com/ps3/Talk:GbLAN#FTP_speed_changes_between_firmwares

Are there plans to work on this for future CFW-Releases?
This table shows more or less that most noticed speed differences are due to using a different ftp client or different ftp server or both.
Server/Client choices apart, there is not much difference coming from using different CFW except one.
A significant change in upload speed (down about 40%) on PC to PS3 starting with 4.30 fw and which remains until now.
At the time Joonie created a thread about this, habib thought it was something to do with changes made by S#ny to cellFS. Not sure if the research went any further..
 
Last edited:
I'm having some issues with Rebug 4.81
I'm on DEX and when I try to "Change active ID" in Rebug toolbox it says it successfully changed from 82 to 85 it but it actually doesn't. If I check it with PSNpatch and multiman it still says 82 and I can't connect to PSN because of it.

2. I can't seem to downgrade from this firmware, I convert back to CEX to install Rebug 4.80 REX but I always get corrupted data. QA is enabled and I've also tried from recovery menu.
I installed Habib 4.81 and from there installed Rebug 4.80, no problem.
On Rebug 4.80 the change active ID works just fine and it goes from 82 to 85.

I then updated to Rebug 4.81 again, converted to DEX but the same thing happens, won't change the ID although it says it does. Can't downgrade directly to 4.80 so went to habib again and then Rebug 4.80. Guess I'm stickng to 4.80 since it works a treat.

Is it just me having this problem?
 
@jonnyjaeger For me, downgrade/upgrade from USB never working after 3.55 (or 3.55+ DEX2CEX). I always using "dev_hdd0/updater/". I'm curious why.

Any BD disc inside your BD Drive?, if so take that out please.

I'm having some issues with Rebug 4.81
I'm on DEX and when I try to "Change active ID" in Rebug toolbox it says it successfully changed from 82 to 85 it but it actually doesn't. If I check it with PSNpatch and multiman it still says 82 and I can't connect to PSN because of it.

I'm really surprised that people actually use this when there are alternatives, PSNPatch, SENEnabler, webMAN, and even IRISMAN.

But yeah I also confirmed that the TOOLBOX's temporary spoofer is not working.
I'm not quite sure which part is broken since the code has never been changed.
The toolbox firstly detects EID5 first then use that IDPS to LV2. I'm still looking at it.

2. I can't seem to downgrade from this firmware, I convert back to CEX to install Rebug 4.80 REX but I always get corrupted data. QA is enabled and I've also tried from recovery menu.
I installed Habib 4.81 and from there installed Rebug 4.80, no problem.

@DeViL303 had the exact same issue but he was able to fix it after using FSM / 3.55 fresh installation.

On Rebug 4.80 the change active ID works just fine and it goes from 82 to 85.
I then updated to Rebug 4.81 again, converted to DEX but the same thing happens, won't change the ID although it says it does.

Which is really weird , and still looking at it
Can't downgrade directly to 4.80 so went to habib again and then Rebug 4.80. Guess I'm stickng to 4.80 since it works a treat.

Again, yes try FSM 3.55 fresh installation like @DeViL303 did

Is it just me having this problem?

For IDPS Spoofer on REBUG, I confirmed it, but the PUP installation problem, I've seen couple reports but couldn't figure exactly why, but heard FSM fixed it
 
@Joonie No, I never leaving disc in drive. Also I heard that PS3 with QA have first priority seeking update from drive so that's another reason why avoiding such situation (even if there is patch for this inconvenience).

I cannot tell if all update from USB on CFW doesn't work or just only on Rebug. I never see a reason to switch from the best CFW to another. ;) Also it's not big deal for me if updates from hdd works well.
 
@Joonie Thanks for all your clarification. Like you said I can easily spood the ID with PSNpatch instead of the toolbox so it's not really a big issue. But it's weird that it stopped working with 4.81 if the code hasn't been changed since 4.80
 
@Joonie

Why has the new REBUG_TOOLBOX_02.02.11 a "root_key_475.self" included
instead of a "root_key_481.self" (or instead of a "root_key_480.self")?
 
Last edited:
@Joonie

Why has the new REBUG_TOOLBOX_02.02.11 a "root_key_475.self" included
instead of a "root_key_481.self" (or instead of a "root_key_480.self")?
If I had to guess I would say it's because the root_key 4.75 self is compatible with 4.81 & there was no need to compile a new one.
Remember s#ny went back to the 4.75 kernel with this release. That's why multiman 4.80 could work on 4.81 cfw without updates...
Joonie will correct me if I am wrong...
 
If I had to guess I would say it's because the root_key 4.75 self is compatible with 4.81 & there was no need to compile a new one.
Remember s#ny went back to the 4.75 kernel with this release. That's why multiman 4.80 could work on 4.81 cfw without updates...
Joonie will correct me if I am wrong...

Everyday more and more input. Thx for the detailed declaration, @bguerville.

Now i understand too, why REBUG_TOOLBOX_02.02.10 has the "root_key_480.self" included.
 
No worries.
We are here to share our knowledge.
Humbly too because nobody knows it all.. But we try our best...
If you learn, our team is happy...
 
@Joonie, @Habib, @Mysis

When I use the "*Soft Reboot" - Function of the "*Custom Firmware Tools",
I get lost in space :), I mean, my DS3 doesn't sync correctly.
It happens to me only, after the LED's of my DS3 go off and I hit the PS-Button too early.
The issue is not reproducible with the "*Hard Reboot" - Function. --> Everything ok.

Is there maybe a possibility to improve this?

BTW: Backup of my "xRegistry.sys" is done.


Greetingz
 
Last edited:
@Joonie, @Habib, @Mysis

When I use the "*Soft Reboot" - Function of the "*Custom Firmware Tools",
I get lost in space :), I mean, my DS3 doesn't sync correctly.
It happens to me only, after the LED's of my DS3 go off and I hit the PS-Button too early.
The issue is not reproducible with the "*Hard Reboot" - Function. --> Everything ok.

Is there maybe a possibility to improve this?

BTW: Backup of my "xRegistry.sys" is done.


Greetingz
Never had a single issue with this feature & I use it several times daily since it was released as WIP ages ago.
Soft reboot has been a solid feature for me since 4.7x until now in Rebug 4.81.2.
I can't reproduce your issue. Never heard anyone with such problem either.
I suggest you check all your setup again..
Test all the reboot types using wMM (check the parameters for the web command & test them all).
 
Never had a single issue with this feature & I use it several times daily since it was released as WIP ages ago.
Soft reboot has been a solid feature for me since 4.7x until now in Rebug 4.81.2.
I can't reproduce your issue. Never heard anyone with such problem either.
I suggest you check all your setup again..
Test all the reboot types using wMM (check the parameters for the web command & test them all).

Ok, much to testing. I will give a try in the next days.
 
Last edited:
Back
Top