Homebrewing with KingKong original

[atiman]

Here is battle plan to enlarge a bit more the number of potential homebrewers on 360 (feel free to comment, technical impossibility especially)

Phase 1: Use King Kong original 1st edition instead of patched KK backup
(the one which doesn't verify shaders)

In order to achieve that :
- flash drive with a specific firmware which holds the data to replace inside shader and is able to supply, on the fly, replacement data when console requests the data for this disc area
- insert King Kong original
- do as usual (should reach the same point as with a patched KK backup)

Many will think it's useless, but it will bring useful knowledge for next phase.



Phase 2: Try to put each demo/game/whatever into the following categories

Category No:
The code loads its shaders in memory and verifies it in memory at one place, then keep it in memory and use it at will without needing further disc access.

Category Ok:
The code loads its shaders in memory and verifies it in memory in a preliminary check phase. Later, it reads it again from disc and use it (without verifying it, we assume for now, can't verify yet).

How to put them in each category:
- Locate shaders on disk.
- Use a specific drive firmware to detect when these areas are read.

Once we get something in category Ok, we can try to apply the same trick as with KK, but by asking the firmware to not patch on the fly the shader data when we think it's the verification phase and cross finger next time it's read it won't be verified.


If nothing comes to block this plan, the potential gain is a possible easier way to initiate the vulnerable state for homebrew purpose.

Rebooter project is complementary and will allow later to just reset console at will without initiating again vulnerable state.

[robinsod]

Great plan, go for it. Let us know how you get on

[atiman]

Ok.
I will do research for Hitachi ROM VER: 0047DJ (mine, of course).
Absolutely no ETA.

[do0my]

Hmm, we're already flashing DVD drive firmware, so why not save your time and use the wonderful tools that are already out and take the extra 1.5 hours to make a patched King Kong backup.

Good luck fitting all of that code plus the shader in 256kb.

[atiman]

Work in (slow) progress...
- Got all info about chipset from http://www.kev.nu/360/dvd.html
(including mn103 assembly manual and IDA Pro mn103 plugin)
- Invested into 360 Blaster SE and 360 Usb for easy drive reflashing
- Currently studying original 47 fw and comparing it with iXtreme 1.4 ones.

First step : to be able to change a color when original KK is started.

(do0my, you don't get the point. This project is to create a new tool that allows us to not waste a double layer dvd-r for each patch research step)

[atiman]

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...

[Pitfall6667]

 
you do know that robin was making fun of you, right?
it's practically impossible to patch the shaders on the fly
there's a big wall between the dvd drive and the gpu
but sure, I'll let you go and try reinvent the wheel! 

btw, in case you're looking for a "cheap" solution, you could solder a max3232 to the onboard serial port and try the patches that way (using crawler360 loader)

another btw, you haven't really "invested" any money, you only wasted it (you know, blaster360, usb, etc.)

again, I won't be in your way blocking your dreams!

[atiman]

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!)

[Pitfall6667]

good luck
I'll look forward to this

[atiman]

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...)

[atiman]

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

[Arakon]

not single layer, you still need double layer. read closely, he said "I hunted down one single dual layer disk".

[arnezami]

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

Yes. Very nice indeed (although im pretty sure he is talking about a single double-layer disc).

Anyway. Your idea of creating a way to patch disc contents on-the-fly is kinda nice. Some ppl may wanna play around with shaders (and refine what is done there which may or may not interfere with any rebooting/homebrew code later on).

I do think though these ideas are more for convenience. Not so much a necessity.

But thinking along these lines: to make things even more convenient you could stretch the idea further by this: altering the hdd fw to (partially) emulate the dvd drive with a game "inserted" containing a shader to exploit the HV. Assuming KK you may even automate the pressing of the "start" button (since we own the SMC). This would effectively give you (the illusion of) a full hdd bootup into linux/homebrew. After the exploit code has run the hdd would have to be switched back to normal mode and the dvd drive would have to be "turned on" giving back normal functionality to the homebrew/linux code.

Of course I don't know if this is even (remotely) possible. Especially the HDD stuff. But if we can't find any other exploit then this is probably the direction we want to go to come close to a xbox 360 that boots directly into an OS of our liking.

Just some thoughts.

Regards,

arnezami

[Icekiller]

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

like arakon said i didn't mean single layer dvd but ONE dual layer dvd

[Pitfall6667]

I thought a sector size was 2048.

2064 = 2048 byte sector + 16 byte header

btw, you're saying you want to do it without people being able to play pirated/backup games?
how about reading something unique...say the SS? check if xtreme -> crc correct -> run, else fail

[atiman]

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?

[Icekiller]

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?

like i said in the post.. i made it to not change the disc anymore..

[Pitfall6667]

atiman, no offense but what is your goal in all this?
until yet I've only seen giggles-style replies
experiment with shaders? use onboard rs232
run exploit without having to waste a DL? make it legal that way?
excuse me, but wtf?
can you give us a simple example of what the goal is, which wasn't possible yet? throwing around ideas isn't going to help.

[atiman]

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.

[atiman]

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.