hacking DVD firmware ?

[Nayr]

Bluecop:

I would be interested to know if the Dangerous Brothers tell you what sort of obfuscation is used on the firmware.

Are you comparing the unencrypted or encrypted version of the various firmwares?

Nayr

[BlueCop]

Nayr: no response as of yet. i will post any information i receive on this thread. also they all appear to be scrambled in the same way.

The link below has pictures of the dev kit dvd rom
http://theconsolewars.blogspot.com/2005/08/smartxx-xbox-360-dissection-mutilation.html

It is a Toshiba-Samsung drive model TS-H943.

I find it interesting that they used a different drive. perhaps they are learning from their mistakes and not making the dev drives capable of reading retail discs. which in xbox1 the drive was capable just the kernel didn't have the correct challenge response to unlock the disc which was what xboxloader.xbe was for. I'm just speculating though since i don't know anything about this dev drive or its capabilities.

[SharkUW]

Why not put an extra session on the end of any given ISO to contain data needed to emulate the handshake, and write firmware for a drive to check for it first and communicate accordingly?

[Geremia]

Maybe i miss something....where is the "decrypted" version of 8050L?!?! i can't find, can someone point it?
Can someone else dump the 3120L firmware? just to see if any difference, but probably dvdrom<->motherboard marriage is done with something like dvdrom serial number stored into...MN103?!?! I don't see any eeprom or simple "silicon serial number" near
Have someone the pinout of the MN103S94FDA (or another MN103 with same total pin number), just to see where jtag pins are, anyway i think it could be hard to find a free jtag software that support this cpu, any idea?

[anita999]

bluecop:
seems that we're doing things in almost the same way. I also send a message to the dangerous brothers asking them for any decryption/disasm info regarding to this MN103S94 MCU. I also compared the bios between 3120 and 8163 and I found the same header and almost the same encryption blocks in similar offsets. So here is something we need to do.
1. To get a decrypted 3120 bios.(or a 8050L, 8163B will also help, too).
2. To disasm the 3120 bios.
3. To tape the SATA on xbox360 and look for
    a. dvd-motherboard marriage clue such as DVD serial# or any thing else.
    b. any possible challenge/response sequence.
4. To fully understand the challenge/response sequence in xbox1 of
    a. kernel side: which bluecop provides a very useful input already. also there might be a kernel source available.
    b. DVD drive side: which we still need further work to trace the firmware of Samsung 605. I think Tiros in xbox-scene has some experience in this drive, but I havn't got any input from him.
So if anyone can help with any items above, especially for 3.a and 3.b, please provide your help. We'll be appreciate.

[TheSpecialist]

I updated my post on my kernel findings a bit'. Little by little I'm starting to understand what exactly is happening. I'll keep updating that post on the previous page about the way the authentication routine works, whenever i find something new.

[TheSpecialist]

So, to my current understandings, the way it works is:

1. The kernel sends  a 'READ DVD STRUCTURE' command to the drive. The drive returns $664h bytes of data, read from the leadin of the disc.
2. Kernel splits this data in 2 parts: signature and table. Verifies the table with the signature and decrypts the 'challenge/response' table
3. The kernel sends a challenge to the drive.
4. The drive receives the challenge reads info on disc (probably 'security placeholders') and returns a response based on the data it read (I'm not sure about that 'placeholders part, but it seems logical).
5. The kernel then verifies the response the drive sent against the response in the table and sends the next challenge from the table etc.
6. If all responses were correct, the kernel sets the 'authenticated' bit to 1.

