Sniffing what is done is not always enough to be able to reverse a device. Look at how zero knowledge tests work. I don't know how this USB jb works but I do know that knowing what is said could give no context to the conversation if you know what I mean.

I just got a free year trial to XNA on my Live box. I tried to get it running on my JTAG boxes but have not have much luck yet.

I have been looking at the files in IDA Pro but I don't know much powerpc. I patched some checks in HostLoader.dll and default.xex and now it doesn't complain about not being signed in to Live anymore. It just complains that I don't have a XNA subscription now. I don't know if I am on the right track. I have been looking around some Xam imports. The patches I have done so far were for the XamUserGetSigninState. I am looking at XamUserCheckPrivilege, XamUserGetSigninInfo now. I am not sure I am capable of cracking this but I will give it a try.

On a positive note the connection keys that are generated to associate your 360 with your XNA computer seem to be generated locally by the program. I did some test generating new keys while the network was disconnected and it seems to work fine.

I am going to try some tests on compiling packages and sending to the 360 with some network disconnects to try to see if there is anything essential being communicated from live for the functionality or if it is a artificial limitation for another reason.

Edit: On positive note it seems I can compile and deploy a package to the 360 after I disconnect the network from the internet. There is a periodic check for a connection to Live but that happened after I was already playing my test project for a while.

No

I created a package to patch the retail emulator to remove checks. I didn't find any of these patches myself. They are all from the Hacked v5829 for Devkits. Infact the Final product should work identical to the hacked devkit one. The files will not be identical because of some xex header info that isn't the same.

Files needed.
Original xbox.xex and xefu.xex from a 360 hdd
360 Backwards Compatibility Update 2007 - http://www.megaupload.com/?d=NFQ3BLOI
or
Fusion Title Update v1.9 5829

Tools needed
wxPirs - http://gael360.free.fr/wxPirs.php
XexTool 5.2
XeXtractor - http://helldoc.blogspot.com/2010/04/xextractor-v103.html
BC_Patch.rar - http://www.megaupload.com/?d=9N4G4HAV

How to get Title Update from BC Update.
Extract the default.xex from XBOXCompatible_11-2007.zip
Open default.xex in XeXtractor
Extract /XUIZ/$TitleUpdate/fffe07d2/tu20075c00_00000000
tu20075c00_00000000 is the needed Fusion Title Update v1.9 5829

Patching...
Extract BC_Patch.rar to new directory.
Copy xbox.xex and xefu.xex from 360 hdd to the same directory.
Use wxPirs to extract the title update to the same directory.
Copy Xextool.exe to the same directory.
Run patch.bat
This will update your xexs and patch them with ppfs in binary format then encrypt and compress them again.

Optional
I also made some splash images to make the emulator look more like the original xbox start up with a black background.
I didn't include trademark symbols or Microsoft logo.

Run PatchSplash_16x9.bat to patch

or
Run PatchSplash_4x3.bat to patch


Installation
Copy the following patched files to the Compatibility folder on your 360 hdd. overwrite the original xbox.xex and xefu.xex.(make backups)
xbox.xex
xefu.xex
xefu1_1.xex
xefu2.xex
xefu3.xex
xefu5.xex
xefu6.xex
xefu7.xex
xefu7b.xex
xefutitle5.xex
xefutitle6.xex
xefutitle7.xex
xefutitle7b.xex

I don't know if this is useful to anyone. I was bored and playing with the emulator so I thought I would share. Let me know if you have any problems.

I would really like to see a patch to enable the guide features(music playback mostly). Does anyone know how to patch the Restricted HUD Features flag out of the xex?

I also have an idea to make it easier to work on the compatibility of unsupported games with different profiles. I want to compile a small xbe whose only function is to launch the default.xbe in the same directory. We could then patch that this xbe to run in various emulator profiles. So we could easily copy these files to a game directory and launch each to check the game compatibility with each version of the emulator. I think this would work ok? I have not looked into much though. Just an idea right now.

I had an idea to work around this problem. I am rather uneducated on these boxes but if I understand correctly the MU file system on the nand allocates blocks used by the hack.

If the memory unit part of the nand is just a fatx filesystem(is it?) then why not manually fake a file table entry to allocate the needed blocks so they don't get written to. you could make it invisible to the dash.

anyway I don't have one of these boxes currently but I am currently searching for a jtagable one so if I find one I will try to implement my idea.

