Print

[Gadorach]

As I'm not familiar with the Xbox 360 and how it's built, or how most of the code-launch settings are made by both MS and the JTAG team, I just thought I'd throw in my two cents and see if it's a plausible, if somewhat "dirty" method to achieving a JTAG software state through the RGH glitch.
Though I can't say whether this idea could apply to the slims or not it is likely based on how they handle old dashboard revisions.
Basically, These are my thoughts.

From research, I believe the "Freeboot" application is designed to emulate the correct sequences of blown E-Fuses for each dashboard revision in order to prevent kernel panics and allow booting of newer dashboards over older ones.

As such, if we can emulate a new fuse set,can we not also emulate an old one?
If Freeboot is coded in LibXenon,  could we not boot it through Xell?

Assuming it is coded in LibXenon,  Through that emulation, could we not boot an older, exploitable kernel over-top of our new kernel?

If so, could we not patch that exploitable kernel and run the JTAG based applications from it?

So the process would be more like this:

RGH Loads Xell
Xell Loads Patched Freeboot
Patched Freeboot loads Exploitable Kernel
Exploitable Kernel loads New 13599 Patched Freeboot
13599 Patched Freeboot loads JTAG patched 13599 Kernel
Patched 13599 Kernel loads Homebrew.

Of course, looking at it now, If Xell can load Freeboot, couldn't it just straight boot to the patched 13599 kernel?

I wish I knew enough about the 360 to code for it but I'm unfamiliar with it so I can't try this theory myself.

anyways, as before, just my 2 cents. not sure where things are gonna go from here so yeah best of luck to whoever figures out how to break open the 360s loading system and give us all RxE Dashes xD

- Gadorach

[Aldanga]

If you're trying to describe a situation where the console boots into a hacked dashboard, it's already possible with the reset glitch. All that needs to be done is for someone to complete a hacked dashboard so that it can boot using the new hack.

Applications such as FSD and others aren't coded specifically for exploited consoles. They're coded for 360s using the Xbox 360 SDK. They can run on dev units and exploited consoles, and don't require any special modifications aside from the signing requirements being removed.

This post has been edited by Aldanga: Sep 23 2011, 02:18 AM

[Gadorach]

That's basically part of what I'm trying to describe, but I'm wondering if Xell can boot Freeboot. If Xell can boot Freeboot, then, as freeboot can boot pretty much any dashboard, and because it's a "Rebooter", will it not also load the necessary xex's for running the software environment as well upon the reboot initiation?

Please, correct me if I'm wrong as I'm interested in how this whole boot process works and what would be necessary to implement into a program if I choose to try to build it myself for when my coolrunner comes in.

As such, what would be involved in this?
That's what I want to know (IMG:style_emoticons/default/smile.gif)

[Aldanga]

XeLL doesn't boot freeBOOT or XBR. Since an exploited or glitched console can run unsigned code, all that needs to be done to the NAND flash image is have it modified to remove several security checks. Once those are removed, the console basically boots the hacked dash as it would to a normal dash, but with a lot more freedom.

If you want to learn about the 360 boot process, head over to free60.org and read the wiki. There's a ton of good information there. You know virtually nothing about how the console boots and what is involved in the exploit/hack (not a fault of yours; just a fact), so you need to read up quite a bit before considering attempting such a thing. That'll lay a good foundation for any further questions you might have.

[Gadorach]

Thanks for the info, I'd +rep you but it looks like the forum hasn't implimented that system so a simple "Thanks" will have to suffice (IMG:style_emoticons/default/tongue.gif)

I'll be back with more questions when I've read up some more. Expect me back within the next week (IMG:style_emoticons/default/biggrin.gif)

Edit:

Just one more question spree for verification, Does there not already exist modified dashboards being used for the JTAG based hack?
What differs in the launching of the system to a patched kernel between the two methods of JTAG and RBH?
Is it just that the JTAG hack uses the hyperviser bug to load everything, and therefore is based in a fully booted software environment which means that the patched dashboard would need to be patched to boot from an already launched kernel?

As such, the JTAG would work through a Kernel < Old Dash < New Kernel < New Dash idea and thus the new kernel for the RGH would require it to be patched as the original dashboard (13599) through the booting process, then just accept the new permissions overall?

Seems tricky to impliment but if patched dashes already exist that remove the permissions based around the JTAG hack, would it not be simple for the one who made them to just repatch the dash again?

From reading up on the RGH a bit earlier, I also wondered how the patched CD loads Xell. Also, if there is a decrypted source code available or information on how to make modifications to it in order to make it load something other than Xell, like a Dual-Booter that can either boot Xell or the main dash (for now while waiting for a hacked dash) as I can see that being fairly straight forward to code as it could be like:

If [Sync Button] held in, Boot Xell (As the sync button and DVD Eject button both report key presses prior to a nand boot (I think) and therefore have easily retrievable software signals)
If [Sync Button] is not held in, Boot next process to begin Xbox 360 boot sequence.

Just an Idea. I'm going to try to get myself familiar with LibXenon so I can make this as well.

That way we could still use our boxes while waiting for the patched dash to load anything.

