hacking DVD firmware ?

[Tiros]

I dont have much hope for removing the part unless there are solvents that wont damage the rest of the board.

Try a hot soldering iron on the epoxy, a dremel tool can also work well.
It looks just like the old Sammy (well kinda) !! Bet you the firmware tool can read it! Do you have IDE to SATA?

Anyway,
For the heck of it I DL'd the 360 firmware (D7&D6 I think) into my 8163 and guess what?
The 8163 can kindof run the firmware of the 360. It responds to eject, but the drawer seems to be confused. Sound familiar to anyone ? Haven't hooked it up to a PC or anything just basic signs of life test. More testing later...

[darkfly]

Try a hot soldering iron on the epoxy, a dremel tool can also work well.
It looks just like the old Sammy!! Bet you the firmware tool can read it! Do you have IDE to SATA?

I got most of it off with a small attachment on a heat gun and a hobby knife and the bulk edges I used a diamond wheel on a dremel. If you make small cuts it chips right off, I think with a little more work I can get it free.

I dont have IDE to SATA yet, it should be here tomorrow or thursday. I do have a SATA to Firewire external case but I doubt that is going to be of any use.

[darkfly]

Got the crap off, but I just got confirmation my adapters will be here tomorrow afternoon so I am going to wait to try the dump software first before desoldering the chip, I hope it was a waste of time.

[Stealth]

mtkflash is definately a no-go without a SATA->PATA adapter.  It can support sata interfaces but they have to be visible as ide channels 1-4 (really 1 slave and master, and 2 slave and master), whereas on my mobo they are 5-8 (really 3,4,5,6 master).  Additionally windows hated the drive.  As others reported, the bios recognized the drive just fine, but it wouldn't even boot to windows fully with it attached.  It just kept spinning at the windows xp boot up screen.  Wouldn't detect it with a "scan for hardware changes" after a hotplug either.  Ah well, luckily darkfly has all his crap sorted and can do it

[anita999]

Got the crap off, but I just got confirmation my adapters will be here tomorrow afternoon so I am going to wait to try the dump software first before desoldering the chip, I hope it was a waste of time.

be careful darfly. the resin fills into the underneath of the PLCC chip. So when you try to desolder it, the high temperature and the adhesion introduced by the resin might destroy your bond pads on the PCB or even lift them off in the worse case. Try the MTKflash dos version with a SATA<>PATA converter first might help.

[jig]

i'm surprised at how the epoxy looks. the fact that the face of the chip doesn't have any on it is strange to me.. chip seems to be a surface mount since the backside shows no vias, so the epoxy came after the chip was attached... i guess. i'm not sure how to infer how much might have been able to wick under the chip.

might want to try this as a stripper:

Can be chemically removed with methylene-chloride (several hour soak). A commercially available stripper is supplied by Miller-Stephenson Co. at phone (203) 743-4447 or fax (203) 791-8702, part number
MS-111.

http://www.miller-stephenson.com/  product index->stripping agents (there are others, tougher)

you might be able to get a sample sent to you...

f you get worried about it attacking other things on the board, you can always build a little bowl out of candle wax...  in any event, good luck!

[Takires]

Please detail the source of this information as it conflicts with my LA testing.
1) I don't see any external ram.

According to the MN103S Instruction Manual for every memory mode everything
above 0x80000000 is external memory. It might be different for this ASIC, only
way to know for sure is to trace the address lines going to the flash and check
if they are going to another chip.

The firmware copies data to 8003CC00 before sending them to the host. This
is why the RAM is at least 256k big.

2) I see external execution starting @40000020, but am testing your irom theory later as I speculated a few posts back this may be the case.

Nope. The flash IC is addressed by 18 address lines and a CE line. Unless you found the exact
pinout somewhere you cannot be sure which line is connected to the CE line, most likely it
is one of the CS lines the address decode inside the MN103S generates.

On the other hand, the flash image is full of absolute jumps to 900xxxxx and these jumps
make sense if the flash image is loaded at 90000000.

5) Permanant? Private key? Could be bad news.

Permanent means non-volatile in this case.

WRITE BUFFER calls a function that copies code from the flash to the RAM and executes this code. Currently
I can only come up with one reason for that: Most flash chips cannot be read if they are in erase or
programming mode.

