Print

[Blindside]

Pedro,
 thanks - that was more or less what I was thinking. Someone else indicated they believe Xbox is using a heaviliy modified win2k Kernel, and of course it's still using x86, so many of the rules still apply.

Can't imagine MS completely re-writing an OS from scratch for a console.

[PedrosPad]

)

[Grospolina]

QUOTE

I believe that the entire header is copied into the allocated buffer, ahead of further reads. Meaning that anything after the first 3 bytes in the file will overwrite adjacent memory.

Perhaps, but here's something that's worth knowing: The size field (at 0x28) contains the size of the file from the beginning of the size field (0x28) to the end of the file.

QUOTE

Proven with Dash 4817 as your boot dashboard, right? (where I suspect the OS has no option but to put the Bert thread's thread metadata structure consecutively in the heap).

Actually, I was using 4920.  I was going to try 4817 next, in order to compare.

QUOTE

(This could also be an issue of alignment, try bumping the 'jump-to-Ernie' address forward or backwards a couple of bytes).

If you mean the "exception net" (as I call it), then that's not necessary.  It is a collection of 2-byte instructions that are designed to work whether it jumps to an even or an odd address.

i.e.
EB 90 EB 90 EB 90 EB 90...

If it jumps to an even address, it sees EB 90 -> jmp +0x90 (-112 bytes).
If it jumps to an odd address, it sees 90, EB 90 -> nop, jump 0x90 (-112 bytes).

All of the fonts are designed with this in mind, but they use different instructions.  All of them use EB 0E (0E -> push cs), except for Bigfonts, which uses EB FA (FA -> cli).

Have you read my Font Exploit Analysis?

And I'll give you the source.

[Nailed]

QUOTE (PedrosPad @ Aug 29 2003, 02:01 PM)

If someone can put me in touch with the Ernie NASM source code (original + rearranged) (plus a sample command line or two for NASM) I'll join in and and play with this over the weekend. Pedro. (What?  Pedro a coder? )

Same here.. I'd like to muck around in some of this.

[PedrosPad]

*bump* (to make my last post appear :-/ )

[ntdon]

QUOTE (PedrosPad @ Aug 29 2003, 04:21 PM)

QUOTE QUOTE Perhaps, but here's something that's worth knowing: The size field (at 0x28) contains the size of the file from the beginning of the size field (0x28) to the end of the file. Ah! I didn't know that.  My take from the Tech Analysis was it was the size of the whole file.  Shoots down some of my theories.  Thanks

Just want to make a quick point that the size field at 0x28 might neither be the size of the whole file (or -40, although they are the case for the most of the hacked Ernie.xtf files).  Both original 4920 Xbox.xtf & XboxBook.xtf contain 0x10c (268 bytes) in this field and both fonts in the 4817 dash have 0x41b4 (16820 bytes).  Furthermore, if you compare Xbox.xtf & XboxBook.xtf for the same dash version, you will notice that they start to differ after this offset (not counting the difference in font name in the first 40 bytes font header).  For 4920, Xbox & XboxBook differt starts at 0x138 (312), which is 268 + 44 (probaby the 40 bytes font header).

As someone already pointed out, once the heap got fragmented, the 3 bytes allocated for Bert might be allocated far away from the data structure it hopes to overwrite.  That data structure might be even above Bert's 3-byte buffer in the heap, which makes it impossible to overwrite by the thread loading Bert (I assume it keep trashing the memory from there to further down the heap).   Furthermore, dash 4817 might not use the same data structure, which makes Bert's code irrelevant (besides crashing).  Would someone please enlighten me how MS OS allocate AND reuse freed mem on the heap?

I don't have either the old dash or the necessary debug tools to investigate any further.  Although I'm a bit pessimistic, I hope someone will crack this.

[Grospolina]

Huh!  You're right!  I completely forgot to verify this in the original files.  I guess we'll have to work out these numbers then.

[Blindside]

QUOTE (Grospolina @ Aug 29 2003, 09:09 PM)

Huh!  You're right!  I completely forgot to verify this in the original files.  I guess we'll have to work out these numbers then.

Grospolina,
 I thought you had worked it out in the original font files - that's why I'm not arguing about where anything in the header is located.

We'll find out shortly now - I'm sure you'll have an answer in a short while  

[Grospolina]

QUOTE

When the XTF header is processed the dashboards reads a 4 byte blocksize field from the font file. This is expected to represent the size of some datablock including the 4 bytes of the size field itself. The blocksize is then allocated and the sizefield is copied into the beginning of the buffer. This is already a possible overflow bug when the field contains the values 0..3. Due to memory alignment this is not exploitable. But then the blocksize is decreased by 4 because the dashboard wants to read the rest of the block into memory. Obviously values of 0..3 will underflow when decreased by 4 and this results in the dashboard wanting to read up to ~4 gigabytes of data from the font file in a f.e. 3 bytes buffer. Because the XBOX malloc()/free() implementation is also storing control information inbound and is similiar to the Windows 2000/XP heap allocators this bug is exploitable and allows execution of arbitrary code.

So...
1. The "blocksize" is read.  In our Bert exploit, this is 3.
2. A buffer is allocated with this size, and the blocksize is copied into the beginning of the buffer.
3. It tries to read in the rest of the block.  This is calculated as "blocksize minus 4" bytes.  This gives us -1.
4. It tries to read 0xFFFFFFFF (almost 4 GB) bytes, but stops when it reaches the end of the file.
5. There are no more data blocks, and it happily quits reading.

Okay, so the bytes from 0x2C to 0x40 must be relevant.  It's just that both the jump offset in Bert and the exploit code in Ernie start at 0x40.  Maybe everything up to 0x40 is the block header, and the rest is the block data.

Anyhow, it simply means that our exploit files don't need to include any extraneous "real" data in order to work properly. Hurray for us.

[underthebridge]

First things first, before trying to modify B&E we must see what the problem is

There's a function in XDK called DmCrashDump (in xbdm.dll) that creates a crash dump containing 128mb of the RAM state. I'm going to see where I can go with this...

I tried using XbWatson before just for the heck of it, but it doesn't provide sufficient analysis of the crash (for some reason it doesn't dump the mem when I want it to)...

