Post by: lordvader129 on December 03, 2005, 01:48:00 PM
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
Post by: TheSpecialist on December 04, 2005, 12:30:00 PM
We'll have to extract this signature key from the DVD player.
Post by: lordvader129 on December 04, 2005, 01:40:00 PM
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?
Post by: lordvader129 on December 04, 2005, 02:37:00 PM
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
Post by: TheSpecialist on December 04, 2005, 09:09:00 PM
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
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
---------------------------
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
Post by: Tiros on December 05, 2005, 08:14:00 AM
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 encryptedI'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.
Post by: TheSpecialist on December 05, 2005, 08:36:00 AM
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 ?
Post by: TheSpecialist on December 05, 2005, 06:49:00 PM
QUOTE
00002A7B E54E MOV A,$4E
00002A7D 9F SUBB A,R7
00002A7E E54D MOV A,$4D
00002A80 9E SUBB A,R6
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 ?
Post by: TheSpecialist on December 05, 2005, 07:23:00 PM
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.
Post by: kowrip on December 05, 2005, 07:32:00 PM
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.
Post by: TheSpecialist on December 05, 2005, 09:14:00 PM
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.
Post by: Tiros on December 06, 2005, 08:57:00 AM
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
Post by: TheSpecialist on December 06, 2005, 09:09:00 AM
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.
Post by: Tiros on December 06, 2005, 09:22:00 AM
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.
Post by: TheSpecialist on December 06, 2005, 09:53:00 AM
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 ?
Post by: Tiros on December 06, 2005, 10:15:00 AM
QUOTE(TheSpecialist @ Dec 6 2005, 05:00 PM)
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 ?
You need to follow the program to understand it. It's not easy and that's why it has not been done. However, it's all sittin' right there and has been for years. That's why I think it's such a joke that so many people are waiting for "the experts" to crack the 360. There aren't any! If you are interested you can compare the FW to the 616T original and see the differences of what MS added or had added to the FW.
As far as the disassembly goes, as I told you before, IDA can't tell code from data. Try hitting the letter 'C' when you are positioned on the "encrypted" code.
Good Luck!
Post by: TheSpecialist on December 06, 2005, 10:34:00 AM
QUOTE(Tiros @ Dec 6 2005, 06:22 PM)
You need to follow the program to understand it. It's not easy and that's why it has not been done. However, it's all sittin' right there and has been for years. That's why I think it's such a joke that so many people are waiting for "the experts" to crack the 360. There aren't any! If you are interested you can compare the FW to the 616T original and see the differences of what MS added or had added to the FW.
As far as the disassembly goes, as I told you before, IDA can't tell code from data. Try hitting the letter 'C' when you are positioned on the "encrypted" code.
Good Luck!
Ok
I always wondered why no one had bothered hacking the firmware and I could not find any info from ppl doing this. Now I understand You can't realtime debug it like a program on your PC, code is much harder to read since there are no API calls like in windows code and you have to findout yourself what the different sections are (what's code and what's not). So basically all you can do is start 'single stepping' through it, starting with the reset vector ... I thought firmware hacking would be fun, but this kinda sucks BTW, did you try this software: http://www.fstsoftware.com/index.html ?
Post by: Tiros on December 06, 2005, 11:39:00 AM
QUOTE(TheSpecialist @ Dec 6 2005, 05:41 PM)
You can't realtime debug it like a program on your PC, code is much harder to read since there are no API calls like in windows code and you have to findout yourself what the different sections are (what's code and what's not). So basically all you can do is start 'single stepping' through it, starting with the reset vector ... I thought firmware hacking would be fun, but this kinda sucks
BTW, did you try this software: http://www.fstsoftware.com/index.html ?
No, it's not like just hitting CTRL-D and seeing what pops up with commented kernal/sys calls
But there are other ways too and it can be LOADS of fun
Even worse you don't know where the memory mapped I/O devices or registers are, what they control, or how to control them. Then there are the MPU I/O pins, (P1,P2 etc) where do they go and what do they control? Some explicit knowledge of the hardware is gonna be required. This might involve tracing some things out, drawing some sketches, nothing impossible. Maybe you don't need to understand the system COMPLETELY to hack it. You will have to know somthing though, a hex editor wont cut it here. Often port pins can be easily traced. For starters, find the one that controls the LED. Search for code that affects that pin. Same for eject button and others. Comment the disassembly as you learn. Look at the ATA command set, can you identify the routine that parses commands? Are they all standard? Which ones are unusual? Try to figure out what low level routines do . Can you ID any of the peripheral IC's? Can you get a pinout for the MPU? More and more pieces will start to fit together. First you need get a toehold. It's like solving a puzzle.
Now imagine:
You don't even know the opcode/instruction set for sure!! The MPU is connected to internal peripherals, external ports, and LSI registers that are custom silicon and completely undocumented. You don't know where they are let alone what bit controls what function. There is no documented memory map. There is no pinout for any of the ICs. The "reset vector" is unknown so you can't find the front door. The bios code is encrypted, and can only be decoded by the bootloader (INSIDE the LSI) unique to each unit. The CPU has hardware security and is WAAAY more complicated than a single tasking 8 bit microcontroller. I'm sure it has TONS of control registers, that are also undocumented. No doubt there is also an MMU that also has these similar challenges.
That's the 360!! Who's gonna crack it? Once you fully understand what is involved you begin to realize, probably no one.
Post by: TheSpecialist on December 06, 2005, 06:36:00 PM
QUOTE(Tiros @ Dec 6 2005, 07:46 PM)
Look at the ATA command set, can you identify the routine that parses commands? Are they all standard?
If delved a little into the code and I believe this to be part of the parsing part of the 'Region code' check inside the firmware, am I correct ?
00002508 B4A409 CJNE A,#A4,$2514
0000250B 78A4 MOV R0,#$A4
0000250D E6 MOV A,@R0
0000250E 543F ANL A,#3F
00002510 6408 XRL A,#08
00002512 605E JZ $2572
00002514 EF MOV A,R7
00002515 B4A309 CJNE A,#A3,$2521
00002518 78A4 MOV R0,#$A4
0000251A E6 MOV A,@R0
0000251B 543F ANL A,#3F
0000251D 6406 XRL A,#06
QUOTE
Now imagine:
You don't even know the opcode/instruction set for sure!! The MPU is connected to internal peripherals, external ports, and LSI registers that are custom silicon and completely undocumented. You don't know where they are let alone what bit controls what function. There is no documented memory map. There is no pinout for any of the ICs. The "reset vector" is unknown so you can't find the front door. The bios code is encrypted, and can only be decoded by the bootloader (INSIDE the LSI) unique to each unit. The CPU has hardware security and is WAAAY more complicated than a single tasking 8 bit microcontroller. I'm sure it has TONS of control registers, that are also undocumented. No doubt there is also an MMU that also has these similar challenges.
That's the 360!! Who's gonna crack it? Once you fully understand what is involved you begin to realize, probably no one.
True. That's why we need to look for other possibilities, like an emulation device
Post by: TheSpecialist on December 06, 2005, 08:02:00 PM
QUOTE(Tiros @ Dec 6 2005, 07:46 PM)
No, it's not like just hitting CTRL-D and seeing what pops up with commented kernal/sys calls
Well, there are (hardware-) ICE's for the 8051, they are a little expensive though, but I'm sure that they'll make the life of a hacker a lot easier
Post by: stampsm on December 07, 2005, 02:20:00 AM
Post by: Tiros on December 07, 2005, 11:40:00 AM
QUOTE(TheSpecialist @ Dec 7 2005, 03:09 AM)
Well, there are (hardware-) ICE's for the 8051, they are a little expensive though, but I'm sure that they'll make the life of a hacker a lot easier
Another less costly option is a prom emulator.
With the right setup, it can be almost as effective as an ICE.
Post by: TheSpecialist on December 07, 2005, 05:10:00 PM
QUOTE(stampsm @ Dec 7 2005, 10:27 AM)
there is no cheap way to tap the data transfer lines to see what is going across them. there is equipment arround to do this (very expensive) and people with the know how (few) but it is possible to log the data transfer and find the unique commands that are used to "unlock" the drive for data transfer.
For someone with both access to a device that's able to tap the data transfer and an ICE for the processor in the drive, it shouldn't be too hard to get an exact idea of what's going on and build some 'emulation device'. But I doubt that there are ppl in the scene that have access to such hardware. And without tapping the bus, it wil be pretty hard to build something like this ...
Post by: InterestedHacker on December 15, 2005, 04:48:00 AM
QUOTE(TheSpecialist @ Dec 6 2005, 06:16 PM)
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.
OK, here's my shot... What's to say that they expected someone to go and start disassembling the code, and put a couple of dodgy bytes, adjusting the alignment. Just like you get in x86 exes. Throwing any standard disassember?
I wouldn't let anything put you off pursuing this route just yet. If an exploit is found, then other things might be possible. eg. finding a way of flashing the ROM using a standard PC, so the media checks are always valid etc.
Post by: anita999 on December 17, 2005, 04:02:00 AM
For some MTK DVD player controllers, there are DSP units inside the controller, also the firmware blocks might be compressed. But this might not be true for the DVD drive controller. just for reference.
Post by: Tiros on December 18, 2005, 05:30:00 PM
QUOTE(anita999 @ Dec 17 2005, 11:09 AM)
Tiros, I admit your hardwork. I tried it myself long time ago, but I quit since there is no any data available of the MTK controller. Since you did success in modifying the firmware, do you have any tech. data of the MTK controllers such as data sheet or application notes?
For some MTK DVD player controllers, there are DSP units inside the controller, also the firmware blocks might be compressed. But this might not be true for the DVD drive controller. just for reference.
Never found any valuable datasheets either.
A real good starting point is to decompile the 605 AND the 616T and compare them. You can see easily what has been added by MS since the bulk of the code is the same. When your looking at the disassembly pay careful attention for P0, P1, etc. These ports are actual pins on the MTK controller. Also the famous "yellow wire" control signals are likewise. IDE, LED and Eject also. With a little detective work you can narrow down most of the digital I/O pins and thier P assignments.