[TheSpecialist]

BTW, anyone tried getting the 360 drive detected under DOS ? Maybe a good old win98 bootdisk can detect it ? I mean, if the bios can detect it, the OS also *should* be able to detect it

[QuiescentWonder]

Here are a bunch of bootdisk images: http://bootdisk.com/bootdisk.htm

Personally, I'm a fan of the Windows 98SE without the ramdrive... You may want to download the 98SE OEM disk though, I think it comes with a wider variety of CD drivers.

[thecheekymonkey]

BTW, anyone tried getting the 360 drive detected under DOS ? Maybe a good old win95 bootdisk can detect it ? I mean, if the bios can detect it, the OS also *should* be able to detect it

ive tried a few dos utilitys, filemanagers etc etc and couldnt access the drive, however one or possibly 2 did show the drive, but wouldnt allow access.


i used some utils of hirens boot cd, such as pc info i think, it gave me the drive letter and even some statistics of the drive, but wouldnt allow access. all my tests where rushed, so i could be wrong with the name of the tuil, but it was definatly on hirens boot cd.



hope this helps 

[QuiescentWonder]

BTW, anyone tried getting the 360 drive detected under DOS ? Maybe a good old win95 bootdisk can detect it ? I mean, if the bios can detect it, the OS also *should* be able to detect it

ive tried a few dos utilitys, filemanagers etc etc and couldnt access the drive, however one or possibly 2 did show the drive, but wouldnt allow access.


i used some utils of hirens boot cd, such as pc info i think, it gave me the drive letter and even some statistics of the drive, but wouldnt allow access. all my tests where rushed, so i could be wrong with the name of the tuil, but it was definatly on hirens boot cd.



hope this helps 

What type of discs did you try to access?

Here are some more DOS CD drivers: http://oldfiles.org.uk/powerload/cdrom.htm
This seems to be the motherload of DOS CD drivers: http://digilander.libero.it/pnavato/drivers/

[thecheekymonkey]

ok sorry this was just a bit of a rushed attempt.

connected the 360 drive (hitatchi-LG) to my pc, the bios picked it up fine, and even tried booting from it (paused for ages and even the disk span up which incidently was CoD2, but failed lol  )

windows started , but no deal, nothing would pick up the drive, even sisoft sandra, just wasnt being reported in windows.

ok, tried a few dos utilitys , some would pick up the drive no problems , basic filmanagers, but wouldnt let me browse the disk.


dont have linux installed, could never get it to work on my main pc, but i did give it a go with `knoppix linux bootable from dvd`

which also didnt report the drive, however this could be to do with the llimitations of knoppix being bootable from a dvd, so not really sure on that one.


thats all i can do chaps, hope this helps anyone  

 a normal pc data disk and also call of duty 2

the above quote is what i originally posted earlier in this thread.


hope this helps

[Disabled]

The bios just sees there is something refering itself as a dvd-rom. Windows trys to talk to the drive and realises it does not work, so it does not show up. I don't think you will have some success with a DOS boot disk, even if it detects the drive you will most probably not be able to use it.
It has been suggested already but I dont think it has been done properly, to post a log of a drive connecting under linux. (Someone has posted a log but it was of the full system start and I didn't see anything in it)
If someone has linux running, try to start without the drive attached, run "tail -n1 -f /var/log/messages >> output.txt", then attach the drive and wait some time (it was assumed, that the drive shuts itself down after a period of "not a specific command received", so wait a few minutes) and then detach the drive again. You can hit CTRL+c to stop the above process. A file named output.txt should have been created with the system log, please post that here.
I guess this is the way you get the maximum information from the drive with a pc doing nothing special (IE unlocking or something like that).

[QuiescentWonder]

So the next step would be to use a couple of SATA<->PATA converters to sniff what's going on during the boot sequence on the 360 itself? Then we can figure out how to initialize the drive or if the traffic is modified on it's way to and from the drive in any way?

[jasper]

That seems to be the next step to be able to compare the Xbox 1 vs. 360 communications and start work on the unlocker port (assuming that a way is also found to mount the drive from any popular operating system).  On a parallel track, the next step is probably to accomplish a successful drive swap.  The process would probably be to dump 2 identical version firmware samples from different 360s, flash the firmware from dvd A onto dvd B, and place dvd B back into 360 A.  It should work.  If it does not work, there must be some other external persistent storage on the drive somewhere that will also need to be analyzed.

[MacDennis]

Please detail the source of this information as it conflicts with my LA testing.
1) I don't see any external ram.

