Cracked Samsung SDG-605B/616T/616F Firmware for Xbox 1 - V2

[Geremia]

IT WORKS

i had simply a filesystem corrupted during my first burn

[DonJ]

Great work commodore4eva

[TheSpecialist]

Well, congrats to the author then And sorry for being VERY skeptical after his first fake release Still, I'm VERY much puzzled why this works ... Most strange thing is the rescrambling of only $7F bytes where you'd expect rescrambling of the complete table ... Going to look into that now and experiment a bit with it ...

[Arakon]

@geremia: what did you make the dump with? what swapdisk and app?

[stonersmurf]

I can't believe it took you guys 4 day to confim his hack.  lol Anyways great work commodore4eva and could you post the firmware that snags the SS. Thanks

[twizter]

the reason it took 4 days is because its hard as f*ck to make a backup disc that will work with this firmware, without a proper guide.

- btw i hope Geremia posts a detailed guide of how he made it work.

[evestu]

I can't believe it took you guys 4 day to confim his hack.  lol Anyways great work commodore4eva and could you post the firmware that snags the SS. Thanks

it only took 4 days because the way the iso needs to be setup

we are lucky geremia took the time to find out more on how the iso was made

but any how looks like it works so test completed  

but more things can be looked at now from the TS side of things

[madwill]

nice work commodore4eva congrats and mucho respecto for having the balls to release this hack.I hope for your sake your door doesent come off lol ms are a hard battle to beat in court and im sure that they are watching this forum.Looking forward to see what you can do with the 360 again CONGRATS 

[gillianseed]

THANK YOU commodore4eva!  Great work!

[nokaktsawa]

Well, CONGRATS to commodore4eva for your hack. This guy pwned everybody's a$$e$ this time I would say.
Oh, and many thanks to Geremia too, as always helpful with his precious contributions.

Well, it looks like the way commodore4eva recreated the hack was kinda different from the original idea in more than a part. I would like that the differences are discussed, to see which is the best approach for the time being. I think that there SHOULD be some kind of "standard" soon to modify FW's, and especially to create backups, for obvious reasons. Like, for example, in which sector should be placed the SS and in which form (TheSpecialist and other's way or Commodore4eva's way? What's best? And why?).

[Geremia]

My "big dvd" is a burned DL of 8,5GB, big enought to overlap both the layerbreak and secondlayer dataend PSN of original xbox disk.
Hotswapped with AUF pal, then i made a .tao image with isobuster, wich give the option to set badsector retry value to 1 and fill the badsectors with dummy data (clonecd seems to skip too many sectors. but maybe i'm wrong). Isobuster makes an image without information of layerbreak, so i could not burn directly.
Clonecd instead makes images with addictional text file .dvd containing information about layerbreak position and image file name.
If you don't want to make a .dvd file yourself, you can start dumping the image with clonecd an then stop immediatly.

here is my AUF.dvd for example

LayerBreak=2086864   <- this is in decimal the first LBA sector of layer1, so in hex PSN 1FD7D0+30000 (30000 is leadin size)
AUF.000  <- this is the 8,5GB image i did with isobuster

note about layerbreak
the layerbreak specified into the leadin, which you can read with read dvd structure command with dvdinfopro, is the last sector of layer0, here clonecd call layerbreak the first sector of layer1, so it's the real layerbreak+1

Prior to burn, i used hexworkshop for hexediting the image and add the SS
The position of the SS into the image is calculated like this:

My big dvd has last sector = FCFFEF
FCFFEF-F9FA00=305EF, each sector is 2048byte(0x800 hex), so 305EF*800=182F7800 this is in hex the distance backward of the PSN F9FA00 from the end of the image file, use hexworkshop to find the right place.
BTW, it seems that this is the distance of the end of the F9FA00 sector, so the sector begins 0x800 bytes back, anyway in dubt i pasted the SS in both places.

Just burned with clonecd and go. I've a pioneer 109 drive and i suppose it automatically set the disk to dvd-rom after burning, just only for DL disks, but actually i really don't know. Anyway it worked maybe because i've a modded xbox, maybe it's the hacked bios that patch media type, anyway hacked bios doesn't do anything to authentication protocol (as i know), so it was not important to test the disk on an unmodified xbox.

*edit*
another note, TSunlocker unlocks the drive correctly and with xiso1.1.5 i can browse the xbox game partition content correctly

it tooks 4 days because of skepticims, holyday and gf. Anyway respect to commodore4eva, maybe it works alone and have no time to spend on boards.

[TheSpecialist]

Well, CONGRATS to commodore4eva for your hack. This guy pwned everybody's a$$e$ this time I would say.
Oh, and many thanks to Geremia too, as always helpful with his precious contributions.

Well, it looks like the way commodore4eva recreated the hack was kinda different from the original idea in more than a part. I would like that the differences are discussed, to see which is the best approach for the time being. I think that there SHOULD be some kind of "standard" soon to modify FW's, and especially to create backups, for obvious reasons. Like, for example, in which sector should be placed the SS and in which form (TheSpecialist and other's way or Commodore4eva's way? What's best? And why?).

