Topic: Xbox Live Exploit (Read 2551 times)

Nailed · « **Reply #120 on:** August 26, 2003, 10:02:00 PM »

QUOTE (krazykamikaze @ Aug 27 2003, 04:02 AM)

QUOTE (underthebridge @ Aug 27 2003, 04:31 AM)

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.

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. :-(
Maybe by putting our hacked live xbe read only, the update wont ovewrite it and the hack will remain there...
But who knows what MS will program to make sure the update does go to the HD.
Maybe if a hacked bios keeps an eye on our hacked live xbe and prevents it from being overwritten with an update...
But we'd have to make sure to activate the live xbe so it loads the hacked bios before we insert any new game disc that might have a type of automatic dash update.
(By "live xbe" I mean the older dash that look for fonts in root C: that we rename to replace the real xbox live xbe.)

You've completely missed underthebridge's point. It's very likely MS will overwrite xboxlive.xbe when updating the dashboard, in which case someone would use the Mech Assault exploit or such to replace xboxlive.xbe with the original xboxdash.xbe. A BIOS monitering xboxlive.xbe would be overkill.

The real point is that as long as MS calls an xbe from xboxdash.xbe, this new method would continue to be easily exploitable (assuming its possible). Of course a smart developer could prevent this exploit from a future dashboard quite easily... but that's neither here nor there.

krazykamikaze · « **Reply #121 on:** August 26, 2003, 10:03:00 PM »

QUOTE (Grospolina @ Aug 27 2003, 06:54 AM)

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.

But who knows if the update won't disable the gamesave hack and audio hack...

hmm.. thinking about it and they would actualy have to patch the bios or the game itself to fix this exploit... of course M$ can't do either on our xbox !

Cool !

But they could patch the audio exploit easy.

krazykamikaze · « **Reply #122 on:** August 26, 2003, 10:11:00 PM »

QUOTE (Nailed @ Aug 27 2003, 07:02 AM)

You've completely missed underthebridge's point.

Not really... I just didn't realise (at that moment) that MS can't patch the bios as that would require a bridge to be closed. And they can't patch the game either because it's rom device (dvd-rom) and there's no auto-patching mecanisme on the xbox...
I do understand the point of this, it's just I didn't think it thru before posting my reply. but thanks for keeping me in check

Nailed · « **Reply #123 on:** August 26, 2003, 10:27:00 PM »

QUOTE (krazykamikaze @ Aug 27 2003, 06:03 AM)

hmm.. thinking about it and they would actualy have to patch the bios or the game itself to fix this exploit... of course M$ can't do either on our xbox !

Actually this exploit could be easily closed without patching either the bios or a game. But since I don't play on XBoxLive, doesn't matter to me.

As a side note, I'm convinced once someone determines where the new buffer overflow occurs, this exploit will be cake.

PedrosPad · « **Reply #124 on:** August 27, 2003, 01:31:00 AM »

QUOTE

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)

The mem change is likely.
The command line parameters is very unlikely, but remains until proven false.

Ok, a strategy:

1. Prep:
Someone with an X2 Pro (or other switchable mod chip) burns 2 'hacked' BIOS into their mod chip, BIOS 1 boots xboxdash.xbe first, BIOS 2 boots Evolution-X first (use XBTool?).

2. Verify assumptions
Switch to BIOS 2 (booting Evolution-X)
FTP Dash 4817 & B&E onto C:.
Switch to BIOS 1 (booting 4817 xboxdash.xbe)
Verify that B&E & 4817 Dash 'function' as expected using a hacked BIOS. (Confirming that the xboxdash DID load into the correct memory position even with the mod chip).

3. Gather information
Switch to BIOS 2 (booting Evolution-X)
Someone with the an XBOX assembler builds a light weight GETMEM.XBE that find's it's location in memory* and writes it to a disk file (much easier than screen). Names their GETMEM.XBE xboxdash.xbe, and FTPs it onto C:.
Switch to BIOS 1 (booting fake xboxdash.xbe)
Boot. Wait a few seconds. (probably nothing to see). Shutdown.
Switch to BIOS 2 (booting Evolution-X)
FTP written file to PC and inspect to reveal xboxdash.xbe's memory address.