According to the MN103S Instruction Manual for every memory mode everything
above 0x80000000 is external memory. It might be different for this ASIC, only
way to know for sure is to trace the address lines going to the flash and check
if they are going to another chip.

The firmware copies data to 8003CC00 before sending them to the host. This
is why the RAM is at least 256k big.


WRITE BUFFER calls a function that copies code from the flash to the RAM and executes this code. Currently
I can only come up with one reason for that: Most flash chips cannot be read if they are in erase or
programming mode.

Let's get some facts straight shall we?

Facts:

• The DVD-ROM in the X360 can contain a Hitachi-LG GDR-3120L DVD-ROM
• This model contains the MN103S94 CPU from Panasonic / Matsu$#!ta Electric Industrial
• The purpose of this CPU is being a DVD controller
• This CPU contains the AM32 core, a third-generation microcontroller core
• Instructions / code can be run from ROM, RAM, Flash memory and cache memory
• Data can be stored in RAM and cache memory
• The CPU is connected to external Flash memory, type: 39SF020A (SST)
• The CPU is NOT connected to any *external* RAM/DRAM memory (buffer/cache). There simply isn't any on the mainboard. The Philips XBOX1 drive has external DRAM and also the other X360 drive has it, but not this drive which is odd.
• "One assignment that is common throughout, however, is the location of the reset vector. It is always at 0x40000000."
• The instruction manual has a picture for the AM32 which shows external memory starting at 0x40000000, so it's not always 0x80000000!! See page 13 of the manual, processor mode (for program in external memory / with cache)
• In different mn103 firmwares from different dvd devices, the first 0x1C bytes are almost the same!
• The READ_BUFFER / WRITE_BUFFER commands are used in ATA / ATAPI devices to update the firmware by uploading it to the device by ATA commands, note that Takires mentions that these operations affect the 0x90000000 region. Did you find that out by disassembling the firmware?
• Noticed this on a forum: "However, FYI a custom version of the MN103S with a ROM mask (and not a flash) is commonly used in DVD drives (like the Pioneer 1x6 for instance) as a secondary controller for low level tasks."

With the above facts in mind, this is my theory, yes speculation but still ..

• The missing buffer/cache SRAM (which is odd for a high-speed DVD controller) is *in* the CPU package itself, next to the CPU die
• Reset vector starts at 0x40000000, internal boot rom. Might also contain functions common for a DVD controller. Jumps to 0x90000020. Why 0x20? Then you have room for a (cleartext) header in the firmware.
• The buffer/cache SRAM starts at 0x80000000
• The external firmware flash starts at 0x90000000
• I don't believe this is a custom MS / X360 ASIC, this because of the costs involved.

Opinions anyone?

[Nayr]

• The external firmware flash starts at 0x90000000

Opinions anyone?

Looks at this funtion:

Code:

   30095:       fc a8 00 00     movbu   (0x90000000),d0
   30099:       00 90
   3009b:       cb              nop
   3009c:       cb              nop
   3009d:       fc a9 00 00     movbu   (0x90000000),d1
   300a1:       00 90
   300a3:       cb              nop
   300a4:       cb              nop
   300a5:       a1              cmp     d0,d1
   300a6:       c9 ef           bne     0x30095
   300a8:       fc a9 00 00     movbu   (0x90000000),d1
   300ac:       00 90
   300ae:       cb              nop
   300af:       cb              nop
   300b0:       a1              cmp     d0,d1
   300b1:       c9 e4           bne     0x30095
   300b3:       f0 fc           rets

Looks to me like it is debouncing a memory mapped something or other at 0x90000000.
My vote is that flash is not mapped at 0x90000000.

Nor do I vote for 0x80000000 because there are absolute writes to this range.

[JayDee]

A bit off-topic...

