Hacking Hardware Is this Xbox 360 hacked or not?

[lucmsilva]

Hello yall, I have some questions regarding my Xbox 360, since it acts like a locked one (doesn't run homebrew nor games from high seas) but gives a E71 on boot if a xell.bin or xell-1f.bin (any of those) is inside a USB drive. I have been using BadUpdate with XeUnshackle since my Xbox is in this situation, but I managed to dump my NAND from it and I put it into JRunner to see what is happening...

It also doesn't react to eject button, booting normally (like a non-hacked console)
I found a Xell related folder on the internal storage Content folder (while using Aurora on BadUpdate) dated from mid 2020 (I got it in end 2020) so what is happening??

Also works on Xbox Live if BadUpdate isn't running ()

*snip*

There is a video of it not booting while Xell is on USB:

It recognizes Glitch2 (hacked?) on JRunner if I put dumped NAND so what is happening here? Is my console hacked and something is wrong inside of it?

 

[Vstromakias]

if on your console with eject it entered xell then it was rgh and not badupdate. you have fucked the nand. logically you have some chip inside that takes over the process (unless you are rgh3 with only 2 cables and you have the wrong settings). as the photo shows you have rgh1.2 (see if any led inside flashes when you press the power).

 

[DinohScene]

I've removed your Jrunner screenshot, be careful when showing console identifiable strings.

A foolproof way of checking if your console is hardware modded is to open it up.
Did you get this console used?

 

[lisreal2401]

do you also have "default.xex" on the root of the same USB?

this will trigger E71 on any retail if the executable in question isn't applicable (so basically all of them, can't think of one that will launch from USB in that context)

 

[lucmsilva]

I've removed your Jrunner screenshot, be careful when showing console identifiable strings.

A foolproof way of checking if your console is hardware modded is to open it up.
Did you get this console used?

Yes, used, but I have it since the end of 2020, but I never tried to do anything before, only used BadUpdate lmao

Post automatically merged: Jul 15, 2025

do you also have "default.xex" on the root of the same USB?

this will trigger E71 on any retail if the executable in question isn't applicable (so basically all of them, can't think of one that will launch from USB in that context)

Oh it was on USB, so this is the real problem? What about Glitch2 in JRunner? Mod removed the screenshot but I maybe will upload again censoring some things...

Also, why would a retail console try load a default.xex even if it really can't then because of the lock stuff?

Post automatically merged: Jul 15, 2025

if on your console with eject it entered xell then it was rgh and not badupdate. you have fucked the nand. logically you have some chip inside that takes over the process (unless you are rgh3 with only 2 cables and you have the wrong settings). as the photo shows you have rgh1.2 (see if any led inside flashes when you press the power).

This only happens if the USB with Xell is inserted. When not, it acts normally...

 

[lisreal2401]

Yes, used, but I have it since the end of 2020, but I never tried to do anything before, only used BadUpdate lmao

Post automatically merged: Jul 15, 2025

Oh it was on USB, so this is the real problem? What about Glitch2 in JRunner? Mod removed the screenshot but I maybe will upload again censoring some things...

Also, why would a retail console try load a default.xex even if it really can't then because of the lock stuff?

Post automatically merged: Jul 15, 2025

This only happens if the USB with Xell is inserted. When not, it acts normally...

Possible retail image with RGH wiring?

That's my only guess if it genuinely doesn't respond to any form of unsigned code. That would date it before RGH3, see if there's any LEDs on the inside of the case when plugged in - definitely post your Jrunner screenshot again, just blank out your keys etc.

 

[lucmsilva]

Possible retail image with RGH wiring?

That's my only guess if it genuinely doesn't respond to any form of unsigned code. That would date it before RGH3, see if there's any LEDs on the inside of the case when plugged in - definitely post your Jrunner screenshot again, just blank out your keys etc.

Yea but I read somewhere that Retail NAND can't boot on RGH so it should be modified if something is there. I didnt opened it yet but there is no noticeable LEDs inside the case while the console is on and the console works fine in Xbox Live as if it was never modified...

