Utter Chaos' Notes

Monday, May 21, 2007

My thougths on the recent XBL-banning (Part 1)

Theory 1: The FW-change theory
This theory describes the possibility MS has to checksum the Firmware of the DVD-drive. At a certain moment the drives firmware gets checksummed and the value will be stored either locally or remotely. At a later moment (during each bootup and/or logging into XBL) the FW gets checksummed again. If the stored value is different from the newly obtained checksum the drives FW has been altered which results in a ban.

Possibility: VERY UNLIKELY

Although this theory is quite popular I believe it's a very unlikely scenario. A Firmware change can have other reasons than just modding a drive. A large number of drives are replaced during repair centers every day around the world with other brands/types (and therefore different chekcsums). I also like to add the fact I own a single box using different drives/firmwares (Hitachi/Samsung) and have not been banned (yet). Lastly: MS wants to block the use of backups on XBL, logging differences in FW-checksums is a long shot to accomplish such a thing. Just think of all the modders who flashed the DVD-firmware out of the box, there would be no changes recorded so every backup should still be playable online without the risk of getting banned!

Theory 2: Monitoring backup-usage over a period of time
This theory describes the possibility MS has to detect the use of backups and storing such information localy. When the user logs into XBL the locally stored information about backup-usage is sent to MS along with the unique console-id. Once the console-id is flagged as capable of running backups it will be added to the ban-list.

Possibility: UNLIKELY

I believe this is also an unlikely scenario. Keep in mind the statement MS has made on the subject: MS wants to block the use of backups on XBL. However when this theory would be fact it would mean people can get banned for XBL while they have never been on XBL using a backup. This looks like incosistent since MS would ban people for a mistake they could possibly make in the future but haven't made so far! I'd like to add my personal experience also: I've been using a number of backups offline and originals online. So far I have not been banned (yet).


Theory 3: Monitoring backup-usage on/logged into XBL
This theory describes the possibility MS has to detect the usage of backups once logged onto XBL. Once backup-usage has been confirmed when logged into XBL the unique console-id gets flagged and sent to MS to add to the BAN-list.

Possibility: LIKELY

I believe this is scenario is the most plausible as it does exactly what MS has in mind: Stop the usage of backups on XBL. If this theory holds up the main question remains when did MS start collecting data on backup-usage. Despite the "Stealth" Firmware and images there are a whole bunch of (documented) ways to differentiate an original from a backup. Since the first news of the bannings I've only used originals when logged in to XBL on an unaltered drive. So for I have not been banned (yet). Since it's unclear when the logging started (if all) my console-id could be flagged already and a ban could become reality in one of the following "ban-batches".

To wrap things up:
- Respect for the nicely executed action from MS. Especially the fact bannings have been done "randomly" kept us in the dark (and probably still does).
- Even if you're not banned NOW is no guarantee it won't happen in the (near) future, this is especially true if you're already flagged but the hammer has yet to fall!

And finally:
This is/was all just a game.. so don't whine when you're banned: YOU WIN SOME... YOU LOSE SOME! :)

Useful links:
http://www.majornelson.com/archive/2007/05/17/xbox-live-security-5-17.aspx
http://gamerscoreblog.com/team/archive/2007/05/17/545414.aspx
http://www.xboxhacker.net/index.php?topic=7566.0

-UC-

(As you may have guessed English is not my native language, sorry for all the mistakes!)

Tuesday, August 01, 2006

External drive experiences

I took quite some time to play around with the external 360-drive hooked up to my console. I am running an unmodified original FW on the Hitachi drive. I took the PGR3 disc from the shelf after it's been collecting dust the last few months. And I gotta say: I love it again :)

Never had any problems playing until I downloaded the Style Pack and the Turbo Pack for PGR3. The problems started when I was playing one of the new type of games: "Cat and Mouse". The race would startup fine but after almost one round of driving the 360 would freeze and then reboot. I had the exact same thing with the "Team Cone Challenge" game.

All the other games (on- and offline), cars, tracks, challenges work fine using the external drive.

