It will be certainly boring and not useful for expert coders, but modified xna launcher and net library will be interesting for casual coders, and more important to RPG makers (the kind of people who wants to spend most of their time creating a story and graphics rather than coding technical challenges for fun).

- patch xna launcher to severe any relationship with MS servers
- patch net library in order to allow basic network capabilites with private servers (if your homebrew needs networking)

Non-expert coders will be glad to just download legally and for free xna 3.1 game studio and visual c# 2008 express edition (which will be less nasty if they code mistakes in c# rather than in c)
You can then try developping for free and have a few beta testers on jtag'ed 360's then later if you like, pay and try to develop for the real mass market.

It seems that re-using these 2 free stuff seems to work already for creating free homebrew on zune (http://zunedevwiki.org/wiki/) even if there are serious changes in this first approach (c++ instead of c# it seems)

Since managed code based on xna framework is made for identical running on PC/Zune/360 the investment in that way of coding may have more potential in term of user base than one may think...

I'm addicted to 5x drive speed (I can't bear loud noise from console anymore, ever), and on my water cooled 360 it's a pure silence pleasure since then...

Of course, do it only if you never connect to internet with your 360.

This is how to switch to 1.51 5x speed on Hitachi 47, using jungle flasher 1.55 beta, SE Blaster and usb/sata adapter (no need to re-open console or pc) :

First, the study of difference between hitachi 47 iXtreme 1.4 x12 et x5 reveals :

Comparison of files 47_16-12x.BIN et 47_16-5X.BIN
00003802: 31 35  (decimal offset 14338)
00003803: 32 78
00003804: 78 FF
00026AEC: 03 02  (decimal offset 158444)
00026AF0: 04 02

- Unplug console cord
- Switch the 3 buttons on SE Blaster
- Plug cord
- Turn on console
- Connect usb/sata adapter to SE Blaster
- Connect usb/sata adapter to PC
- Launch jungle flasher 1.55beta
- Click 4th tab
- Select Upload Ram method
- Select dumps and click Dump to source button
- Save the .bin of your current 1.51 12x fw (hitachi 47)
- Edit .bin and apply the 5 bytes change (as above) with any hex editor
- Press CTRL+F8 to enable 'free flash'
- In first tab, select target fw (the one you dumped then patched)
- In 4th tab select 'free flash' and flash
- To be safe, dump again, compare (fc /b a.bin b.bin >diff.txt)
Only the 5 bytes should have changed.
- Unplug console cord
- Switch the 3 buttons on SE Blaster
- Plug cord
- Turn on console
- Enjoy silence (well at least, minimal fan noise if you water cooled console...)

Sure get a kit (if you know exact drive version). Deluxe solution is SE Blaster kit that avoids to reopen later again console when new versions of ixtreme drive firmware arrive.
For the link between the kit and the pc, you have luck. For hitachi there is a small blue device on the market that has an usb cable on one side and a sata cable on the other side and works wonderfully.

However you will need to read the drive version on the drive itself before knowing what product is compatible with it. May takes time. You shouldn't rush. Also wait for ixtreme 1.6

Ok, found it. Don't know how to reach it the normal way (never found the path of links that leads to it), but I could find it through a forum search with keywords "system update" :

http://www.xbox.com/en-US/support/systemuse/xbox360/console/systemupdates.htm

The page explains how to burn cd in order to update and offers a little link "here" that leads to

http://download.microsoft.com/download/D/1/8/D181EE58-DE70-4484-936B-0E9161CCD6B2/$SystemUpdate_Fall08.zip

(74.6Mb)

I think MS is not publishing this offline method in front because they count on NXE upgrade to just attract more LIVE subscribers...

Try to flash your dvd drive with an older hacked firmware version
(recent ones reject non perfect backups, in order to 'try' to prevent bans)

While you trying homebrew/linux through KK and using older drive firmware and 4532 or 4548 kernel, never connect to live. Disconnect physically ethernet cable (put it back when Linux has finish its booting sequence for example).

Dunno if it's related, but I have similaire failure rate in the booting process using the serial device. If you are using the serial device, maybe it's more in the serial booting process that the lack of reliability is, and not sure we can improve it at all.

If you are using another method than serial device, then ignore this post since it's then related to something completely different.