Have anyone talked with TDB (The Dangerous Brothers), Herrie or Liggy And Dee?

None of them are involved with the xbox/360 scene afaik, but when it comes to firmwares on pc dvd-burners they are legends.

Might be worth pm or two to see if they can offer any help with going over the 360 firmware...

(All can most likly be reached in some form on the cd-freaks forum)

[oz_paulb]

• The external firmware flash starts at 0x90000000

Opinions anyone?

I agree - it looks like external flash firmware (the code we have dumped) is at 0x90000000.

Looks at this funtion:

Code:

   30095:       fc a8 00 00     movbu   (0x90000000),d0
   30099:       00 90
   3009b:       cb              nop
   3009c:       cb              nop
   3009d:       fc a9 00 00     movbu   (0x90000000),d1
   300a1:       00 90
   300a3:       cb              nop
   300a4:       cb              nop
   300a5:       a1              cmp     d0,d1
   300a6:       c9 ef           bne     0x30095
   300a8:       fc a9 00 00     movbu   (0x90000000),d1
   300ac:       00 90
   300ae:       cb              nop
   300af:       cb              nop
   300b0:       a1              cmp     d0,d1
   300b1:       c9 e4           bne     0x30095
   300b3:       f0 fc           rets

Looks to me like it is debouncing a memory mapped something or other at 0x90000000.
My vote is that flash is not mapped at 0x90000000.

Nor do I vote for 0x80000000 because there are absolute writes to this range.

This looks like it could be code related to flash programming (programming at chip at 0x90000000).  Often, when a flash chip is in programming mode, it will return different data on back-to-back 'reads' until the programming operation is complete (one bit of the byte 'toggles' on each read from the chip).  When you get two consecutive 'reads' that are identical, you know that the chip finished programming.

So, the above code is consistent with flash being at 0x90000000, IMO.

Also, look at the following:

Code:

    60eb: fc cc c2 60  mov 0x900060c2,d0
    60ef: 00 90
    60f1: 01 c0 df     mov d0,(0xdfc0)
    60f4: fc cc e2 64  mov 0x900064e2,d0
    60f8: 00 90
    60fa: 01 b4 00     mov d0,(0xb4)
    60fd: fc cc 71 61  mov 0x90006171,d0
    6101: 00 90
    6103: 01 00 00     mov d0,(0x0)
    6106: fc cc a8 61  mov 0x900061a8,d0
    610a: 00 90
    610c: 01 04 00     mov d0,(0x4)
    610f: fc cc aa 61  mov 0x900061aa,d0
    6113: 00 90
    6115: 01 08 00     mov d0,(0x8)
    6118: fc cc ac 61  mov 0x900061ac,d0
    611c: 00 90
    611e: 01 0c 00     mov d0,(0xc)
    6121: fc cc bf 61  mov 0x900061bf,d0
    6125: 00 90
    6127: 01 10 00     mov d0,(0x10)
    612a: fc cc d2 61  mov 0x900061d2,d0
    612e: 00 90
    6130: 01 14 00     mov d0,(0x14)
    6133: fc cc f5 61  mov 0x900061f5,d0
    6137: 00 90
    6139: 01 28 00     mov d0,(0x28)

It appears that a bunch of 'function pointers' are being initialized to point to functions in the 0x9000xxxx range.  If you look at the corresponding offsets in the disassembly (example: at 0xxxxx60c2, 0xxxxx64e2), you'll see what looks like the start of a function at each address.  Some of the functions are 'null/empty' functions - just a 'rets' instruction.  But, the offsets never point into the middle of a function - always to a valid function start.  So, these functions must exist in memory based at 0x90000000.  Either the flash chip is there, or the flash code gets copied to RAM at 0x90000000 before the above code snippet is used.

- Paulb

[maddy2005]

A bit off-topic...

Have anyone talked with TDB (The Dangerous Brothers), Herrie or Liggy And Dee?

None of them are involved with the xbox/360 scene afaik, but when it comes to firmwares on pc dvd-burners they are legends.

Might be worth pm or two to see if they can offer any help with going over the 360 firmware...

(All can most likly be reached in some form on the cd-freaks forum)

i did contact em about this thread they neva answered...