And afterwards, It could be a triple boot with a GUI that I'll have to implement but I'm starting with a simple, no-gui solution for now when I figure it out.

Also, does Xell interfere with the normal boot process just by being installed?
If so, what would be necessary to bypass this restriction without removing Xell?
If not, I assume what I'm reading about the boot process should let me load the next sequence of the normal 360 Boot which, in turn, should load the next and so on and so forth, as M$ intended.

If these questions can be answered and in a favorable way, perhaps we can get of on a good foot for the appearance of patched dash, or at least a more accessible Homebrew menu, as I'd like to load more than one app and switch back and fourth out of them without a reboot If I'm only running emulators based on LibXenon with this exploit and a dash isn't released >_<

Anyways, I'd love some informed answers while I make myself informed xD

This post has been edited by Gadorach: Sep 23 2011, 03:19 AM

[Gadorach]

(As it's not letting me Edit my last post, i'll have to continue it like this)

From the description of how the CB works, with the patched CB, it could be re-directed to the multiboot program that stores an original copy of the real CB and also the run string for Xell.
With the multi-boot program running first,  all it would need to do it say either 1, [RUN XELL] or 2, [RUN CB]
To my knowledge, the original CB takes care of the booting process so all I need to so is have the real one run and it will boot into the normal kernel without me having to code a HV bootstrapper to make everything boot correctly.

As such, it appears to be easier than I thought [Assuming I'm correct in my judgement of the series of events leading to the boot].

As such, that should take care of problem 1.

What I need to do now is figure out how to load a licenced, M$ application from a LibXenon based application.
If this isn't possible, directly, would it be possible to copy the whole CB to RAM and then send an instruction from the LibXenon app to the cpu to tell it to run the file starting at 0xXXXX in ram which would push the loading responsibility to the native hardware, thus bypassing the need to load it from LibXenon entirely?

From my viewpoint it seems possible, and not all that complicated if coded correctly, thus making it much more painless to work with.

Any thoughts or comments on my ideas are entirely welcome and encouraged!
I really want to make this happen so we can start actually using our soon-to-be glitched boxes to play Zelda without Lag and glitching, like on the old xbox emulator, while switching back to retail OS for normal gaming without having to flash the NAND back and forth.

Of course, I'm not even considering Xbox Live Safety at this point so I don't care if any methods used are traceable/detectable (which they probably are seeing as, after a processing hand-off, the program I make no longer controls the items in RAM, IE, the CB is still there, where it isn't supposed to be, and I can't remove it after booting signed code into an unpatched hypervisor which would probably do a RAM Flush anyways, like it seems to do at SC03 during the boot process. As M$ could add a check before the Flush for the CB in RAM, any new revision would instantly detect it. More research will need to be done to see how to either FAKE the RAM location as the intended (where the previously patched CB will be) or patch all future HV's to always report a "Yes" to said check.)

Gees, Now I'm making and attempting to solve nonexistent problems. xD

I think I'll have to clean up my post soon at this rate

I'll be updating this again after I pull my thoughts together!

Also, as before, Please comment and give suggestions!
No one person can think up everything!

Thanks to anyone who takes their time to read this and comment!

Edit:

Moving on, It seems that, After the patched CB makes the hand off to my program, I can unload that CB and replace it with the original CB in RAM, in it's original spot, thus eliminating the problem of HV Pre-boot detection on that front, not that it matters as later on in the boot chain the HV can send a execution hand-off to a new M$ app that scans the NAND for the hack-related files and returns either a yes or no statement as to mark for an exploited console. as such, I don't think M$ will have any problem finding out if our 360s are RGH'd unless a NAND patch is placed which edits the scan permissions of the NAND to only a specially-privileged application for certain NAND sectors. Though this could probably be detected as well (I see another upcomming "Cat and Mouse" game here...) but anyways. Of course, Multi-Nand setups would probably be safe on this so no problem there. It's just the Single-Nand setups that are going to be detectable easily. Unless M$ decides to do a NAND Manufacturer + Serial check to make sure no un-registered NAND chips are being used. Though I'm rather sure that the default NAND chips are reasonably easy to come by so it wouldn't stop us for long.

Anyways, Just trying to unravel some theories here so yeah, I'll post again after reading up more, BBL!

As before, please post your thoughts as well!

If two heads are better than one, 500 heads should get the job done

[Aldanga]

I'm still not sure what you're trying or wanting to do. Could you boil it down to a sentence or two?

[Gadorach]

Ok, so, in a few words, I'm going to program a Multi-Boot application in LibXenon that is triggered by a held key during the boot process which either boots Xell, or the normal CB which will, in turn, launch the normal dashboard.

My next project will be to build a multi-boot LibXenon menu for the Xell Loader that lets me load and unload Emulators and applications based in LibXenon by loading them as a virtual machine or something along those lines that can be controlled by a reset button combination,like the SoftReset built into the original Xbox's Homebrew menus.

[Aldanga]

By "normal CB" and "normal dashboard", are you referring to a non-hacked dashboard, just like the one run on stock consoles? Or are you referring to a dashboard like freeBOOT/fbbuild provides?

[Gadorach]

I'm referring to the stock CB and stock Dash.

I figure that it should be a stock for now, until someone figures out how to patch and boot a new one, hopefully based on another modified CB for specific use with the patched Dash.

After which, it should be easy to add another CB into the program and have a modifiable config file for setting the button combos for booting the specific dashes.

Anyways,as I have to work in the morning, I'll be back on around 1pm-2pm.

I'll get started on learning LibXenon at that point.
Also, any suggestions as to where the best place to read up on LibXenon and it's functions is or is free60.org the best place right now?

Thanks as usual!

- Gadorach

This post has been edited by Gadorach: Sep 23 2011, 05:08 AM

[Aldanga]

I honestly haven't looked into it from the technical side, but I don't believe that's possible without a dual-NAND setup. Beside that, it would be much, much easier to implement with a dual-NAND setup as you could just enable/disable the glitch and change NANDs with a simple physical switch. There would be no problems, as you wouldn't have to worry about chain-loading like you're describing, which I'm still not sure is possible due to the space in the NAND. You could leave the internal NAND at stock, while the add-on NAND could be modified, getting rid of any possible issues.

[Gadorach]

True, which would be great for those of us actually able to preform the installation of a second NAND, but until then, it would be nice for the novices to have something to use as well. Also, It would be fairly easy to find the space in the Big-NAND Jaspers I'd bet, and with the possibility to load a virtual NAND from the HDD (Like using UNEEK on the Wii) It could be easy to do this virtually, thus having little that actually needed to load from the stock NAND. Though I don't think I'm experienced enough at coding to make a NAND emulator for the Xbox 360, I'm sure there's someone out there that could either make it, or give me a hand with it!
As such, until such developments are made, It's likely that this would just be a nice way to avoid having to re-flash the NAND and turn off the Coolrunner (or any other solution) just to play stock 360 games.
Seeing as the NAND is built to store backups of all the Kernels, there should be enough room to add a simple, very small app for achieving this setup. And even if some of the backed-up kernels are deleted to make room, I doubt the 360 would kernel panic unless either the BK kernel (Original) or the current kernel (2.0.13599) were deleted as, to my knowledge the Xbox 360 only checks the original and the highest revision number in NAND for the kernel check on boot.

This would mean removing anything in-between that was unnecessary for the boot process and normal operation of the Xbox.

Yet again, another Theory. I'll get right to work on debunking everything once I get my Coolrunner in on around the 4th.

... Not that I'm waiting that long to start coding (IMG:style_emoticons/default/tongue.gif)

Anyways, Just to summarize the plan a bit:

1) Modify CB to launch a patched CD with my MultiBoot Code inside instead of Xell.
2) Have the MultiBoot app detect the presence of the desired button being held in (Likely Sync).
3) If held, execute the CD with the Xell Patch. If not held, execute the original CD with the M$ Boot Code
4)
5) Profit?

