hacking DVD firmware ?

[marvin]

i've look firmwares from http://tdb.rpc1.org/#GDR8163B

* DLD part is at 0x20A58 inside .exe files
* DLD header length is 0x40 (already known)

DLD header infos I've found:

offset length
0x0       0x2          short(16bit)     sum of the whole DLD (from offset 2 till the end)
0x2       0x2          short(16bit)     " " without header      (from 0x40 till the end)
0x1D     0x3          length of binary part (obvious)

comparing binary part of DLD is interesting, between RPC1 and AUTO.

changes must be really small (few bytes)
sample:
BB26AUTO.BIN / BB26RPC1.BIN  (DLD without header)

offset  length:

0x3E7FC        4 bytes (in a middle of a 99 9b 9f 08...)
0x3FFFC        4 bytes (tail of the file)
=> those are maybe checksums (?)

0x1A94C        8 bytes
0x2A17D        8 bytes
0x2A5E4        4 bytes
0x2A8E9        4 bytes
=> suspicious, could be checksum too.

0x2A2D4      big diff. here, the real job.

EDIT: corrected 2nd checksum, from a post on http://forums.xbox-scene.com/index.php?showtopic=325005&st=630

[Tiros]

I think all this XOR/ROR etc. business is just wheel spinning. I could be wrong, but I think it is highly unlikely that the rom is encrypted. There is prolly not enough resources (RAM/horsepower) to decrypt code on the fly, maybe small sections, but not the bulk of it.

So why is the code a mess?
What about this:
Address and/or Data lines have been transposed on the physical ROM to CPU connection. For instance A0 (CPU) may not be wired to A0 (ROM) maybe wired to A7 etc.... So what you do is take your normally compiled FW obj code, and run it through a program that transposes the address and or data bit connections to match the actual PCB connections that connect CPU to Rom. Program up the rom with the result. Now when the CPU boots up it sees the correct FW in logical order, But if you look at the rom dump with a hex editor, it's a mess!
The firmware is obfuscated completely to hex dumpers, but the CPU sees it perfectly, and can execute at full speed with no "decrypting" overhead.
What needs to be done is to verify the Address and Data line connections from CPU to ROM are 1:1 or not. The CPU address/data pins are fixed in silicon as are the Rom connections. I have no 360, so I can not check. A simple mulimeter test should prove or dispell this theory quickly. I wouldn't waste anymore effort on "decrypting" software until this basic information is known for sure.

[GrosPlombs]

I agree with Tiros.

How was the firmware image  gotten? Was it downloaded by connecting the drive in a PC and using some utility to download it? If so, then the memory mapping should be intact, but if it was dumped by removing the FLASH chip from the DVD control board and dumping it with a programmer, then we need to know how the address/data pins are connected to the FLASH memory address/data pins. Hence we need a pinout of the CPU.

I have been unable to find the pinout for the MN103S94 anywhere.

If anyone has info on how the firmware was obtained, i'd like to know, please...

Thanks.

[InterestedHacker]

I think all this XOR/ROR etc. business is just wheel spinning. I could be wrong, but I think it is highly unlikely that the rom is encrypted. There is prolly not enough resources (RAM/horsepower) to decrypt code on the fly, maybe small sections, but not the bulk of it.

So why is the code a mess?
What about this:
Address and/or Data lines have been transposed on the physical ROM to CPU connection. For instance A0 (CPU) may not be wired to A0 (ROM) maybe wired to A7 etc.... So what you do is take your normally compiled FW obj code, and run it through a program that transposes the address and or data bit connections to match the actual PCB connections that connect CPU to Rom. Program up the rom with the result. Now when the CPU boots up it sees the correct FW in logical order, But if you look at the rom dump with a hex editor, it's a mess!
The firmware is obfuscated completely to hex dumpers, but the CPU sees it perfectly, and can execute at full speed with no "decrypting" overhead.
What needs to be done is to verify the Address and Data line connections from CPU to ROM are 1:1 or not. The CPU address/data pins are fixed in silicon as are the Rom connections. I have no 360, so I can not check. A simple mulimeter test should prove or dispell this theory quickly. I wouldn't waste anymore effort on "decrypting" software until this basic information is known for sure.