Someone with the XDK builds a light weight COMMANDLN.XBE that reads it's command line parameters and write them to a disk file**. Names their COMMANDLN.XBE xboxdash.xbe, and FTPs it on C:.
Switch to BIOS 1 (booting 2nd fake xboxdash.xbe)
Boot. Wait a few seconds. (probably nothing to see). Shutdown.
Switch to BIOS 2 (booting Evolution-X)
FTP written file to PC and inspect to reveal xboxdash.xbe's command line parameters.
Inspect this file to verify that no command line options are in fact present (At least this would eliminate that theory).

Switch to BIOS 2 (booting Evolution-X)
Install 4290 Dash.
Name GETMEM.XBE XODash.xbe and place in XODASH Folder.
Switch to BIOS 1 (booting 4290 xboxdash.xbe)
Select XBOX Live option (executes fake XODash.xbe, that write ITS memory location to a file on C:)
Switch to BIOS 2 (booting Evolution-X)
FTP written file to PC and inspect to reveal xodash.xbe's memory address.

4. Take actions
Compare the memory address captured for xboxdash.xbe with that captured for xodash.xbe. If they're the same we're screwed.*** It they're different, subtract xodash.xbe's address from xboxdash.xbe's address, revealing the offset.
Apply offset to hardcoded memory addresses in Bert & Ernie font files.
Switch to BIOS 2 (booting Evolution-X)
FTP modded B&E fonts to C: & put 4817 Dash in XODash folder.

5. Test
Switch to BIOS 1 (booting 4290 Dash)
Choose XBox Live option
View results.

Pedro.

Footnotes:
* Finding the location in memory in assembler appears fairly easy. Just 'jump-to-subroutine' to the following instruction and pop the pushed return address from the stack.
** I expect that reading the command line arguments, not to mention the writing to a disk file, is easier in C++ with the XDK. This XBE can be tested by executing it from the Evolution-X menu which allows command lines args to be supplied.
*** Bugger. This would imply that the LaunchNewImage library function called from the 4290 Dash is very different from the BIOS XBE launcher.

PedrosPad · « **Reply #125 on:** August 27, 2003, 02:37:00 AM »

A further thought:
Since finding your location in memory is so straightforward in assembler, why not build this into Bert & Ernie, making them entirely relative?
My brief review of the B&E source is that they are already largely relative which means that we could be barking up the wrong tree (but of course it only takes one physical address to screw things up).

Pedro.

Mordenkainen · « **Reply #126 on:** August 27, 2003, 05:08:00 AM »

Actually, it's the fonts we need to change.

Has anyone here acutally ever tested for a buffer overflow?

I work in QA, and this is what we do to examine our SW for buffer overflows:

1. Take the font exploit files and replace the "meat" of them with a repetative pattern of opcodes. (Like the jump net currently in the fonts, but you want to make sure it hangs the system.)
2. Do what underthebridge is doing, but when the system freezes use a remote debugger to examine the memory. It should be a very simple matter to find your repetative pattern.
3. Now that you have the memory locations the new dash is loading to, you should be able to modify the fonts.

The catch here is that I don't know if there is a capability to remotly examine the memory of the XBox like you can do with a PC!

Just capturing the memory address of xboxdash.xbe or xonline.xbe won't help, as it is the addresses of the FONTS we would need.

As far as applying the offset to the fonts, I don't think that is the problem, remember that is what the jump net is for. One font points in the general direction of the other.

Morden.

PedrosPad · « **Reply #127 on:** August 27, 2003, 05:58:00 AM »

QUOTE

What I mean, does it ever get to Ernie's code, or is it crashing when Bert tries to do the overwrite to get SEH to step into Ernie's code...

