Print

[Mordenkainen]

This is probably why the fonts sometimes hang systems a couple of times.

I'm looking at this and it doesn't make a lot of sense, if we assume that the first 4 bytes are for alignment then the code in BigFonts is incomplete, whatever is after the D0 becomes part of the code.

If we assume that only the first 3 are for alignmennt, then the code changes drastically:

ADD     [BX+SI-33],AL
ADD     AL,D0

This could do it, I guess..... If the memory pointed to by [BX+SI-33] contains the exception handler, and this handler lies somewhere below ernie in mem, adding the arbitray (or not so arbitrary!) value in AL may push the pointer up into the jump net.


But then why add d0 to AL? Unless the code somehow runs backwards. Meaning that d0 gets added to AL first, pushing it up 208 bytes + whatever is in AL?

I'm guessing here, I think this stuff is for the most part beyond me.

But I would venture to guess that: (Using Day-x as an example)

4141C00040CD04D0EBFE414141414141

The Blue bytes are for alignment.
The Green bytes do all the work.
The Red bytes are junk. Perhaps a catch all for if by some miracle the system does NOT exception.

But, I'm just guessing, hell I'm so low tech I'm using debug to dissasemble this stuff!

Morden.

[Mordenkainen]

Huh, my last reply is shown as the last one by the board, but it didn't show up!

Morden.

EDIT - and now that I posted this one it is!

[underthebridge]

CODE

;;font header db "XTF0 " times 3 db 0 db "Xbox Book" times 23 db 0 ;;real code add ax, [bx+si] times 6 db 0 add ax, [bx+si] times 3 db 0 inc cx add [bx+di+0x1],al inc cx add [bx+di+0x2],al inc cx add [bx+di+0x41],al inc cx rol byte [bx+si],0x40 int 0x4 shr bl,1 inc byte [bx+di+0x41] inc cx inc cx inc cx inc cx

[underthebridge]

a 32 bit compile turns out to be quite different than the original bert.xtf in terms of hex

[PedrosPad]

I agree that Bert.xtf is probably data.  And some of that data is a memory address for Ernie's entry point.

Assume that separate threads are created to load in the XTF fonts (disk access is 'slow' afterall).

How about this for a heap view:

|Bert thread structure|Bert.XTF|Ernie thread structure|Ernie.XTF|
0000--->----->----->----->------>------>----->----->----->------>FFFF

Bert 'underflows' overwriting Ernie's thread structure (containing Ernie's thread's SEH).

Or, if the font buffer first is allocated first, then a thread fired off to populate it

|Bert.XTF|Bert thread structure|Ernie.XTF|Ernie thread structure|

Meaning that Bert.XTF would trash it's own thread structure.

Pedro.

[underthebridge]

yea, what I meant was I did a compile with a 32-bit source but the hex code didn't match the original bert.xtf much. Maybe the code still works though?

[Mordenkainen]

How could this be dumped on the heap?

It would have to be on the stack to be executed wouldn't it? That's the way the majority of buffer over/underruns work.  Abitrary code just overflowing a variables boundries in the heap usually won't cause this type of behavior unless it punches out of the heap and into the stack.

Morden.

[baturkin17]

my theory as to why the second dash fails...............

before you upgrade to the xbox live dash, all the dash files are stored on the root, not in xboxdashdata1whatever/fonts.

so when you click the live button, the old dash looks for all its files in the root, which arent there.

i dont have all the ORIGINAL files from the old dash so i couldnt test it, but i think you need all the old dash files (fonts/xips) in the root of C.

and of course all the new dashs (fonts/xips) in there appropriate folders.

and the bert and enie fonts in the root too.
also have the PBL  in the root of C because thats what the fonts look for. (default.xbe)

the fonts/xips from the new dash wont work for the old dash in the root, i tried that.

someone try the original old files.............

[baturkin17]

why would the button dissapear?

wouldnt that mean it wont work

[Grospolina]

The button "disappears" because it has loaded D:4817 and that dash doesn't have an XBox Live button.  You can also go into Settings -> System Info and verify that it's D:4817.

[mnm6687]

yes i can verify that the old 4817 dash does work when all the original files and fonts (no exploits at all) are present.  you do need all the original xips, and the 2 original fonts in the C:\ root directory.  this is not the problem baturkin17, the problem that this group is having is the hacked bert and ernie fonts themselves.  they are designed to do whatever they do at bootup, not after.  at least this is what i get from all the programming discussion that has been going on the past couple days.

[Grospolina]

So now I'm trying to increase the size of Ernie, while keeping Bert the same.  I want to see how big it could get, and what it does when it's too big.

32 MB -> works
64 MB -> resets
48 MB -> resets
40 MB -> resets
36 MB -> resets
33 MB -> works
34 MB -> works
35 MB -> resets
34.5 MB -> resets

That's enough.  I don't need to find the exact value.  If the file is bigger than about 34 MB, then I guess it doesn't have enough RAM to allocate it.  Since Ernie can't be loaded, Bert jumps to some random area and it crashes.

[Blindside]

QUOTE (Grospolina @ Aug 28 2003, 04:02 AM)

So now I'm trying to increase the size of Ernie, while keeping Bert the same.  I want to see how big it could get, and what it does when it's too big. 32 MB -> works 64 MB -> resets 48 MB -> resets 40 MB -> resets 36 MB -> resets 33 MB -> works 34 MB -> works 35 MB -> resets 34.5 MB -> resets That's enough.  I don't need to find the exact value.  If the file is bigger than about 34 MB, then I guess it doesn't have enough RAM to allocate it.  Since Ernie can't be loaded, Bert jumps to some random area and it crashes.

This would tend to indicate that the OS has no virtual memory features in use  since allocating more memory shouldn't fail with such a small allocation (64 MB is not much).

That makes things easier because we now know what addresses are definitely invalid.

Note that I've modified it so that the exploit code is at the beginning of the file.
-> Reducing the jump address to 0xA20224 (the beginning of the exception net) works!
-> Reducing it to 0xA20008 (the beginning of code) doesn't work!

I assume your are talking about Ernie in this case. Like you have <font header><exploit code><bunch of jmps><final jumps that  place you back to the beginning of ernie exploit code>

[Grospolina]

That's right.  But I heard that it couldn't do disk swapping before.

And yes, your description of Ernie is correct, but I was changing the jump address (offset) that was in Bert.

So basically, Ernie can be between 1 and 34 MB.  Let's try a few things with the big one (34 MB) and our double-dash experiment...

Edit:
Interesting tidbit: The fonts that come with D:4817 have the header "XTF0", but the fonts that come with D:4920 have the header "XTF1".  If I use "XTF1" in my exploit files, they don't work with D:4817.  If I use "XTF0", they work with both D:4817 and D:4920.

And by "working", I mean with a single dash.  I'm trying the double-dash next.

Edit 2:
Damn, that's a no-go.  I set Bert to jump into the middle (17 MB) of Ernie (total 34 MB).  I think that when the second dash loads, the jump location that we're trying to overwrite must not be there anymore.  How strange.

[PedrosPad]

QUOTE

I think that when the second dash loads, the jump location that we're trying to overwrite must not be there anymore. How strange.

It could be that the LaunchNewImage function in the BIOS executes the initial dashboard in some form of 'privileged' mode.  But the LaunchNewImage 'library' function, compiled into XBEs (including the Dashboard XBE) doesn't.

Lets hope this isn't the case.

Pedro
(an old 68000 hacker).