Whilst that sounds possible, I do think there is at least XOR applied, because of the space fillers.  These must be either FFFFFFFF or 00000000, and they aren't.  Swapping the lines wouldn't cause this.  I think it's likely a combination of the two.  I am experimenting swapping the lines after the XOR.  I don't have a 360, so I can't check the lines myself.

[BlueCop]

GrosPlombs: germania desoldered the chip and then extracted it. as far as i know no one has the commands for dumping this strait from the drive but the dangerous brothers might. as for how teammodfreaks dumped their images i can't say but their 047DH is the same as germanias so i assume it is the same method used for their 046DH as well

[darkstar]

What about this:
Address and/or Data lines have been transposed on the physical ROM to CPU connection. For instance A0 (CPU) may not be wired to A0 (ROM) maybe wired to A7 etc.... So what you do is take your normally compiled FW obj code, and run it through a program that transposes the address and or data bit connections to match the actual PCB connections that connect CPU to Rom. Program up the rom with the result. Now when the CPU boots up it sees the correct FW in logical order, But if you look at the rom dump with a hex editor, it's a mess!

If you count the bits set to 1 (=the parity) in each byte/word/dword then you get different results in each rom, so at least it is not a transposition alone.

[Tiros]

Interested,
Why do you think filler must be 00 or FF?
FF is just the value that unprogrammed flash has. It is quite common for (embedded systems) programmers to fill unused memory with code to catch runaway firmware. If transposition is being used, who says the 99 area wont be some kind of opcode once de-transposed? Furthermore the end of the rom (if it really is ) does contain FF, and is typically the area left unprogrammed.

Darkstar,
The parity is a good observation, and the parity would be identical transposed or not for the same firmware. But what are you comparing? The 2 firmwares up for grabs right know are KNOWN to be different. Why would you think they have the same parity?

All,
Don't discount the horsepower/ram requirement. This is not a PC. It is an embedded system. Embedded systems are driven by cost. The transposition method costs nothing, and there is zero performance hit. I have seen it before. Sometimes just to make PCB layout easier, other times to obfuscate things. In any event it really doesn't make sense to pursue "decryption software" until the "decryption by hardware" has been ruled out completely. The software method amounts to guessing. The hardware method can be confirmed/denied with certainty relativly easily.

[Geremia]

Address and/or Data lines have been transposed on the physical ROM to CPU connection. For instance A0 (CPU) may not be wired to A0 (ROM) maybe wired to A7 etc.... So what you do is take your normally compiled FW obj code, and run it through a program that transposes the address and or data bit connections to match the actual PCB connections that connect CPU to Rom. Program up the rom with the result. Now when the CPU boots up it sees the correct FW in logical order, But if you look at the rom dump with a hex editor, it's a mess!

It was my first doubt i had after desoldered the flash and readed with the flash burner, first i doubt of my adapter(a sawed piece of an old maxtor hardisk PCB that has 14mm TSOP pads), but comparing to 8163b and other MN103 based firmwares most bytes and areas were the same. Not all the MN103 chips have the same pin numbers and pinout, so it seems quite strange that they studyed all the CPU to flash connection to meet the same scrambling method on all LG drives. The only changes beetween similar devices i can see, is a different xor mask.

[Tiros]

It was my first doubt i had after desoldered the flash and readed with the flash burner, first i doubt of my adapter(a sawed piece of an old maxtor hardisk PCB that has 14mm TSOP pads), but comparing to 8163b and other MN103 based firmwares most bytes and areas were the same. Not all the MN103 chips have the same pin numbers and pinout, so it seems quite strange that they studyed all the CPU to flash connection to meet the same scrambling method on all LG drives. The only changes beetween similar devices i can see, is a different xor mask.

The MN processors that I have looked at use the same pins for Addr/Data/osc/reset etc.
How would a "xor mask" be used at runtime? Read a crumb into ram, decrypt it, run it, get antoher crumb? For a real time embedded system? I don't think so. Maybe just a couple routines, but not the bulk. And if they are purposely "hiding" some routines, you can bet XOR ain't the answer. The PC and the Xbox read the rom into ram (decrypt if needed) and execute from there with zero performance penalty for encrypted rom. (They have TONS of ram) Those systems have the resources, and actually run faster from ram.

[Phantasm]

I think i might have found something quite interesting here:

If you take the string

HL-DT-STDVD-ROM and convert the first 8 bytes to hex you get