I am having a slight issue trying to modify a OEM WD1600BEVS Scorpio Drive

I keep getting
"LBA size does not match!"

Manufacturer: WDC WD1600BEVS-60RST0
Serial: WD-WXEZ07R01611
Firmware Revision: 04.01G04
LBA: 312581808

It does dump the undo.bin
here is a copy if that will help.
http://pastebin.com/f8605491

I have tried 5 different sata chipsets and some will error out and not dump the undo.bin but all the ones that get far enough to dump it will error out with "LBA size does not match!"
I then tried auto-detect and manual and the same error happens.
I also tried version .91b and it will detect the drive but reports incompatibility.

any body have any ideas? is this a known issue?
thanks for any help.

I am not sure which LBA size it is matching to what? i am going to load it up in ida pro and see if i can figure out what the error message means.

any chance of getting the source?

not 100% true
so it merely limits what media it can be executed from.

i have a stack of about 25 dl discs and a 2x360s(1 hitachi,1 samsung) with vulnerable kernels for testing.

i don't know what is needed technically to implement something like this but i would volunteer as a tester if there is a programmer willing to implement any of this. i will be try to be in #free60 if anyone wants to poke me to try something.

from
http://www.xbox.com/en-US/games/backwardcompatibilitygameslist.htm

splinter cell is there.

also save the trouble people have tried the known savegames exploits and they don't work. it might be possible there is another exploitable savegame for another game that isn't publicly known.

yes. that is the only way i can get single layer DVD+R to work. i think the DVD-ROM bitsetting is required.

I have beta tested 5.1 and it fixes alot of those dirty disc problems with the backups i already had made. doom 3 specifically works fine and a few others i had problems with before now work fine. i still had a few issues but i need to double check the files i built those isos with.

I have been building all my iso with their orginal layouts from http://layouts.xbox-scene.com/ with XDVDFS. it works really well.

yes i can verify that these same burns work 100% in an orginal modified xbox

from the success reports i have seen on another forum. it seems that dvd-r might be working. i don't currently have any so i can't be sure. this might have something to do with why the +R or +RW discs aren't geting authenticated.

Has anyone goten single layer to work at all?

I have tried craxtion, gnu gdfimage, orginal ms gdfimage for building isos of games from files. I verified the xbe signature on all burns. I tried dumping directly from my orginals and building isos. nothing works. all report errors. i tried other region games which report a region error. I tried old and new games. i tried launch games and games released this year. I tried DVD+RW and just incase RW was the problem tried a hand full of +R. nothing has worked.

if you have had success with single layer. please detail your entire process so i can try to replicate it.

also if you have success please report which firmware you are using a or b.

Edit:
I just tried burning valid xbox game files in nero with udf xbox compatible disc format to see how the 360 would react. It gives me the exact same error that i got before when burning in xbox dvd filesystem.

This leads me to beleive the the function within the new firmware for triggering a challenge response isn't happening to authenticate these discs even when built with gdfimage. so it is simply reading the disc and not recognizing it as authenticated. well thats my theory at least. i am going to pull apart my drive again and do some tests with  various firmwares and see what happens then.

Thanks for the firmware. i look forward to testing it out.

speaking of reading.. Maybe you should actually read what you quote and respond to.
Worst first post ever.

reread what you just quoted and think it over. maybe you will understand

Great news. what irc network were you on?

why does everyone say $4000 - $4200? those ranges aren't always correct. i have a drive whose key was at 4290. like i said in the orginal xtreme thread just copy from 4000 till you see all FF's and then overwrite in the xtreme firmware. there is a commandline patcher that is much easier though.

its not a benefit. it is a restriction of the processor. like germania said the 8052 can only address 64kb of program space. so the only way to have a firmware bigger then 64kb that is to have it multibanked with bank switching in a common header code area. it is just the way the controller uses the flashrom. the bank switching and the reason for it has been talked about well before the firmware hack was released even back to the orginal firmware hacking thread if you search.

the signature on launched xbes is still checked.

Dzgx216: are you sure that it is the actual firmware on the drive. i know several people who had different fw rev stickers underneath with ms25 on top. i heard ms22 and a couple others. i had a ms07 debug drive that actually had a ms07 firmware which i posted on the forum. perhaps your ms25 sticker fell off. unless this is a replacement drive from etech4sale i would say that it has ms25 and not any other.

or posted on this forum before that