HD-DVD addon Toshiba SD-S802A

[Geremia]

just a note

the firmware of the SD-H802A drive for pc is very very similar, also the xbox related ascii text 
http://buffalo.jp/php/ldl.php?to=hd/hdvrom24fb-ts06.exe

It's a buffalo rebranded, HDV-ROM2.4FB
Not yet found any pics

ah, btw, not so technical, qite speculative, but hex FD0200 is present 1 time in both firmware, but not in TS-L802A (also not xbox ascii text present)

Redline99 has sent me his SD-S802A (xbox360 hd-dvdrom) flash dump, seems that unique data is in area 0x4000-0x7FFF, which is 2 small 8KB flash sectors, blanked in the firmware upgrade by buffalo and others.

[Geremia]

i'm 99% sure the cpu (unknown) maps the flash at 0x00200000
The begin of fw could be just checksum stuff, then at 0x3C starts a sequence of flash addresses, the most important are 0x00200060 and x00200070, maybe the cpu resets to an embedded rom, then code choose one of these address, don't know, but for sure 0x60 and 0x70 are good entry points

[Geremia]

After spent time in reading about mips instructionset with no result, i've played a little randomly with IDApro and the CPU seems a Fujitsu FR 32bit family

I was right about the flash mapped address, here is the code about flash erase

ROM:002F0F10                 ldi:32  #unk_200000, r0  //flash relative address 0x0
ROM:002F0F16                 ldi:20  #0xAAAA, r1       // then standard JEDEC commands for flash memories
ROM:002F0F1A                 ldi:20  #0xAAA, r13
ROM:002F0F1E                 sth     r1, @(r13, r0)
ROM:002F0F20                 ldi:20  #0x5555, r1
ROM:002F0F24                 ldi:20  #0x555, r13
ROM:002F0F28                 sth     r1, @(r13, r0)
ROM:002F0F2A                 ldi:20  #0x8080, r1
ROM:002F0F2E                 ldi:20  #0xAAA, r13
ROM:002F0F32                 sth     r1, @(r13, r0)
ROM:002F0F34                 ldi:20  #0xAAAA, r1
ROM:002F0F38                 sth     r1, @(r13, r0)
ROM:002F0F3A                 ldi:20  #0x5555, r1
ROM:002F0F3E                 ldi:20  #0x555, r13

The firmware entry point is not at 200060 or 200070, these location are called from the end of the firmware, i'll take a look tomorrow.

[Redline99]

whoa, good job Geremia.

If the processor is indeed Fujitsu FR 32bit series, here is a great link with some nice PDF's and such.

http://www.fujitsu.com/us/services/edevices/microelectronics/microcontrollers/fr32bitseries/frseries/

see related products for other families
http://www.fujitsu.com/us/services/edevices/microelectronics/microcontrollers/fr32bitseries/feature.html

[Geremia]

Thanks

Some info about instruction set can be found in the Softune Workbench assembly manual

http://www.fujitsu.com/us/services/edevices/microelectronics/microcontrollers/datalib/devtools/softune5.html

[awhitehead]

Wow!  Really nice work, Geremia.  Congratulations, and thank you for all the effort you've been putting into this. 

xvi's FR disassembler seems to work and generate the same assembly:
http://web.archive.org/web/20051216103050/xvi.rpc1.org/files/disassemblers/disfr.c (No, I don't have IDA Pro, nor can I really justify the price).  Source code shows what bytecode corresponds to what instruction.

Code:

hostname:~/src/firmware/SD-S802A[01:26 PM]$ ../xvi/disfr
Binary file to disassemble : SH-S802A.bin
Offset : 0x00200000
TBR register value [FFC00]:
Swap bytes order (y/N) ? y
Done.
hostname:~/src/firmware/SD-S802A[01:26 PM]$

then....

Code:

[...]
002F0F10 9F80 0020 0000       LDI:32    #$00200000,R0
002F0F16 9B01 AAAA            LDI:20    #$0000AAAA,R1
002F0F1A 9B0D 0AAA            LDI:20    #$00000AAA,R13
002F0F1E 1101                 STH       R1,@(R13,R0)
002F0F20 9B01 5555            LDI:20    #$00005555,R1
002F0F24 9B0D 0555            LDI:20    #$00000555,R13
002F0F28 1101                 STH       R1,@(R13,R0)
002F0F2A 9B01 8080            LDI:20    #$00008080,R1
002F0F2E 9B0D 0AAA            LDI:20    #$00000AAA,R13
002F0F32 1101                 STH       R1,@(R13,R0)
002F0F34 9B01 AAAA            LDI:20    #$0000AAAA,R1
002F0F38 1101                 STH       R1,@(R13,R0)
[...]