Posting the JRunner screenshot soon when I get home.

EDIT: read it again and it is stated that only Corona can boot with RGH wiring and mine is also a Corona so maybe is it?

Post automatically merged: Jul 16, 2025

Screenshot of JRunner (w/ censored CPU key, if there is more to censor, DM and tell what I need to remove...

 

[lisreal2401]

You can effectively build a NAND image that serves to boot a clean retail kernel if you want, it still has to be compatible with whatever RGH method and motherboard you're using (the actual process of the hack still has to succeed, and generally Xell is present alongside the kernel/dashboard, but I suppose isn't required).

I did notice the Xebuild tab on Jrunner will default to Glitch2 selected as a target when loading retail NAND dumps just now however, so I'm inclined to say this box isn't an RGH. Can't explain the "xell related folder" on the 4GB user partition other than the possibility this console was glitched for the DVD key, swapped with an LTU board and returned to stock. Can you add more to that anecdote?

 

[lucmsilva]

You can effectively build a NAND image that serves to boot a clean retail kernel if you want, it still has to be compatible with whatever RGH method and motherboard you're using (the actual process of the hack still has to succeed, and generally Xell is present alongside the kernel/dashboard, but I suppose isn't required).

I did notice the Xebuild tab on Jrunner will default to Glitch2 selected as a target when loading retail NAND dumps just now however, so I'm inclined to say this box isn't an RGH. Can't explain the "xell related folder" on the 4GB user partition other than the possibility this console was glitched for the DVD key, swapped with an LTU board and returned to stock. Can you add more to that anecdote?

Well, I don't know to be honest... LTU also never worked, so maybe it was lost when we updated it here...

Isn't hacked then?

 

[Vstromakias]

Why are you analyzing it so much? Open the console and upload photos if you see any boards or cables. Then we'll help you with the rest.

 

[lisreal2401]

Well, I don't know to be honest... LTU also never worked, so maybe it was lost when we updated it here...

Isn't hacked then?

Almost certainly not, see above post if you really want to confirm.

 

[lucmsilva]

Almost certainly not, see above post if you really want to confirm.

Finishing this thread, I opened up the console and there is nothing related to hacks. I taked the chance to change thermal paste and stuff.

E71 is triggered if a unsigned file renamed as default.xex is on a external device, as stated by you on post #4 of this thread. I don't know if it actually loads something on a RGH. I searched it up and I found this thread on Digiex which shows manufacturing mode while booting with a modified memory card which the modding steps takes basically the same thing as just putting the files (default.xex and another one) on the root of the memory card and this actually may boot on a unmodified console (not tested on mine yet).

I think this could be useful if we managed to make BadUpdate work with this way because it would allow us to theorically hack the console while it is booting so no need to run Rock Band Blitz or the Tony Hawk game.

Anyway, this are just random thoughts. Feel free to not take this seriously, as the issue is solved by now. If you guys want, we may open a separate thread regarding this.

 

[lisreal2401]

Finishing this thread, I opened up the console and there is nothing related to hacks. I taked the chance to change thermal paste and stuff.

E71 is triggered if a unsigned file renamed as default.xex is on a external device, as stated by you on post #4 of this thread. I don't know if it actually loads something on a RGH. I searched it up and I found this thread on Digiex which shows manufacturing mode while booting with a modified memory card which the modding steps takes basically the same thing as just putting the files (default.xex and another one) on the root of the memory card and this actually may boot on a unmodified console (not tested on mine yet).

I think this could be useful if we managed to make BadUpdate work with this way because it would allow us to theorically hack the console while it is booting so no need to run Rock Band Blitz or the Tony Hawk game.

Anyway, this are just random thoughts. Feel free to not take this seriously, as the issue is solved by now. If you guys want, we may open a separate thread regarding this.

mfg mode will only load executables signed to be loaded in that context, you would simply prompt E71 like usual.