I just need to know now If I require Xell to load the drivers for LibXenon before I can boot even a simple LibXenon app, or not.
If I do, what version of assembly do I need to code it in order to execute the program natively?
Better yet, what is Xell Reloaded coded in? That'll probably be my next target for finding out what I need to code.

Anyways, I'm thinking too much and I have to work in 7 hours so yeah, more posts when I get back!

This post has been edited by Gadorach: Sep 23 2011, 05:56 AM

[Aldanga]

I'll say it again: I'm not sure such a setup is possible with a single NAND flash. If you want to have a second, virtual NAND on a storage device, the complexities associated with that are extremely numerable, and you'd have to boot an executable before dealing with that, which would then have to constantly run behind the dash, likely slowing down everything associated with the dash as well as software run on the console since the backend will require significant CPU cycles, as almost every call would need to be translated. Having a standard dual-NAND setup would be much more advisable. If you want to make things simple, hardware is the path you want to take.

I think you're duplicating efforts for something that has a very small market. If someone can implement the reset glitch hack, they can definitely implement a dual-NAND setup. The simplicity of doing things similarly to how it's been done with the rebooters is much greater than what you're hypothesizing. The simplicity rule applies here, and I think it would be wise to heed it.

[Gadorach]

Do you know where I could find the source code for any of the re-booters or is it all closed source?
If I can dissect a rebooter, I'm sure I can figure out how it works and then build a program that achieves this based around that method. Also, from what you're saying, It seems like it's a near definite that something will come out from an expert that will achieve the necessary requirements for a modified dash, as it should be much simpler to just straight boot the dash then to have to patch the underlying kernel to think that a certain number or efuses are blown in order for it to boot.

Even still, I'd like to do this for a learning experience on Xbox 360 programming. I'm sure you'll see some homebrew from me in the near future once I get familiar with it (IMG:style_emoticons/default/tongue.gif)

Anyways, NIGHT!
[Gotta force myself off this computer and get too sleep xD ]

[Aldanga]

It's all closed-source as far as I'm aware. The coders are all anonymous (either by choice or de facto), possibly due to the potential legal issues. You might be able to find them, but given your lack of history in the scene, I find that unlikely.