[Redline99]

http://rapidshare.com/files/20631572/disfr.zip.html

here is a win32 console build of disfr.

Code:

/*
Program originally written by xvi (xvi@rpc1.org)
You can use this program freely, I don't hold any copyright on it!
This program was written with compatibility in mind, it should compile and run
on most platforms, Mac, PC, Unix. I did test it on Mac and Digital Unix.
All I ask is that you mail me the modifications if you make some correction.

Build:

001 Initial release
002 Corrected some opcodes. Added JMP/RET/BRA line spacing
003  20-AUG-04 Corrected for gcc3, corrected opcodes: COPOP/COPLD/COPST/COPSV/DL - LasVegas

[Geremia]

binutils has FR30 support, just compiled and tryed "objdump" and seems to dissassemble correctly. "as" give errors for branches or jumps to unknown regions, i'm not expert about assembly stuff, i think it should work with some tricks.

I've compiled in cygwin enviroment (just with a --target=fr30-elf)

http://rapidshare.com/files/20653883/binutils-FR30.rar.html

objdump.exe -D -b binary -m fr30 -EB --adjust-vma=0x200000 fw.bin > fw.asm

[Backfire]

http://www.pimposh.com/TOSHIBA_TS-L802A_AC05.ZIP <= Firmware AC05
http://www.pimposh.com/TOSHIBA_TS-L802A_AC06.ZIP <= Firmware AC06)

Hi there,

awhitehead posted these two download links for the TS-L802A firmware.
Unfortunately both links are down. Can you anybody provide me another download location or the firmware files directly?

Thanks
Backfire

[Redline99]

Here is a firmware for the "SD-H802A HDV-ROM2.4FB" very similar to our xbox 360 HD-DVD SD-S802A

http://rapidshare.com/files/20683536/SD-H802A.zip.html

[Redline99]

Forgot to add in the last post.

The SD-H802A firmware posted is setup to be in the format for disassembly using the config awhitehead posted.  Specifically "Swap bytes order (y/N) ? y"

And If anyone has issues with disfr I have another version built by VS2003 instead of VS2005, for some reason it worked on on computer but not on another (for me).

[awhitehead]

the firmware of the SD-H802A drive for pc is very very similar, also the xbox related ascii text 
http://buffalo.jp/php/ldl.php?to=hd/hdvrom24fb-ts06.exe

It's a buffalo rebranded, HDV-ROM2.4FB
Not yet found any pics

I bit the bullet over last weekend (or more like convinced her who must be obeyed), and ordered a Toshiba HD-A1, that is supposed to have SD-H802A drive. 

So yes, there will be photos of SD-H802A, including side by side comparisons with SD-S802A.

In fact, looking at the firmware for SD-H802A and SD-S802A I am sitting here and quetly wondering if it's the same drive, with the difference in the model string indicating a standard internal IDE connector vs the JAE50 connector on the Xbox drive. 

q: Would the firmware image for SD-H802A extracted from the Buffalotech installer help anyone? 
It's just winvup2_h802a_hcts06.exe with the first 197512 bytes cut off.

Code:

hostname:~/src/firmware/SD-H802A$ dd if=winvup2_h802a_hcts06.exe of=hcts06 bs=197512 skip=1
5+1 records in
5+1 records out
1080440 bytes transferred in 0.010332 secs (104571114 bytes/sec)
hostname:~/src/firmware/SD-H802A$ ls -la hcts06
-rw-r--r--   1 user group  1080440 Mar 12 11:37 hcts06
hostname:~/src/firmware/SD-H802A$

[Geremia]

i think that actually the problem is to understand the firmware, mainly to find the cdb command handler.

[Geremia]

One step ahead, I've found some table regarding CDB opcodes and relative fuctions

this is from SD-S802A (xbox360)


ROM:00223626                 ldi:32  #0x405BB, r12 // 0x405BB seems 99% starting of received CDB
ROM:0022362C                 ldub    @r12, r8
ROM:0022362E                 cmp     #3, r8  // and starts analyzing CDB opcode
ROM:00223630                 beq:D   loc_22363C
...........

ROM:002236C8                 ldi:8   #0x5F, r0
ROM:002236CA                 cmp     r0, r8
ROM:002236CC                 bgt:D   loc_2236DE
ROM:002236CE                 ldi:8   #0xC, r0
ROM:002236D0                 mul     r0, r8
ROM:002236D2                 mov     mdl, r0
ROM:002236D4                 ldi:32  #unk_23B1BC, r4 ; table for opcode from 00 to 5F

tables of CDB opcode and related function to call:

0x3AFD0 when cdb opcode from D0 to DF and F9  (not present in SD-H802A, only F9 is there)
0x3B03C when cdb opcode between A0 and BF (0x3A38C for SD-H802A)
0x3B1BC when cdb opcode from 00 to 5F (0x3A50C for SD-H802A)

I've found this starting from the ascii text reported by the inquiry command, but there should be other tables for bootmode (because from this table 3B write buffer points to the same code as invalid opcodes).

Not so much, but the big (and hope funny) part begins.
Looking for any crc check of fw prior to start patching anything.
Find the CDB to dump firmware.

PS: awhitehead, the pics of the SD-E802A is not needed anymore, i was looking for it to see if the main chip was labeled, but actually is not important since we already know how to dissassemble the fw.

[Geremia]

the checksum calculation was more harder to find, i've not discovered yet a bypass trick.
Actually i've traced the checks the bootloader does on main firmware (it skips some flash regions, unique data at 0x4000-0x7FFF and bootloader area).

These areas are checked (flash is mapped to 200000):

- from 200000 to 203FFF
- from 208000 to 20BFFF
- from 210000 to 2DFFFF

for each area (starting form the last word then backward), a word based sum is done and the result must be 00, while 4 parallel xor are calculated and must result 00. I'll try to explain better:

Code:

00000000 56 31 59 4C 28 22 2D 23 02 01 02 00 00 00 00 00 V1YL("-#........
00000010 40 40 00 79 1E 02 4A 14 00 00 00 00 00 00 00 00 @@.y..J.........
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 4D 43 30 38 31 30 2F 30 33 2F 30 36 00 21 7C E4 MC0810/03/06.!|.
..............
...............
00003FB0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
00003FC0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
00003FD0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
00003FE0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
00003FF0 F6 71 56 29 90 AE 58 C4 48 AB A3 37 0F 20 6C A5 .qV)..X.H..7. l.
         |          |           |           |           |
         |          |           |           |           |

divide the above into 4 vertical columns, each word in the colums, starting from the end, is xored with the upper word in the same column, finally the result for each column must be 00 (at least it seems for sure for the 3rd column in the code i've traced)

ROM:002F0D76 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
ROM:002F0D76
ROM:002F0D76
ROM:002F0D76                 .type various_XOR, @function
ROM:002F0D76 various_XOR:
ROM:002F0D76                 stm0    (r5, r6)        ; DATA XREF: checksum_firmware+C
ROM:002F0D76                                         ; checksum_firmware+18
ROM:002F0D76                                         ; bootmode_unknown_3B_not04_writebuffer+18
ROM:002F0D76                                         ; bootmode_unknown_3B_not04_writebuffer+20
ROM:002F0D78                 enter   #4
ROM:002F0D7A                 stm0    (r0, r1, r2, r3, r7)
ROM:002F0D7C                 stm1    (r13)
ROM:002F0D7E                 mov     r5, r13
ROM:002F0D80                 lsl     #2, r13         ; 4000, D000, 4000, offset to start reading flash content
ROM:002F0D82                 ldi:8   #0, r7          ; will contain sum of words
ROM:002F0D84                 ldi:8   #0, r0          ; will contain result of xor of 1st column
ROM:002F0D86                 ldi:8   #0, r1          ; will contain result of xor of 2nd column
ROM:002F0D88                 ldi:8   #0, r2          ; will contain result of xor of 3rd column
ROM:002F0D8A                 ldi:8   #0, r3          ; will contain result of xor of 4th column
ROM:002F0D8C
ROM:002F0D8C loc_2F0D8C:                             ; CODE XREF: various_XOR+38
ROM:002F0D8C                 add2    #0xC, r13       ; subtract 4
ROM:002F0D8E                 ld      @(r13, r4), r5  ; r4 is flash base address, 200000, 210000, 208000
ROM:002F0D90                 add     r5, r7
ROM:002F0D92                 eor     r5, r3
ROM:002F0D94                 add2    #0xC, r13
ROM:002F0D96                 ld      @(r13, r4), r5
ROM:002F0D98                 add     r5, r7
ROM:002F0D9A                 eor     r5, r2
ROM:002F0D9C                 add2    #0xC, r13
ROM:002F0D9E                 ld      @(r13, r4), r5
ROM:002F0DA0                 add     r5, r7
ROM:002F0DA2                 eor     r5, r1
ROM:002F0DA4                 add2    #0xC, r13
ROM:002F0DA6                 ld      @(r13, r4), r5
ROM:002F0DA8                 add     r5, r7
ROM:002F0DAA                 eor     r5, r0
ROM:002F0DAC                 cmp     #0, r13
ROM:002F0DAE                 bne     loc_2F0D8C      ; repeat untill the begin of the checksumed area
ROM:002F0DB0                 mov     r7, r4          ; r4 now is the sum of words
ROM:002F0DB2                 ld      @r6, r5         ; initially should be 00000000
ROM:002F0DB2                                         ; but if more than one fw area is checked, it
ROM:002F0DB2                                         ; contains the resulting xor of the previous
ROM:002F0DB2                                         ; fw checked part
ROM:002F0DB4                 eor     r0, r5
ROM:002F0DB6                 st      r5, @r6
ROM:002F0DB8                 add     #4, r6
ROM:002F0DBA                 ld      @r6, r5
ROM:002F0DBC                 eor     r1, r5
ROM:002F0DBE                 st      r5, @r6
ROM:002F0DC0                 add     #4, r6
ROM:002F0DC2                 ld      @r6, r5
ROM:002F0DC4                 eor     r2, r5
ROM:002F0DC6                 st      r5, @r6
ROM:002F0DC8                 add     #4, r6
ROM:002F0DCA                 ld      @r6, r5
ROM:002F0DCC                 eor     r3, r5
ROM:002F0DCE                 st      r5, @r6
ROM:002F0DD0                 ldm1    (r13)
ROM:002F0DD2                 ldm0    (r0, r1, r2, r3, r7)
ROM:002F0DD4                 leave
ROM:002F0DD6                 addsp   #8
ROM:002F0DD8                 ret
ROM:002F0DD8                 .size various_XOR, .-various_XOR
ROM:002F0DDA ; ---------------------------------------------------------------------------

I've checked the sum of fw part is really 00, using firmsum.exe by xt5 (also hitachi drive uses a word based sum for checks)http://www.ingenieria-inversa.cl/files/toolkit.rar

but i need a tool that calculates the xors, is there anyone that could help? i'm not able to do it myself

the first and last 0x10 bytes of fw part seems changeable values to let calculation pass, but...just wondering, is it possible that sums and xors could be all 00?

[Geremia]

Much thanks to Arnezami from doom9 board for providing the xor calculation app and for sharing headache

the checksum verification is quite huge code, it's not just a sum and a xor, and have not been already understood completely.
What is sure is that the check involves:
- 4 xors of columns,
- the sum=0
- the first and last 16bytes of fwpart

mantaining these 3 things, the code can be changed without knowing the exact verification process

night and days in tracing the f***ing verification process and get an hole, and just few hours in tracing the read disc structure - get volumeID, and be able to get volumeID without AACS authentication

Code:

E:\HD-DVD\PLSCSI>plscsi.exe -v -x "AD 00 00 00 00 00 00 80 00 24 00 00" -i x24
x 00000000 AD 00 00:00:00:00 00 80:00:24:00 00 .. .. .. .. "-@@@@@@@@$@@"
x 00000000 00:22:00:00 40:00:09:18 20:06:08:41 00:20:20:20 "@"@@@@IX FHA@   "
x 00000010 20:20:00:00 xx:xx:xx:xx xx:xx:xx:xx xx:xx:xx:xx "  @@xxxxxxxxxxx"
x 00000020 xx:xx:xx:xx .. .. .. .. .. .. .. .. .. .. .. .. "xxxx"

[awhitehead]

Wow!  Congratulations, Geremia and Arnezami.

Just as I was in the middle of writing an xor calculator :-) 


Edit: Question: Besides bypassing drive AACS authentication to obtain volume ID, what else would one look for from the xbox perespective?   I am totally unfamiliar with the realities of Xbox.  From HTPC side of things, making it RPC1 for standard DVDs is probably the only other nice thing to have, and that is such a minor thing any way (I assume that firmware giving up full volume ID superseeds any host revocation lists that might be distributed on newer HD-DVDs). 

[Geremia]

From an xbox360 poin of view, it will be interesting to see if the challenge/response protocol for disc authentication is present. This is what i'd like to do, because the "xbox media" ascii text presence in fw is something interesting; i'm wondering, why a drive is capable of recognition of xbox media if games can't boot from hd-dvd drive?

from an AACS point of view, since both host and drive revocation list are on disc (correct me if i'm wrong, i've read aacs specs quite time ago), it shoube be interesting to be able to clear it up a bit

[awhitehead]

So if the protocol is present, would that imply that it's potentially possible to replace the Xbox 360's built in DVD drive with HD-DVD drive, assuming one gets the proper cryptographic keys in place?   

[Geremia]

yes, but it's just a fantasy derivated by the ascii text inside the fw, nothing techical atm.