Never got glitches or RROD, but I wanted to prevent them.
I never let my summer 2006 360 go beyond 60 degres celcius (thx to probes), then 6 months later I removed X-Clamps (just used plastic caps to maintain board against heatsinks legs) and replaced heatsinks with X-matic water block (which reuses same legs). Now it can never go above 55 degres celcius.
Never got a problem with my 360 (touching wood...).

Interesting! Thanks!
If humidity change is the key, what would you think about adding one of these little bags filled with a substance that absorbs madly humidity, inside console?

I'm still being squeezed by my boss, losing weekends very often.
But in the few hours of free time I could save, I could label functions with names given by anita999 in this post (thanks a lots to anita999 for it!):
http://www.xboxhacker.net/index.php?topic=276.0

In this post, focused on authentication phases (whereas I'm trying to learn what's happening in normal phases, i.e just reading normal data from media), the commands for reading normal data are missing in the given commands dumps. I'm lacking basic knowledge about dvd and cd access, so I'm still studying randomly atapi_read_cd, atapi_read_12, atapi_read_10 and atapi_read_buffer.

When IDA Pro displays calls trees for atapi_read_buffer we can see:
atapi_read_buffer->sub_90030d08->CopyToRam
and
atapi_read_buffer->sub_90030d3a->CopyToRam

When I have more free time I will try to find out if CopyToRam really handles normal data transferts or not (so I can patch them on the fly). Of course if everything is made through DMA without going through mn103 chipset ram, I will be in trouble...

Wow! Impressive! Many thanks!

1) How to fix restore.bat in iXtreme 1.4 package

replace

if NOT exist orig2-e.bin goto CHK59b

with

if NOT exist orig2-e.bin goto CHECK59b

(otherwise, it doesn't really reach the final messages that confirms everything was restored, or wasn't restored, and plenty of files are not cleaned up in the directory)


2) About progress status...

The more I dig into ATAPI command handler READ(12)/READ(10)/READ CD, the less I find any connection to AES encryption function. So, maybe encryption between drive and southbridge only happens at authentication time (1614 bytes is the size of the subpart of SS sector, I guess).
So, I will seek the right place in code where I can intercept data and patch on the fly. I'm studying slowly, during weekends. No ETA at all.

About needed room for simulation, I think arnezami's idea was to have needed data on hard disk itself.

About simulation, I know nothing about 360 hdd. I just added that using another hard disk, if possible, a model with a connection similar to the one used between current 360 dvd drive and console, would be easier than trying to bend the official 360 hdd.

If too hard or impossible, let the thread sink. No problem.

In thread http://www.xboxhacker.net/index.php?topic=8983.0
arnezami suggested an idea about...


I will add this : instead of hacking the 360 hdd fw, we can even just replace the physical drive with a cheap, huge, not-overprotected (or not protected at all), standard hard disk. Legal and free firmware edition tools may even exist for the chosen hdd model, and since we know the drive firmwares we can try to have the hdd simulate a valid dvd and its contents. Another part of the hard drive would be a fully usable standard partition for Linux.

The bright side of this project would be to add a 3rd booting method :
Current (now old) method : requires 1 dvd DL (patched KK) + 1 CD
IceKiller's & StonerSmurf's : requires 1 dvd DL (patched KK merged with CD) + 360 hdd
arnezami's idea (if works) : requires 1 cheap hdd with 'dvd simulation' fw on it.

Of course the dark side would be to allow the birth of something similar to a quite infamous software I won't even name here. It's a software for ps2 that triggered lawyers actions against its resellers.

So here is a thread for this nice idea. Feel free to give your opinion (and share your knowledge of existing interesting hard disks models, or technical impossibilities). Thanks.

If I want to test a new booting method for people who don't own either hdd or cable soldered to serial port, then, for now, I'm compeled to burn DL DVD's.
I want to avoid that. If you are not interested, just ignore this thread.

About arnezami's brilliant idea. I will create a separate thread now.

Oh me bad... Still DL burn needed. And DL burn costs, so yes, patch on the fly is not a necessity, unless you want to test many different patch. So it's really a project to create a tool for devs.

I didn't think about the hdd fw... Anyone has made some research on that?

Wow, IceKiller just posted a way to boot Linux from 360 hard drive without swapping disks! And it's about a single layer DVD burn too! Very interesting!

http://www.xboxhacker.net/index.php?topic=9262.0

Very good for hdd owners! Thanks a lot!
(I will think about purchasing one now... hehe)

I see more clearly what can be done, as a first "patch-on-the-fly" attempt :

