Print

[YoshiKool]

If you changed a PAL xbox's EEPROM to NTSC xbe region - then you wouldn't be able to boot retail PAL games before the exploit triggered (in case you screwed anything up.) You could still hotswap or use MA though (i think MA is elsewhere and us_canada region).

Of course once the exploit triggers you can run any game, backup or retail.

[chimpanzee]

QUOTE (mkjones @ Jul 27 2004, 11:19 AM)

Sounds Risky but could an EEPROM switch be "Scripted" in any dash language? Or a Linux distro? I assume AVA would have this potential, if so it could help in ensuring its done right. OR it could go wrong 1/2 way through and kill the box! However, what disadvantages are there to a changed eeppom? Is one that you cannot boot orig games? OR can you still boot them from a dash like a backup? I cant see why it would make a difference as this would efectivly make the box regoin free anyway

the linux guys only tell us how to read/write eeprom but not how to 'change' it as they don't see the need for it and consider it to be purely 'pirate' related activity :-(

[PedrosPad]

QUOTE (chimpanzee @ Jul 27 2004, 11:22 AM)

the linux guys only tell us how to read/write eeprom but not how to 'change' it as they don't see the need for it and consider it to be purely 'pirate' related activity :-(

QUOTE (PedrosPad @ Jul 26 2004, 12:50 PM)

The source code for ConfigMagic can be found here

[chimpanzee]

[mkjones]

[ldots]

QUOTE (chimpanzee @ Jul 27 2004, 11:39 AM)

Ah, too complicate for me. I am sure if ldots has the time and is willing to do it, should be easy for him. Can we now pray to our god

The reading of the eeprom is one thing. The decryption is another. We need to decrypt the eeprom to start editing it.
The eeprom decryption needs an update (both LiveInfo, ConfigMagic and all linux tools use the "Friday 13th" hack to do this). Once the eeprom is decrypted it not a big deal to change the XBE region

Edit : Sorry! I was thinking v1.6. The current code available decrypt the v1.0-1.5 eeproms just fine. So making the XBE region swith could be automated. I was considering doing this for the UDE2 installer. But decided not to. Imagine if there was a bug  in the code. Automatic eeprom editing sounds a bit risky to me. I could try to make a tool that :
- reads eeprom
- decrypts eeprom
- Sets xbe  region
- encrypts eeprom and dumps to a file.
- tests the encrypted eeprom (decrypt again and extract various information, like XBE region).

Then one could use official tools to write back the eeprom (linux, ConfigMagic or a dashboard).

[PedrosPad]

QUOTE (chimpanzee @ Jul 27 2004, 11:39 AM)

Ah, too complicate for me. I am sure if ldots has the time and is willing to do it, should be easy for him. Can we now pray to our god

If anyone knows where the source is for the Enigmah video switcher, it may be easier to modify - it already toggles the 'video mode', the EEPROM byte right next to the 'xbe region' byte.

Edit: Just read that apparently both XBMC and AvaLaunch also contain the ability to toggle the video EEPROM byte - so there's more source to checkout.

[chimpanzee]

QUOTE (PedrosPad @ Jul 27 2004, 12:17 PM)

If anyone knows where the source is for the Enigmah video switcher, it may be easier to modify - it already toggles the 'video mode', the EEPROM byte right next to the 'xbe region' byte. Edit: Just read that apparently both XBMC and AvaLaunch also contain the ability to toggle the video EEPROM byte - so there's more source to checkout.

The code in configure magic is good enough, just that I haven't done any of those eeprom encrypt/decrypt mod before but ldots just did for the HD locking so it should be a piece of cake for him.

[rmenhal]

QUOTE (ldots @ Jul 27 2004, 12:15 PM)

I could try to make a tool that : - reads eeprom - decrypts eeprom - Sets xbe  region - encrypts eeprom and dumps to a file. - tests the encrypted eeprom (decrypt again and extract various information, like XBE region).

Assuming you know what the current xbe region is you could (since it is encrypted with RC4) just xor the encrypted region with the known region value and xor again with 0x00000001.

Most probably Config Magic just needs to be updated to have the v1.6 EEPROM key (or the corresponding middle message hashes).

Xbe region is apparently a bit field. Why can't we just make it have bits set for all regions? Or if the box is not US/Canada region, then xor the byte at offset 0x2c with 0x01 so that it has also the US/Canada region in addition to the native one?

EDIT: oh, xbe region is also hashed into data_hash. So the EEPROM key (or the middle message hashes) is required. But the multiple-region idea still stands.

EDIT2: multi-region won't work.

[krayzie]

QUOTE (rmenhal @ Jul 27 2004, 04:45 PM)

Assuming you know what the current xbe region is you could Xbe region is apparently a bit field. Why can't we just make it have bits set for all regions? Or if the box is not US/Canada region, then xor the byte at offset 0x2c with 0x01 so that it has also the US/Canada region in addition to the native one?

If you can acomplish this you are truly the best.

[ldots]

QUOTE (rmenhal @ Jul 27 2004, 04:45 PM)

Xbe region is apparently a bit field. Why can't we just make it have bits set for all regions? Or if the box is not US/Canada region, then xor the byte at offset 0x2c with 0x01 so that it has also the US/Canada region in addition to the native one?

Indeed with the region codes (0x01, 0x02, 0x04) it does look a lot like its bit packed

Hmm - that would be neat. So you are saying having the byte at 0x2c set to 0x05 the xbox would function both as a Europe and North America region box?
Should be easy to test, but I'm not sure I'm brave enough. I dont have a modchip

[chimpanzee]

QUOTE (ldots @ Jul 27 2004, 05:58 PM)

Indeed with the region codes (0x01, 0x02, 0x04) it does look a lot like its bit packed Hmm - that would be neat. So you are saying having the byte at 0x2c set to 0x05 the xbox would function both as a Europe and North America region box? Should be easy to test, but I'm not sure I'm brave enough. I dont have a modchip

no, please set it to 7 so we NTSC-J users can be benefitted too :-)

However, just found out that running a game hack is not an easy task for NTSC-J, the three known exploitable games either don't have NTSC-J version or don't have the necessary game save :-(

Would it be that simple though ? That would mean any Xbox can run all region original games by design.

[YoshiKool]

Hmm.... i think i'll say it now so noone tries it
Don't try to xor video modes together...

[Chicken Scratch Boy]

i was thinking once we get the region for a pal one changed, we can do a diff patch

but if configmagic only needs the key... then do that

[ldots]

QUOTE (Rmenhal)

EDIT: oh, xbe region is also hashed into data_hash. So the EEPROM key (or the middle message hashes) is required

I'm not suggesting everyone does this, but it is possible that xor'ing your current region with 0x01 will make it multi-region. Someone with a chip could test this out.