Post by: PedrosPad on June 18, 2004, 01:39:00 PM
Two bits caught my eye:
| QUOTE |
| This XMTAXBOX.XBE is an XBE retail-signed for hard disk |
and
| QUOTE |
| A new Xbox still contains the file XMTAXBOX.XBE on the first cache partition, as well as some temporary files on the third one. |
This may be able to be turned into a new bootstrap for UDE (that just might work on Kernel 5713).
This is long gone from my XBOX cache. Anyone with a new XBOX found this? The cache drives are X:, Y:, and Z:.
PM me
-
Title: Xmtaxbox.xbe?
Post by: Angerwound on June 18, 2004, 01:56:00 PM
-
Wow, very very interesting. I am curious as to if it will try and access the fonts as well as what it actually performs when launched.
EDIT: Here's its actions:
This XMTAXBOX.XBE is an XBE retail-signed for hard disk, also with the region code set to 0x80000000, that does the following:
* retrieve the EEPROM contents from a network server
* retrieve the contents of the system and data partitions from a network server
* lock the hard disk
* make some self tests and send the report to the server
-
Title: Xmtaxbox.xbe?
Post by: RiceCake on June 18, 2004, 02:00:00 PM
-
Might work but if something goes wrong, could cause some major havok.
Edit: Does this set reset-on-eject or not? Might be the answer to a double-dash layout.
-
Title: Xmtaxbox.xbe?
Post by: Angerwound on June 18, 2004, 02:09:00 PM
-
Just checked my virgin box to see if it possibly still existed. However, it doesn't.. Maybe someone will grab a copy, preferably from a 5713 console
I'm almost tempted to go buy a new 1.6 box, check the cache and take her back...
-
Title: Xmtaxbox.xbe?
Post by: RiceCake on June 18, 2004, 02:14:00 PM
-
Lol, crazy bastard.
Would be one of the only ways to get it. (Well without requesting it which would get a bad rap from the forum admins.)
-
Title: Xmtaxbox.xbe?
Post by: PedrosPad on June 18, 2004, 02:19:00 PM
-
This is long gone from my XBOX cache. Anyone with a new XBOX found this? The cache drives are X:, Y:, and Z:.
PM me
Post by: Angerwound on June 18, 2004, 01:56:00 PM
EDIT: Here's its actions:
This XMTAXBOX.XBE is an XBE retail-signed for hard disk, also with the region code set to 0x80000000, that does the following:
* retrieve the EEPROM contents from a network server
* retrieve the contents of the system and data partitions from a network server
* lock the hard disk
* make some self tests and send the report to the server
Post by: RiceCake on June 18, 2004, 02:00:00 PM
Edit: Does this set reset-on-eject or not? Might be the answer to a double-dash layout.
Post by: Angerwound on June 18, 2004, 02:09:00 PM
I'm almost tempted to go buy a new 1.6 box, check the cache and take her back...
Post by: RiceCake on June 18, 2004, 02:14:00 PM
Would be one of the only ways to get it. (Well without requesting it which would get a bad rap from the forum admins.)
Post by: PedrosPad on June 18, 2004, 02:19:00 PM
| QUOTE (Angerwound @ Jun 18 2004, 10:56 PM) |
| I am curious as to if it will try and access the fonts |
It won't be accessing the standard Dashboard fonts - they wouldn't exist at the time it runs
It may have a UI, it may not have one at all - but it may still be exploitable 
.
Post by: RiceCake on June 18, 2004, 02:25:00 PM
If its completely stand-alone and gathers files directly to and from the server, it would probably need some weird program running on a PC.
Post by: PedrosPad on June 18, 2004, 02:31:00 PM
| QUOTE (RiceCake @ Jun 18 2004, 11:00 PM) |
| Edit: Does this set reset-on-eject or not? |
So far, Reset-on-Eject is never turned on for the first HDD based XBE the BIOS loads, regardless of it's media flags - that's one of the tricks of the UDE (see here).
If they're still using this to program 5713 Kernel XBOXs, it'd be another HDD based, non-dashboard, XBE - like Update.xbe - that would run on 5713 Kernel (See here).
Post by: RiceCake on June 18, 2004, 02:36:00 PM
Edit: Anyhow, if anyone buys an Xbox, help us!
Post by: PedrosPad on June 18, 2004, 02:39:00 PM
| QUOTE (RiceCake @ Jun 18 2004, 11:25 PM) |
| It might be loading some of those temp files, which might be exploitable. Hopefully they are loaded into memory as a way to prepare that system check information to send to the server, or a way to know what server its getting its files from. If its completely stand-alone and gathers files directly to and from the server, it would probably need some weird program running on a PC. |
My thoughts exactly
Post by: RiceCake on June 18, 2004, 02:41:00 PM
Edit: Pedro's, you got an identical XBox to mine...except mine ain't modified...bastard!
Post by: PedrosPad on June 18, 2004, 02:43:00 PM
| QUOTE (RiceCake @ Jun 18 2004, 11:36 PM) |
| Damn...why did they even bother having the reset-on-eject flags if the only (In a way) XBE that can be ejected on is the dashboard XBE? |
The Team Xecuter info claims the XBE does have the necessary 0x80000000 (ROE-stay-off) media flag, so it may be good for boot, and double-dash.
Post by: RiceCake on June 18, 2004, 02:49:00 PM
Got confused about media flags...thought 0x80000001 was ROJ=Off.
Anyhow this better work, because then its a "foolproof" UDE clone, because you can still access the dashboard in a retail mode, or like you said another loader for UDE providing an alternative to the upgrade.xbe.
Post by: devz3ro on June 18, 2004, 02:52:00 PM
-devz3ro
http://sh0x.tk/
P.S. Since there is 3 people left in the mod race (all confirmed), I will start setting up a poll soon.
Post by: RiceCake on June 18, 2004, 02:56:00 PM
Anyhow now we just need someone to buy an Xbox, modify it, grab the file, and give it to us without booting a single game...fun.
Or get lucky and boot a gamesave exploit without it overwriting the file.
Post by: PedrosPad on June 18, 2004, 03:09:00 PM
| QUOTE |
| When the Xbox kernel initializes, it checksums the EEPROM. If it fails, the Xbox will be in DEBUG mode, i.e. the region code is set to 0x80000000. <snip /> This XMTAXBOX.XBE is an XBE retail-signed for hard disk, also with the region code set to 0x80000000, |
It may be we need to zap our EEPROMs to get this to launch - the exploit could restore it before launching a game, but then how do you zap it again in time for the next boot?
Just thoughts....
Post by: RiceCake on June 18, 2004, 03:12:00 PM
As for zapping - unzapping, can't you just use a kernel-level EEPROM? That way the hardware can stay blank.
Post by: Chicken Scratch Boy on June 18, 2004, 03:57:00 PM
then we can start peeking into the hex and looking for vaunerabilities
Post by: Angerwound on June 18, 2004, 07:36:00 PM
Post by: afon on June 18, 2004, 07:37:00 PM
Zapping and unzapping? Im unfamiliar with those words. If you referring to messing with an EEPROM on each boot, i think we should stay away from that (As it has a certain amount of times it can be written to). As long as the people with new xboxs can open thier drive on boot, then tap it in to play a backup...they should be fine.
But i have a question about the MCPX setting the ROE flag. When the xbox enters the error screen when ROE is enabled...it doesnt reset on eject. Is there anyway we could find what flag is being sent to MCPX and use it to our advantage?
Post by: Australian Rat on June 19, 2004, 12:04:00 AM
| QUOTE (Yod@ @ Jun 19 2004, 08:09 AM) |
| Post Removed... |
I wouldn't say that here... even if people are looking for it.
Get it around the 'usual ways'. Don't offer for PMs. You'll regret it.
Post by: m.e on June 19, 2004, 02:29:00 AM
| QUOTE (Yod@ @ Jun 19 2004, 08:09 AM) |
| edit |
Great!
Post by: BluhDeBluh on June 19, 2004, 03:17:00 AM
It works on all regions, it is signed for the HDD, and it hasn't got the CRC32s of the two .IN files internally so it means the exploit people can modify those files. Looking in it via hex, the file uses z:\BUFFER.IN and z:\FFT.IN.
Only one flaw with this is that every time you run a game, the Z drive is deleted, so you might have to reinstall the exploit every time...
Either way, it's VERY intresting. Cheers Yod@
Post by: Angerwound on June 19, 2004, 03:32:00 AM
Post by: PedrosPad on June 19, 2004, 03:59:00 AM
| QUOTE (Yod@ @ Jun 19 2004, 08:09 AM) |
| I've got these files - XMTAXBOX.XBE off the X partition, and the BUFFER.IN and FFT.IN from the Z partition. If anybody wants them, PM me with your email address. |
Yod@, what XBOX version did you find these files on?
Post by: PedrosPad on June 19, 2004, 04:09:00 AM
| QUOTE (Yod@ @ Jun 19 2004, 01:04 PM) |
| They're from a V1.5 Xbox. *I think*. It's brand new, anyway. |
Ta. And what Kernel version does the Dashboard's 'system info' page report?
Post by: PedrosPad on June 19, 2004, 04:24:00 AM
| QUOTE (Yod@ @ Jun 19 2004, 01:04 PM) |
| They're from a V1.5 Xbox. *I think*. It's brand new, anyway. EDIT: Kernel version 5101. |
Ta. muchly Yog@, I'm off to play
But if anyone happens to find copies of these on a new Kernel 5713 or later XBOX, I'd also be intrested
Post by: PedrosPad on June 19, 2004, 04:32:00 AM
Without posting your XBOX serial number, please can you post your XBOX's manufacture date. The following link shows your where to find it, serial number format
I suspect the date of the files on the Z: drive will 'match'/'be close to' your manufacture date. Which would confirm that these files are, in fact, output files, and may not be exploitable
.(In which case I'll focus on the network aspect, and get ethereal installed
)
Post by: mkjones on June 19, 2004, 04:36:00 AM
| QUOTE (Yod@ @ Jun 19 2004, 12:54 PM) |
| Ok, thanks for the heads up. At least it's not built with an illegally-leaked version of the SDK. I'm sure enough people have it now anyway. |
Yod@ man!
(see what I did there ^? thats wordplay for ya!)
Anyhow!
Another day, another chance of an exploit..
Post by: Yod@ on June 19, 2004, 05:00:00 AM
Serial 5xxxxxx 33205
So that makes it 2003, week 32, made in China, production line 5?
Post by: PedrosPad on June 19, 2004, 05:17:00 AM
| QUOTE (Yod@ @ Jun 19 2004, 01:53 PM) |
| Manufacture date 2003-08-06 Serial 5xxxxxx 33205 So that makes it 2003, week 32, made in China, production line 5? |
Hmmmm.
The XBE file on X: is dated 2003-11-15.
The data files on Z: are dated 2003-12-05. Not now, and not then - Odd
Post by: PedrosPad on June 19, 2004, 05:46:00 AM
May still help with a UDE for Kernel 5713+ users From examining the XBE it appears like it also used some additional external support files, that I suspect it deleted as it exited (and since deleting a HDD file simply modifies the directory entry, the files contents are likely to still exist on the virgin disk - FATX undelete anyone?).
We've seen
z:\BUFFER.IN - I suspect this is a test sound sample/DSP program.
z:\FFT.IN - This is a ASCII text file, either specifying sound sample tests (and their expected results), or reporting the output of the sound sample tests (I suspect the latter as it's human readable).
but not seen
z:\surface.bmp - source?
z:\copied_surface.bmp - destination?
z:\%s-%s.bmp - used for dumped graphic test screen grabs?
Y:\xboxdash.xbe - Hmmmmmm.
z:\%s - anyone guess
z:\rawimage - graphic image, disk image? - who knows.
c:\MemoryUnitStressTest%d.txt - seems clear.
I'm backing up me XBOX 120GB HDD, before I execute this puppy.
Post by: wrayal on June 19, 2004, 06:30:00 AM
*Removing moron-post - url is where info on first page is from...*
Wrayal
This post has been edited by wrayal: Jun 19 2004, 01:31 PM
Post by: RiceCake on June 19, 2004, 06:41:00 AM
XBox boots using special disk.
The XBE first checks for the cache files, just incase it already did the testing.
System checks are run, and caches of the results are saved.
The EEPROM is written to and the hard drive is locked, dashboard probably installed.
The XBox reboots and the XBE is reloaded.
The XBE searches for and loads the cached files to send them to the server.
If this is so, badda-bing, no real worries of frying your system. Main problem is these caches would get overwritten very easily.
This post has been edited by RiceCake: Jun 19 2004, 01:42 PM
Post by: UGLYMONKEY on June 19, 2004, 11:25:00 AM
Post by: RiceCake on June 19, 2004, 06:02:00 PM
Post by: Chicken Scratch Boy on June 19, 2004, 07:30:00 PM
Post by: RiceCake on June 19, 2004, 09:54:00 PM
Post by: PedrosPad on June 20, 2004, 02:37:00 AM
| QUOTE (RiceCake @ Jun 20 2004, 06:47 AM) |
| Yeah true, but still need a crazy bastard who'll have to recover everything should this botch. |
Someone call?
. Just need to finish backing up to DVD+RW's first PS Dissassembled this XBE last night. Many of those files I listed appear to be output files. Unless I can find some input files, there may be no way to inject out own code
. Still looking through.Post by: rmenhal on June 20, 2004, 03:45:00 AM
Wouldn't zapping the EEPROM just give you a paperweight until you get a modchip?
Post by: RiceCake on June 20, 2004, 07:38:00 AM
I guess this is just a project!
Post by: wrayal on June 20, 2004, 08:09:00 AM
As this gets code from the network ("* retrieve the EEPROM contents from a network server * retrieve the contents of the system and data partitions from a network server") , might it be possible to do a PSO-style hack as on the GC?
(In above my head here, but Im guessing that as nouser was ever really meant to use this file, would there be a greater chance of finding some sort of buffer overflow in it eg. in the downloaded eeprom contents?)
But as to changing the region or whatever, I dont have a clue
. Anyone? Although it may be a difficult hack to implement at first, it just seems to me that it would be worthwhile as it would be the first universal softmod as it seems to have been used on all the xboxes until now, albeit Im sure MS could implement some new protection featureWrayal
Post by: PedrosPad on June 21, 2004, 02:40:00 AM
| QUOTE (RiceCake @ Jun 20 2004, 04:31 PM) |
| Now I'm really confused. Ah hell this seems like a bad idea anyhow, we already have the safer way of loading UDE. I guess this is just a project! |
Kernel 5317 owners can't use the existing 'update.xbe' based UDE (Becuase their Kernel prevents the execution of legacy Dashboard code). I'm looking for a MS signed, HDD flagged XBE that they may be able to use.
I agree, this one doesn't sound ideal (and rest assured, the search does continue), but this is all that's come up so far.
Post by: PedrosPad on June 21, 2004, 02:42:00 AM
| QUOTE (wrayal @ Jun 20 2004, 05:09 PM) |
| "Unless I can find some input files, there may be no way to inject out own code" As this gets code from the network ("* retrieve the EEPROM contents from a network server * retrieve the contents of the system and data partitions from a network server") , might it be possible to do a PSO-style hack as on the GC? (In above my head here, but Im guessing that as nouser was ever really meant to use this file, would there be a greater chance of finding some sort of buffer overflow in it eg. in the downloaded eeprom contents?) But as to changing the region or whatever, I dont have a clue . Anyone? Although it may be a difficult hack to implement at first, it just seems to me that it would be worthwhile as it would be the first universal softmod as it seems to have been used on all the xboxes until now, albeit Im sure MS could implement some new protection featureWrayal |
My thoughts exactly - and my current project
.
Post by: Angerwound on June 21, 2004, 09:08:00 AM
Post by: sargun on June 26, 2004, 01:22:00 PM
Post by: BluhDeBluh on June 26, 2004, 02:44:00 PM
| QUOTE (sargun @ Jun 26 2004, 10:22 PM) |
| Can some1 post it in "the usual places" |
I don't think they will post it as it's completely MS code.
Post by: PedrosPad on June 29, 2004, 06:18:00 AM
| QUOTE (PedrosPad @ Jun 19 2004, 02:46 PM) |
| I'm backing up me XBOX 120GB HDD, before I execute this puppy. |
120GB HDD/4 GB DVD-RWs = 1 full week of burning and about 30 disc's.
At least now I'm able to experiment
Post by: PedrosPad on June 29, 2004, 06:23:00 AM
| QUOTE (rmenhal @ Jun 20 2004, 12:38 PM) |
| How would you guys run this binary at boot? The region doesn't match so you would need to zap the EEPROM. On the other hand, if the EEPROM checksum doesn't match, the kernel doesn't have much reason to trust any of the EEPROM contents, wouldn't build the HD key and HD password out of it and the HD wouldn't get unlocked. So C:\xboxdash.xbe wouldn't get executed. The only thing that would get executed is D:\default.xbe with region flag 0x80000000. Wouldn't zapping the EEPROM just give you a paperweight until you get a modchip? |
Just a thought - Can't we use Configure Magic to permanently unlock the HDD, and then zero the EEPROM?
(Isn't this the state the XBOX would be in on the manufacturing line at the time Xmtaxbox normally executes?)
PS. Kidz - Don't try this at home!
Post by: PedrosPad on June 29, 2004, 02:12:00 PM
| QUOTE (rmenhal @ Jun 29 2004, 10:54 PM) |
| It may also be that the kernel doesn't even try to execute C:\xboxdash.xbe in that state (after all, the HD is empty when the box is at that stage of the manufacturing.) |
Ouch! Good point.
I should find time to finally experiment with this tomorrow.
Post by: devz3ro on June 29, 2004, 03:08:00 PM
.Another note:
After many, many hours of searching I found the "Evox m8 bios leak". Evox's note to the bios was that it will fry your xbox if you run it for a certain amount of time. Of course I believe them and if I had a 1.6 xbox, I would not flash it on a hardware mod and try it. But what if one were to patch the bios into the kernel memory? Would it have the same xbox destroying results? Or what if one were to disassemble the bios and patch the original bios with its patches?
Let me know if you think any of this is possible.
-devz3ro
http://sh0x.tk/
P.S. rmenhal: glad to see you are still breathing, I thought we lost you for a minute
Post by: PedrosPad on June 29, 2004, 03:21:00 PM
| QUOTE (devz3ro @ Jun 30 2004, 12:08 AM) |
| Very shortly I will obtain xmtaxbox.xbe from a virgin 1.6 xbox. Hopefully this will help with the code execution on both 5713 & 5838 kernels . |
That would interest me
Post by: wrayal on July 01, 2004, 11:01:00 PM
Post by: John Hoek on September 20, 2004, 07:48:00 AM
Post by: PedrosPad on September 20, 2004, 08:33:00 AM
| QUOTE (John Hoek @ Sep 20 2004, 03:51 PM) |
| Is this tread dead? |