[afon]

Your post is confusing, but also informative. One thing left out was: Did you run unsigned code using this method? I caught the LED changing telling you it was working, but the results arent making sense to me. Another question is this: When are you going to release such fonts for this occasion (launching from msdash).


-Af0nzo

[afon]

BEE YOU EMM PEE
(BUMP)

[RiceCake]

...

That or I can fuck up my PC easily...whatever, I should read up on this. Buffer overflows, thy is god...

[Blindside]

QUOTE (PedrosPad @ Sep 1 2003, 09:39 AM)

Could be. More info: I created a homebrew app that malloc'ed chunks of RAM and logged the addresses of the allocations to a text file.  I got exactly the same memory addresses returned when I executed my app as a boot dashboard, as the XODash, and from Evolution-X. This implies, as others had stated, that XLaunchNewImage() does appear to replace the parent in memory.  (This is assuming that the addresses returned are physical addresses, and not logical addresses from an MMU, (which I don't believe the XBOX has)). It could also be that the XLaunchNewImage() executes the target in a sandbox, but the BIOS doesn't.  Which would also cause the same symptoms.

Pedro,
 Xbox has a logical memory management unit (I assume that is what you mean by MMU) - it's an intel pentium 3. The question is whether it is enabled and in use.

Since it this is a windows 2000 kernel, I would almost bet that what you are getting back are logical addresses, not physical addresses. To get physical addresses, I believe the processor would have to be operating in real-mode (I'll have to check this in my x86 manuals).

[Swede_Hac]

but when i went in to the menu thats tagged xbox live but i couldnt see text  when i ent into the menu wolla i saw text so the fonts that Live is using (yeah guess) is xbox book.xtf this was on a 4920 dash so.


As i said dot know if it can help.