hacking DVD firmware ?

[InterestedHacker]

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.

Sounds like an idea!!

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.

I have shifted using single bytes, and 32bit shift, I couldn't see anything of value in the output of either.  Just been experimenting using RCL, rotate carry left, and I think this is string data found at around 0003C2C0.  It's still not correct, but I think that's a good place to look to check results.  You may need to copy and paste the below into notepad to see the alignment.  I am looking at the patterns more than the content below.

0003C2C0 5F3F AF7F 4F3E AF7F FF7F FEFE EF3F FEFE _?..O>.......?..
0003C2D0 6F3E FEFE FF7E EE7E EF3F EE7E 6F3E EE7E o>...~.~.?.~o>.~
0003C2E0 DF7E BEFE CF3F BEFE 4F7F AEFE DF7E AE7E .~...?..O....~.~
0003C2F0 5F3F AE7E 6B7F BE7F FB7E FFFD 7B3F FFFD _?.~k....~..{?..
0003C300 6B7F EFFD EB7E EF7D 7B3E EF7D 4B7F FF7D k....~.}{>.}K..}
0003C310 CB7E BFFD 5B3E BFFD 4B7F AFFD CB3F AF7D .~..[>..K....?.}
0003C320 5B3E AF7D FB7F FEFC EB3F FEFC 7B3E FEFC [>.}.....?..{>..
0003C330 FB7F EE7C EB3F EE7C 6B3E EE7C DB7E BEFC ...|.?.|k>.|.~..
0003C340 5B3E BEFC DB7E AE7C 5B3E AE7C FF7E F7FF [>...~.|[>.|.~..
0003C350 7F3E F7FF FF7E E77F 7F3E E77F DF7E B7FF .>...~...>...~..
0003C360 5F3E B7FF DF7E A77F 5F3E A77F FF7E F6FE _>...~.._>...~..
0003C370 7F3E F6FE FF7E E67E 7F3E E67E DF7E B6FE .>...~.~.>.~.~..
0003C380 5F3E B6FE DF7E A67E 5F3E A67E FB7E F7FD _>...~.~_>.~.~..
0003C390 7B3E F7FD FB7E E77D 7B3E E77D DB7E B7FD {>...~.}{>.}.~..
0003C3A0 5B3E B7FD DB7E A77D 5B3E A77D FB7E F6FC [>...~.}[>.}.~..
0003C3B0 7B3E F6FC FB7E E67C 7B3E E67C DB7E B6FC {>...~.|{>.|.~..
0003C3C0 5B3E B6FC DB7E A67C 5B3E A67C FF7C FFDF [>...~.|[>.|.|..
0003C3D0 7F3C FFDF FF7C EF5F 7F3C EF5F DF7C BFDF .<...|._.<._.|..
0003C3E0 5F3C BFDF DF7C AF5F 5F3C AF5F FF7C FEDE _<...|.__<._.|..
0003C3F0 7F3C FEDE FF7C EE5E 7F3C EE5E DF7C BEDE .<...|.^.<.^.|..
0003C400 5F3C BEDE DF7C AE5E 5F3C AE5E FB7C FFDD _<...|.^_<.^.|..
0003C410 7B3C FFDD FB7C EF5D 7B3C EF5D DB7C BFDD {<...|.]{<.].|..
0003C420 5B3C BFDD DB7C AF5D 5B3C AF5D FB7C FEDC [<...|.][<.].|..
0003C430 7B3C FEDC FB7C EE5C 7B3C EE5C DB7C BEDC {<...|.\{<.\.|..
0003C440 5B3C BEDC DB7C AE5C 5B3C AE5C FF7C F7DF [<...|.\[<.\.|..
0003C450 7F3C F7DF FF7C E75F 7F3C E75F DF7C B7DF .<...|._.<._.|..
0003C460 5F3C B7DF DF7C A75F 5F3C A75F FF7C F6DE _<...|.__<._.|..
0003C470 7F3C F6DE FF7C E65E 7F3C E65E DF7C B6DE .<...|.^.<.^.|..
0003C480 5F3C B6DE DF7C A65E 5F3C A65E 793E CD7A _<...|.^_<.^y>.z
0003C490 9B74 E4F9 1D56 F67F BD7D A67C 6D76 F5DF .t...V...}.|mv..
0003C4A0 4F55 A1FE EF17 F87C 4F5D F4DC 4B5C BC5D OU.....|O]..K\.]
0003C4B0 EF1D FC5F EB1F F4FD 5F5E E47F CB1F ED7E ..._...._^.....~
0003C4C0 5B1E EC7D FB5E BDFD 6F5E ACFE 4F5E BD7F [..}.^..o^..O^..
0003C4D0 4B17 E7DE EB75 A2DC 4B35 B35D EB74 F35D K....u..K5.].t.]
0003C4E0 DF75 B25E FF75 F25E DF35 B35F 5F35 B3DF .u.^.u.^.5.__5.

When I get a bit further I will rethink about ways of looking for text patterns, regardless of the obfuscation.  ie. differences between dwords in sequence.  I am pretty sure that the XOR is applied first, just not sure if it's  999b9f08 or 666460f7 just yet.  I need to test RCL with 666460f7 next.

[tser]

I have 2 simpel  questions.
- There are people mentionning the 3 firmwares.. I scouted less then 3.. can somebody post the links for all 3 ?
- Some people are mentioning that the string "HL-DT-STDVD-ROM" should be in the Firmware, starting somewhere at 0x20... is this a Speculation, or a fact ?

[BlueCop]

tser: Geremia posted a link to the GDR-3120L. The 8050L is available through xbins(samsung and phillips xbox1 firmwares are there too) firmwares for the 8163B are available at rpc1.com and moded versions from the dangerous brothers website. linked to in previous posts

Also I reference cleartext source twice as to where it came from over on xbox-scene. It hasn't been confirmed but the poster seemed to know what he was talking about.

[InterestedHacker]

000398C0 0142 8528 4940 044C 0378 02A4 420E 21C0 .B.(I@.L.x..B.!.
000398D0 0043 8448 4950 040C 0348 03A4 0154 A141 .C.HIP...H...T.A
000398E0 0043 8448 4152 0008 0149 0781 0155 A141 .C.HAR...I...U.A
000398F0 0142 8528 4142 0048 0149 0781 0154 A341 .B.(AB.H.I...T.A
00039900 0142 8508 4142 0048 0149 0781 0154 A341 .B..AB.H.I...T.A
00039910 0142 8508 4142 0048 0149 0781 0154 A141 .B..AB.H.I...T.A
00039920 0043 8448 4152 0008 0149 0781 0B5C 8109 .C.HAR...I...\..
00039930 0043 8448 4152 0008 0149 0781 0B5D 8109 .C.HAR...I...]..
00039940 0142 8528 4142 0048 0149 0781 0B5C 8309 .B.(AB.H.I...\..
00039950 0142 8508 4142 0048 0149 0781 0B5C 8309 .B..AB.H.I...\..
00039960 0142 8508 4142 0048 0149 0781 0B5C 8109 .B..AB.H.I...\..
00039970 0043 8448 4152 0008 0149 0781 0154 A141 .C.HAR...I...T.A
00039980 0043 8448 4152 0008 0348 0780 0155 A141 .C.HAR...H...U.A
00039990 0142 8528 4142 0048 0348 0780 0154 A341 .B.(AB.H.H...T.A
000399A0 0142 8508 4142 0048 0348 0780 0154 A341 .B..AB.H.H...T.A
000399B0 0142 8508 4142 0048 0348 0780 0154 A141 .B..AB.H.H...T.A
000399C0 0043 8448 4152 0008 0348 0780 0154 A141 .C.HAR...H...T.A
000399D0 0043 8448 4152 0008 0348 0780 0155 A141 .C.HAR...H...U.A
000399E0 0142 8528 4142 0048 0348 0780 0154 A341 .B.(AB.H.H...T.A
000399F0 0142 8508 4142 0048 0348 0780 0154 A341 .B..AB.H.H...T.A
00039A00 0142 8508 4142 0048 0348 0780 0154 A141 .B..AB.H.H...T.A
00039A10 0043 8448 4152 0008 0348 0780 4A5C 8509 .C.HAR...H..J\..
00039A20 0043 8448 4152 0008 0348 0780 4A5D 8509 .C.HAR...H..J]..
00039A30 0142 8528 4142 0048 0348 0780 4A5C 8709 .B.(AB.H.H..J\..
00039A40 0142 8508 4142 0048 0348 0780 4A5C 8709 .B..AB.H.H..J\..
00039A50 0142 8508 4142 0048 0348 0780 4A5C 8509 .B..AB.H.H..J\..
00039A60 0043 8448 4152 0008 0358 07C0 0B54 8541 .C.HAR...X...T.A
00039A70 0043 0528 4008 8140 0171 87C1 0925 2540 .C.(@..@.q...%%@
00039A80 0063 A408 402C 8340 0371 87C5 4925 2408 .c..@,.@.q..I%$.
00039A90 0063 A408 4064 0248 2349 8785 0B5C 8109 .c..@d.H#I...\..
00039AA0 0043 0468 4112 8028 0149 0781 0B5D 8109 .C.hA..(.I...]..
00039AB0 0043 8448 4102 8068 0149 0781 0B5C 8309 .C.HA..h.I...\..
00039AC0 0142 8528 4102 8068 0149 0781 0B5C 8309 .B.(A..h.I...\..
00039AD0 0142 8528 4102 8068 0151 0601 72C5 9735 .B.(A..h.Q..r..5
00039AE0 4001 0100 4001 0100 4001 0100 4021 0180 @...@...@...@!.

I think I have been looking at this for too long now... I see chips and chars all over the place...   That was using {66 64 6 0f7} as a 32 bit XOR, and rcl 8.  I have wrapped right round 32 shifts using RCL and SHR, and I don't see much other than the clearly identifiable string / data areas, like the one above.  I am sure it is!

[nix]

Hi, hope I'm not posting stuff that's allready known, but I just ran into some info on the MN103, thought it might be of interest to some of you: https://www.semicon.panasonic.co.jp/micom/manual/pdf/13250-040e.pdf (i.e. check Appendix for instruction set).

(there's some more developer info here: https://www.semicon.panasonic.co.jp/e-micom/manual/download/index.html => Development Tool Manual => MN103S)

[TheSpecialist]

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.

Well... the modded 8050L for the 8163B contains that string BUT it's in an added section. So I think that they might be taking about THAT string and that string doesn't have to be in the unencrypted 8050L itself ...

Anyway, I have also done a program that did 32 32-bit rotations for the 2 xor operands and this also didn't yield anything.
@ Phantasm -> did you only try 32 bit rotation ? Because that's what i did, i'm also gonna try 16 bit and 8 bit

[Geremia]

I'm comparing to LG GCC-4241N comboDVD-cdrw, it uses MN103 also, and data pattern 99 9B 9F 08 is substituted with E9 05 53 08.
I simple xored the 8163 and the 4241 firmware with their own pattern (or reverse pattern, doesn't care), but the data at the base address discussed here doesn't match, the "area" are similar at global looking, but data is different. Now searching if there is a common DWORD value to xor both and have same result...hum..by hand

[InterestedHacker]

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.

Well... the modded 8050L for the 8163B contains that string BUT it's in an added section. So I think that they might be taking about THAT string and that string doesn't have to be in the unencrypted 8050L itself ...

Anyway, I have also done a program that did 32 32-bit rotations for the 2 xor operands and this also didn't yield anything.
@ Phantasm -> did you only try 32 bit rotation ? Because that's what i did, i'm also gonna try 16 bit and 8 bit

I can't speak for Phantasm but I did 32 bit rotations, but I think you could be right in trying 8 bit or 16 rotations.  You can kind of get a feeling for what looks like potential ASCII, but it just doesn't seem to want to come together with what we've tried.

EDIT: You are on the right tracks though, the proof there's no real encryption comes from the fact that the filler is the same DWord over and over, consistant through the file.  I did have a quick thought, wondering if maybe the rotation changes.  Like 1st Byte rcl 4, 2nd byte rcl 8, 3rd byte rcl 16, 4th byte rcl 24, repeat until end of block.  Or alternate left, right, left, right.  The other thing that backs up a rotation / substitution type method is the fact that the fillers $000000 and $FFFFFF wouldn't change, which is what we need.

[TheSpecialist]

I just tried 8bit and 16bit rotations, didn't yield anything too ...

[InterestedHacker]

I just tried 16bit rotations, didn't yield anything too ...

=/

I know it's blatently obvious, but I was looking at the mask and looking for patterns that could be related or linked in someway.  Seems a bit strange to me that the last byte doesn't conform to the sequence, but they can choose what they want I suppose.   The next question is there any other way we could convert 999b9f08 to either 00000000 of FFFFFFFF, assuming that's what they are intended to be.  Also assuming it's got to be quick and simple.

10011001  = 99
10011011  = 9B
10011111  = 9F
00001000  = 08

EDIT: Heres E9 05 53 08.
11101001 = E9
10000101 = 05
01010011 = 53
00001000  = 08

EDIT: Interesting how they both end on an 08 though?!?

Maybe they have just been XOR'd with a random key, there doesn't look to be a pattern in that second one at all.


EDIT 2:

If the keys are different, this suggests that the 2nd part of the decode function might be differnent as well.  eg.  more or less rotates etc.

Can someone compare the very first DWord that follows these space filled areas right at the start of each ROM, that's assuming it's located at the same offset, and also hoping that the first value might be the same data / opcode.  If it is, we may be able to compare the two, after XOR and look for a difference?  I don't know how much that would help us, but it's got me thinking...

[Phantasm]

I only tried 32 bit rotations with and without carry.

oh and I tried addition/subtraction instead of xor and no joy there either.

There are a couple of sections that consist of repeated FF FF FF FF which doesnt seem right if the file
is wholly encrypted.

Maybe not all of the file is encrypted or it is using different encryptions in various parts.

[InterestedHacker]

I only tried 32 bit rotations with and without carry.

There are a couple of sections that consist of repeated FF FF FF FF which doesnt seem right if the file
is wholly encrypted.

Maybe not all of the file is encrypted.

I don't think it is, I get the impression of at least 4 areas of data where the encryption changes the general feel of the data.  It could just be opcodes, then data, then opcodes I suppose.

[MacDennis]

Maybe they have just been XOR'd with a random key, there doesn't look to be a pattern in that second one at all.

Would it be possible that the scrambling routine takes the actual offset of the data into account? Maybe the offset points to a data table which is used in the scrambling routine? This on top of XORing and shifting bits around etc etc ..

[anita999]

Dear folkls:
  Sorry I was busy i past few days and I might not be free in next fews days, either. In the mean time, I think there might be ways to reduce this try and error procedure.
Assuming the xor is a must have operation, and we can reduce the xor key to 2 or 3, or we can focus on 2 or 3 temple bios.
then, if the next process is only a bit rotate or bit switching, it will not affect the bit check sum inside a 32bit block what ever it's a byte/word/dword bit process. So we can search the bit checksum first then try to find out the possible bit operation here.
for example, the IDE identify ATAPI command shall return the device name and serial #. So in most case the 1st 4 bytes of the device name shall be within the same 32bit block. Check the bit checksum of the plain text. Then search the same bit checksum in the de-xored bin files, we may narrow down our focus area. Then we can try some bit process manually/automaticly. this may speed up this decryption process. I don't have the xbox360 or any similar DVD drive here because I am in far east (out side of Japan). So it's difficult for me the tape the DVD drive's access.
btw, if we can get the opcode and reset vector of this AM3 MCU, then in most cases the startup code shall be the same binary code, then this might also be a target string (not ASCII string). again similar attacks can be applied to speed up this decryption.
Hope this help.

[Phantasm]

Maybe they have just been XOR'd with a random key, there doesn't look to be a pattern in that second one at all.

Would it be possible that the scrambling routine takes the actual offset of the data into account? Maybe the offset points to a data table which is used in the scrambling routine? This on top of XORing and shifting bits around etc etc ..

i think its unlikely since the 99 9B 9F 08 pattern appears at various places throughout the file. If the encryption was based on the address it would vary.
The fact that this pattern repeats in the way it does suggests a simplistic encryption that doesnt change within a section or rely on a changing seed from the previous value, but as previously mentioned it does seem that  some sections are either encrypted differently or not at all.

[TheSpecialist]

I also tried something else -> first bitrotate (32 bit) the original file, to yield 32 new files and then per file extract the 'XOR' key and xor it with that (i figured they might have first rotated and then xor-ed). This also didn't yield anything unfortunately ...

[TheSpecialist]

Here's an encryption scheme for firmware in some mp3 player (i believe) -> DaveHooper : The code is divided into 512-byte blocks. We initialise a 16-byte mask with a fixed pattern and XOR this with the first 16 bytes of the block. Then we write out the bytes in the following order: 2,3,4,1,6,7,8,5,10,11,12,9,14,15,16,13. Then we shift these bytes into the mask and use it to XOR the next 16 bytes. At the end of the 512-byte block, we reinitialise the 16-byte XOR mask with the fixed pattern. At the end of the firmware image is the checksum block. For each 512-byte block we derive one checksum (this checksum is actually just the XOR of all decoded bytes).

Of course, it might be possible that they've also done the byte re-ordering (per 4 bytes) ... But I've had enough today

[Phantasm]

I also tried something else -> first bitrotate (32 bit) the original file, to yield 32 new files and then per file extract the 'XOR' key and xor it with that (i figured they might have first rotated and then xor-ed). This also didn't yield anything unfortunately ...

i dont think it matters which way around you do it.

[TheSpecialist]

do you guys also have that 8050L firmware that has an unencrypted header added, saying "HD-DL-ST"and "DVD-ROM GDR8163B0L23" ? I found it somewhere on my harddrive, i think it's the modified bios for the 8163. However, when i strip the added header (the first $40 bytes), its exactly the same file as the normal 8050L file, no differences ...

[Geremia]

http://forum.rpc1.org/dl_file.php?site=firmx&file=4241orig.zip
here is firmware of GCC-4241N, a combo drive with MN103 chip i mentioned above using a different xor mask
The very fisrt byte are the same of our LG, so probably no scrambled (i'm not able to disassemble, sorry)
xoring with 16 FA AC F7, at address 0x1E00 the situation is very similar to 3120L (or 8161/2/3.8050) xored to 66 64 60 F7 at address 0x2000

notice the pattern 00 1A 08 00.

Code:

4241N

00001E00 0C 20 04 20 00 00 00 00 00 00 00 00 00 00 00 00 . . ............
00001E10 00 00 00 00 00 1A 08 00 00 1A 08 00 00 1A 08 00 ................
00001E20 00 1A 08 00 00 1A 08 00 00 00 00 00 01 0A 02 00 ................
00001E30 00 1B 18 00 60 90 09 08 5C 96 A6 08 9E 81 11 58 ....`...\......X
00001E40 4E 97 A6 99 D8 83 A4 88 B8 02 D0 DA CE 82 24 DA N.............$.
00001E50 01 1B BE 80 80 0E 0C 40 00 1A 08 00 00 10 08 00 .......@........
00001E60 22 00 80 00 02 00 00 00 00 00 00 01 00 00 00 00 "...............
00001E70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00001E80 00 00 00 82 41 02 01 00 08 01 48 00 00 00 00 00 ....A.....H.....
00001E90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00001EA0 11 01 68 01 00 00 00 00 00 00 00 00 00 00 00 00 ..h.............
00001EB0 00 00 00 00 12 08 02 22 08 01 40 82 C8 86 E4 08 ......."..@.....
00001EC0 1D 15 A7 09 CC 83 B4 C9 9A 03 84 98 CC 8A A2 C2 ................
00001ED0 23 13 BC 88 01 1B 1A 00 C2 01 09 48 08 1A 00 02 #..........H....
00001EE0 44 9B 3A 41 05 1F 0E D1 00 1A 08 00 00 08 02 0A D.:A............
00001EF0 00 00 00 40 40 00 00 01 22 08 02 00 00 00 00 00 ...@@...".......
00001F00 90 10 10 80 22 48 82 18 FF FF FF FF FF FF FF FF ...."H..........
00001F10 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................

8163B

00002000 04 00 05 24 00 00 00 00 00 00 00 00 00 00 00 00 ...$............
00002010 00 00 00 00 00 1A 08 00 00 1A 08 00 00 1A 08 00 ................
00002020 00 1A 08 00 00 1A 08 00 00  00 00 00 08 08 02 80 ................
00002030 01 9A 18 41 38 12 40 08 14 94 CF 0A 9D 81 91 C8 ...A8.@.........
00002040 DA 82 66 8A 9E 06 84 18 D1 0B 1A D0 04 18 19 41 ..f............A
00002050 00 1A 08 00 00 1A 08 00 00 1A 08 00 00 12 00 00 ................
00002060 22 00 80 10 02 00 00 00 10 00 00 C0 00 00 00 00 "...............
00002070 00 00 00 00 00 00 00 00 00 00 00 00 10 80 20 83 .............. .
00002080 08 01 68 01 49 03 49 00 41 02 01 00 00 00 00 00 ..h.I.I.A.......
00002090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000020A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000020B0 10 C0 20 03 08 11 50 C2 28 00 C0 08 F8 8B A4 10 .. ...P.(.......
000020C0 9B 00 B7 09 2E 95 85 98 58 90 A1 8A 03 1D 9B 03 ........X.......
000020D0 83 03 28 49 03 13 1C 49 88 08 01 43 00 1B 8A 00 ..(I...I...C....
000020E0 72 9B B8 93 01 1A 1C 41 00 12 00 02 FF FF FF FF r......A........

Now focusing in comparing 0x20BA from 4 firmware revisions of the same drive http://forum.rpc1.org/dl_file.php?site=tdb1&file=GDR8163B.ZIP, to see if some rotation or whatelse  is involved, ...well... still assuming that the single bit change from firmw v14 to v15 is in this area ehehheheheh