Print

[underthebridge]

QUOTE (mnm6687 @ Aug 25 2003, 07:46 AM)

This exploit will be much more convenient for the user, allowing the ability to launch phoenix when preferred, WITHOUT THE USE OF AN AUDIO CD.  This will be a defanite fix for the clock loop, and will prove the most successful exploit out there if it is ever completed.  So if you are a programmer or know anything detailed about the source code of bert and ernie, step in and help us get this done!

now if something like this could be posted on the front page...

[Mordenkainen]

What versions of the font exploits have you tried?

I would try each one of them one by one. It is possible that the failure is not due to a memory issue (though it could very well be). It may be due to the fact that the clock recovery code that is in most of these hacks can't deal with the system already being up!

Try the original FreeVox ones, as I don't think that do anything with the clock.

My understanding is that the memory should be brainwiped on the change from one XBE to another. Seeing as how the X runs stuff, I don't think there would be a big difference in loading at boot or any other time. Everything else in mem shoudl get ripped out of there when the new XBE runs.

Morden.

[underthebridge]

[PedrosPad]

QUOTE

Now when I try to run the very same xboxdash.xbe from Evox, the exploit crashes. So ask yourself, what is different in this case?

Potentially, quite a lot.  This isn't a valid test as the system state is already 'unpredictable' and/or contaminated.  (The only 'predicable' system state is from a cold start).

Scenario 1 (No Mod chip): MS BIOS boots 4920 xboxdash.xbe, B&E font exploit used to spawn Evolution-X, Evolution-X then used to execute 4817 xboxdash.xbe.

B&E font exploit probably leaves a footprint in memory (possibly the entire 4920 xboxdash.xbe that didn't terminate cleanly)
Evolution-X remaps logical drives to physical volumes (so DVD games executed from the hard disk, 'think' there executing from the D drive.)
Evolution-X may also leave a further footprint in memory, if not itself, it may leave a stub in order to patch the loaded XBE to modify it's media flags, and to implement it's software InGameReset feature.  (Even if IGR is turned off, Evolution-X may still leave the necessary stub in memory).

Scenario 2 (Using a mod chip): Hacked BIOS boots Evolution-X, Evolution-X then used to execute 4817 xboxdash.xbe.

The hacked BIOS doesn't, by definition, behave the same as the MS BIOS.  The hacked BIOS may be a different length, use RAM differently (more or less buffers during bootup), etc.  So even if the use of Evolution-X were completely transparent (unlikely), then the 4817 Dash would still be in a different location in memory.


Interestingly, I recall a while ago I tried executing the xboxdash.xbe from a standard Evolution-X menu (as apposed to the Evolution-X special 'Run Dashboard' command) and it didn't work.  But when I used Evolution-X to launch the Xcommander file manager, the Xcommander file manager did execute the xboxdash.xbe fine.  It appears that Evolution-X's special 'Run Dashboard' menu task does something different to the default launch action used to lunch standard XBEs.

Pedro.

PS. Not likely but, Evolution-X (by supporitng it) also reveales thay XBEs can take command line arguments.  The BIOS could execute the xboxdash.xbe with a command line argument.  Executing xboxdash.xbe without the unknown argument may also cause different runtime behaviour.
eg.
BIOS -> C:XBOXDASH.XBE GoodClock
BIOS -> C:XBOXDASH.XBE BadClock

[PedrosPad]

[duplicate msg deleted]

[Grospolina]

This potential hack sounds interesting.  I hope we can eventually get it working.  Unfortunately, I don't have the "old" dash, so I can't try it out myself.

Anyways, I've been spending the last days analyzing the font hacks.  Like underthebridge, I've been ale to disassemble and reassemble the fonts.  I've even experimented with changing the code to be a little more efficient and to load PBL from E: drive instead of C: (doesn't work with F: drive).

Anyways, I'll post my comments in a new thread, since other people may find it interesting too.

[Mordenkainen]

Well,


First off, all the fonts patch the kernel in mem. If you have Evox up, then it is not the kernel it expects to see... This may be cause that issue anyway.

Second off. The non-evox IGR, is done by the BIOS, not through SW.

Third, there is no such thing as a "child" process on the X. All other programs go bye bye when a new one is run. A program can have multiple threads, but not processes. When the XODash "returns" it is actually RUNNING the original, as there is no longer anything to return to!

As far as I am aware there is no way for a program to leave a "stub" in mem. I guess it could patch code into the XBE as it is loaded. But once loaded only that XBE would be able to execute. At least this is what all evidence points to.

