Live 2.0 Compatible Exploit Options

[PedrosPad]

Ok, new idea brewing to solve the ROJ problem...

We've all been booting to Live 1.0 Dashboard 4290, and spawning pre-live Dashboard 4817. This is because only Dashboard 4290 has the XBOX!Live menu option.

Now here's an interesting finding:

Live 1.0 Dashboard 4290, Allowed media types = 0x80000001, XBE_MEDIA_HDD
Pre-Live Dashboard 4817, Allowed media types = 0x00000001, XBE_MEDIA_HDD
However, when you boot into Dashboard 4817, ROJ isn't on, as you can insert Music CDs, etc.

Also note that these Dashboards keep their fonts in different places, but the font exploit works with both these Dashboards.

Thus, one should be able to boot into Pre-Live Dashboard 4817, and ROJ is known not to be set, and then use the Easter egg exploit to boot Live 1.0 Dashboard 4290, exploited with the font exploit. Because it has the magic 0x80000001 - ROJ stay off - media flag, the font exploit should fire, launching Evox, etc., and ROJ should remain off.

I'll try this later if someone doesn't beat me to it.

This post has been edited by PedrosPad: May 21 2004, 03:20 PM

[PedrosPad]

Worked!

• Restored Pre-live Dashboard 4817 (in its entirety to C:\)
• Replaced C:\setting_adoc.xip, with the Live 1.0 Dashboard 4290 xboxdash.xbe
• Put the double-dash Bert & Ernie font files in C:\fonts.

Booted to 4817, entered the Easter egg code, Dashboard 4290 booted momentarily, then jumped to the Evox menu. I then ejected the DVD tray, and closed it repeatedly – Evox correctly reported the tray state in the corner of the screen, and absolutely no sign of Reset-On-Eject.

A bit cumbersome to use, I admit, but it worked.

This seems to verify rmenhal's understanding of the relationship of the "Allowed media types = 0x80000001" XBE header field to Reset-On-Eject, but also reveals that this bit doesn't need to be set for the boot Dashboard.

This post has been edited by PedrosPad: May 21 2004, 08:35 PM

[devz3ro]

[PedrosPad]

hehe - I largely agree with your points - I'm just playing. (I’m the guy who’s just invented the chocolate tea pot).

However, there was a slightly more serious point to me research.

1st – this seemed a simple way to verify rmenhal's understanding of the relationship of the "Allowed media types” flag, and ROE

2nd – There are a lot more XBE’s around with Allowed media types = 0x00000001 and XBE_MEDIA_HDD, than there are with Allowed media types = 0x80000001 and XBE_MEDIA_HDD. The finding I was after was the fact that the Allowed media types =0x00000001 didn’t set ROJ on the first XBE the BIOS loaded.

This opens up the possibility of not actually booting a Dashboard at all, but possibly booting another XBE all together. One that simply happens to have the necessary Allowed media types = 0x00000001 and XBE_MEDIA_HDD. Right now, I playing with booting versions of real settings_adoc.xip easter egg XBE, and the xodash\update.xbe. These programs don't give a hoot if the clock is set or not (they're not looking out for it - unlike the Dashboard's). And I’ve a few ideas regarding these early, non-maintained programs

This post has been edited by PedrosPad: May 21 2004, 09:24 PM

[devz3ro]

"Non-maintained"

HAH

Watch how that suddenly changes

-devz3ro

http://sh0x.tk/

[PedrosPad]

I've been playing, and thinking, some more.

Me thoughts are that the update.xbe that get’s installed into the xodash folder by the update to Live 1.0 Dashboard 4290 also reads it’s fonts via the wildcard “*.xtf”. The time of it's creation, and this similarity-in-operation, leads me to suspect that it is likely to contain exactly the same font overflow bug the 4290 Dashboard has.

I’ve been running some tests with custom Bert and Ernie fonts, and, although I’ve not got it fully working yet, I believe the symptoms I’m seeing support my theory.
I can contribute that the update.xbe checks C:\fonts\ for the fonts first, followed by C:\ - which is a slight pity (I’d hoped it was the other way round).

The reason this interests me is that I suspect that the update.xbe program isn’t going to be checking the system clock, like the Dashboard’s do. Thus if XBOX boots update.xbe (and it does appear to have all the necessary flags set), instead of a Dashboard, can be hijacked via it’s fonts, and it pays no heed to the clock argument packet the BIOS passes to a boot Dashboard, it’s operation should be very stable. i.e. No clock loop.

If all this proves true (and I strongly suspect it is) it would produce an “update” exploit that would allow directing booting to Evox, etc. (It can’t get easier than that), with absolutely no risk of clock-loop. The holy grail?

I'll continue playing, but I suspect rmenhal would have more success in determining the correct values for Bert.xtf. (Please!)

Comment invited.

This post has been edited by PedrosPad: May 21 2004, 11:31 PM

[PedrosPad]

[PedrosPad]

[Kthulu]

i have no personal interest in these exploits (i'm tsop-flashed) but i find reading about them very interesting. with my ignorance professed, i will now comment

if you indeed get this 'update exploit' working, i'm thinking it would have a Pro to it that you haven't mentioned. if the update.xbe is replaced or hijacked, m$ would not be able to upgrade or over-write your existing dashes. am i right?

[Australian Rat]

[ldots]

These are very good findings Pedro - keep it up

I actually thought there would be some check from the bios that the boot xbe had to be a dashboard, but sure enough you can boot to the update screen using the update.xbe. Just for the fun of it I also tried using the rmenhal fonts which didn't produce an error but a reboot. I also think it is very likely that this xbe can be exploited.

So when Pedro confirms that this xbe does not check for an unset clock on boot, we just need rmenhal to do a little magic on Bert. This scene has really produced some interresting result the last few weeks

[Kthulu]

[PedrosPad]

[rmenhal]

Here come the update fonts.

Standard requirements: dash 4920 and kernel version strictly less than 5713.

Runs HABIBI-signed executable E:\default.xbe. Consider this as work-in-progress and take appropriate precautions.

1. Copy your C:\xodash\update.xbe to C:\xboxdash.xbe
2. Rename your C:\fonts directory to C:\font5 (or whatever)
3. Create directory C:\fonts and copy bert_ate_ernie.xtf from the package below
4. Reboot and pray

I had to put the exploit payload into bert, because update.xbe didn't load ernie. So there's only one font file now. Works great on my box. No sign of clock-loop. I tested it by setting the clock to zero using NtSetSystemTime. I've previously caused clock-loops that way.

[Angerwound]

Absolutely Amazing.......