Since I wanted to get to the bottom of this I deceided it was time to hook up the drive directly to the console. The only difference in this situation is the power is coming from the 360-motherboard. I could play "Cat and Mouse" and "Team Cone Challenge" without a problem this way. Makes me really confused!

Any suggestions/comments would be welcome :)

Thursday, July 20, 2006

External 360 drive finished

After the thoughts I had earlier I deceided to build the external DVD-drive for the 360. However I didn't use the case I was planning on earlier. Since I couldn't use much of the components and had to cut the legs of the drive to fit in the housing I deceided to build the thing from scratch. So here's the result:



As you can see from the picture above the drive get's its own power. This means the drive can be hooked up to a notebook without the need to get power from the 360. In that case you have to use an USB<->SATA cable as discussed earlier.

Near the power-socket is the on/off switch. At the front you can see a red led (not burning in the picture) to indicate the on/off-state of the drive. Next to the led is the eject-switch. Here's another picture, this time from the front:


And yet antoher one from the top, this time with open drive:


Note the drive itself is totally unaltered. Meaning I can just unscrew it from the board it is placed on right now and put it back in the 360. If you're wondering how I would hook this up to a 360 please read my first post on that subject. Also note I'm using a USB<->SATA adapter to hook the drive up to my PC.

The power-adapter board is heavily based on the "PC power supply to 360 DVD power connector adapter" as described by Kevin East aka SeventhSon.

Another project finished :)

Friday, July 07, 2006

First look into the external 360 DVD-drive

After my succesful attempt to use the Hitachi drive with my 360 it wasn't "married" to before I did my first careful step in creating an external 360 dvd-drive.

I'm planning on using the USB-casing I currently use for my DVD-writer. This casing makes it possible to transform an internal device into an external device by providing a power source and incorporating a IDE <-> USB adapter. This is what the casing looks like with the current DVD-writer installed:



Time to look into the 360 DVD-drive vs a "normal" DVD-drive to compare measures:


The 360 DVD-drive is higher due to the legs it's using


The 360 drive is a little less deep

Currently I'm facing these challenges:
  • Build a power-adapter for the 360 drive and incorporate this in the casing;
  • Build a custom-eject button since the button is not on the 360-drive itself;
  • Make a decision to either cut the legs from the 360 drive to make it fit in the casing or don't cut the legs and forget about closing the casing;
  • Make a hole or (use an existing one) to lead the SATA-cable from the back of the 360 drive to the outside of the casing.
Basically all I wil use from the casing is the casing itself, the power Adapter inside of the casing is of no good for this project and neither is the IDE <> USB adapter.

To be continued (that is if I go through with it)

Tuesday, July 04, 2006

Running the Hitachi in another 360

After restoring my Hitachi to the original FW-state I had a crazy thought of building an external DVD-drive to use with my other 360. My idea is to enclose the Hitachi drive in an external USB-casing so I can easily hook it ip to either my PC (USB) or my 360 (SATA). In case you´re wondering how I would hook this up to my 360 without having to open it all the time read my earlier posting about the SATA-extension I made.

However as you possibly know you can´t just use the DVD-drive from one 360 in another 360 because each 360 drives firmware has it´s own unique 16-bytes key embedded. So to get the Hitachi-drive running on another machine I had to do at least the following:
  • Dump the unique 16-byte key from my other 360´s Samung-drive;
  • Flash the Hitachi with the obtained key from the Samsung.
Step 1 - Getting the key from the Samsung-drive
I used my earlier build bootable USB stick to boot my PC using DOS. I then used mtkflash to dump the FW of my Samsung-drive:

mtkflash r /m samsung.bin

After rebooting my PC to windows I used Keydrive Xtractor 1.5 to grab the 16-byte key from the FW like this:


Please Note: DVD Key shown is faka data

Step 2 - Preparing the FW-bin from the Hitachi
After copying the DVD-Key to the clipboard I opened the original FW from my Hitachi (orig.bin) and pasted the DVD-Key from the clipboard to the DVD-Key field. I then saved the firmware as "hits.bin".

As you probably know by now the Hitachi-FW has to be encrypted before flashing. Using a tool made by Loser named FirmCrypt I created a "ready to flash FW" using the following command:

