Print

[boochip]

Grounding the pin stops the contents of the nand from being changed.

mike1250 let us know how your box gets on with this mod.

a bit late for my box but might be worth a shot for someone that does not want to lose harddrive install.

[majinsoftware]

Sounds like a good idea, Have it on a switch and only have it enabled when you want to apply updates or change dash settings.

[Mike1250]

I'm seeing some side effects to write protecting the nand. Most of the time when I turn it on while write protected, it boots up with the xbox sphere, then goes through the initial settings menu (language, locale and stuff). When finished and choose done, it loops through again, only way out is to flick the switch back to write enable. So I boot the console with ethernet unplugged and write protect switch off. It all comes up fine but disconnected from live. Flick the switch and plug ethernet in, all plays well. While playing a game I hit the xbox menu button, screen resolution sets to a messed up 480p. Upon returning to the dashboard I am hit with the initial setup loop again. You'd think once you set the nand you'd be able to lock it and be good, but there's obvious issues when the xbox can't write its own nand. Maybe poor programming from Microsoft (we all know they have the best programmers in the world   ), or maybe it's a failsafe in case of nand problems. Regardless, I'm sure future games will just have the hard drive locking update on disc. I guess I'll just sell my 250GB and revert to the old 20GB.

[lollercakes]

From what I understand, the updates released on discs could well contain a 'console revoke list' or 'CRL' that contains you console ID, so applying an update that has your console in that list would still result in you getting banned.

The hard drive crippling isn't an 'update', it's a part of the latest form of console-side bans M$ is enforcing.

As for why it loses those settings etc when you have the ethernet cable plugged in at start; it might be because the console can't retain its real-time clock when the system has no power (from the mains)?

Maybe it references the time you switched on the console against the time the last settings were applied, sees something is wrong and decides to boot from a set of 'safe mode' type settings instead?

If this is the case, it may be possible to find and edit those 'safe mode' settings on the NAND to settings you use by default, so that it'll always fall back to those, instead.

[hamwbone]

A crl list with 1 million console id's? That would be pretty big in a CSV format even wouldnt it?

[lollercakes]

When last did you see any single dash update that was smaller than 25mb, even if it contained no graphics/sounds? ;/

[lollercakes]

Just created a word document that had in excess of 1mil lines containing the following in it:


ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890

I estimate the final document had 1.08mil lines with that in it.
It saved to a 5.6mb document.


So yeah, I guess a massive CRL wouldn't be too much of a problem for a patch to contain nor the console to read through during startup/at the dash.

[majinsoftware]

But thats a 5.6mb file thats needs to be added to a already overflowing 16mb chip.
I doubt they would add every one to the list in a update. They would save it to just the worst offenders.

Or else they would have to save it to the hdd or mu. Which we could easly edit due to its un-encrypted and un-signed nature.

[lollercakes]

Unless a check against the CRL is performed at the time of patching? I mean, I've seen some minor updates take excessively long to apply themselves AFTER all the data has been downloaded, and it cannot possibly take that long for a few files to get overwritten and modified on the NAND chip by the console itself through its native bus?

But yeah, I agree that it would be great if the CRL could be edited or removed entirely from patches.

Failing that, an image builder where you modify an image you have of the NAND contents stored on your PC, and you write the relevant patch data to the image and re-sign and/or encrypt it using your CPU key, would be great.

That way we could bypass the CRL entirely, maintain console updates (as required by some games to allow you to boot them) etc.

I still have to wonder if there are any components of system updates that are crucial to the ability for some games to run, or if it's a simple matter of them requiring a minimum Dash version number.

[rfisher1968]

Is it possible to use the concept of lowering the voltage on VCC to below 2.0v (4.1 Data Protection & Power On/Off Sequence) at the exact time the xbox tries to read the keyvault. And instead have a circuit feed a different keyvault. Then bring VCC back to 3.3v when the request is done.

[r0b0tix]

QUOTE(lollercakes @ Nov 13 2009, 12:12 PM)

Just created a word document that had in excess of 1mil lines containing the following in it:
ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890

I estimate the final document had 1.08mil lines with that in it.
It saved to a 5.6mb document.
So yeah, I guess a massive CRL wouldn't be too much of a problem for a patch to contain nor the console to read through during startup/at the dash.

I'm affraid it is not that simple. As I understood you took 'ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890' and repeated it 1.000.000 times. I'm guessing ms word has some built-in compression mechanisms and that is why you got only 5 mb.

I've generated 1.000.000 random, 12-digit "fake xbox IDs" and put it into a text file and ended up with a 26 mb file! After zip compression it went down to 12 mb...

[lollercakes]

Ok, well, there's a new mandatory dash update coming out on the 17th. Someone with an unmodified console that isn't vulnerable to getting banned could well monitor the bandwidth used to download the update via a gateway PC, and then report how large the file ends up being.


Either way, I doubt the CRL needs to be stored on the console as opposed to simply scanning through it for a matching ID at the time the console gets updated, then making the necessary changes to the data within the NAND for the console to consider itself 'banned'.

Again. When last did you see a dash update that was any smaller than 25mb, even without any graphics or sounds being added with it.

[ade2]

alright.... a xbox crl entry looks like this: 01174CFDE3  (http://xorloser.com/...2009/05/crl.txt)

that's a 40-bit number. for a million consoles stored sequentially, thats 40000000 bits, or about 7.62 megabyte.

as there is no certain pattern to these numbers (would make serial number guessing possible) there is no benefit what so ever trying to compress them, afaik.

[lollercakes]

CRL size aside, point is that it seems to be something that can be included in patches and that if it is, can cause your console to get banned without needing to go online.

Write protecting the NAND chip seems to be a way to avoid an accidental patching of the thing, but will mean that you cannot get anything done if your console is connected to live, as it will get the 'mandatory patch' message, if it hasn't been banned from the live service itself yet.

It also, as has already been mentioned in this thread, causes issues such as default settings resets. On its own this doesn't necessarily pose a great problem, as it means one has to go and change the resolution you are running games at; I imagine that's about all that's 'serious' about that issue.


What I would be more interested to know then, is about the block failure functionality; do the blocks get marked as bad permanently? If they do, then excessive use of the write-protect functionality would gradually reduce the available blocks for usage on the chip, and ultimately result in it becoming unusable, correct?


If so, then that, in my opinion, means that one is left with no option other than retaining a solid backup of the NAND chip's contents so that if something goes wrong and you get the local ban, you can reverse it by rewriting the NAND with the 'good' version.


I have to wonder if M$ doesn't have publishers updating the CRLs in 'older' wave data patches as well - ie; just because you wrote a wave3 to your disc instead of wave4, doesn't mean your console hasn't been added to the 'source' wave3 data that you've gotten ahold of. I guess a simple way to avoid this is to make sure that you are always using the oldest-known available wave3 data for patching purposes.



tl;dr
So it looks like keeping a backup of your old NAND data pre-ban, and patching wave4 games with wave3 data is the only way to go if you want to avoid the local-ban, if you've already been flagged, for now.