Print

[PedrosPad]

QUOTE (Blindside @ Sep 3 2003, 01:15 PM)

Interesting thoughts Pedros - pre-release demos and demos probably are less secure than they probably should be. I never considered it from that viewpoint.

Often the compression/encryption of datafiles (maps, graphics, sounds, etc.) is left until the final stages of development (Alpha/Beta).  This allows files written out by the 'tools' to be used directly for fast turnaround during development.  Title specific compression/encryption of datafiles is a nobrainer that is often left until last.  

If the 'sales' team want a developement cut  for a trade show (or cover disk;)), etc......

Pedro.

[af12345]

ill do some testing to see if i can load ms signed xbes (from magazines) from retail bios on the HD.

Unfortunately, I can't seem to get the latest version of XBTool to work for me, I get the "Invalid config params for kernel extract!" error. Even though I'm using the same RC4 key that worked for the earlier versions.

The idea I got is once I've loaded Evolution X Dash through Audio St.db... then to load another copy of Phoenix which boots a retail bios such as 4817 but the BFM version. Inside that Bios I will set the first boot XBE to E:demo.xbe which will be the game cd/or magazine cd, ive copied onto the hard drive. Enables me to test all this without losing my XBoxLive menu item just yet.

Does that kind of make sense? Will report my progress with the magazine CDs once I can get rid of this annoying XBTool problem!

[af12345]

QUOTE (Blindside @ Sep 3 2003, 01:15 PM)

AUF won't run from the HD unless we load it from Evox (unless I'm mistaken). We have to get to Evox first to run anything from the hard-drive.

What i was thinking was to copy at least parts of AUF to the C:xodash
then rename the AUF default.xbe to xonlinedash.xbe. As long as there arent media checks, i don't see why this wouldn't work.

More the point of this is that whilst using AUF to boot EvoX is a hassle. but if we could get something more generic which has an explout (read: smaller) like a xbox magazine game cd, then maybe this might be a potential solution. This is pretty much what the original post in this thread invisioned... just thinking of other solutions if we're unable to get Bert & Ernie running through the menu item.

[PedrosPad]

QUOTE (af12345 @ Sep 3 2003, 02:03 PM)

ill do some testing to see if i can load ms signed xbes (from magazines) from retail bios on the HD. Will report my progress with the magazine CDs once I can get rid of this annoying XBTool problem!

Sounds like interesting research.  There may be a PC utility (xbedump?) that would reveal the media flag settings without having to actually copy the things onto an actual XBOX.  I'd focus on early games and cover disks.

I've been waiting for an OXM cover disk that allows you to save and restore progress.  Then the MA/007 save game exploit could be applied and used for free.

Certainly, knowing what M$ signed XBEs run from the HD may open up new avenues for exploits.

Pedro.
PS. Many commercial game also contain XBEs, additional to the default.xbe.  e.g. Project Gotham Racing has a separate XBE for the 'future games' demos.

[PedrosPad]

QUOTE (PedrosPad @ Sep 3 2003, 11:14 AM)

Didn't I read in 'Bunnies' book that the high address lines aren't physically connected?

Didn't I also read that 'Bunnie' discovered this due to some of the original XBOX developers using high addresses (e.g. 0xD004CD40, and others using low addresses(0x0004CD40)?

Also

QUOTE (A Quick Review of Structured Exception Handling @ Sep 3 2003, 11:14 AM)

In essence, the SEH frames form a linked list, with the head of the list pointed to by FS:[0]. It's critical to note here that each successive node must be higher on the thread's stack. The operating system enforces this particular rule, meaning that you can't just arbitrarily make your own handler frame and insert it into the list.

So 0x0004CD40 could be a valid pointer to a, fallback, terminating SEH frame in low memory (or the BIOS) (The infamous 'Error 21' screen-of-death?) but has to be addressed as 0xD004CD40 so it appears higher in memory to pass "operating system enforcement".

Pedro.

[Grospolina]

The article "A Quick Review of Structured Exception Handling" says that SEH is done on the stack.  It also says that vectored exception handling was added into Windows XP and wasn't in Windows 2000 (which the Xbox kernel is based on).  The XboxSDK help file (which I extracted manually from the XDK setup file) corroborates this, as it only mentions SEH and not VEH.  Also according to the help file, each thread maintains its own exception handlers and has its own stack space.  This must be what we're breaking into.

Edit:
Also, the Xbox uses 26-bit linear memory addressing.  The 64 MB of RAM fits into this exactly.  Therefore, the D0 in 0xD004CD40 is probably some kind of flag, but it's not something that's simply ignored (as we found out).  Memory address 0x4CD40 would probably be somewhere in the application code.  I thought it was supposed to be on the stack?  Are we really modifying the SEH frame?  What are we missing?

[Grospolina]

Paraphrasing:
Using XLaunchNewImage is called "quick-booting" and takes less than one second.  After rebooting, all memory is cleared, except for the 4 KB launch data structure!  The kernel reboots itself, but the hardware is not reset.  You can leave the frame buffer intact, in order to show a splash screen between XBEs (for instance, a new level may be stored in a separate XBE).

So if this is correct, this MUST be our problem!

[underthebridge]

[[]V[]nm6687]

keep up the good work guys, and PM me or reach me on AIM mnm6687 for more information.

[Grospolina]

QUOTE

hey grospolina, you know you can open that setup in WinRAR, right? dont know if that helps, but you have access to every file in there.

Thanks, but I know.  That's how I extracted the help file.  Anyways, I just found out that I need Visual Studio .NET Professional, not Enterprise.  Now where am I supposed to get that??

[death trap]

Why cant I see Grospolina's post

[PedrosPad]

QUOTE (Grospolina @ Dec 10 2003, 08:56 PM)

I'm here.  Sorry for the vanishing act.  I wasn't abducted by aliens (AFAIK). It was a long read, catching up on all the things I missed in this thread.  I need to let it soak.  I'll be back soon.

Welcome back m8.   Glad to have your aboard again.  I'll draft a summary/state-of-play update fing and post it later.

[BonerDoner]

[butters4life]

[PedrosPad]

QUOTE (Grospolina @ Dec 12 2003, 09:21 PM)

If you can use MI to load PBL and EvoX, then the clock loop is probably mostly solved.  Is this what most people are using now, or are they scared to try it?  There doesn't seem to be all that much conversation about it, which surprises me.  Did I miss something of earth-shattering importance?

The MI-EvoX fonts, always drop you on the MS Dashboard, the previous B&E fonts, went directly to the Evolution-X menu.  I think people miss this (yes, pressing down, and 'A' is too much ).  What would be ideal is, if clock is fine, jump directly to Evolution-X (like B&E), else jump to MS Dashboard.  If this can't be determined automatically, it's been suggested that the DVD-tray state could be used to force the required behaviour.  e.g.  If tray closed, act like B&E, and jump directly to Evolution-X, else, if tray open, act like MI-EvoX, and jump to the MS Dashboard.

I've been working toward this myself, but current IRL work pressures are leaving me very little personal time.  

Pedro.