Ticallion
BANNED
Why would it matter if RGH is not updated anyway? And even so there would be time to apply eFuse protection prior to update anyway?
New 2.0.14717 Dashboard - Security Changes
- Thread starter Xecuter
- Start date
Martin C
VIP Member
Because the moment you want to run a modified console, you should attempt to protect what you can. It's common sense. It's still possible to update an RGH console, especially if someone hasn't applied Dashlaunch or set the switches incorrectly.
Yes, there's still time for those who are running dual NAND without updating etc, but not for those who didn't.
Goldensavage
VIP Member
Updates may have essential data for newer games, so an update may be required in the future.
And yes, i would have thought if you haven't updated to the latest dashboard, you can still remove the resistor and protect your efuse before updating.
Ubergeek
Xecuter Groupie
Yes we already know this - thanks for posting further confirmations though.
It's all in hand.
One thing we do tell everything to do is to get your CPU Key before you update - this is absolutely imperative if you want to use RGH in the future as you may not be able to get your CPU Key even if CB_B is cracked.
prankster
VIP Member
Judging by reported results, i think it's safe to say, if you are a modder and consider taking on an RGH for someone, make sure the dash is 14699 or lower with phat consoles, DO NOT tell them to update (as may have been done in the past!)
sk8boy204
VIP Member
Even if it's considered "safe", always flash to stock then update, then you can flash back. If you have a RGH make sure to get all you're info from Xell before updating. Go back to stock nand and update if you want. If it renders you unable to RGH than your out of luck until a work around is found.
Ticallion
BANNED
I figured this was the case, but assumed most people would apply the dashlaunch patches and anyone who has RGH'd there own console would know damn well not to connect to live or update without checking first, but then I guess I place too much faith in people....
Martin C
VIP Member
This thread has f-all to do with CFW. Don't pollute it with FW questions.
Don't understand why we would go back to stock before update on an rgh. This isn't firmware. We aren't talking live access or dvd flashing here. For the minute it's back to like the jtag wait for the patched dash before updating I guess.
Last edited:
sk8boy204
VIP Member
I update with a stock nand because if I want to remove my RGH to use my console as a live console then I have an unbanned KV with an update console. I know you can unflag a console that's updated through usb but this is just easier. Unsolder power to coolrunner, put in stock nand, update to check things out, then make a new nand image and put power back to the coolrunner and see if it's still going strong. that's what I'm going to do. 
You don't need to unsolder anything on the Coolrunner. Switching it to PROG basically turns it off.
Martin C, reading back 6 pages I read something you mentioned and had a question.
If you remove/disable eFuse and create a retail update of 14717+ (in a future MultiBuilder) and flash it, then go on Live, wouldn't Live be able to detect that you do not have the new CB_B on Phat or the newer updated CD?
If you remove/disable eFuse and create a retail update of 14717+ (in a future MultiBuilder) and flash it, then go on Live, wouldn't Live be able to detect that you do not have the new CB_B on Phat or the newer updated CD?
I have every faith that this will get sorted and we'll be back in business in a few weeks / months.
tx have never let us down yet.
tx have never let us down yet.
Removal of R6T3 gives you a nice E80 on anything over 12611 when trying to run a stock nand iirc
Martin C
VIP Member
It's a good question and TBH nobody really knows. At least with eFuse protection you have the choice
Thank you Martin, will be interesting to test that out.
Personally, I think everything will be OK. Slims are dual-stage and were RGHed and at the time RGH was released and until 14717 there were only a few dual-stage Phat's so there was really no motivation to get RGH working on dual-stage Phat's, now there is.
Personally, I think everything will be OK. Slims are dual-stage and were RGHed and at the time RGH was released and until 14717 there were only a few dual-stage Phat's so there was really no motivation to get RGH working on dual-stage Phat's, now there is.
TilVl
VIP Member
- May 11, 2011
- 1,383
- 0
Doesn't work. I tried with a jtag xenon. It had an exploitable dash/cb. I built a retail image for the newest das and the xbox wouldn't boot any more. Just black screen and single green light.
I then flashed back to exploitable dash and did the updates through microsoft and everything worked fine. Until it started freezing and I sent it to little for a reball.
Sent from my SGH-T839 using Tapatalk
I then flashed back to exploitable dash and did the updates through microsoft and everything worked fine. Until it started freezing and I sent it to little for a reball.
Sent from my SGH-T839 using Tapatalk
Last edited:
not saying that this is correct but Logic sunrise is usually a good source:-
Yesterday we announced the release of a surprise update on Xbox Live stamped 14717 . At first glance, nothing to report for reader users flashed or **** who were the first to return. Comes back today a more precise about what has changed on the system files of the console. Indeed, a closer look at bootloaders, it appears that CB and CD (BootLoader 2-4) consoles have been updated as well as on FAT Slim. What are the implications of updating bootloaders Glitchées for consoles?
■ Xbox Slim:
http://www.logic-sunrise.com/images/images_contenu/u14717-9.png
To make it compatible again build.py, it will "just" a priori change patches on the CB.
■ Xbox FAT:
To make them compatible, you'll have to wear the hack Slim on FAT as both are different. Indeed, on Slim, we make the glitcher CB_A to launch a CB_B changed while on FAT, we glitch the CB to launch a modified CD.
To carry the hack, you have to redo everything: JED Installation and Build.py and patch Build.py
You understood, a lot of work for the stage hack into perspective. Be careful though not to confuse, Microsoft has not blocked the RGH fault as he had done with the Jtag kernel blacklistant in 4548. Here, it just made consoles updates incompatible with the current tools.
IF THIS IS total [email protected] then sorry
Yesterday we announced the release of a surprise update on Xbox Live stamped 14717 . At first glance, nothing to report for reader users flashed or **** who were the first to return. Comes back today a more precise about what has changed on the system files of the console. Indeed, a closer look at bootloaders, it appears that CB and CD (BootLoader 2-4) consoles have been updated as well as on FAT Slim. What are the implications of updating bootloaders Glitchées for consoles?
■ Xbox Slim:
★ glitchée console ever (we do not know the CPU key)
The CB is changed, making it incompatible with the current patches Build.py. You will get an error like
http://www.logic-sunrise.com/images/images_contenu/u14717-9.png
To make it compatible again build.py, it will "just" a priori change patches on the CB.
★ Console glitchée already (you know the CPU key):
In theory, if you reflash your nand before adding more value to an LDV (since you did an update), the console should boot normally, the CB could not be revoked.
■ Xbox FAT:
★ glitchée console ever (we do not know the CPU key)
All go into split CB CB (CB_A and CB_B), making the creation of pictures ecc impossible as for Kernel 5772 on the Falcon, 6752 at Jasper, etc..
To make them compatible, you'll have to wear the hack Slim on FAT as both are different. Indeed, on Slim, we make the glitcher CB_A to launch a CB_B changed while on FAT, we glitch the CB to launch a modified CD.
To carry the hack, you have to redo everything: JED Installation and Build.py and patch Build.py
★ Console glitchée already (you know the CPU key):
The problem is different since going on in Split FAT CB, a downgrade should not be feasible.
You understood, a lot of work for the stage hack into perspective. Be careful though not to confuse, Microsoft has not blocked the RGH fault as he had done with the Jtag kernel blacklistant in 4548. Here, it just made consoles updates incompatible with the current tools.
IF THIS IS total [email protected] then sorry