Print

[mnm6687]

QUOTE (Swede_Hac @ Sep 1 2003, 08:55 AM)

I dont know if this can help or if it have been covered before but i KNOW that the fonts that LIVE uses isnt xbox.xtf and that it IS xbox book.xtf, because when i was trying to do the fonts on a m8 box i accedently removed xbox.xtf. didnt add anything youst removed it. i booted the xbox  and saw the menus youst no text because there warent any fonts 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.

the point of this exploit is not to launch the LIVE application, it is to lauch the old MS dashboards using the live tab.  the xbox LIVE application is not used in this exploit at all! we just trick the 4920 dash into thinking that 4817 is the xbox LIVE application by renameing it to xonlinedash.xbe and plopping it in the xodash folder.

[afon]

  (afon waits for jeet coders to fix the problem)
Hummmpppffff

[PedrosPad]

QUOTE (Grospolina @ Sep 2 2003, 07:01 AM)

QUOTE Small heap allocations, like 3 byte Bert get allocated low heap addresses. Large heap allocations, like 16MB Ernie get allocated high heap addresses. Wait a minute... if small heap allocations get allocated low heap addresses, and large heap allocations get loaded high heap addresses, then why would 12-MB bigBert (Big Bird?) be loaded into a low address?

Because even a Bert file of 12MBs says it only need 3 bytes of storage  (and had this solved the XODash issue, yes, I was going to christen it bigBird Great minds eh?)

QUOTE

The jump address in Bert is (usually) 0x00C02020.  This is a "jump ahead" of 12591136 bytes.  That's 12 MB + 8224 bytes.  However, this should be jumping ahead from within the application code, not from the heap address that the SEH pointer (which we're overwriting) is stored at.