Any ideas on how to verify this?

QUOTE

Or maybe the font code needs to be reversed such that the code comes at the beginning and the jumps at the end?
a bigger font might do the trick (say 64 MB)

An intriguing idea.

Mordenkainen

QUOTE

I work in QA, and this is what we do to examine our SW for buffer overflows:
....
The catch here is that I don't know if there is a capability to remotly examine the memory of the XBox like you can do with a PC!

Your spoilt. I'm from the old school of embedded devices and no tool assistance.

QUOTE

Just capturing the memory address of xboxdash.xbe or xonline.xbe won't help, as it is the addresses of the FONTS we would need.

True, but assuming that the heap begins at the end of the XBEs location in memory, and that the fonts are placed in the heap, the offset would still be revealing.

Pedro.

PS. The GETMEM.XBE exercise would also clarify once and for all
whether the xodash is a spawned child, or replaces the parent
whether ALL XBEs are loaded into an identical location, as has been implied in this thread.
and could also be used to verify whether Evolution-X does leave any stub in memory to implement its S/W IGR.

Mordenkainen · « **Reply #128 on:** August 27, 2003, 07:01:00 AM »

Well I'll see if I can bang together an app that will record the current IP value.

I don't think I can get the "location in mem" for the start of the program. but I can certainly grab the current IP value, then dump it to disk. As the location in compiled code will not change it should give us a general, if not exact, location in mem. Enough to tell if the app is being loaded to the same location in memory or not should be enough....

The hard part is distributing it!

I will look into it today.

Morden.

EDIT - Scratch that.... My compiler has gone all flaky.... But, I can write the source and post it here if someone else wants to compile it. I will not be able to ensure the code is 100%correct though!

Mordenkainen · « **Reply #129 on:** August 27, 2003, 08:10:00 AM »

CODE

#include
#include
#include

#define DEBUG_FILE "D:\\mem.log"
#define IN

typedef struct _UNICODE_STRING {unsigned short Length; unsigned short MaximumLength; PSTR Buffer;} UNICODE_STRING,*PUNICODE_STRING;
extern "C" XBOXAPI DWORD WINAPI IoCreateSymbolicLink(IN PUNICODE_STRING SymbolicLinkName,IN PUNICODE_STRING DeviceName);
extern "C" XBOXAPI DWORD WINAPI IoDeleteSymbolicLink(IN PUNICODE_STRING SymbolicLinkName);

void debug(char *str)
{
   FILE *fp;
   _SYSTEMTIME MySystemTime;
   GetLocalTime(&MySystemTime);
   char szDate[300];
   sprintf(szDate, "%u/%u/%u %u:%u:%u", MySystemTime.wDay,   MySystemTime.wMonth, MySystemTime.wYear, MySystemTime.wHour, MySystemTime.wMinute, MySystemTime.wSecond);
   fp=fopen(DEBUG_FILE, "a+");
   fprintf(fp, "%s\n", szDate);
   fprintf(fp, "%s\n", str);
   fclose(fp);
}

void UnmountD()
{
   char szDestinationDrive[16];
   strcpy(szDestinationDrive,"\\??\\D:");

   UNICODE_STRING LinkName = { strlen(szDestinationDrive), strlen(szDestinationDrive) + 1, szDestinationDrive};

   IoDeleteSymbolicLink(&LinkName);
}

void MountD(char* szDevice, char* szDir)
{
   char szSourceDevice[256];
   char szDestinationDrive[16];

   strcpy(szDestinationDrive,"\\??\\D:");
   sprintf(szSourceDevice,"\\Device\\%s",szDevice);
   if (*szDir != 0x00 && *szDir != '\\')
   {
strcat(szSourceDevice, "\\");
strcat(szSourceDevice, szDir);
   }

   UNICODE_STRING LinkName = { strlen(szDestinationDrive), strlen(szDestinationDrive) + 1, szDestinationDrive};
   UNICODE_STRING DeviceName = { strlen(szSourceDevice), strlen(szSourceDevice) + 1, szSourceDevice};

   IoCreateSymbolicLink(&LinkName, &DeviceName);
}