firmcrypt e hits.bin hitse.bin

So there it is: the encrypted firmware hitse.bin ready to get flashed.

Step 3 - Flashing the Hitachi with the new key
After putting my Hitachi drive in ModeB using the SlaxVM solution I flashed the sector containing the drives key from windows XP (i being the drive-letter):

flashsec47_win i hitse.bin 90004000 1000

Please note there´s no need to flash the Master Checksum since the key is in an area of the FW not included in the checksum-calculation.

Step 4 - Attach the Hitachi to the new 360
After plugging in the power and the sata-cable (which leads to the motherboard of the new 360) and inserting COD2 it was time to fire up the new 360. And as expected: it works like a charm :)

So there it is: My Hitachi drive works in a 360 it wasn´t "married" to before. At least this part won´t stop me from building my external DVD-drive! Still not sure if I go through with it.

Monday, July 03, 2006

Restoring the Hitachi FW: The 4 bytes difference

After playing around a bit with the Xtreme FW for the Hitachi 47D in my 360 I deceided to flash the FW back to it's original state. After using the SlaxVM-solution to put the drive in ModeB I used the restore.bat included with the Xtreme-package. No problems during the flashing-process, so I thought I was good to go.

I deceided to dump the new flashed FW to compare it against the FW-dump made before I flashed the Xtreme-FW. I didn't expect to find any differences: however there were! Using the fc (filecompare) command I found out 4 bytes were different between the two dumps:

0003E7FC: B6 00 (B6 = "original", 00 = "restored")
0003E7FD: 1C 00
0003E7FE: 68 00
0003E7FF: 33 00


Hmmm, I wanted to restore the FW to the original-state, not to the "almost" original-state. A quick look at the restore.bat file included in the Xtreme FW-package shows me the reason for not flashing back to the entire original situation. The very first flash-command was made a remark:

rem @echo Flashing sector 9003e000 (Master Checksum)...

Uncommenting the above line by removing the "rem" would be the solution to flash back the entire original FW. However the question remains (at least for me) why the 4 byte difference, and more: what do these 4 bytes do/mean?

So I went over to xboxhacker.net to see if my questions had been answered before. And as expected: They were :) Thanks to Garyopa at the xboxhacker BBS I learned what the 4 bytes indicated as "Master Checksum" were and why they were not flashed back:

"The reason the Master Checksum is not flashed back, is because incase one of the other restore flashes failed, or the backup was corrupt or a byte got changed somehow, and the user turned the power off, before checking all the flashes were OK, and the backup was 100% correct, the drive would be a BRICKed drive if the checksum does not match. "

My suggestion is for those of you who want to flash back the entire FW to alter the restore.bat from the Xtreme-package and move the line "@echo Flashing sector 9003e000 (Master Checksum)" to the end of the flashing process. Obviously don't forget to remove the "rem" at the begin of the line. By moving the flash of the "Master Checksum" to the end of the bat-file the checksum will not be set when one of the earlier sector flashes fail (and the batch-file gets aborted by the user!).

Sunday, July 02, 2006

The Slax Live-CD in a VM Summary

Here's my final(?) post on the Slax Live-CD running within a Virtual Machine to enable access to the hitachi's drive firmware using a USB<-> SATA Cable.

To reproduce my findings you need these three things:
  • An USB<->SATA cable. I used this one;
  • The free VMWare Player (link);
  • The Live-CD iso including the VMWare Virtual Disk and VMWare Configuration File (link).
Unzip the live-cd package to a location of choice and open the slax.vmx file using VMWare Player. This will fire up the Slax Live-CD within the player. Once fired up login using "root" for user and "toor" for password.

After logging in use the modprobe-command:
modprobe usb-storage fix_inq_vendor_id=0x152d fix_inq_prod_id=0x2338
Please Note: vendor_id and prod_id will differ if you're using another device.

Use dmesg to find out if and where your device is located (mine was at /dev/sda). Use the modeb command to get the Hitachi-drive in modeb:
modeb /dev/sda

That's it: You can either release the USB device from here and continue your work in Windows (without a need to reboot) or you can just use the linux-environment within the VMWare player.