In my tests a 3 byte malloc returns an address of 0x1E? something (I don't have the exact address here) so even the low heap is still already a fair way up the RAM.  Also I took 0x00C02020 to be an actual memory address, not an 'jump ahead' offset.  (Surely you can do this in x86?)

Symptoms I witnessed, lead me to believe that the Dashboard code continues to run for quite a while (comparatively) after the fonts are loaded.  I built a 6MB Bert, and verified that a modified SEH address was in fact landing in Bert.   I then replaced Ernie with the the original font file.  The exploit didn't trigger, but the dash still crashed.  I built an Ernie of identical size to the original font, and filled it with zeros, after the header, and the exploit triggered.  This leads my to believe that it's only when the dashboard tries to use Ernie's font information, that it finds it corrupt, crashes, and followed the hijacked SEH.

Although the bigBert exercise revealed a lot, I've realised that the 'large single font' exploit idea is flawed.  Even through a 12MB jump table was successfully read into memory, because Bert was only actually allocated 3 bytes, it's jump table gets polluted as the dashboard makes subsequent memory allocations and fills them.  Meaning that even if the exploit successfully lands in the jump table, extra data may have been put in the jump table area, breaking the jump sequence.  


I've gained a whole new respect for the Bert and Ernie exploit.  It appears that Ernie actually serves 2 purposes.  1st, because Ernie actually contains its valid size, the area of memory it occupies is officially his, and won't get overwritten (maintaining the integrity of his jump table).  And 2nd, because it contains code, not valid font data, also causes the crash-upon-usage.  Also, although Bert under allocates it's memory needs, it only overflows by a very marginal amount, allowing the dashboard to continue running until it tries to use the Ernie font data.  Shit this is clever.

Pedro.

[PedrosPad]

QUOTE (PedrosPad @ Sep 2 2003, 10:36 AM)

In my tests a 3 byte malloc returns an address of 0x1E? something (I don't have the exact address here)

Sorry, I was unclear here.  By 0x1E?  I meant ~0x1E0000.

QUOTE

Don't know if this might help some: Process organization Low memory addresses   ------------------------------                |                         .text (program code)                |                         ------------------------------                |                         .data (static and global initialized variables)                |                         ------------------------------                |                         .bss (static and global uninitialized data)                |                         ------------------------------                |                         heap (grows from low to high addresses)                |                         ------------------------------                V                        stack (grows from high to low addresses) High memory addresses   ------------------------------ As you can see from the 'diagram' above the heap won't start  at memory address 0 - we're most likely not using the segmented memory model in this case, so everything gets loaded into the same segment. Heap addresses will not start at 0, but somewhere above that (possibly way above that).

Matches my own thinking, and matches the results I was getting.

[Grospolina]

QUOTE

Because even a Bert file of 12MBs says it only need 3 bytes of storage

Oh, right.  Duh. >_<

QUOTE

(and had this solved the XODash issue, yes, I was going to christen it bigBird Great minds eh?)

Heh.

QUOTE

Also I took 0x00C02020 to be an actual memory address, not an 'jump ahead' offset.  (Surely you can do this in x86?)

Eh... yes you can, and I suppose that makes more sense.  For some reason, I thought that I knew it was using the E9 opcode, but now I realize that I couldn't know that.  Maybe I was tired last night or something...

[Grospolina]

Okay, here's a question and an idea:

How much of the data in Bert is required?  We already know that the EB 41 41... etc. is not necessary.  We also know that we're replacing data, not code.  Can we replace the rest of the stuff that comes after the blocksize?

What I would like to try is this:  Replace the jump address 0x00C02020 with 0x01010101, and then replace the bytes before and after it with 01's as well.  This way, even if the SEH address pointer is offset by a byte or three, it will still jump to 0x01010101.  This is just under the 6 MB mark in Ernie, so Ernie would have to be at least that big.  If it works at all, then at the very least, it would make the exploit more robust.  In the best case, it could fix our double-dash problem and/or the clock loop problem.

Unfortunately, I can't try it right now, but I can later.

[PedrosPad]

QUOTE (Grospolina @ Sep 2 2003, 05:18 PM)

Okay, here's a question and an idea: How much of the data in Bert is required?  We already know that the EB 41 41... etc. is not necessary.

One of the first tests I did was change the bytes in Bert individually and test.  I've created a Bert that works that just all zeros except the Font name, the fake file size (0x00000003) (2 occurances), and the bytes below.
4141C00040CD04D0EBFE414141414141

The Blue bytes appears to be the address in Ernie to jump to.
The Green bytes do appear to be important.  Change 'em and it don't work.
The Red bytes are junk.  Confirmed by the fact that they're missing in one of the font exploit versions.  I suspect this is a memory fingerprint that could be easily searched for in a RAM dump to locate where Bert was placed.  (6*0x41 = 'AAAAAA')  (Not very imaginative.)


I'm buggered if I know what the green bytes are and why they're important.  I'll try trimming them (as apposed to zeroing them which I did in my test).

Pedro.

[ntdon]

[Grospolina]

QUOTE

The Green bytes do appear to be important. Change 'em and it don't work.

Damn.

Hey, that article by Stefan Esser said something about the heap being aligned.  Does that mean it's aligned by 2 bytes? 4 bytes?  If so, then maybe there's a combination of 2 or 4 bytes that we could use.  0x02020202 would also work as a jump location, but Ernie would have to be increased to about 22 MB.  Maybe we could use something like 0x02440244.

[Blindside]

QUOTE (Grospolina @ Sep 2 2003, 06:24 PM)

Damn. Hey, that article by Stefan Esser said something about the heap being aligned.  Does that mean it's aligned by 2 bytes? 4 bytes?  If so, then maybe there's a combination of 2 or 4 bytes that we could use.  0x02020202 would also work as a jump location, but Ernie would have to be increased to about 22 MB.  Maybe we could use something like 0x02440244.

Grospolina,
  Check this kbase article out - relevant section is Unaligned Allocations - basically, all allocations are 'guaranteed' to have a start address that is 8-byte aligned.
286470

[Grospolina]

QUOTE

basically, all allocations are 'guaranteed' to have a start address that is 8-byte aligned.

Nice.  That could make our exception net a lot quicker.  Just jump to the start of the exploit code (this takes 5 bytes) instead of jumping up or down by a set amount.

Also, from some virus programming sites I've seen , it looks like the SEH frame is simply two 32-bit pointers (8 bytes total): return from exception pointer, exception handler pointer.  If we're 8-byte aligned, then maybe we can just repeat the SEH frame a few times.  If I'm following the alignment correctly, then the "green bytes" above are a pointer to the exception handler (at 0xD004CD40)?  Hmm, that seems kind of high.  Still, maybe repeating it will help.

[PedrosPad]

QUOTE (ntdon @ Sep 2 2003, 05:47 PM)

Scenario 1: This one works by design of FreeX team Dash 4920 --Bert-SEH---------------Ernie-- Scenario 2: Dash 4920 launches Dash 4817 --SEH---Bert---------------Ernie--- (this would never work) Scenario 3: --Bert---data--data--SEH---Ernie

ntdon, Your post above is an excellent summary of the situation  (and very useful  for those joining the ever growing thread).

Knowing which 'Scenario' we're in would allow us to focus our effort.

If Scenario 1 were true when the boot dash spawned the XODash,  then it would have all worked straight-from-the-box and underthebridge (who, lest we forget, started this thread) would be a complete hero.

If Scenario 2, we're on a road to nowhere, so we're all hoping this isn't the case.

Which leaves us with Scenario 3, which is where the current effort is being placed.

QUOTE (ntdon @ Sep 2 2003, 05:47 PM)

If it's scenario 3, then try adding Bert1.xtf, Bert2.xtf, etc.. until one overwrite the SEH.  BTW, add another Bert, you might want to use size of 4 in Bert that is not supposed to overwrite.

Your idea of using multiple Bert's is new.  Of course this would rely on the Dashboard loading in all the XTFs in a directory, but since we know the actual filenames aren't important, this may have merit.

QUOTE (underthebridge @ Aug 30 2003, 06:19 PM)

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 didn't miss this post, but underthebridge hasn't reported back any findings yet.  This would allow is to verify, finally, if we're in a Scenario 2 or 3 situation.  

underthebridge, if this didn't work straight-from-the-box, then it'll probably be cause the function requires a debug BIOS also.  Post any findings from your investigation, even failures, because I suspect this was exactly how the original exploit was developed.  Also any idea if this dumps to a disk file on the XBOX or just streams the dump out of the network port?

Pedro.

[PedrosPad]

QUOTE (Grospolina @ Sep 2 2003, 07:33 PM)

Also, from some virus programming sites I've seen , it looks like the SEH frame is simply two 32-bit pointers (8 bytes total): return from exception pointer, exception handler pointer.  If we're 8-byte aligned, then maybe we can just repeat the SEH frame a few times.  If I'm following the alignment correctly, then the "green bytes" above are a pointer to the exception handler (at 0xD004CD40)?  Hmm, that seems kind of high.  Still, maybe repeating it will help.

That'd sure explain the green bytes.  Didn't I read in 'Bunnies' book that the high address lines aren't physically connected?  Which means that 0xD004CD40 could actually be 0x0004CD40,  putting this is very low memory, where I'd guess the BIOS etc. sit.

0xD004CD40 = 11010000000001001100110101000000

Pedro.

[PedrosPad]

QUOTE (af12345 @ Sep 3 2003, 11:26 AM)

Just some thoughts, as a replacement for the xboxlive xbe file, could you use something like a copy of AUF sitting on the HD

I believe the media flag in the AUF XBE would prevent it running from HD.  Same for the OXM cover DVDs.  (I haven't tried this though)  I'm not shooting down the idea.  I think that there'd be a coolness about using free software to exercise the hack.

In my experience demo versions of upcoming software can reveal a lot.  Often they're put together in a hurry and can be less protected than normal (often debug builds, complete with labels, etc.).  I recall one incident where a floppy disk demo of a game (that shows my age) actually had the full source code as a deleted file on the mass produced give-away floppy.  Norton proved very useful that day.

Pedro.

[Blindside]

QUOTE (af12345 @ Sep 3 2003, 11:26 AM)

Im following this thread in anticipation... seems like you're all making some serious progress here. I currently use the audio exploit and don't intend on using Live; so this would be an excellent option! Just some thoughts, as a replacement for the xboxlive xbe file, could you use something like a copy of AUF sitting on the HD... not ideal I know... but just some food for thought. Also, whilst using dash 4817 seems like a good option, im sure there are other MS signed XBEs that could be used... maybe something like the xdemos dashboard that MS gives out... or something from the cover of an xbox magazine? Either way... keep up the good work; I can guarantee this will be a popular option for many people!

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.

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