First off, let me say that I KNOW what Error 66 is. This is not another "noob tard who can't read the documentation" thread.-Purchased never modded, never banned 360 Xenon first gen, with a Samsung MS25. XBL updated a few days ago to dash 13604, system still stock.
-Dumped drive firmware with JungleFlasher 0.1.90; reported as MS28 spoofed as MS25. Flashed with Samsung LT 2.01 with spoof carried over as MS25.
-System boots and plays games just fine with new CFW, still on 13604.
-Attempt XBL update to 14699 today, and within the first update progress bar, the system crashes to the classic E66 black error screen from 2006:
http://forums.xbox-scene.com/index.php?showtopic=559583-Reflashed with original dumped firmware, and update installs correctly.
Now, I hit XS searching for answers of course immediately after because this struck me as very bizarre behavior. E66 has always been a console boot error, and seeing it on a system update is very new. I started looking over the firmware files in a hex editor carefully to see if I could shed some light:
1) My MS25 dumped firmware, and the "iXtreme_LTplus_v2.0-v2.01-hitachi_2.0b_added\Stock firmware\Samsung\Samsung_Post_13141" reference firmware are *VERY* different. I expected only the drive key, and Inquiry/Identify areas to be different, but there's massive blocks of data very much unique to each. This flys directly in the face of the notion that all the drive firmwares are identical post XGD3 firmware update.
2) Over on Xbox-Scene, a user named
Ruhllatio offers his input the problem lies with the spoofing, and that he successfully updated with LT 2.01 still installed, sans MS25 spoof. I compared an output CFW with and without the spoofing, and the only difference is the Inquiry/Identify areas:
3) My original MS25 dump has
exactly the same Inquiry/Identify data, at
exactly the same offsets as the spoofed CFW that failed the update.
Conclusion: There IS a difference between the firmware flashed to the MS25 vs the MS28, and running LT 2.01 right now on a MS25 will surely lead to a detection on XBL.
Either that, or C4E's rootkit tech is reporting something faulty? This needs to be looked into, and I would follow the general advice of staying off XBL for now, regardless of what drive you have.
Side note question / discussion:
A few years back, the general consensus of the classic CFW's was, they were invisible to the 360 host itself, and all the detection was related to how the discs were handled. This year's updates have radically changed this standing it seems, with the system itself now flashing the dvdrom firmware, and system updates which require multiple reboots, cold booting the hardware again, and in theory gaining access to the same boot sequence hijacking of the MTK chips that was exploited in the early days of DOS flashing CFW.
Now the Liteon drives do not have a user dump able firmware, and all the progress on that end was done through the acid decanting projects of the Jungle team and co. These drives I presume are still invisible to a host read, and are only "blind" flashed by the system with the console specific information embedded.
The Samsung drive on the other hand, along with the BenQ, always had means of being completely dumped from the user end. JungleFlasher itself, now has the master unlocking command of both drives, and this same command works verbatim on iXtreme LT. What is to stop the 360 itself from simply dumping the drive firmware in the same manner, when it pleases, to have a nice inspection of?
Also, was there ever any info available that the system logged an Error 66 somewhere? A Xval test still reports a clean secdata in the NAND, so there doesn't appear to be any direct flags associated with it, but I'm still wondering if it will come back later to bite us in the ass.
Dilber MC Theme by HarzeM