HD-DVD addon Toshiba SD-S802A

[Geremia]

just got one yesterday, opened, the main chip has no brand and no model number, does anyone have a minimal idea of what chipset culd be, and what's the main CPU inside? I've read the toshiba standalone hd-dvd player HD-E1/HD-A2 has SD-E802A drive inside, but didn't find any drive pcb scan on the net.

I can't upload my dump, becase unique AACS stuff inside, but if someone else has another flash dump, please PM me to have a compare.

I've desoldered and readed the flash, EON29LV160, not yet figured out how to deassemble, anyway looking with hexeditor, byteflipping (16bit), a lot of clear text is visible (maybe is a 16bit CPU?!?).
The text is about debug mode console messages, probably trought a serial port (wich i've not already found on pcb).
The funny thing is that there are debug messages regarding xbox disks

No Use..
XBOX Media w/o BCA..
XBOX Media w/ BCA...    #Hum, BurstCuttingArea on xbox disks?
No XBOX Media...
Invalid MKB detect..      #AACS stuff
Invalid MMV detect.
DVD+R/DL Not-Finalized Media....


SYS: XBOX 1/2 Bit AD Chal...   #this "Chal" surprise me a bit, hum, maybe it's a  "challenge"?
SYS: XBOX 1/2 Bit Chal..
SYS: XBOX Mirror AD Chal....
SYS: XBOX Mirror Chal...
SYS_IGN: XBOX CDF Read..


No Use..
XBOX XGD2...    #? xbox CD media?
XBOX X2.          #???
CD-RW...
CD-RW...
CD-RW...
CD-RW...
CD-R....
CD-ROM..
HD-RW/DL....
HD-RW...
HD-R/DL.
HD-R....



So, this drive seems to me interesting, i'll make a PCB scan as soon as possible, maybe someone can recognize the main chip, ...maybe a NEC?

[Geremia]

[garyopa]

On the back of the board there is TC94A86 part, where the cache ram is and the flash chip.

This is in the line of Toshiba Single-Chip CD/DVD controllers with complete A/D and microcontroller all in one.
But their current "released" catalog of datasheets only goes up to the TC94A39 part.

[bender_]

A blog that says that the drive is recognized on PCs without any kind of hack http://uneasysilence.com/archive/2006/11/8303/ , so it's also a pretty cheap hd-dvd player even for people that does not have an x360  . There are some few photos about inside the case, not big res though 

[k0mpresd]

the drive requires udf reader 2.5 for the pc to be able to read the contents of an hd disc

[awhitehead]

Good day.  Hopfully the following will be useful to someone.  I am just a n00b.

I am a visitor from doom9 forums, where a bunch of folks are using Xbox 360 HD-DVD drives with their PCs to play back, backup and decrypt HD-DVD disks.    I own one of these drives myself, and use it with a PC, although I don't own an Xbox 360.   

From hardware point of view, these drives seem to be similar to SD-E802A in Toshiba HD-E1 stand-alone HD-DVD players.
 
Unfortunately I don't have high res scans of SD-E802A.   X807616 (which is how this drive reports itself to the Windows system) is possibly a custom firmware version written specifically for Xbox (and it is possible that the above two drives are the same physical hardware but different firmware).

(Some photos of internals of HD-E1, which are, sadly, not that useful:
http://www.cstone.net/~dk/A2-1.jpg
http://www.cstone.net/~dk/A2-2.jpg
http://www.cstone.net/~dk/A2-3.jpg  Note similarities of this label with this label from Xbox 360 drive: http://www.stor-age.com/resources/7A23B881-1825-4E6B-80B4-56B51DB18FFE/TOSHIBA-HDDVD/Label.jpg
 )


(Disclaimer: The following is how I understand it, which is probably very wrong)
HD-DVD disks are encrypted using Advanced Access Control/Content System (AACS).  It consists of a set of encryption keys called "device keys" that embedded into each software player.   Player uses the device keys to derive processing key, and in turn uses processing key to authenticate itself to the drive, and to convince the drive to read volume ID off the drive.   By combining the volume ID and the processing key, player software generates a volume key, that is used to decrypt a file containing the chapter keys on the HD-DVD disk.  Finally Chapter Keys are used to decrypt the actual video files (EVOs) on the HD-DVD, and play back video.  Best place to read about it would likely be on the doom9 forums ( http://forum.doom9.org/showthread.php?t=122363 )  and the AACS documentation.

Current speculation by some doom9 members is that the board inside the HD-DVD drive enclosure (the one that contains a USB hub, two memory devices and a USB to IDE adapter) also contains a hardware decoder for HD-DVDs.  In other words, the 11 megabyte image that is contained on the CD-ROM disk packaged with the drive contains the device keys for decrypting AACS, and upon installation part of the image gets flashed into the memory device(s) on the board. 

As someone else mentioned, by installing Toshiba UDF 2.5 drivers for Windows XP in conjunction with either Cyberlink PowerDVD 6.5 or 7.1, or with WinDVD 8 Japanese one is able to play back HD-DVD disks on a Windows XP system. 

One of the avenues of attacking the player software have been use of USB Sniffer 1.8 to sniff the communication between the drive and the host system, and use of memory dumps and winhex to reverse engineer the device keys for software players.  (Some more information/techniques/findings in this thread: http://forum.doom9.org/showthread.php?t=121866 )

Personally I am hopeing that the C08 firmware in X807616 supports both firmware downloading and flashing using propriatary Toshiba CDBs, and thus firmware is extractable and modifiable without the use of a hardware flasher.     If someone is familiar with Toshiba/Samsung CDBs, I am willing to run tests (I have ordered a mini-ITX to IDE adapter as well, and thus shortly will be able to mount this drive on an IDE chain instead of through a USB to IDE converter board).

(Toshiba also has another HD-DVD drive model, TS-L802A that is in Toshiba Dynabook Qosmo laptops:

Some links to TS-L802A firmware, in case a stand-alone TSSD flasher and firmware images are useful for reverse engineering flashing routines:
http://dynabook.com/assistpc/download/modify/qosmio/fwts802a/802tf31.exe  <= Firmware TF31
http://www.pimposh.com/TOSHIBA_TS-L802A_AC05.ZIP <= Firmware AC05
http://www.pimposh.com/TOSHIBA_TS-L802A_AC06.ZIP <= Firmware AC06)

[bourke]

As you lads are all well aware, there is a format war going on.  So if in your firmware travels you happen to come across a device key for this drive - please don't release it!

Not until after Blu-Ray meets its fate anyway ;-)

[robinsod]

As you lads are all well aware, there is a format war going on.  So if in your firmware travels you happen to come across a device key for this drive - please don't release it!

Not until after Blu-Ray meets its fate anyway ;-)

Eh? If a device key is revealed for a particular player then it can be revoked. That means that the player will not be able to play disks released in the future, it does not mean the format is revoked.

It would be really interesesting to see what the reaction is if the 360's device keys are compromised. However it's almost certain that the device key for the 360 is encrypted in the 360's flash (along with the DVD key for playing games) so not much chance of it happening anytime soon & if it did, it may be updateable

[bourke]

Eh? If a device key is revealed for a particular player then it can be revoked. That means that the player will not be able to play disks released in the future, it does not mean the format is revoked.

Simple, if HD-DVD devices are revoked consumers will be returning them to shops and replacing them with Blu-Ray.

More consumer backlash for one format necessarily translates to an increase in sales for the competing format.

[Geremia]

Just to clear something:

i personally don't care of NAND storage (256MB? don't know and don't care) inside the usb to ide adapter, maybe the hd-dvd software player inside, maybe simple a permanet storage (as called by AACS) for storing custom playlists; i want only to focus on the drive.
The green dvd disk in boundle wit the hd-dvd is not necesary to the drive to operate, probably only a dash update.

Don't mistake host key (the software player) with device key (drive key) (both private key used to sign AACS specific CDB data exchange); the device key is inside the drive firmware, probably all xbox360 hd-dvd drive have the same device key.
Does anyone has a fw dump of it? i've a dump of my drive, but prior to share with you all, i want to be sure that it's the same for all drives.

The firmware is similar to the slimline drive, TS-L802A
I was able to reflash the drive using http://www.toshibaer.com/firmware/download.php?software_utilities/WinVup2_V2070.exe but i had to byteswap AA BB -> BB AA my flash dump.
I've sniffed the flashing, and i found some debug comands
The main problem is to know what CPU inside the main chip.
The similar drives and the drives flashed by WinVUP are all slim drive, no pics foun out here.
Maybe the most interesting of desktop drives are SD-R5772 and 5272 (dvd burners), flashable by Twinfwup.exe that (sniffed) uses similar debug commands to WinVUP.
These 2 drives uses TC94A53, that i don't know what CPU inside, but i know that the bigger one, TC94A63, has also a toshiba TX19 mips cpu inside wich is based on the mips R3000A architecture.
Even if the SD-S802A does not support bus encryption for AACS (as far as i've seen), i think a fast cpu is anyway used. 

[Geremia]

here is the sniffed flashing using WinVUP

WinVUP checks the drive if supported

out
1D 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00  // 06=datalenght
out
88 00 00 02 01 41  // 02=commandlenght 01 41=command

out
1C 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00  // FF=data lenght to retrieve
in
88 00 00 2C 01 41  // 2C=lenght (asked for FF but only 2C is available) 01 41=command
xx xx 00 00 00 xx xx xx 00 xx 00 xx 00 xx 00 xx 00 xx xx xx 00 xx 00 xx xx xx 00 xx 00 xx 00 xx 00 xx 00 xx 00 xx 00 xx 00xxx  // fw from 0xFDC18

out
1D 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00
out
88 00 00 02 02 41

out
1C 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00
in
88 00 00 2C 02 41
xx xx xx xx xx xx xx 00 00 00 00 00 40 40 fw at 0x4 and 0x10004
xx xx xx xx xx xx xx 00 00 00 00 00 01 40 fw at 0xFDC04
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?? ??

repeat both another time


WinVUP start flashing

out
1B 00 00 00 02 00 00 stop unit

out
1D 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00
out
88 00 00 02 03 41  // enters in "boot mode" (maybe a safemode), inquiry reports "BOOT" as fw revision, eject does not work, maybe only a few cdb commands are recognized

out
3B 04 00 00 00 00 00 20 00 00 00 00 00 00 00 00  write buffer ID 00
out
first 0x2000 fw chunk, the tray opens without any cdb command

out
3B 04 01 00 00 00 00 20 00 00 00 00 00 00 00 00  write buffer ID 01
out
second 0x2000 fw chunk

out
3B 04 02 00 00 00 00 20 00 00 00 00 00 00 00 00  write buffer ID 02
out
3rd 0x2000 fw chunk

..... till last chunk, than drive resets automatically

I've tried to send the command that enters "boot mode" then sending various READBUFFER cdb, but the response was always "no media present"

---------------------------------------


other debug commands found

out
1D 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00
out
88 00 00 04 00 40 00 00  // this command is sent by Twinfwup, but then it does not accept my flashdump as compatible

out
1C 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00
in
88 00 00 0C 00 40
48 42 36 2F 31 30 2F 30 33 20 // fw at 0x3A318, ASCII HB6/10/03, similar to TS-L802A fw

---------------------------------------------

out
1D 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00
out
88 00 00 04 00 40 01 00

out
1C 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00
in
88 00 00 0C 00 40
xx xx xx xx xx xx xx xx xx xx // ASCII xxxxxxxxxx drive serial number at 0x6008

-----------------------------------------------

out
1D 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00
out
88 00 00 02 01 42

out
1C 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00
in
88 00 00 56 01 42
         // various part around 0xBFD0  ASCII S803ANA69120, where in TS-L802A is L802ANE64220

--------------------------------------------

[awhitehead]

out
1B 00 00 00 02 00 00 stop unit

out
1D 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00
out
88 00 00 02 03 41  // enters in "boot mode" (maybe a safemode), inquiry reports "BOOT" as fw revision, eject does not work, maybe only a few cdb commands are recognized

I've tried to send the command that enters "boot mode" then sending various READBUFFER cdb, but the response was always "no media present"

Please forgive an idiotic question, but how are you sending these commands?

Specifically, I attempted to replicate sending these CDBs using plscsi.  Things like

Code:

C:\>plscsi -vx "1B 00 00 00 02 00 00" -p
x 00000000 1B:00:00:00 02:00:00 .. .. .. .. .. .. .. .. .. "[@@@B@@"
// 0 = plscsi.main exit int

happily work - unit ejects the tray and spins down (Thank you, useful command).

I can replicate the things in plscsi tutorial - INQUERY, UNIT READY, obtain media size, read blocks from disk, etc.
However things like

Code:

C:\>plscsi -vx "1D 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00" -p
x 00000000 1D:00:00:00 06:00:00:00 00:00:00:00 00:00:00:00 "]@@@F@@@@@@@@@@@"

result in a command just sitting there.  Attempts to send further commands also hang until I powercycle the drive.

Sending just 88 00 00 02 03 41 results in sense error.

This is the moment where I feel that I should RTFM a great deal, however re-reading plscsi tutorial and spending about an hour reading some of the previous posts on this site did not leave me more enlightened.  At this point I wonder if I should be sniffing the USB bus.  Are you accessing your drive over USB, or did you put it into IDE chain?   Are you using plscsi, or DVDInfo Pro to send these?

As a probably irrelevant aside: I've had a chance to extract the TF31 firmware from the flasher for TS-L802A, and compare it to the other two firmware images:
Seems like the section of the code that contains BOOT string (My primary tools for looking at these images are hexdump, strings and hexedit) doesn't necessarily change between firmware versions.  Specifically timestamp that section of the code reports did not change between TF31 and AC05 (released about 2 months apart), but got updated in AC06.    Thus BOOT mode is the mode that Toshiba is likely not changing as often as the rest of the image.

[Geremia]

I've the drive connected by usb as normal. I've also a JAE50 adapter (the one for notebook slim drives to 40pin IDE) but does not have the 12v connected, so the drive does not work (but works with slim drives that dont' need 12v).
It hangs because the drive is waiting for data from the host, you have to create a bin file with the data to send to the drive.

E:\HD-DVD rip\PLSCSI>plscsi.exe -v -x "12 00 00 00 60 00" -i x60
x 00000000 12 00:00:00 60 00 .. .. .. .. .. .. .. .. .. .. "R@@@`@"
x 00000000 05:80:00:32 5B:00:00:00 54:4F:53:48 49:42:41:20 "E@@2[@@@TOSHIBA "
x 00000010 44:56:44:2F 48:44:20:20 58:38:30:37 36:31:36:20 "DVD/HD  X807616 "
x 00000020 4D:43:30:38 31:30:2F:30 33:2F:30:36 00:00:00:00 "MC0810/03/06@@@@"
x 00000030 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 00000050 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
// 0 = plscsi.main exit int

this commands sends addictional data (-o x6 = 6 bytes) taked from file (-f toshibaboot.bin, wich contain 6 bytes, 88 00 00 02 03 41)
E:\HD-DVD rip\PLSCSI>plscsi.exe -v -p -x "1D 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00" -f toshibaboot.bin -o x6
x 00000000 1D:00:00:00 06:00:00:00 00:00:00:00 00:00:00:00 "]@@@F@@@@@@@@@@@"
x 00000000 88:00:00:02 03:41 .. .. .. .. .. .. .. .. .. .. "H@@BCA"
// 0 = plscsi.main exit int

E:\HD-DVD rip\PLSCSI>plscsi.exe -v -x "12 00 00 00 60 00" -i x60
x 00000000 12 00:00:00 60 00 .. .. .. .. .. .. .. .. .. .. "R@@@`@"
x 00000000 05:80:00:32 5B:00:00:00 54:4F:53:48 49:42:41:20 "E@@2[@@@TOSHIBA "
x 00000010 44:56:44:2F 48:44:20:20 53:44:2D:53 38:30:32:41 "DVD/HD  SD-S802A"
x 00000020 42:4F:4F:54 30:36:2F:30 36:2F:30:36 00:00:00:00 "BOOT06/06/06@@@@"
x 00000030 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 00000050 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
// 0 = plscsi.main exit int


maybe with this command, the code jumps to the end of the fw where this ascii string is present, maybe a sort of essential code to let flash all the main fw parts without overwriting code in execution, just speculations

[awhitehead]

Thank you very much for your explanations. 

I pulled down a bunch of flashers from toshibaer.com, and played with them, while snooping the USB bus.

Looking at your results, I made a small table:

Code:

rem We know
rem 88 00 00 04 00 40 00 00  // fw at 0x3A318, ASCII HB6/10/03 0x10 bytes
rem 88 00 00 04 00 40 01 00 // fw at 0x6008, ASCII drive serial number 0x10 bytes
rem 88 00 00 02 01 42 // fw around 0xBFD0, model/serial number 0x5A bytes
rem 88 00 00 02 01 41 // fw at 0xFDC18 0x30 bytes
rem 88 00 00 02 02 41 // fw at 0x4 and 0x10004, and 0xFDC04 0x30 bytes
rem 88 00 00 02 03 41 // drops drive to boot mode

This seems to imply that 88 00 00 is the Toshiba vendor specific CDB.  I searched for the byte sequence in the usbsnoop.log, but there was only one additional command that is not in the above list (88 00 00 0C 00 40 48 42), and it was getting me nowhere.

Code:

C:\>plscsi -v -p -x "1D 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00" -o x8 -f 8800000C00404842.bin
x 00000000 1D:00:00:00 08:00:00:00 00:00:00:00 00:00:00:00 "]@@@H@@@@@@@@@@@"
x 00000000 88:00:00:0C 00:40:48:42 .. .. .. .. .. .. .. .. "H@@L@@HB"
x 00000000 70:00:05:00 00:00:00:0A 00:00:00:00 26:00 .. .. "p@E@@@@J@@@@&@"
// x 5 26 sense // 8 residue
// -x0102 = -258 = plscsi.main exit int

C:\>plscsi -v -p -x "1C 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00" -i -xFF
Usage: plscsi

C:\>

Attempting CDBs derived from the above table (88 00 00 02 01 40, 88 00 00 02 01 43, 88 00 00 02 02 42) didn't get me anywhere either.


The rest of the commands that you documented,  of course, worked.

[Geremia]

88 00 00 is not a cdb command, is the header of the addictional data, something like mode sense and mode select.
what you sniffed was part of this:

out
1D 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00
out
88 00 00 04 00 40 00 00  // this command is sent by Twinfwup, but then it does not accept my flashdump as compatible

out
1C 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00
in
88 00 00 0C 00 40
48 42 36 2F 31 30 2F 30 33 20 // fw at 0x3A318, ASCII HB6/10/03, similar to TS-L802A fw


i've quick looked at your pm, your drive serial number is diferent from mine.

random bruteforce to find valid commands is quite hard, anyway unless anyone can deassemble the fw, it's the only try.

[k0mpresd]

ive gotten this so far:

C:\Documents and Settings\xxxx>plscsi.exe -v -p -x "1D 00 00 00 06 00 00 00
00 00 00 00 00 00 00 00" -f boot.bin -o x6
x 00000000 1D:00:00:00 06:00:00:00 00:00:00:00 00:00:00:00 "]@@@F@@@@@@@@@@@"
x 00000000 88:00:00:02 03:41 .. .. .. .. .. .. .. .. .. .. "H@@BCA"
// 0 = plscsi.main exit int

C:\Documents and Settings\xxxx>plscsi.exe -v -x "12 00 00 00 60 00" -i x60
x 00000000 12 00:00:00 60 00 .. .. .. .. .. .. .. .. .. .. "R@@@`@"
x 00000000 05:80:00:32 5B:00:00:00 54:4F:53:48 49:42:41:20 "E@@2[@@@TOSHIBA "
x 00000010 44:56:44:2F 48:44:20:20 53:44:2D:53 38:30:32:41 "DVD/HD  SD-S802A"
x 00000020 42:4F:4F:54 30:36:2F:30 36:2F:30:36 00:00:00:00 "BOOT06/06/06@@@@"
x 00000030 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 00000050 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"

*power cycle*

// 0 = plscsi.main exit intC:\Documents and Settings\xxxx>plscsi.exe -v -x "12 00 00 00 60 00" -i x60
x 00000000 12 00:00:00 60 00 .. .. .. .. .. .. .. .. .. .. "R@@@`@"
x 00000000 05:80:00:32 5B:00:00:00 54:4F:53:48 49:42:41:20 "E@@2[@@@TOSHIBA "
x 00000010 44:56:44:2F 48:44:20:20 58:38:30:37 36:31:36:20 "DVD/HD  X807616 "
x 00000020 4D:43:30:38 31:30:2F:30 33:2F:30:36 00:00:00:00 "MC0810/03/06@@@@"
x 00000030 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 00000050 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
// 0 = plscsi.main exit int

C:\Documents and Settings\xxxx>plscsi.exe -v -p -x "1D 00 00 00 06 00 00 00
00 00 00 00 00 00 00 00" -f serial.bin -o x8
x 00000000 1D:00:00:00 06:00:00:00 00:00:00:00 00:00:00:00 "]@@@F@@@@@@@@@@@"
x 00000000 88:00:00:04 00:40:01:00 .. .. .. .. .. .. .. .. "H@@D@@A@"
x 00000000 70:00:05:00 00:00:00:0A 00:00:00:00 26:00 .. .. "p@E@@@@J@@@@&@"
// x 5 26 sense // 8 residue
// -x0102 = -258 = plscsi.main exit int

C:\Documents and Settings\xxxxx>plscsi.exe -v -p -x "1C 00 00 00 FF 00 00 00
00 00 00 00 00 00 00 00"
x 00000000 1C:00:00:00 FF:00:00:00 00:00:00:00 00:00:00:00 "\@@@?@@@@@@@@@@@"
x 00000000 70:00:05:00 00:00:00:0A 00:00:00:00 2C:00 .. .. "p@E@@@@J@@@@,@"
// x 5 2C sense
// -x0002 = -2 = plscsi.main exit int

can one of you please explain what "in" along w/ the commands listed mean please?

sorry..im trying to learn here

[Geremia]

C:\Documents and Settings\xxxx>plscsi.exe -v -p -x "1D 00 00 00 06 00 00 00
00 00 00 00 00 00 00 00" -f serial.bin -o x8

in the CDB command you specified 6 bytes of addictional data but you sent 8 (-o x8)

1C and 1D are not standard commands, but seems to work similar to modesense and modeselect
1D seems similar to modeselect, where 5th bytes is "parameter list lenght", anyway i've not readed all specification of scsci and multimedia command, i can be inprecise about terminology.

BTW, in "bootmode" only this commands operation code are accepted:

03 request sense
12 inquiry
1B start stop unit
3B write buffer
4A get status event notification
F5 unknown vendor specific, works also in non bootmode, same response


E:\HD-DVD rip\PLSCSI>plscsi.exe -v -p -x "F5 00 00 00 06 00 00 00 00 00 00 00" -i x10  // 06 is allocation lenght
x 00000000 F5 00 00:00:06:00 00 00:00:00:00 00 .. .. .. .. "u@@@F@@@@@@@"
x 00000000 00:01:08:01 00:00:AE:AE AE:AE:AE:AE AE:AE:AE:AE "@AHA@@.........."
// 10 = xA = plscsi.main exit int

tried to set allocation lenght to FF and change remaining fields to something else than 00, but always the same respose.

I've got enought of manual random bruteforce commands , a dissassemble of this fw is needed.
does anyone want to take a look at fw? i can privately send.

[awhitehead]

xvi of rpc1.org used to have a page on disassembling drive firmware.  His site is gone, but archive.org has a copy: http://web.archive.org/web/20060204193327/http://xvi.rpc1.org/

There are source codes there to drive firmware disassemblers for various architectures.   Since it was mentioned earlier that some of the Toshiba CPUs are based on MIPS R3000A architecture (Same architecture as what was used in  the original PlayStation, so there must be people out there that know it), I can try to make sense of the wikipedia page and attempt to write a disassembler for MIPSR3K based on xvi's code, and see if the results make any sense.

http://en.wikipedia.org/wiki/MIPS_architecture#Summary_of_R3000_instruction_set

Otherwise, I am probably out of my depth here.  Anyone else has any ideas?   

[k0mpresd]

in the CDB command you specified 6 bytes of addictional data but you sent 8 (-o x8)

does anyone want to take a look at fw? i can privately send.

thank you for the correction...i didnt know thats what that byte was for..still learning..a lot

[awhitehead]

A bit about the firmware images.

After assuming that the CPU in the drive is running a TX19 core, I did a bit of reading on the matter. 
Toshiba has two CPU cores that could potentially work: TX19 and TX39.  TX39 is based on MIPS R3900 and is 32 bit, while TX19 supports both 32 bit, and extensions to MIPS 1 - 3 architecture called MIPS 16.

mips16 are 16 bit operations, designed to save memory at the cost of performance. 

Since Geremia mentioned the fact that the firmware needs to be byteswapped on two byte word boundary, 16 bit bigendian core likely makes sense.

At this point I downloaded and built GNU gdb (debugger) and binutils (primarily for the objdump disassembler) with a target of mips16-big-ecoff (At the time ecoff made sense, as it's not elf and not a.out, right?), however currently that is not getting me far - neither the firmware, byteswapped firmware, or firmware cut the the beginning of the BOOT mode section (and byteswapped, if needed) is recognized as valid object.  Maybe by further manual reading, I'll figure out how to convince objdump to just disassemble, without trying to recognize file format.

So far I've played with RAAC06.bin firmware for TS-L802A, which, I believe, is for the same core used in SD-S802A.

As an aside, here is my byteswapping routine, in case it's useful to someone (yes, I at the "write tools" stage).  It does no error checking what so ever, and probably has bugs if the file is of odd length, if it can't open/close files, or if something I can't think of happens.

Code:

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>

#define BUFSIZE 10000

int main(int argc, char **argv)
  {
   FILE *infid, *outfid;
   infid=fopen(argv[1],"rb");
   outfid=fopen(argv[2],"wb");
   unsigned char databuf[BUFSIZE];
   unsigned char *byteptr, byteval;
   int nread, foo;

   while ((nread=fread((void *)databuf,1,BUFSIZE,infid)) > 0)
    {
     byteptr=databuf;
     for (foo=0; foo < nread; foo+=2)
       {
        byteval=byteptr[0]; byteptr[0]=byteptr[1]; byteptr[1]=byteval;
        byteptr+=2;
       }
     if (fwrite((void *)databuf,1,nread,outfid)!=nread) break;
    }
  fclose(infid); fclose(outfid);
}

Usage:

Code:

$ cat test ; echo
ABCDEFGH
$ gcc -o swaptwo swaptwo.c
$ ./swaptwo test test.out
$ cat test.out ; echo
BADCFEHG
$

(Before anyone asks, code is public domain, most of it was at one point copied from a textbook, and then mutated over the years any way)