I would assume that even the MS Dash maps D:\ to the application dir as XLaunchNewImage will NOT start an XBE that isn't mounted there, though it seems that EVOX has the ability to do so (damn I wish I could figure out how they did that, it would be SO useful!).

From examining the code, the only "footprint" the B&E leaves in memory is a corrupted signature key, the "font" signature.  B&E may also patch the BIOS to get around the first gen media check.

But, all this being said, it may be a memory location issue. The BIOS may use a very different method to load a XBE that the XLaunchNewImage API. This may result in a vastly different memory structure.

Unfortunatly, I don't know how you would figure out the new memory areas that the exploit is dumping to.... Does the XDK have the ability to explore memory on the X just like VC can on the PC? If so it should be fairly simple. If not....

Oh, and as far as loading the dash off of F:\, it can't because the standard BIOS doesn't know there is an F:\

Morden.

[mnm6687]

QUOTE (Grospolina @ Aug 26 2003, 11:36 AM)

This potential hack sounds interesting.  I hope we can eventually get it working.  Unfortunately, I don't have the "old" dash, so I can't try it out myself. Anyways, I've been spending the last days analyzing the font hacks.  Like underthebridge, I've been ale to disassemble and reassemble the fonts.  I've even experimented with changing the code to be a little more efficient and to load PBL from E: drive instead of C: (doesn't work with F: drive). Anyways, I'll post my comments in a new thread, since other people may find it interesting too.

to change the location of where the dash will load, change al instances of partition2 to partition6.  i am not a programmer or anything, but doesn't this make sense?

[Mordenkainen]

The reason that the font files will not load a file on F:\ is that according to the BIOS in use at that time there is NO F:\, you need to use PBL to load a BIOS that supports it.

BUT, potentailly the font exploit could patch the bios to recognize F:\ before trying to load the dash. It's already patching things... Whats one more thing?

[underthebridge]

QUOTE (PedrosPad @ Aug 26 2003, 10:31 AM)

Further speculation: Supporting the 'different location in memory theory', wouldn’t the XODash.xbe be loaded as a 'child' of the xboxdash.xbe (and not replace it in memory), as XODash.xbe allows you to ‘return’ to the parent dashboard?

the fact that you can return to the dash (quickly!) supports the idea that the memory is not wiped upon the launch of xbe

QUOTE

And in this case, wouldn't the 4920 Dashboard's fonts be cached in memory?  We know that the fonts aren’t selected by filename (it doesn't matter what filenames the XTF files have).  In MS Windows, they're selected by 'characteristics' (typeface, point size, etc.).  Assuming that the 4817 Dash is being loaded as a 'child' of the 4920 Dash, wouldn’t it already find fonts with the 'characteristics' it needs in the parent's font cache, and not load the hacked versions?

Even if this were true, the 4817 dashboard launched from xblive won't load without its original fonts on the root. If these are present (and can be given any name *.xtf), then it starts up perfectly. This shows that the fonts on root ARE loaded, which should be all that is needed for exploit purposes.

So really the problem can only be either:
- Mem change
- Different method of launching xbe (bios launching code or command line arguments diff. than xbl launching code)

[andrelrandrade]

So, were do i find the dash 4817???
I wanna do this kind of exploit but i cannot do it because Ive not the dash 4817
If is there somebody who can send me by mail I would be thankfull

[Mordenkainen]

Um... Do a search for "update" and "dash" you will find it.

You can even search with my name in addition... I know I posted this several times.

Morden.

[afon]

i have found two (almost for sure) useless facts:

If an audio Cd is inserted, then clicking xbox live, it plays a few seconds of the first track on the cd, telling us AUDIO is loaded before XTF.

If the sound Directory is renamed to sAudio, the dash starts to load, but is crashed because of fonts.


Im out of ideas, this is a brilliant idea in the first place..but more brillance needs to be interviened to execute.

[underthebridge]

I just realized another advantage of doing this-- IT will most likely be resistant to any dash update from m$, because it relies on a vulnerability in an older dash. Even if M$ were to patch up their newer dash (soon to be released), we can still access the exploit as long the execution of an arbitrary signed xbe thru xblive is still allowed.

If M$ does indeed patch up their stuff, then I suspect it'll be more of a reason for someone to get this shit going...

[Grospolina]

QUOTE

The problem is that the update will overwrite not only your dash with a new one but also overwrite the xboxlive xbe too.. thus killing your exploit and leaving you with no way to access you box unless you get a modchip. :-(

That's not necessarily true.  You should always leave the MA/007 gamesave hack on your system, just in case you can't access the dash.  That way, you can get FTP access in order to fix things up.