void __cdecl main()
{
   DWORD location;
   TCHAR szIP[16];

   UnmountD();
   MountD("Harddisk0\\Partition1", "");

   debug("Started GetMem.");

   __asm
   {
call $+5
pop ebp
mov location, ebp
   }

   ltoa((long)location, szIP, 10);

   debug(szIP);

   debug("Ended GetMem");

   Sleep( INFINITE );
}

Mordenkainen · « **Reply #130 on:** August 27, 2003, 08:13:00 AM »

The above code SHOULD do the following:

Open a file on D and put a started line in it, then the current IP (instruction pointer) address, then an ended tag.

Morden.

Mordenkainen · « **Reply #131 on:** August 27, 2003, 08:46:00 AM »

As far as Bert....

I dissasembled it a couple of ways, neither makes a lot of sense: (Mind you I don't know much about assembly, and without knowing the exact location where the overflow occurs makes this difficult. )

try 1:
AND [BX+SI],AH
DB C0
ADD [BX+SI-33],AL
ADD AL,D0
JMP 0108
INC CX
INC CX
INC CX
INC CX
INC CX
INC CX

The DB C0 makes this a look kinda wierd, it defines a byte then never refernces it that I can tell. (and I don't think C0 is a valid opcode. Anyone?)

try 2: (removing the first 20, perhaps the overflow doesn't start right after the header?)
AND AL,AL
ADD [BX+SI-33],AL
ADD AL,D0
JMP 0108
INC CX
INC CX
INC CX
INC CX
INC CX
INC CX

This looks a little better, but that first line AND AL,AL thows me, as the result would be..... AL!

Please correct me if I have missed the obvious!

Morden.

Mordenkainen · « **Reply #132 on:** August 27, 2003, 09:04:00 AM »

CODE

__asm
{
push ebp
call $+5
pop ebp
mov location, ebp
pop ebp
}

That should be better?

Morden.

Blindside · « **Reply #133 on:** August 27, 2003, 10:38:00 AM »

how about this (decoded from location 0x00000034 and above):
:00000000 004100 add byte ptr [ecx+00], al
:00000003 41 inc ecx
:00000004 014100 add dword ptr [ecx+00], eax
:00000007 41 inc ecx
:00000008 024100 add al, byte ptr [ecx+00]
:0000000B 41 inc ecx
:0000000C 2020 and byte ptr [eax], ah
:0000000E C00040 rol byte ptr [eax], 40
:00000011 CD04 int 04
:00000013 D0EB shr bl, 1
:00000015 FE4141 inc [ecx+41]
:00000018 41 inc ecx
:00000019 41 inc ecx
:0000001A 41 inc ecx
:0000001B 41 inc ecx

The INT 4 instruction is ignored (a NOP) unless the overflow (OF) flag is set. Is it possible maybe the flag is set, causing an exception to be generated and thereby starting the magic that is ernie?

Morden,
C0 is the opcode for ROL (rotate left)

Blindside · « **Reply #134 on:** August 27, 2003, 11:15:00 AM »

Reading the technical analyses of bert and ernie (http://phoenix.maxco...rternie.inc.php), there is something I don't understand.

It seems like Ernie is designed to be loaded first, and then bert. If bert loads up and the underflow REALLY munges memory, it's possible that an exception is generated *before* ernie gets loaded (for example in the font loader code). Seems like if Ernie is loaded first, followed by Bert, any exceptions after that should trap into Ernie and execute from there (since it is already loaded).

Ernie is actually xbox.xtf - is this the font that normally gets loaded first?

Man this is cool stuff - I wish I had another $150 to blow on an XBox so I could tear the thing apart...

Author Topic: Xbox Live Exploit (Read 2551 times)