Yes, I'm also very interested in discussing this. If I didn't know Geremia as being a very good hacker, I'd probably call him a liar, lol Seriously, I am so much puzzled. I just tried to decrypt the drive's table using 0x00000000 as key (like MacDennis suggested), but the table doesn't decode correctly (like I suggested, it almost CAN'T decode correclty if you only rescramble a part of the table). Anyway, still looking at it, I'm VERY interested to solve this puzzle

[TheSpecialist]

Geremia, seriously, I'm going crazy here I really don't see how this could work. The SS doesn't contain any unencrypted responses. decrypting the drive's table using CPR_MAI=0 doesn't work. Then how did he do it ?

I feel stupid for asking, but seriously, you did switch off the modchip in your xbox ?

[qwerty]

Hello, it is my first post here but i've been following this threads for a very long time. I have experience with assembly and embedded programming and would like to review this FW and try to help understand this. I have IDA, but i would like to know what tools are you using to disassemble the bin. I also need to know which CPU is used. Thanks.

PD: i don't have an XB or XB360 but i am interested in hacking, specially this expensive "security" systems ;-) I can't really believe they spent so much money on this protection and left this backdoor open...

[TheSpecialist]

Hello, it is my first post here but i've been following this threads for a very long time. I have experience with assembly and embedded programming and would like to review this FW and try to help understand this. I have IDA, but i would like to know what tools are you using to disassemble the bin. I also need to know which CPU is used. Thanks.

*EDIT* sorry, for THIS FW (the sammy), use 8051 in IDA

[Geremia]

I feel stupid for asking, but seriously, you did switch off the modchip in your xbox ?

hum, no, i've the TSOP flash flashed with hacked bios, but does is it really important? The authentication protocol is still in place in an hacked bios, it was not known at that time, right?
I'll lock an HD and flash it with original bios if you like.

Another note for you: you previously disassembled this fw at location round FDB5 (where the value F9FA00 is found) and as far i can understand asm (quite near zero) you decoded F9FA00 as part of an instruction if i'm not wrong. well, my backup disk have 2 SS near, so if i change in fw the value F9FA00 to F9FA01 it works again, it reads the SS apparentely from F9FA01, then if i change to F9FA02 (i've empty sector here) tsulocker report empty SS.
I also made a test this morning with SS on layer0 (the SS from commodore4eva untouched, so with the original game partition layout information) but didn't work, i'll play with i later.

[twizter]

anyway hacked bios doesn't do anything to authentication protocol (as i know), so it was not important to test the disk on an unmodified xbox.

-
uhh just by chance, could you try it on a unmodified box just in case?

[TheSpecialist]

hum, no, i've the TSOP flash flashed with hacked bios, but does is it really important? The authentication protocol is still in place in an hacked bios, it was not known at that time, right?
I'll lock an HD and flash it with original bios if you like.

Hehe Please try again on an unmodded xbox

Another note for you: you previously disassembled this fw at location round FDB5 (where the value F9FA00 is found) and as far i can understand asm (quite near zero) you decoded F9FA00 as part of an instruction if i'm not wrong. well, my backup disk have 2 SS near, so if i change in fw the value F9FA00 to F9FA01 it works again, it reads the SS apparentely from F9FA01, then if i change to F9FA02 (i've empty sector here) tsulocker report empty SS.

Yes, that is also what is VERY weird and another reason why I believe this can never work His code jumps to FDA0, this is the location of his patch. Then it executes FDB5, this is program code, NOT data ...

[wans]

I feel stupid for asking, but seriously, you did switch off the modchip in your xbox ?

hum, no, i've the TSOP flash flashed with hacked bios, but does is it really important? The authentication protocol is still in place in an hacked bios, it was not known at that time, right?
I'll lock an HD and flash it with original bios if you like.

Another note for you: you previously disassembled this fw at location round FDB5 (where the value F9FA00 is found) and as far i can understand asm (quite near zero) you decoded F9FA00 as part of an instruction if i'm not wrong. well, my backup disk have 2 SS near, so if i change in fw the value F9FA00 to F9FA01 it works again, it reads the SS apparentely from F9FA01, then if i change to F9FA02 (i've empty sector here) tsulocker report empty SS.

Hacked bioses only patch the key as far as i was aware, since the xbe isnt patched to read from dvd or HD, the key wasnt altered.  In theory this does proove that it was a succesful boot, however it would be really nice to apply it to a totallty un moddifed console and see it boot.

Im gonna make me a big 8.5 dummy disc, unless anyone knows of any dvd films that will do the job?

[TheSpecialist]

Hacked bioses only patch the key as far as i was aware, since the xbe isnt patched to read from dvd or HD, the key wasnt altered.  In theory this does proove that it was a succesful boot, however it would be really nice to apply it to a totallty un moddifed console and see it boot.

I am not 100% sure here, but I believe that most 'modern' modchips autopatch the mediaflag in the XBE, so you don't have to patch the XBE yourself. That could explain why the disc booted: it never executed the C/R session. But again, I might be wrong   Anyway, I'd VERY much appreciate it if you could test it on an unmodded xbox Geremia, thanks !