48 4C 2D 44 54 2D 53 54

right now take the first 8 bytes of the data at $6000 xored with 66 64 60 F7 you get

D0 04 CD 0A 0D 95 87 8A

convert these to 32 bits of binary and you will get

  4      8      4       C      2      D      4      4
0100 1000 0100 1100 0010 1101 0100 0100

and

 D      0      0        4      C     D      0      A
1101 0000 0000 0100 1100 1101 0000 1010

for the first 32 bits and

 5      4      2       D      5      3      5       4
0101 0100 0010 1101 0101 0011 0101 0100

and

 0      D      9      5       8       7     8       A
0000 1101 1001 0101 1000 0111 1000 1010

Now notice how both of these two sets of numbers have the exact same numbers of 0's and 1's in them.

This basically suggests to me that the xor value is correct and the bits do need re-arranging to get the correct values out.

Am now going to test this with the remainder of the sequence and see if it holds true. If so we may be able to figure out the
bit pattern arrangement using more of the sequence.

Update: Doesnt seem to hold true for the next 2 sets of 32 bits but this seems a huge coincidence to me that those first 8 bytes match.
thats 1 in 32 times 1 in 32 (1 in 1024) that both sets would be corect.

Maybe that string HL-DT-STDVD-ROM isnt quite correct??

Update 2: This also holds true for the 2 sets of 4 bytes at offset $20BC and $20C0

[thecheekymonkey]

ive read everysingle page, and have tried my best to keep out of this, i cant offer any help, but all i can say is 


:


