Print

[lordvader129]

emulating the dvd drive without actually being the dvd drive is probably more impossible than a modchip, theres just as much authentication between the cpu and dvd drive to prevent such a thing from being done, thats why with xbox when we replace the drive with a PC drive we can only use a few select models and they have to be flashed with xbox dvd firmware

plus it would have to have its own processor/ram/operating system/external input/screen to be able to do all that, the thing would probably cost more than the 360 itself, lol


oh, one more thing, the 360 discs use the same type of copy protection as the xbox discs, meaning in order to back them up we'll probably have to find some way of FTPing or otherwise copying from the 360 itself, without that we wont have a way to make the backups that would be run on this device

[TheSpecialist]

Just read that someone who has two 360's swapped the DVD drives and the games wouldn't boot, which means that each drive holds his own signature. This of course was to be expected, makes it a little more difficult, but still nowhere to impossible We'll have to extract this signature key from the DVD player.

[lordvader129]

QUOTE

In order to build this emulation device, we'd 'only' have hack the firmware (understand the authentication part) and the way the DVD-ROM 'answers' to data requests from the XBOX (the 'driver' part).

in 4 years we havent been able to do either of those things for xbox1, why would 360 be any easier?

[lordvader129]

QUOTE(TheSpecialist @ Dec 4 2005, 03:12 PM)

It wasn't done since there was no use at all for it (or at least rather limited use). Now there is Furthermore, I think M$ realized that this is one of the major weaknesses in their security and that's why they locked the DVD-ROM's this time.

if we had hacked the dvd firmware we could have removed the dvd+r problems with samsungs, patched other PC drive firmwares to read original games in an xbox, write drivers/new firmwares to rip originals on a PC, there were alot of uses, but MS has some pretty good security on it

[TheSpecialist]

QUOTE(Tiros @ Dec 5 2005, 01:27 AM)

Actually there is NO security on it. This issue is a sad testament to the very weak hacking capabilities here. The drive firmware code is straight 8051.

Hmm.. are you sure about that ? I just disassembled the 8050L with a 8051disassembler and the disassembly just doesn't make sense. I don't know much about the 8051, but some parts of the code are not that hard to read. And some of these parts just don't make sense at all, like:

QUOTE

00024DA4 18         DEC   R0
00024DA5 00         NOP   
00024DA6 83         MOVC   @A+PC

why would anyone want to use a NOP here ?

or:

QUOTE

00024E48 32         RETI   
---------------------------

00024E49 702C       JNZ   $4E77

a JNZ instruction after a RETI ?

or:

QUOTE

00024F79 2D         ADD   A,R5
00024F7A 60F7       JZ   $4F73
00024F7C D020       POP   $20
00024F7E 60DF       JZ   $4F5F

How would a POP instruction influence the Accumulator ?



and the best part:

QUOTE

000250B4 27         ADD   A,@R1
000250B5 EE         MOV   A,R6

Add a value to the accumulator and then directly overwrite it ? Hehe, I was kinda hoping to find something like this last example, it's IMHO 100% proof that this data is either not 8051 or it's encrypted

[Tiros]

QUOTE(TheSpecialist @ Dec 5 2005, 04:16 AM)

Hmm.. are you sure about that ?

Add a value to the accumulator and then directly overwrite it ? Hehe, I was kinda hoping to find something like this last example, it's IMHO 100% proof that this data is either not 8051 or it's encrypted

I'm 100% sure. The 8050L has not been out for 4+ years. It does not use 8051 at all.
The SDG605 is the original DVD drive that started it all. Try it on that FW and I'm sure you will agree.

[TheSpecialist]

QUOTE(Tiros @ Dec 5 2005, 04:21 PM)

I'm 100% sure. The 8050L has not been out for 4+ years. It does not use 8051 at all.
The SDG605 is the original DVD drive that started it all. Try it on that FW and I'm sure you will agree.

Ok, that makes sense I'll try it later today, when I'm home. Where do I find this bios, in the usual places ?

[TheSpecialist]

QUOTE

00002A7B E54E       MOV   A,$4E
00002A7D 9F         SUBB   A,R7
00002A7E E54D       MOV   A,$4D
00002A80 9E         SUBB   A,R6

Again, moving a value to the accumulator, subbing from it and then overwriting the result ? Either the programmer was drunk, the code isn't executable or it's not 8051 (or encrypted). And more strange things like this:

QUOTE

00002D82 22         RET   
---------------------------

00002D83 22         RET   
---------------------------

2 RET instructions in a row ?

QUOTE

001381F F518       MOV   $18,A
00013821 E518       MOV   A,$18

