Print

[Tiros]

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!

[TheSpecialist]

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 ?

[Tiros]

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.

[TheSpecialist]

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

[TheSpecialist]

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

[stampsm]

the main problem i see with the new 360's is that the dvd drive uses a sata connection. and if my understanding is correct ( i am still researching the specifications) it runs at 1.5 ghz serial transfer rate. 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. i just today got my copy of the "IEE Electronics System and Software" magazine for oct/nov and on page 36-40 there is an article on debugging sata systems. in my very humble opinion the best way to crack the dvd data storage system if you do not know the porcessor/io/bios/ect. once you know the unique commands that are sent it would be possible to write a new bios for almost any sata dvd drive that you have an full datasheet for all parts or most parts. the worst part is there is a chance that the processor is not a off the shelf unit programmed for the job. since it has to have a high data bandwith plus it has to encode the data it is most likely it is a FPGA, ASIC, high end arm processor, ect. the good part is since the cost of having a custom ASIC designed and made is getting quite expensive for a single project ic that the dvd manufacture will most likely use an existing design and modify it or have it manufacture with markings that are unique to their shipment and therefore hard to find out what is underneath. it is 1am here so if anything seems hard to understand it is probably my rambling  

[Tiros]

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.

[TheSpecialist]

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 ...

[InterestedHacker]

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.

[anita999]

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.

[Tiros]

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.