So, if this would be true, patching it would not be too hard -> before sending the table, let the drive decrypt it itself so it knows what responses to give to the challenges the kernel sends (or if there's not enough free space in the firmware for the decryption routines for example, we could always add a file to the ISO with the decrypted challenge response table, so the firmware doesn't even have to decrypt it.

Anyway, I've still got a LOT to do, some of the above might not be correct, i have to delve a little more in it, hopefully more time tomorrow ...

BTW, thanks to everyone in this thread for participating and helping !

[BlueCop]

Geremia: I don't think you are missing anything. I haven't found a descrambled version the firmware anywhere. Janniz on xbox-scene forums seems to have descrambled it somehow but never posted details on what he did.  He did say this "Panasonic MN103 series or if you prefer Matsu$#!ta MN103 or Matsu$#!ta AM33 that are in fact the same 32 bit processor" so if you are searching for information on the processor that might be of help.

earlier in the thread LenteSubigo was supplied a tool from the dangerous brother to dump 8163B firmwares from dos. I assume modified it might work with any MN103 controller. I have pmed him to request a copy of this file because i couldn't find it anywhere because all the links were dead. hopefully he'll send me a copy to at least take a look at the process used to read the firmware out might be the same and we wouldn't have to desolder anything. Though it is not promising because they never got it working and had to manually dump the chip.

perhaps anyone with the 0046DH or 0047DJ roms could dump theirs more easily. hmm i just realized your bin is labeled 0047DH while the free60 listed  the 0046DH (Core) 0047DJ (Premium). Is this different rom version accurate or just a typo? also was yours a core of premium?

* BlueCop heads to sleep

is there a way to turn off the profanity filter? Matsu$#!ta isn't too profane is it

[MrMod]

great work guys, so If I understand correctly we might fake some data sent from dvdrom to XBOX once we know what exactly happens between the dvdrom and the x360 kernel 

[xor37h]

The Burst Cutting Area (BCA) is part of the Gamecube disc protection sheme (which was hacked silly)

You can indeed read the BCA on your PC with a drive that supports it and a fitting software, for example the free program DVDInfoPro.

An example of a drive that is known to support reading the BCA is Pioneer A05 DVD/RW w/ 1.33 Firmware

You can find a very good description of the BCA in this pdf - Check out the section named "Annex H - Burst Cutting Area (BCA)"

About the scrambling of the firmware, its quite likely to be the KeyCode security function, which you can read more about by
checking the Flash Writer User's Manual and the PX-FW2 User's Manual (section "5.4 Security Function") avaliable from this site,
along with other mn103 manuals and datasheets.

Regards, xor37h

[anita999]

xor37h:
the key code seems to be a validate string in the firmware which control the ability of the programer to read/reprogram the firmware instead of scramble it. thanks anyway.

[Geremia]

perhaps anyone with the 0046DH or 0047DJ roms could dump theirs more easily. hmm i just realized your bin is labeled 0047DH while the free60 listed  the 0046DH (Core) 0047DJ (Premium). Is this different rom version accurate or just a typo? also was yours a core of premium?

I writed wrong in the other thread about flash rom, my drive is correctly rom v. 0047DH, i've the eeprom near the CPU and my 360 is a pal premium buyed in europe in december 2, manufacturing date 2005-10-26

GDR-3120L
X800475-009
E-H023-05-1094(B)
ROM 0047DH
October 2005

[TheSpecialist]

I've also been comparing the 3 bioses. We know for sure that the images are not compressed as a whole, since there are clearly sections in it (as you'd normally see in unencrypted/uncompressed bios files) ->

1. section starting at $0000
2. section starting at $1000
3. section starting at $2000
4. section starting at $6000

There are probably more sections, but these 4 are really easiliy identifiable.
Now, if you compare these sections, you'll find for section:
section 1 -> first $A0 bytes are the same.
section 2 -> no similarities
section 3 -> these sections are exacty the same in both files !
section 4 -> first $42 bytes are the same

So, since 2 sections start the same but differ later on, it's pretty safe to say (in my opinion) that these sections are not compressed (per section), but really weakly encrypted, by a simple XOR, r/l shift or something like that.

Now, of special interest is the modded 8050L bios (for the 8163) ->  An extra ($40 bytes long) header is added. The sections seem to be the same, but clearly, there will be differences It will be interesting to see a bitwise comparison of the (header stripped) 8163 firmware to the 8050L. I'll be trying that this evening.

[TheSpecialist]

also I noticed lots of 99 9B 9F 08 and 66 64 60 F7 repeating through the file and thought it might just be xored. so i xored the whole file with 66 64 60 F7 because that would convert the 99 9B 9F 08 to FF FF FF FF like i thought they should be and the 66 64 60 F7 to 00 00 00 00 which i thought it should be but then the offsets listed didn't have clear text so it wasn't just something simple like that

I think you're onto something here. I don't believe it's a coincidence that 999b9f08 xor 666460f7 = FFFFFFF. It might be possible that it's first XOR-ed and after that (like Amadeus noted) it's bit shifted. After xoring, the fillers will be 0000000 and FFFFFFF (I agree that's what the fillers should be) and after bitshifting the fillers will be still just that, only the rest of the data will be different.