if you lot need any viagra i`ll get you some, because you really need to keep this up 

[TheSpecialist]

BTW, Tiros, good to see you participate !

[Tiros]

So, to summarize: the xbox request the "control data structure" from the xbox and sends challenges found in that data to the drive. The drive has to respond with the correct response. If this is succesful, the kernel has 'authenticated' the DVD and the drive switches to XBOX partition.

Great Work!
After reading this and thinking about it, especially the last line quoted, it becomes clear that modfying the firmware will likely NOT allow backups to run. The problem is that the challenge/response info is read from the pressed DVD. The challenge and expected response will be different according to each disk. It will no doubt have to do with the location of the non reproducable "security placeholders" that are on the disk. If you read the patent you will see that the locations are psuedo randomly seeded, and placed according to a rule set. Since your backup won't have the placeholders, the drive will not be able to authenticate. Even with modifed firmware you won't know how to "answer" the kernel when it calls since the "answer" is related to the exact location of these placeholders. You would need custom firmware for each game!!
Finally!! I believe this to be the definitive answer as to what the "media check" is all about!

Unfortunately, after thinking about it some more, this likely leads to a dead end on this whole avenue of attack.
Even if you "decrypt" what then? You still can't universal patch the answer to the challenge.

[TheSpecialist]

So, to summarize: the xbox request the "control data structure" from the xbox and sends challenges found in that data to the drive. The drive has to respond with the correct response. If this is succesful, the kernel has 'authenticated' the DVD and the drive switches to XBOX partition.

Great Work!
After reading this and thinking about it, especially the last line quoted, it becomes clear that modfying the firmware will likely NOT allow backups to run. The problem is that the challenge/response info is read from the pressed DVD. The challenge and expected response will be different according to each disk. It will no doubt have to do with the location of the non reproducable "security placeholders" that are on the disk. If you read the patent you will see that the locations are psuedo randomly seeded, and placed according to a rule set. Since your backup won't have the placeholders, the drive will not be able to authenticate. Even with modifed firmware you won't know how to "answer" the kernel when it calls since the "answer" is related to the exact location of these placeholders. You would need custom firmware for each game!!
Finally!! I believe this to be the definitive answer as to what the "media check" is all about!

This is true, BUT you overlook the fact the correct responses are in the table on the lead-in of the original pressed disc. So, we don't even have to let the FW calculate the correct responses, just let it decrypt the table itself and answer with the responses from the table Or we could extract the challenge/response table from disc, decrypt it, save it to file, so we can point the FW to a file or sector to look for and read the decrypted correct responses I don't know if it's possible to copy the table to the correct place on a DVD+/- R (since it's in the Lead-in), so I think we have to extract the table anyway, and save it to some other place on the disc (and let the FW look here).

So, to summarize: extract and decrypte the challengeresponse table from the original disc, and save it to a fixed sector/file on the copied DVD. Point the FW to always look at this sector/file for the correct responses and let the FW send these responses back to the XBOX. This way you don't need any security placeholders on disc at all

[SpenZerX]

May be that they used rom correction features described in the MN103S Manual. 4 channels for rom correction are available.

So the dumped rom may change during execution!

23-3-1 ROM Corrction
The ROM correction function makes temporary corrections to the stored program and data in the internal ROM by
replacing accessed and read data partly with the stored correction data in the ROM correction data register providing
the corrected data to the microcontroller core.
The internal ROM address accessed by the microcontroller core is compared with the ROM correction address set
in the ROM correction address register (RCRnAR), and the ROM correction function detects that access to the
internal ROM is within the right address correction range (i.e., within 8 bytes from the ROM correction address
RCnAD). If access to the address for ROM corrections is detected, the correction data set in the ROM correction
data registers (RCRnDU and RCRnDL) will be selected in place of read data from the ROM.
Four channels of ROM correction function are available. It is possible to correct 8-byte data in any address desired
in the internal ROM on each channel. Each channel has an ROM correction address register (RCRnAR) and ROM
correction data registers (RCRnDU and RCRnDL), respectively where a corrected address and corrected data are
stored.


Spenzerx

[InterestedHacker]

I agree we shouldn't give up this avenue of exploration until we understand every part of it.  We may be able to reproduce the challenge response table ourselves as you say, and attach the data table to images of games.  If the firmware knows where to look in the table there won't be a problem.  This all assumes that the same challenge response happens every time.  We would need a way of working out where all these security placeholders are and to mimick it somehow.

[Tiros]

Spec,
Are you sure the "answers" are in the lead in or are they just some numbers that the FW uses to compute/extract the placeholder locations which are related to the answer? It is quite possible that the kernel can use a variety of different challenges each time, even on the same disk. What i'm saying is do your investigations do anything to disprove my new theory regarding "security placeholders" as the actual media check mechanism? If not, I can not think of any DVD based universal patching scenario that will work for all games. Your idea about creating an "answer file" could possibly work, but I fear that the firmware changes to support this will be too extensive to implement without having source code. Further, even if you did, the counter measure would be very simple. MS could just see if the "answer data" exists, and bomb if it does. Once you standardize it's location on disc to go along with your new hacked FW, you can't move it without new firmware.


Spenz,
Nice Find!!
Unfortunetly this quote refers to INTERNAL rom. It's intended to patch mask rom containing bugs/errors/expansion.

This all assumes that the same challenge response happens every time. We would need a way of working out where all these security placeholders are and to mimick it somehow.

It's not the same every time. The placeholders are psuedo-randomly placed according to a ruleset. They can not be predicted in advance.

[InterestedHacker]

I think i might have found something quite interesting here:

If you take the string

HL-DT-STDVD-ROM and convert the first 8 bytes to hex you get

48 4C 2D 44 54 2D 53 54

right now take the first 8 bytes of the data at $6000 xored with 66 64 60 F7 you get

That's fantastic work.  I just finished searching for bit patterns and got no where.  I outputted the bit count for every byte, then worked out search pattern bit count strings, (ie. number of bits in each character, after XOR'd) and searched for those patterns, but I found nothing. =(

[MODFREAKz]

GrosPlombs: germania desoldered the chip and then extracted it. as far as i know no one has the commands for dumping this strait from the drive but the dangerous brothers might. as for how teammodfreaks dumped their images i can't say but their 047DH is the same as germanias so i assume it is the same method used for their 046DH as well

Yes thats right, I desoldered the chip and then read it, with Willem Programer.

but the 047DH was dumped by Geremia. sorry that I didn´t wrote this    

[Tiros]

Spec,
Typically a challenge/response system does not send the answer to the challenger before the challenge. It usually relies on some info that both the challenger/responder both know. Does it send the EXACT answer, or some data that allows the kernel to compute what the answer should be? This distinction is critical and I don't know the answer. In other words if I told YOU the answer, then why challenge me at all? So I can repeat myself? Something doesn't sound right.


Unfortunately not all hacking yields edible fruit. It takes some nuts to finally decide that something is a dead end, particularly when you spend a lot of time pursuing an idea. Been there done that. Might be time to go back to the drawing board