|
  |
 Double dashboard exploit |
|
|
| debeautar |
 May 5 2004, 02:50 AM
|
X-S Member
Group: Members
Posts: 109
Joined: 13-March 03
Member No.: 27182
|
I'm quite happy that this method is being explored as heavily as has been the case lately. Logic has been swimming in my brain throughout my entire day at work, and I've been trying to think of methods in which this would work...
a) The old, pre-live dash is a requirement... because it reads the font files from C, and not from C:\fonts ... okay, I got that. So does that mean that the newer, xlive xboxdash.xbe is hardcoded to search for ROOT:\fonts\*.* ... instead of, per se, *\fonts\*.*? (I hope that made sense... another way of saying it is, is the path defined, or is it left open? if it's left open, why couldn't a newer dash be used, and a font folder be placed in the live's folder?)
<ignore>b) Because we're signing the old dash with the habibi key anyway, wouldn't it be plausible to edit the heck out of that file, so that it reads the font files we want it to read?</ignore>
EDIT: GOD, I'm an idiot! Just read the part about putting the original dash back, and letting bert and ernie do their job. I'm sorry if you read my orig.
c) This seems like it's a great step forward... but if you have to actually warm up any particular xboxdash to make it work, would all of this effort in the end make it the clear alternative? Or are we only having to warm it up until someone packages the thing and stamps the X-S seal of approval on the thing?
Not a newb, just not normally a heavy-handed hacker. Don't flame me, I clearly admit I don't know what the hell I'm talking about.
Yeah.
edit: files and folders were interchangable in my first draft. Stupid me.
This post has been edited by debeautar: May 5 2004, 02:58 AM
|
|
|
|
| |
| mkjones |
May 5 2004, 09:53 AM
|
X-S Freak
Group: Members
Posts: 1427
Joined: 7-April 03
Member No.: 30843
|
| QUOTE (zorxd @ May 5 2004, 11:44 AM) | | or use the audio exploit to turn on the double dash exploit again after playing on live |
But then you would lose all audio abilities such as in game music and soundtracks while you were playing on live games.. Running 2 exploits, although a great idea to get around the clock loop problem shouldnt be any part of this exploit. I am sure people want just one exploit with no switching and still the ability to use audio. Live! as ever is an issue with this exploit, just like it is with Modchips.. I really hope the people in the know get this thing working  I could use it now as I have all my games on my xbox HD anyway!Only problem I can forsee is it seems to be "different" for every xbox so a package/installer would be hard to code. For now, il stick with my package and the MA fonts, the font/audio switch is the 2nd safest option after this one  Does anyone think there is a way to get this working with later Dash versions? Higher than 4920 I mean? My thinking is it should work, becuase the latest dashboards are simply patched for the fonts and audio hacks, not this. This post has been edited by mkjones: May 5 2004, 10:05 AM |
|
|
|
| |
| rmenhal |
May 5 2004, 03:15 PM
|
X-S Senior Member
Group: Members
Posts: 254
Joined: 3-May 04
Member No.: 117780
Xbox Version: unk
360 version: unknown
|
| QUOTE | | This is indeed interesting. Trying to understand this. The bytes you have os replace in the hexed xolinedash.xbe (68 00 10 01 00 C3) for doing the probing. Do they make a jump to the probe.bin code we have imbedded in xonlinedash ? At the point where the led is blinking red the 'reset-on-eject' flag is not set, so seems likely the xbe has to load succesfully before the flag is set. |
I updated my previous posting. I think I made a mistake and used the xbedump that sets 0x80000000 instead of the newly compiled one. But yes, those bytes jump to address 0x11000 where the execution of probe.bin starts.
| QUOTE | | I don't see why this is so good? At the time bert overwrites the SEH pointer the reset-on-eject is enabled? But at this point we dont yet have any real control yet do we? We still havent made the jump to the exploit code of ernie - or? So if the reset-on-eject flag is allready set at this point how could we prevent this? Please educate me :P. But I mean, dont you think we have to prevent this flag from being set - once it is set it cannot be reverted? |
It would have been good, because at 1) the reset is disabled, at 2) it is enabled, and by what I said before "This is interesting" the reset was disabled. So Dashboard would have had to (for some odd reason) to enable and then disable it. So just check how it disabled it. Unfortunately, it's not so easy. I will look into the kernel export 365 next. That enables reset-on-eject.
This post has been edited by rmenhal: May 5 2004, 03:17 PM
|
|
|
|
| |
| debeautar |
May 5 2004, 09:29 PM
|
X-S Member
Group: Members
Posts: 109
Joined: 13-March 03
Member No.: 27182
|
Wait... it might be possible for me to actually have an applicable, not-so-far-fetched, knowledgable offering!
Check this action out.
Okay... so, once all of the kinks are worked out of this process, and the double-dash method indeed works with all features asked for (no reset-on-eject, easy-working-yay)... would it then be possible to pre-train different bert files for each separate version of pre-live dash? Or, does EVERY single dash have its own unique quirks, like an eeprom to an xbox hard drive?
this way, once we're in the packaging phase (cart before horse, I know)... most everyone would be covered.
I will be forced to wait for progress, as I apparently suck rocks with a hex editor... tried following instructions, and couldn't find the right offsets, NOR could I find particular values for editing.
I leave the fate of exploitation in all of your capable hands. I am but a yutz.
Yeah.
|
|
|
|
| |
|
|
|
. But I mean, dont you think we have to prevent this flag from being set - once it is set it cannot be reverted? 