The current KK patchers change a shader but they also modify a character in 3 strings naming 3 .wmv files, so they aren't found and not shown at boot time. It will be easier to try this filename patch (1 byte to change in a .wmv filename, easy to recognize) as my first attempt.

Normally, thanks to tazphoenix demonstration, KingKong Classics original will be compatible as well.

I think I will be able to provide a .ppf file to apply with PPF3-O-MATIC on several compatible c4eva firmwares but also the original 47 firmware.
I will keep code changes in the areas covered by the RESTORE.BAT delivered in the iXtreme 1.4 package, so we can still rely on this very safe batch file.
I think the FLASHIX.BAT will be reused too. If I need room for code, it's possible it won't be compatible with 1.4 but 1.1 instead (found in older V1R5 archive).

If homebrew on 360 is really to be promoted, I think it will be interesting for stores, to purchase 360's, downgrade them to 4532, then flash original 47 firmware with the 'hbotf' patch ("hombrew on the fly"). That way, the console they resell isn't able to play backups, but can boot homebrew when you launch KingKong or KingKong classics original (better to be sold with the console). That would be a nice "Homebrew" bundle. MS could even do that themselves and patch the firmware a bit more to turn it impossible to reflash (and warranty would be active!).
(I won't be able to test it myself, but a .ppf for 32 or 36 that may be found on ebay, may be useful in case 360's don't have hitachi 47 inside. Easy adaptation for hitachi 46 is possible. Just a 16h offset to apply I think.)

If we beg politics to preserve legal ways to homebrew, it's important to find a few technics that allow homebrew and disable piracy at same time. I think...

If my first attempt works, I will go for the shader patching.
The one that allows booting through serial port will be my second attempt.
With some luck, maybe, later, a bootloader loading through raw ip packet may be researched... Not silly, since streaming video from PC is a common demand.
Other things to do according to battle plan above, is to make a version that allows to report some shader sequence detection to see what can be done with other games/demos/whatever. I think that can be done by storing in drive chipset ram what is found and reading it later by using it as a patch-on-the-fly to apply to a blank data part (with recognizable header) read from a burnable media (need to define that better later, maybe a comment section of a media file allowed on 360).

But no ETA. I don't want to rush and brick my drive. I will study more all the calls to the AES encryption function. I must be sure I'm interfering only with data read from DVD and not the flashing code itself. Also 1614 bytes is strange, I thought a sector size was 2048. There are other calls encrypting only 16 or 32 bytes at a time, maybe they are the good ones to intercept...

Wait & See!
(I'm sure experts can do this faster than me, so don't hesitate to overtake my plan... For other drives, but also 47 if I'm too slow...)

Reading many threads taught us that verifications (beside SS) are done on GPU side, and if vulnerability could be triggered it's because KK fails to verify shader part. We own firmware changes so we just slip a change in the existing AES encryption mechanism, already existing. I still don't see why a small change, on the fly, in a part we know is never verified (since we can reburn it changed and still have a valid dvd), wouldn't work. Maybe a few more things need to be done, but I think the principle is valid.

I have the cable you talk about, and it's for talking with the console AFTER the vulnerability is triggered by shader, not BEFORE.

Once again, I don't want to reinvent the wheel, I want to invent a way to test shader patches that trigger the vulnerability to explore all ways to do it, without needing to burn hundreds of blank DL DVD's.

(Also I don't regret my purchase because you can't imagine my pleasure when I reflashed my drive with a 5x fw. After watercooling my 360, I gained wonderful silence... except when drive spins up... Aweful noise... Without dismantling my PC -I lack hardware and knowledge for a reflash from PC-, I could reflash without a problem just by using a usb cable between console and PC. And now, all is silent!)

Slowly progressing in Hitachi47 firmware code understanding...

ROM:9002E343                 mov     0x80035CFD, A0
ROM:9002E349                 mov     0x64E, D0
ROM:9002E34C                 mov     2, D1
ROM:9002E34E                 mov     0, A1
ROM:9002E350                 call    0x90031083, [D2,D3,A2], 0x10

If I'm right, this call encrypts 1614 bytes with AES at address 0x80035CFD.
Maybe it's the chunk of data read from dvd and ready to send to GPU.
But I may be wrong. Any opinion is welcome.
I'll have to try to detect a unique shader sequence in KK shader and try to change a color, on the fly...