The programmer was drunk again ?


But then, some parts seem to do make sense. So I'm a bit puzzled, but my opinion would still be that it's not 8051 unencrypted code. However, I am going to look more into this thing.

May I ask you why you are so sure that it's unencrypted 8051 code ? If it is, then how do you explain the findings i just described ?

[TheSpecialist]

QUOTE

As mentioned before, the particular uC that is in this drive (MTK1629E) uses an instruction set compatible to an 8032. That uC is in turn similar to the 8052, or its older counterpart the 8051. There is a pretty good simulator called Simulator 2003 available from www.fstsoftware.com for these series chips.

That does make sense ! It explains why some part of the program really look like 8051 but there are some odd things. I think it's not 8051 but something pretty close to it.

[kowrip]

QUOTE(TheSpecialist @ Dec 4 2005, 10:12 PM)

It wasn't done since there was no use at all for it (or at least rather limited use). Now there is Furthermore, I think M$ realized that this is one of the major weaknesses in their security and that's why they locked the DVD-ROM's this time.

While I'm no expert on the subject, this DVD emulation actually does make sense to me.  I also agree that the other security may just be too difficult to deal with this time.  Even if it IS cracked, it may not even work on other units if each CPU is flashed with its own key.  I don't think this DVD emulation or even DVD drive modification should be overlooked.

[TheSpecialist]

I just read that IDA PRO has 8051 support, so I fired it up and loaded the samsung bios. This lead to a very interesting insight: IDA dissassembles program code, starting at byte $255 up to $14C7. All the jumps in it seem to be correct and it looks like genuine 8051 code. IDA can't disassemble the rest of the bytes (and if you look at the strange operations i found, they are all in that 'other' section).

So I think that it's:
* either not 8051, but something very closely related (like 8032). That's why IDA might only disassemble a part of it or
* the disassembled part is a decryptor for the rest of the code.

The way I look at it right now, the last possibility seems the most logical one.

[Tiros]

QUOTE(TheSpecialist @ Dec 6 2005, 06:08 AM)

which supports my last findings and believe that it IS 8051 but that the major part of it is encrypted.

Are you sure you understand 8051 code?
Of course data areas/constants/tables are not going to disassemble! Furthermore when you load dptr with constants, the table address being referenced will be unknown to the disassembler. Even if parts were encrypted, the main vectors all point to valid code, you could walk right in the front door and take it apart.
Good luck, you have a ways to go

[TheSpecialist]

QUOTE(Tiros @ Dec 6 2005, 05:04 PM)

Are you sure you understand 8051 code?
Of course data areas/constants/tables are not going to disassemble! Furthermore when you load dptr with constants, the table address being referenced will be unknown to the disassembler. Even if parts were encrypted, the main vectors all point to valid code, you could walk right in the front door and take it apart.
Good luck, you have a ways to go

As I said before, my knowledge of 8051 is limited, but with the instruction set on www.8052.com and knowlegde of assembly in some other languages, it isn't too hard too read.

But it's the first time I'm disassembling a firmware ROM. However, what you're saying does sound very weird to me. If this were true, then how come that IDA dissasmbles all the jump/call adresses in the first 4k bytes correctly and why can't it dissassemble the rest of it all ? I mean, 4k of executable code in a 128k rom and the rest being data areas/tables ? I don't buy that.

So, please, if you're as knowledgable about firmware hacking as you pretend to be, then explain some basics about disassembling this file. For instance, tell me where you think the different sections are located in this file (code/data). And explain to me why it is that the jump/calls are correct in the first 4k and not in the rest of the ROM.

[Tiros]

QUOTE(TheSpecialist @ Dec 6 2005, 04:16 PM)

So, please, if you're as knowledgable about firmware hacking as you make believe here, then explain some basics about disassembling this file. For instance, tell me where you think the different sections are located in this file (code/data).

First of all I don't have to "pretend" anything. FYI I was the one who developed the actual 616/605 fix. Look around if you don't believe me. I don't have time to teach embedded systems hacking 101. But I will help you with specific questions.
Why don't you just go in through the Reset vector as I previously described. Follow the flow, and then post exactly what code does not make sense.

[TheSpecialist]

QUOTE(Tiros @ Dec 6 2005, 05:29 PM)

Why don't you just go in through the Reset vector as I previously described. Follow the flow, and then post exactly what code does not make sense.

Well, that's exactly the weird thing -> All the ISV's point to code in the first 4k of the ROM. Like I said before, this first 4k looks like perfectl genuine 8051 code, everything is there. But, I guess my question then is: what's in the rest of the 124kb ROM ?