So, the xor operand might be 999b9f08 or 666460f7 (I tend to believe it's the first, since a 000000 filler seems more logical to me) and shifting operand anywhere between 1 and 32. This would yield 64 romfiles to check and scan for unencrypted data. Maybe if i have time for it, i'll try to make these 64 files and look through them for unencrypted string data, but this will take some time And of course, it still might not result in the desired unencrypted file ...

*EDIT* a better idea would be to let a program check the 'unencrypted' files for strings like 'DVD', 'ROM' or '8050' or something like that. I'll try tonight/tomorrow to write a program that decrypts and checks for strings.

[TheSpecialist]

Any other ideas of what simple encryption technique might be used ? I think it's a good idea to write a program that tests every simple encryption method and scans the resulting files for unencrypted strings.

[Nayr]

I've already tried to xor with both 999b9f08 and 666460f7, there are no strings and the disassembly at offset 0 is junk. I also looked at the possibility that the data lines are miss wired.  That didn't look right.  I don't think the address lines are miss wired because of the definite sections we see.

Frequency analysis shows the roms aren't compressed or strongly encrypted.  I wouldn't call it encrypted at all. Obfuscated is the right word.

Remember people have already broken it.  If we don't hear from them, it shouldn't be hard to break it.

One theory I have is that there is a small decryption program hidden in the roms. It could be plaintext or weakly encrypted.

Anita9999: if you hook your LA up the addresses lines of the flash, you can tell where the processor starts executing from at reset.  Any of the similiar dvd drives would work.  It should also tell whether the processor is executing directly from the flash or whether some other code is serially decrypting the flash into ram.

Simple ways to obfuscate things include xors, rotations and bit transpositions.  These are basically free in hardware.  Also the address is available, so bits from it could be used.

Another possibility is that the flashing software has a decryption routine buried it it.  It needs a way to check if the firmware is compatible with the drive it is getting ready to flash.

Nayr

[InterestedHacker]

I've already tried to xor with both 999b9f08 and 666460f7, there are no strings and the disassembly at offset 0 is junk. I also looked at the possibility that the data lines are miss wired.  That didn't look right.  I don't think the address lines are miss wired because of the definite sections we see.

Frequency analysis shows the roms aren't compressed or strongly encrypted.  I wouldn't call it encrypted at all. Obfuscated is the right word.

Remember people have already broken it.  If we don't hear from them, it shouldn't be hard to break it.

One theory I have is that there is a small decryption program hidden in the roms. It could be plaintext or weakly encrypted.

Anita9999: if you hook your LA up the addresses lines of the flash, you can tell where the processor starts executing from at reset.  Any of the similiar dvd drives would work.  It should also tell whether the processor is executing directly from the flash or whether some other code is serially decrypting the flash into ram.

Simple ways to obfuscate things include xors, rotations and bit transpositions.  These are basically free in hardware.  Also the address is available, so bits from it could be used.

Another possibility is that the flashing software has a decryption routine buried it it.  It needs a way to check if the firmware is compatible with the drive it is getting ready to flash.

Nayr

Just tried this myself an hour ago as well.  I had no luck either.  I XOR'd it to get 999b9f08 back to 000000, and I XOR'd to get it to FFFFFFFF.  Scanned through looking for anything remotely textual, and found jack.  I also got it to shift bits left and write each of those files out, and still nothing apparent.  I don't know if we would see string refs in there, I don't know enough about the microprocessor.  It's possible there's a rotation going on as well, I would certainly agree.  It is NO coincidence that these blocks of 999b9f08 are there, I do think were on the right tracks.  There is a rotate ASM instruction for x86 I think...  Might see if I can do more later.  Out of interest does anyone know the kind of strings we could search for?  I am thinking along the lines of interface commands, ATAPI?  Maybe copyright messages, or would there be anything remotely connected to XBOX and MS in there?  easier to find patterns based on simple words maybe.

[TheSpecialist]

Simple ways to obfuscate things include xors, rotations and bit transpositions.  These are basically free in hardware.  Also the address is available, so bits from it could be used.

I agree, 'obfuscation' is a better word in this context than 'encryption' I'm quite sure it's just a combination of xor/rotation/bit transportation.

Another possibility is that the flashing software has a decryption routine buried it it.  It needs a way to check if the firmware is compatible with the drive it is getting ready to flash.

True. If the rom decrypts itself, then it has to be done in the beginning of the reset vector of course.

[BlueCop]

InterestedHacker: As i posted earlier in the thread. the values between the 8050L and 3120L at offsets  0x20BA, 0x6000 are the same in both files. Based on the information from an old post on xbox-scene about the deciphered 8050L it should contain strings HL-DT-STDVD-ROM at these offsets.

I was also thinking parhaps if we have know values for those offsets. I was going to attempt to work backwards starting with the HL-DT-STDVD-ROM (48 4C 2D 44 54 2D 53 54 44 56 44 2D 52 4F 4D) and then ciphered hex and go from there.

With the bit shifts you guys are going are you doing single bytes or like 32bit shift?

You could just look for runs of values that are between the ascii text values. So like Capital A-0x40 through like Capital Z-0x5A and lower case a-0x61 through lowercase z-7A or you could even include the digits 0x30 through 0x39. So you could detect the cleartext if like more then 3 of this values are in a row. I'm sure you would get some false positives but it might be better then looking for specific words.

[Phantasm]

As suggested earlier, i wrote a program to apply the xor's and then try all of the bit rotation values (i did 0-31) and didnt find any useful
instances of the word DVD or ROM or 8050 (apart from a couple of false positives which didnt yield any other interesting ascii strings).

Tried it with both xor values.