Topic: Live 2.0 Compatible Exploit (Read 985 times)

PedrosPad · « **Reply #46 on:** May 21, 2004, 02:19:00 PM »

hehe - I largely agree with your points - I'm just playing. (Im the guy whos 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 XBEs 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 didnt 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 Ive a few ideas regarding these early, non-maintained programs

devz3ro · « **Reply #47 on:** May 21, 2004, 04:15:00 PM »

"Non-maintained"

HAH

Watch how that suddenly changes

-devz3ro

http://sh0x.tk/

PedrosPad · « **Reply #48 on:** May 21, 2004, 04:26:00 PM »

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

Me thoughts are that the update.xbe that gets installed into the xodash folder by the update to Live 1.0 Dashboard 4290 also reads its 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.

Ive been running some tests with custom Bert and Ernie fonts, and, although Ive not got it fully working yet, I believe the symptoms Im 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 (Id hoped it was the other way round).

The reason this interests me is that I suspect that the update.xbe program isnt going to be checking the system clock, like the Dashboards 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 its fonts, and it pays no heed to the clock argument packet the BIOS passes to a boot Dashboard, its 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 cant 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.

PedrosPad · « **Reply #49 on:** May 21, 2004, 04:34:00 PM »

PedrosPad · « **Reply #50 on:** May 21, 2004, 04:38:00 PM »

Kthulu · « **Reply #51 on:** May 21, 2004, 10:30:00 PM »

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 · « **Reply #52 on:** May 22, 2004, 02:51:00 AM »

ldots · « **Reply #53 on:** May 22, 2004, 04:43:00 AM »

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 · « **Reply #54 on:** May 22, 2004, 08:59:00 AM »

PedrosPad · « **Reply #55 on:** May 22, 2004, 09:19:00 AM »

rmenhal · « **Reply #56 on:** May 22, 2004, 10:20:00 AM »

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 · « **Reply #57 on:** May 22, 2004, 10:27:00 AM »

Absolutely Amazing.......

ldots · « **Reply #58 on:** May 22, 2004, 10:37:00 AM »

Kernel 4034 here and ernie-eating font works great! Uhh - and of course no ROE.

PedrosPad · « **Reply #59 on:** May 22, 2004, 10:38:00 AM »

Author Topic: Live 2.0 Compatible Exploit (Read 985 times)