Print

[ldotsfan]

1. Yes I know the xbox doesn't need a new exploit this late in its lifecycle...
2. This idea is probably dumb and crazy but...
3. I did a search but nothing turned out.
4. What's the motivation for this? Unlocked drives for softmods.

The key question:
Does the MS kernel perform checksums, length checks and other integrity checks on the fields of the eeprom when it loads? Is 256 bytes too small a payload to do anything? If a overflow or underflow is possible so early in the booting cycle, a possible exploit scenario will goes like this.

1st time
A. Gamesave exploit -> writes poison eeprom.

Subsequent times
B. Kernel loads and does hdd locking/unlocking routine. Loads eeprom, Overflow/Underflow -> Unsigned code.

End result: Softmod can now run from unlocked hdd. The rest of the puzzle are already solved: nkpatcher and so on so if this ever works out... softmods will finally be able to match up with mod chips/tsops on the locking thing....



 

[krayzie]

Nice idea. Whonder if the guru's ever though of researching this. Although I don't think it would be possible since the eeprom only contains some parameter strings and keys and isn't actually executed so therefore is unlikey to contain flaws that are exploitable. But what do I know.

[Movax]

I really don't think it is possible to fit enough data in 256 bytes to do anything. Even if you  could take control of the CPU, it needs to run some code. Where does this code come from?

A gamesave exploit, for example, has just enough program code to launch something else (dashboard, xcromwell).

[ldotsfan]

I did more research. Xbox error 2 : bootldr eeprom check failed ... which is never seen because it is reflected by a green followed by red flashing LED. So there's seem to be some sort of checks on the eeprom content.  

[ldotsfan]

Using an AVR microcontroller might be cheaper as many of the development tools are free and based on the prices given at mouser.com cheaper than a freescale.

1. http://www.harbaum.o...usb/index.shtml for just USB to i2c. schematics are given. Support for Windows, Mac OS X and Linux.

2. http://hubbard.engr....ded/avr/avrlib/ C library for AVR with external device drivers for both IDE/USB as well as I2C eeprom.
a. IDE: http://hubbard.engr....nmp3/index.html
b. i2c: http://hubbard.engr....oup__i2csw.html

3. For one-time usage, one need to factor in the cost for the programmer to upload the firmware to the AVR but this can be alleviated by manufacturing the devices.

My personal feel is that this will be a niche product for people into such things. It's really much cheaper to get a used copy of Splinter Cell from ebay or from the local game shop. We are seriously out of topic

[ldotsfan]

@obcd if you wish to continue the hardware discussion, please start a new thread at the correct forum and we can continue from there

Now back to the original topic:

I looked at http://www.xbox-linu...cksum_Algorithm.

The checksums are just CRC type checks right? And since they are part of the 256 bytes payload, we can calculate the right values for the poison eeprom and still pass the test. Is it really that simple? Or am I missing something here?

Of course with 256 - the length of the checksums bytes left for our payload, I'm not sure if we can do anything with it. And we still don't know if the eeprom loading routine is vulnerable to buffer overflow/underflows...

[ldotsfan]

I was hoping MS wasn't vigilant enough in the bounds checks for the fields and were content with just the CRC checks to jump to the corrupt eeprom routine. After all the font loader had an integer underflow which was exploited which led to the font exploits.

By the way how was nkpatcher derived? How was the internals of the kernel patched to allow all its features?

On a side note, I was also reminded by someone the extremely low chance this will ever amount to anything but that's fine. Maybe somebody else will make something out of this.

[ldotsfan]

1. A lot of the 256 bytes of the eeprom are used for Unknown padding. We just need some way to jump to a hard-coded path of a habibi signed xbe - integer underflow to modify the IP?

2. The nkpatcher source has memory addresses for different versions of the ms kernel as modification points if I read it right. I asked the earlier question to establish how these were worked out.

3. Does the cxbx source shed any light on the eeprom routines? I'm not familiar with the xbox emulator...

[ldotsfan]

Daily bump - anybody know the answers to any of my questions?

[Movax]

Don't worry about patching the kernel. If (big if) this is possible at all, just worry about skipping the hard drive lock test, let the normal font expliot load the rest of the softmod.

[ldotsfan]

Yes, in that case, the IP just needs to advance to the next kernel check - dvd rom check ?

[xman954]

QUOTE

Even if you could take control of the CPU, it needs to run some code. Where does this code come from?

as stated
if you were to find a hole how would you get code to RAM to jump to
as the eeprom is on the I2C bus

one way to use a unlocked HDD on a softmod
would be to use a FPGA as a state machine to intercept the lock testing command (on the IDE cable)
and report it as locked
then when the unlock command (using any password) was issued
it would then report it as unlocked and pass all other commands (R/W)
you could also have it report any ser # you wanted ( XBL safe ??)
this would be a lot of work but seeing how you can't find a modchip in the US anymore
it may be worth it ...
thats my $0.02

[ldotsfan]

Doesn't a font exploit load the font+exploit code into memory from hdd and through the underflow gain access to CPU?

Though eeprom is read from i2c bus , the contents must have been read into RAM to parse and and do the CRC checks? Once that check is cleared and if there are no other bounds checks, integer underflow may still be possible to gain CPU access.

[Movax]

Yes, what you are saying could be possible (without knowing the facts).

You are going to have to look closely at the code that loads eeprom data into memory. (I hope you know x86 machine code/assembly).

Disclaimer: I have never written code to exploit anything, and am no expert but I understand the theory.

Most of the time, exploits are possible because the function being exploited doesn't check the length of that data being read into memory. It assumes the data is valid, and that it will read a delimiter (typically the value 0 for a string, for example) and stop. If the data is longer then the allocated memory space, and it is specially crafted to overwrite other values, especially a return address, you can take control. A buffer overflow.

The integer underflow in the dashboard (fonts) is basically a buffer overflow as well. It tricks the xbox into creating a small buffer and loading/reading data past the allocated memory.

I really doubt that either attack could work, since the fields in the eeprom data are always a fixed length, and these type of exploits rely on functions that accept data with varying lengths.

Even if there is a vulnerability, you may end up with a corrupt eeprom. I don't know if there is a way around that.