HD-A1 Exploration / Repair (Standalone HD-DVD)

[sega32x]

Well, as we all know, its basically a PC, and has plenty of potential. Broken units can be had cheap ($100 or so, w/ a 2.4ghz p4 + 1gb DDR, and a IDE hd-dvd drive)

Issue is, these broken units usually have a corrupt flash (which has mostly GPL'd linux code on it), same with mine. And of course, nobody out there has a backup (its on a usb key!)

So, the hunt goes on. Eventually, id love to turn it into a standalone linux box, with the ability to play hd-dvd's.

Anyone have any ideas?
Thanks!

[sega32x]

Well, still looking for any info, I am sure someone must have one, that can help!

[jeffy]

I have found this:
"I was able to get access to another HD-DVD player, and after reading the image on its flash disk it's different in a couple places. Also when trying to put the daughter card from my unit in this other player it would reference the disk for a little while, but then halt partway through the boot process. So it looks like there's probably a serial number stored in the firmware, and a check performed during boot to make sure it's the right firmware for that specific unit by serial number."
http://geekswithblogs.net/lorint/archive/2006/04/21/75795.aspx

It also seems like the "brother" doesn't like CPU upgrades:
"HD-XA1 powered up, the typical 'WELCOME' appeared on the lcd, there was a little drive activity, then nothing. Completely locked up."
- the discussion below the abovementioned article

[sega32x]

Thanks for the work, but alas, I've also gone over that page, atleast 20 times!

The issue is that there is a 32mb spansion flash chip onboard as well, but its use evades me (hooked to a xlinx chip) The CPU could be tied w/ a processor serial number, but its hard to test all this with a corrupt flash, you know? If I had a working one, I've got a unit to screw around with, whats the worse that would happen, it breaks?

[jeffy]

try Ebay, there are quite a few listed, however, you know the risks of being deceived.
Eg. $60+25
http://cgi.ebay.com/Toshiba-HD-A1-DVD-Player-AS-IS_W0QQitemZ160093394188QQcategoryZ61250QQrdZ1QQcmdZViewItem
AN EXAMPLE

[sega32x]

Oh I have, daily, the issue with buying something broken = it dont work (of course!), and im just out more cash!

[awhitehead]

I just ordered a used HD-A1 ("It's in the mail"), primarily because I am interested in playing with the Linux on the thing.

Technically, what I am intersted in doing, is the following:

The HD-A1 has a USB header on board, into which the USB disk is plugged in. From photos it seems to be fairely standard (And if it's not, USB ports are pretty simple, with 4 wires and ground). When I saw that, I started thinking of instead of dedicating the port to the internal USB flash, about replacing it with a USB hub. Technically, this should provide a couple of advantages: I should be able to hook up a hard drive over USB to the hub, and not only boot from it (personally I prefer flash - fewer things to break), but also run aacskeys + BackupHDDVD (or some form thereof) right on the stand-alone player. Keyboard, of course, can also be connected. And hey, maybe the player can be convinced to play HD-DVD images right from the hard drive :-)

But thing to do right away, it seems, is to back up internal flash to safe read-only media.

So some questions to those of you that opened up your units already.

This is a first stand-alone player that Toshiba released, so it probably is very rough around the edges, and haven't been fully stripped of all the development features.

Are there headers on the motherboard anywhere, which might be serial ports? Anything that looks like 10 (or 9) solder points, possibly in two rows of 5 (These would be most obvious, of course)? HD-A1 had to be debugged somehow, right? Some Toshiba kernel engineer had to watch the thing boot, and log on, and fix up all the typos in the config scripts, right? So even if it needs a MAX232 or somesuch to bring serial port out, it's not too bad.

Is the JTAG interface brought out? Microcode had to be debugged somehow, and hardware had to be tested.

Is it running a port of a PC BIOS of some kind, or some kind of custom firmware? CFE? RedBoot? Something else?

I guess I'll know more once I open up my unit, but if someone already did all of this research, and is happily using it as a general purpose computer in a living room, or as a mail server on his network, I'd like to know about it ;-)

[laserfan]

I guess I'll know more once I open up my unit, but if someone already did all of this research, and is happily using it as a general purpose computer in a living room, or as a mail server on his network, I'd like to know about it ;-)"Hacking the Toshiba A1" is a great subject but there doesn't seem to be much progress on this vs. the earlier-posted link to Thwait's site. I'm interested too, but can only say at this point that Toshiba is "not unsophisticated" about their use of Linux and its interaction with custom hardware, as I own a couple of Magnia SGXX servers, and these are pretty slick boxes themselves.

Of course I have no idea if the folks involved in their computing business have also advised the HD-DVD guys, but it's a data point.

[sega32x]

awhitehead, thats what im talking about. I did some work on my busted box (got a new one coming, $$ = meh!)

Ok, the USB flash = has a few readable partitions, on mine = no kernel of any sort, some encrypted looking executables (however it had a bad flash, possibly incomplete!)

There are two headers, one connects to the NEC chip thats on the back (with 128kb of flash), the other may connect to the xlinx chip on the lower left, which in turn is connected to a 32mb spansion flash chip (BGA, although there is a TSOP pad)

As far as a hub/hdd, havent gone that far (only wired a USB socket in place of the flash)

But alas, since its bricked anywho, it dont get far.

As far as the USB flash drive, it is supposed to be locked with a 64bit RSA key, mine isnt (again, possibly due to the whole bricked unit thing)

Going out on a limb, but somehow the Intel firmware hub connects with the other 32mb spansion flash (would like to see whats on there, but I cant pull the BGA chip, not that skilled, any other chip = sure!)

We should also invetigate eachothers flash backups (for compare, try to find the uniqueness) as it is also apparently tied (flash, motherboard, and hd-dvd drive) somehow! Theres a tool by the flash manufacturer, has partition stuff, backup/write etc = interesting (and freeware!)

And there is the serial port on the HD-XA1 (and hdv5000), and its on every gen 1 HD-DVD player , just missing the line converter (however, dunno if that can tap into any debug interface or not)

But, the headers that are interesting = the lower two in the left hand side, the one further up is unknown, the lower one = connects to the NEC chip on the back (I beleive!)

The upper one is 8 pins if memory serves me, lower one is 10, however I did not get to tracing the pinout, and comparing (however I thought jtag as well, issue is 128kb is a bit small for much if anything, cept maybe those illusive keys!)

I also heard a rumor that it runs busybox (tiny kernel etc), which i am very familiar with = a start! Would make one great Myth frontend!

Atleast someone feels the same way!

[sega32x]

Ok, got my working unit, some quick updates!

Flash unit itelf = isnt tied to the unit, i did a 1:1 copy of one flash chip to the other = both work.

Also changed an entry (device id keys) , differently = player still boots

Alas, no HD-DVD yet to test playback, but dvd playback works. I beleive the goodies are inside the 32mb spansion chip on the boards underside, as most of the stuff on the flash drive is either encrypted, or an image/config file!

[sega32x]

Well, booting from an external usb pendrive now, I can modify non-critical data, and some critical (IE, can make it fail boot, display custom error messages and images etc)

Working on region-freeing it now, but thats not my stront point (yes, i can write to the flash, and it works)

Goal is to somehow drop a ssh daemon etc on there, to ssh in, and use real linux commands, however thats still a ways off, namely, as all of the interesting exectutables are encrypted, or hashed!

[awhitehead]

Well, booting from an external usb pendrive now, I can modify non-critical data, and some critical (IE, can make it fail boot, display custom error messages and images etc)


Could you elaborate how you are doing this? I guess you imaged the contents of the flash to a USB key, and connected that to your (broken?) unit?


Working on region-freeing it now, but thats not my stront point (yes, i can write to the flash, and it works)


Well, region-freeing would be for standard DVDs, right? HD-DVDs so far are (thankfully) region-free. For doing something like that, you would need a two stage solution: a region-free (RPC1) firmware for the DVD drive, and software that was modded to always return "region OK" during the region check.

What is the HD-DVD drive in the unit? One thing I am idely curious about, is taking whatever's inside out, and connecting Toshiba SD-S802A (drive from Xbox 360 HD-DVD attachment) together with a JED50 adapter in place of what's inside. This is a purely intellectual excercise, though, with no practical value. :-)


Goal is to somehow drop a ssh daemon etc on there, to ssh in, and use real linux commands, however thats still a ways off, namely, as all of the interesting exectutables are encrypted, or hashed!

I am still waiting for my A1 (was shipped yesterday, finally. You never can tell with sellers on eBay how fast they would ship.). In the meanwhile, a few questions:

Is the firmware running a busybox binary, or are all programs independent?

If you connect the unit to the ethernet network, and port scan it, does it list any services as running?
Is there an inetd or xinetd present on the filesystem? sshd doesn't require inetd-like service, but having inetd means that

You mention checksumming, etc. Does it check the flash checksum, or files can be added to the flash without any problems?
Can you copy a binary onto the system, and would a system run an unsigned binary?

What firmware version are you running? Myself I was thinking about imaging the flash with the old firmware to file, upgrading firmware, imaging flash to a diffeernt file, and then looking at what changed. Maybe this way it's possible to figure out where checksums are stored, etc, and subvert firmware.

Lastly, would it be possible to post (maybe as an attachment) a recursive directory listing of the flash? ls -laRt should generate what I have in mind (although you might want to sanitize the user/group listing, if you sufficiently care about such things).

Thank you.

[sega32x]

Ok! Well, it has the NEC 1100A drive in it, straight up IDE, guess we can wait a bit on region free.

I am using my new working unit (different one, ebay!), removed the internal flash drive, imaged it to my usb key, and can insert/remove while the cover is on! (a simple dd in linux did the trick)

Ran nmap on it, showed no open ports at all = really a kick in the pants, but I suppose it needs to be secured atleast (woulda loved port 22!)

Files can be added without any issue at all, some of the binaries on there will run on this x86 pc (simple ones, like eject)

Its running FW 2.0, and I am sure the older FW's have more data, however.

The issue is the 32mb Spansion memory chip on the back, i am 99.9% sure that it holds the goodies (as in, the rest of busybox, you will see with the directory listing)

There are symbolic links on the flash that lead to nowhere, all the good executables are encrypted in some form etc. I beleive our first goal is to get some kind of code access, then grab the data from the other flash, where the real goodies are!

Basically, alot is getting extracted to /tmp, no idea where its coming from.
The fact that the flash boots from any usb drive = showing how much the intel firmwarehub is interacting, i THINK over the GPIO ports its using the xlinx chip as a bios chip of sorts, then reading the data off the 32mb spansion, but I havent a way to prove it (yet!) Still hoping to get my bricked unit fixed, and having access to linux on both!

Edit: Cant attach (or quote, too big) , but here are a few of the interesting ones:


.:
total 31
drwxr-xr-x 4 root root 4096 Mar 21 13:15 ..
drwxr-xr-x 3 root root 1024 Mar 20 21:51 etc
drwxr-xr-x 12 root root 1024 Mar 20 21:01 .
drwxr-xr-x 6 root root 1024 Jan 2 09:50 usr
drwxr-xr-x 2 root root 2048 Jan 2 09:43 lib
drwxr-xr-x 3 root root 1024 Jan 2 09:43 var
drwx------ 2 root root 12288 Oct 19 03:37 lost+found
drwxr-xr-x 2 root root 1024 Jul 5 2006 NetArea
drwxr-xr-x 2 root root 1024 Jan 19 2006 HD_DVD
drwxr-xr-x 2 root root 1024 Sep 23 2005 STRFLG
drwxr-xr-x 3 root root 1024 Jul 11 2005 share


./usr:
total 136222
drwxr-xr-x 5 root root 1024 Mar 20 21:46 local
drwxr-xr-x 12 root root 1024 Mar 20 21:01 ..
drwxr-xr-x 2 root root 1024 Mar 20 21:01 bin
-rw-r--r-- 1 root root 3145728 Mar 20 18:39 netarea.img
-rw-r--r-- 1 root root 135790592 Mar 20 18:39 pstorage
drwxr-xr-x 6 root root 1024 Jan 2 09:50 .
drwxr-xr-x 4 root root 2048 Jan 2 09:43 lib
drwxr-xr-x 4 root root 1024 Jan 2 09:43 share

./usr/local:
total 17
-rwxr--r-- 1 root root 6077 Mar 20 22:04 setting.conf
drwxr-xr-x 5 root root 1024 Mar 20 21:46 .
-rwxr--r-- 1 root root 1361 Mar 20 21:46 capability.conf
drwxr-xr-x 2 root root 1024 Mar 20 21:02 bin
-rwxr--r-- 1 root root 1361 Mar 20 20:09 capability.conf~
drwxr-xr-x 2 root root 1024 Mar 20 18:39 etc
drwxr-xr-x 2 root root 1024 Jan 2 10:55 lib
drwxr-xr-x 6 root root 1024 Jan 2 09:50 ..
-rw-r--r-- 1 root root 81 Jan 2 09:46 driveinfo.conf
-rw-r--r-- 1 root root 56 Aug 8 2006 version.conf

./usr/local/bin:
total 36759
drwxr-xr-x 5 root root 1024 Mar 20 21:46 ..
drwxr-xr-x 2 root root 1024 Mar 20 21:02 .
-rw-r--r-- 1 root root 147476 Jan 2 10:47 excparam2
-rw-r--r-- 1 root root 147476 Jan 2 10:47 excparam1
-rwxr-xr-x 1 root root 16420 Jan 2 09:43 exethromctl.ko
-rwxr-xr-x 1 root root 16420 Jan 2 09:43 exHDD_MOUNT_POINT.txt
-rwxr-xr-x 1 root root 16420 Jan 2 09:43 exrootca.pem
-rwxr-xr-x 1 root root 14909460 Jan 2 09:43 exadvplayer
-rwxr-xr-x 1 root root 16404 Jan 2 09:43 expsinfogen
-rwxr-xr-x 1 root root 98324 Jan 2 09:43 exwriter
-rwxr-xr-x 1 root root 16404 Jan 2 09:43 exwriter.sh
-rwxr-xr-x 1 root root 2949140 Jan 2 09:43 excdplayerd
-rwxr-xr-x 1 root root 3784724 Jan 2 09:43 exdvdplayerd
-rwxr-xr-x 1 root root 3751956 Jan 2 09:43 exdvdvrplayerd
-rwxr-xr-x 1 root root 901140 Jan 2 09:43 exgasdisplay
-rwxr-xr-x 1 root root 4292628 Jan 2 09:43 exhddvdplayerd
-rwxr-xr-x 1 root root 114708 Jan 2 09:43 exvupappd
-rwxr-xr-x 1 root root 3227668 Jan 2 09:43 exlauncherd
lrwxr-xr-x 1 root root 19 Jan 2 09:43 ethromctl.ko -> /tmp/exethromctl.ko
lrwxr-xr-x 1 root root 26 Jan 2 09:43 HDD_MOUNT_POINT.txt -> /tmp/exHDD_MOUNT_POINT.txt
lrwxr-xr-x 1 root root 17 Jan 2 09:43 rootca.pem -> /tmp/exrootca.pem
-rw-r--r-- 1 root root 98388 Aug 31 2006 enexwriter_060317

./usr/local/etc:
total 9
drwxr-xr-x 5 root root 1024 Mar 20 21:46 ..
drwxr-xr-x 2 root root 1024 Mar 20 18:39 .
-rw-r--r-- 1 root root 362 Mar 20 18:39 info.txt
-rwxr--r-- 1 root root 6077 Jul 30 2006 setting.conf

./usr/local/lib:
total 2589
drwxr-xr-x 5 root root 1024 Mar 20 21:46 ..
drwxr-xr-x 2 root root 1024 Jan 2 10:55 .
-rw-r--r-- 1 root root 21120 Jan 2 10:55 libs.so
-rw-r--r-- 1 root root 213028 Jan 2 09:43 exlibsetting.so.1.10
-rw-r--r-- 1 root root 180260 Jan 2 09:43 exlibwmadecode.so.1.1
-rwxr-xr-x 1 root root 122219 Aug 8 2006 libcdaudio.so.1.0.0
-rwxr-xr-x 1 root root 1020971 Aug 8 2006 libiconv.so.2.2.0
-rwxr-xr-x 1 root root 51518 Aug 8 2006 libmp3decode.so.1.2
-rwxr-xr-x 1 root root 1019186 Nov 15 2005 libiconv_plug.so

./usr/bin:
total 649
drwxr-xr-x 2 root root 1024 Mar 20 21:01 .
drwxr-xr-x 6 root root 1024 Jan 2 09:50 ..
lrwxr-xr-x 1 root root 15 Jan 2 09:43 libpng-config -> libpng12-config
-rwxr-xr-x 1 root root 2107 Aug 8 2006 libpng12-config
-rwxr-xr-x 1 root root 593052 Dec 12 2005 fsck.ext2
-rwxr-xr-x 1 root root 18568 Oct 11 2004 setserial
-r-xr-xr-x 1 root root 12636 Sep 28 2004 pkill
-rwxr-xr-x 1 root root 18860 Sep 8 2004 eject

./usr/lib:
total 6415
drwxr-xr-x 6 root root 1024 Jan 2 09:50 ..
drwxr-xr-x 4 root root 2048 Jan 2 09:43 .
-rw-r--r-- 1 root root 114724 Jan 2 09:43 exlibaudiocontroller.so.2.12
-rw-r--r-- 1 root root 32804 Jan 2 09:43 exlibaudiotransfer.so.1.5
-rw-r--r-- 1 root root 65572 Jan 2 09:43 exlibexdvd.so.1.3.2
-rw-r--r-- 1 root root 983076 Jan 2 09:43 exlibgcp.so.4.0.32
-rw-r--r-- 1 root root 65572 Jan 2 09:43 exlibhdmi.so.0.5.0.17
-rw-r--r-- 1 root root 32804 Jan 2 09:43 exlibtossucom.so.1.45
-rw-r--r-- 1 root root 49188 Jan 2 09:43 exlibtsbbackend.so.1.6
-rw-r--r-- 1 root root 1835044 Jan 2 09:43 exlibvideocont.so.003100
-rw-r--r-- 1 root root 32804 Jan 2 09:43 exlibvideotransfer.so.0.5
drwxr-xr-x 5 root root 1024 Jan 2 09:43 locale
drwxr-xr-x 2 root root 1024 Jan 2 09:43 gconv
lrwxr-xr-x 1 root root 33 Jan 2 09:43 libaudiocontroller.so -> /tmp/exlibaudiocontroller.so.2.12
lrwxr-xr-x 1 root root 30 Jan 2 09:43 libaudiotransfer.so -> /tmp/exlibaudiotransfer.so.1.5
lrwxr-xr-x 1 root root 34 Jan 2 09:43 libcdaudio.so -> /usr/local/lib/libcdaudio.so.1.0.0
lrwxr-xr-x 1 root root 34 Jan 2 09:43 libcdaudio.so.1 -> /usr/local/lib/libcdaudio.so.1.0.0
lrwxr-xr-x 1 root root 29 Jan 2 09:43 libcrypto.so -> ../../lib/libcrypto.so.0.9.7a
lrwxr-xr-x 1 root root 24 Jan 2 09:43 libexdvd.so -> /tmp/exlibexdvd.so.1.3.2
lrwxr-xr-x 1 root root 23 Jan 2 09:43 libgcp.so -> /tmp/exlibgcp.so.4.0.32
lrwxr-xr-x 1 root root 21 Jan 2 09:43 libgssapi_krb5.so -> libgssapi_krb5.so.2.2
lrwxr-xr-x 1 root root 21 Jan 2 09:43 libgssapi_krb5.so.2 -> libgssapi_krb5.so.2.2
lrwxr-xr-x 1 root root 26 Jan 2 09:43 libhdmi.so -> /tmp/exlibhdmi.so.0.5.0.17
lrwxr-xr-x 1 root root 32 Jan 2 09:43 libiconv.so -> /usr/local/lib/libiconv.so.2.2.0
lrwxr-xr-x 1 root root 32 Jan 2 09:43 libiconv.so.2 -> /usr/local/lib/libiconv.so.2.2.0
lrwxr-xr-x 1 root root 13 Jan 2 09:43 libjpeg.so -> libjpeg.so.62
lrwxr-xr-x 1 root root 17 Jan 2 09:43 libjpeg.so.62 -> libjpeg.so.62.0.0
lrwxr-xr-x 1 root root 18 Jan 2 09:43 libk5crypto.so.3 -> libk5crypto.so.3.0
lrwxr-xr-x 1 root root 14 Jan 2 09:43 libkrb5.so.3 -> libkrb5.so.3.2
lrwxr-xr-x 1 root root 26 Jan 2 09:43 libmp3decode.so -> /usr/lib/libmp3decode.so.1
lrwxr-xr-x 1 root root 34 Jan 2 09:43 libmp3decode.so.1 -> /usr/local/lib/libmp3decode.so.1.2
lrwxr-xr-x 1 root root 13 Jan 2 09:43 libpng12.so -> libpng12.so.0
lrwxr-xr-x 1 root root 19 Jan 2 09:43 libpng12.so.0 -> libpng12.so.0.1.2.7
lrwxr-xr-x 1 root root 10 Jan 2 09:43 libpng.a -> libpng12.a
lrwxr-xr-x 1 root root 11 Jan 2 09:43 libpng.so -> libpng.so.3
lrwxr-xr-x 1 root root 17 Jan 2 09:43 libpng.so.3 -> libpng.so.3.1.2.7
lrwxr-xr-x 1 root root 19 Jan 2 09:43 libpng.so.3.1.2.7 -> libpng12.so.0.1.2.7
lrwxr-xr-x 1 root root 24 Jan 2 09:43 libresolv.so -> ../../lib/libresolv.so.2
lrwxr-xr-x 1 root root 25 Jan 2 09:43 libsetting.so -> /tmp/exlibsetting.so.1.10
lrwxr-xr-x 1 root root 26 Jan 2 09:43 libssl.so -> ../../lib/libssl.so.0.9.7a
lrwxr-xr-x 1 root root 26 Jan 2 09:43 libtossucom.so -> /tmp/exlibtossucom.so.1.45
lrwxr-xr-x 1 root root 27 Jan 2 09:43 libtsbbackend.so -> /tmp/exlibtsbbackend.so.1.6
lrwxr-xr-x 1 root root 29 Jan 2 09:43 libvideocont.so -> /tmp/exlibvideocont.so.003100
lrwxr-xr-x 1 root root 30 Jan 2 09:43 libvideotransfer.so -> /tmp/exlibvideotransfer.so.0.5
lrwxr-xr-x 1 root root 26 Jan 2 09:43 libwmadecode.so -> /usr/lib/libwmadecode.so.1
lrwxr-xr-x 1 root root 26 Jan 2 09:43 libwmadecode.so.1 -> /tmp/exlibwmadecode.so.1.1
lrwxr-xr-x 1 root root 15 Jan 2 09:43 libz.so.1 -> libz.so.1.2.1.2
-rw-r--r-- 1 root root 169800 Aug 8 2006 libpng12.a
-rwxr-xr-x 1 root root 142648 Aug 8 2006 libpng12.so.0.1.2.7
-rwxr-xr-x 1 root root 63528 Aug 8 2006 libz.so.1.2.1.2
-rwxr-xr-x 1 root root 3350 Feb 16 2006 libcxaguard.so.5
-rwxr--r-- 1 root root 133410 Feb 15 2006 libjpeg.so.62.0.0
-rwxr-xr-x 1 root root 2152277 Sep 13 2005 libimf.so
-rwxr-xr-x 1 root root 82944 Aug 31 2004 libgssapi_krb5.so.2.2
-rwxr-xr-x 1 root root 136044 Aug 31 2004 libk5crypto.so.3.0
-rwxr-xr-x 1 root root 415188 Aug 31 2004 libkrb5.so.3.2

[awhitehead]

Edit: Cant attach (or quote, too big) , but here are a few of the interesting ones:


.:
total 31
drwxr-xr-x 4 root root 4096 Mar 21 13:15 ..
drwxr-xr-x 3 root root 1024 Mar 20 21:51 etc
drwxr-xr-x 12 root root 1024 Mar 20 21:01 .
drwxr-xr-x 6 root root 1024 Jan 2 09:50 usr
drwxr-xr-x 2 root root 2048 Jan 2 09:43 lib
drwxr-xr-x 3 root root 1024 Jan 2 09:43 var
drwx------ 2 root root 12288 Oct 19 03:37 lost+found
drwxr-xr-x 2 root root 1024 Jul 5 2006 NetArea
drwxr-xr-x 2 root root 1024 Jan 19 2006 HD_DVD
drwxr-xr-x 2 root root 1024 Sep 23 2005 STRFLG
drwxr-xr-x 3 root root 1024 Jul 11 2005 share



Neat!

Is /etc on the removable flash as well (It lists as a directory, but you didn't list contents)? If yes, then maybe we can attempt to either replace init outright, or attempt to modify some of the start-up scripts.

(Of course there is a possibility that kernel is not calling /etc/init at bootup. Hrm. But then it's a matter of figuring out what it is that kernel starts up on bootup. There is also a possibility of encrypted/signed binary or some sort of sanity checking performed by the kernel. Hrm.)

[sega32x]

Well, it is, but its filled with all graphics files (why i coulndt list em, its 3x skins by 3x menus, every letter button etc = alot of PNG's, but ill list the root of em!)

I think its a two part system, the unprotected essentials (that wouldnt change, like the kernel, bootloader, crypto stuff), are on the 32mb flash chip, on the underside of the board, and the stuff that does change (like the player executables, images etc) is on the flash drive. Its actually a great idea, two fold, keeps things very secure, and much easier to fix in the event of any kind of upgrade failure etc!

However, it got me thinking, the iso and udf kernel modules are in the clear, if for some reason there not checked, and if we cross compile our own kernel module, that does XYZ (lets say, everything we want), were in business!

The key is to either get that going, or a dump of the other flash, alas, im no good at removing BGA'd chips!

The conf's are just listings of error messages, and XY coords on placement of images, no goodies etc! Sad part is, ive been working quite abit with busybox as of late, and its a great piece of work!


./etc:
total 5
-rw-r--r-- 1 root root 45 Mar 20 22:04 adjtime
drwxr-xr-x 3 root root 1024 Mar 20 21:51 .
-rw-r--r-- 1 root root 60 Mar 20 21:51 resolv.conf
drwxr-xr-x 12 root root 1024 Mar 20 21:01 ..
lrwxr-xr-x 1 root root 42 Jan 2 09:43 localtime -> /mnt/ROM/usr/share/zoneinfo/Canada/Eastern
drwxr-xr-x 11 root root 1024 Jan 2 09:43 image

./etc/image:
total 414
drwxr-xr-x 3 root root 1024 Mar 20 21:51 ..
drwxr-xr-x 5 root root 1024 Jan 2 09:43 1_SetupMenu_old
drwxr-xr-x 11 root root 1024 Jan 2 09:43 .
drwxr-xr-x 5 root root 1024 Jan 2 09:43 1_SetupMenu
drwxr-xr-x 5 root root 1024 Jan 2 09:43 ControlGuide
drwxr-xr-x 2 root root 4096 Jan 2 09:43 launcher
drwxr-xr-x 11 root root 1024 Jan 2 09:43 CD
drwxr-xr-x 5 root root 2048 Jan 2 09:43 COMMON
drwxr-xr-x 6 root root 1024 Jan 2 09:43 DVD
drwxr-xr-x 5 root root 1024 Jan 2 09:43 DVDtitlelist
drwxr-xr-x 4 root root 1024 Jan 2 09:43 pstorage
-rwxr--r-- 1 root root 13758 Jul 26 2006 us_alertparts1.conf
-rwxr--r-- 1 root root 13754 Jul 26 2006 us_alertparts.conf
-rwxr--r-- 1 root root 22210 Jul 26 2006 us_advdvdplayerparts.conf
-rwxr--r-- 1 root root 13549 Jul 26 2006 jp_alertparts1.conf
-rwxr--r-- 1 root root 13545 Jul 26 2006 jp_alertparts.conf
-rwxr--r-- 1 root root 20364 Jul 26 2006 jp_advdvdplayerparts.conf
-rwxr--r-- 1 root root 18313 Jul 26 2006 fr_alertparts1.conf
-rwxr--r-- 1 root root 18309 Jul 26 2006 fr_alertparts.conf
-rwxr--r-- 1 root root 19242 Jul 26 2006 fr_advdvdplayerparts.conf
-rwxr--r-- 1 root root 72268 Jul 11 2006 jp_dvdplayerparts.conf
-rwxr--r-- 1 root root 72574 Jul 11 2006 fr_dvdplayerparts.conf
-rwxr--r-- 1 root root 72119 Apr 28 2006 us_dvdplayerparts.conf
-rw-r--r-- 1 root root 6240 Feb 28 2006 fr_controlguide.conf
-rw-r--r-- 1 root root 6271 Feb 28 2006 jp_controlguide.conf
-rw-r--r-- 1 root root 6256 Feb 28 2006 us_controlguide.conf

./etc/image/1_SetupMenu_old:
total 5
drwxr-xr-x 5 root root 1024 Jan 2 09:43 .
drwxr-xr-x 6 root root 1024 Jan 2 09:43 2_Contrast
drwxr-xr-x 6 root root 1024 Jan 2 09:43 3_Material
drwxr-xr-x 11 root root 1024 Jan 2 09:43 ..
drwxr-xr-x 6 root root 1024 Jan 2 09:43 1_CalmBlue

./etc/image/1_SetupMenu_old/2_Contrast:
total 36
drwxr-xr-x 6 root root 1024 Jan 2 09:43 .
drwxr-xr-x 5 root root 1024 Jan 2 09:43 ..
drwxr-xr-x 2 root root 8192 Jan 2 09:43 fn
drwxr-xr-x 2 root root 8192 Jan 2 09:43 jp
drwxr-xr-x 2 root root 10240 Jan 2 09:43 common
drwxr-xr-x 2 root root 8192 Jan 2 09:43 en

./etc/image/1_SetupMenu_old/2_Contrast/fn:
total 1065
drwxr-xr-x 2 root root 8192 Jan 2 09:43 .
drwxr-xr-x 6 root root 1024 Jan 2 09:43 ..
-rwxr-xr-x 1 root root 1609 Apr 27 2006 bl_text_1_1.png
-rwxr-xr-x 1 root root 3061 Apr 27 2006 bl_text_1_3.png
-rwxr-xr-x 1 root root 2301 Apr 27 2006 bl_text_1_4.png
-rwxr-xr-x 1 root root 2948 Apr 27 2006 bl_text_2_1.png
-rwxr-xr-x 1 root root 3009 Apr 27 2006 bl_text_2_2.png
-rwxr-xr-x 1 root root 3405 Apr 27 2006 bl_text_2_3.png
-rwxr-xr-x 1 root root 3729 Apr 27 2006 bl_text_2_4.png
-rwxr-xr-x 1 root root 3020 Apr 27 2006 bl_text_2_5.png
-rwxr-xr-x 1 root root 3000 Apr 27 2006 bl_text_3_1.png
-rwxr-xr-x 1 root root 2690 Apr 27 2006 bl_text_3_2.png
-rwxr-xr-x 1 root root 2427 Apr 27 2006 bl_text_3_3.png
-rwxr-xr-x 1 root root 2228 Apr 27 2006 bl_text_3_4.png
-rwxr-xr-x 1 root root 1128 Apr 27 2006 bl_text_4_1.png
-rwxr-xr-x 1 root root 2619 Apr 27 2006 bl_text_4_2.png
-rwxr-xr-x 1 root root 1979 Apr 27 2006 bl_text_4_3.png
-rwxr-xr-x 1 root root 2841 Apr 27 2006 bl_text_4_4.png
-rwxr-xr-x 1 root root 1862 Apr 27 2006 bl_text_4_5.png
-rwxr-xr-x 1 root root 2437 Apr 27 2006 bl_text_5_1.png
-rwxr-xr-x 1 root root 2784 Apr 27 2006 bl_text_5_2.png
-rwxr-xr-x 1 root root 3710 Apr 27 2006 bl_text_5_3.png
-rwxr-xr-x 1 root root 3189 Apr 27 2006 bl_text_5_4.png
-rwxr-xr-x 1 root root 2015 Apr 27 2006 bl_text_5_5.png
-rwxr-xr-x 1 root root 965 Apr 27 2006 bl_text_5_6.png
-rwxr-xr-x 1 root root 1794 Apr 27 2006 bl_text_5_7.png
-rwxr-xr-x 1 root root 1390 Apr 27 2006 bm_text_1.png
-rwxr-xr-x 1 root root 1272 Apr 27 2006 bm_text_2.png
-rwxr-xr-x 1 root root 1442 Apr 27 2006 bm_text_3.png
-rwxr-xr-x 1 root root 1450 Apr 27 2006 bm_text_4.png
-rwxr-xr-x 1 root root 1376 Apr 27 2006 bm_text_5.png
-rwxr-xr-x 1 root root 666 Apr 27 2006 bs_text_1_1_1.png
-rwxr-xr-x 1 root root 492 Apr 27 2006 bs_text_1_1_2.png
-rwxr-xr-x 1 root root 1785 Apr 27 2006 bs_text_1_1_3.png
-rwxr-xr-x 1 root root 1069 Apr 27 2006 bs_text_1_3_1.png
-rwxr-xr-x 1 root root 764 Apr 27 2006 bs_text_1_3_2.png
-rwxr-xr-x 1 root root 520 Apr 27 2006 bs_text_1_4_1.png
-rwxr-xr-x 1 root root 927 Apr 27 2006 bs_text_1_4_2.png
-rwxr-xr-x 1 root root 686 Apr 27 2006 bs_text_1_4_3.png
-rwxr-xr-x 1 root root 1417 Apr 27 2006 bs_text_2_1_1.png
-rwxr-xr-x 1 root root 795 Apr 27 2006 bs_text_2_1_2.png
-rwxr-xr-x 1 root root 686 Apr 27 2006 bs_text_2_2_1.png
-rwxr-xr-x 1 root root 1417 Apr 27 2006 bs_text_2_2_2.png
-rwxr-xr-x 1 root root 795 Apr 27 2006 bs_text_2_2_3.png
-rwxr-xr-x 1 root root 2769 Apr 27 2006 bs_text_2_2_4.png
-rwxr-xr-x 1 root root 1069 Apr 27 2006 bs_text_2_3_1.png
-rwxr-xr-x 1 root root 764 Apr 27 2006 bs_text_2_3_2.png
-rwxr-xr-x 1 root root 1069 Apr 27 2006 bs_text_2_4_1.png
-rwxr-xr-x 1 root root 764 Apr 27 2006 bs_text_2_4_2.png
-rwxr-xr-x 1 root root 1025 Apr 27 2006 bs_text_2_5_1_1.png
-rwxr-xr-x 1 root root 927 Apr 27 2006 bs_text_2_5_1_2.png
-rwxr-xr-x 1 root root 1134 Apr 27 2006 bs_text_2_5_1.png
-rwxr-xr-x 1 root root 604 Apr 27 2006 bs_text_2_5_2_1.png
-rwxr-xr-x 1 root root 927 Apr 27 2006 bs_text_2_5_2_2.png
-rwxr-xr-x 1 root root 2416 Apr 27 2006 bs_text_2_5_2_3.png
-rwxr-xr-x 1 root root 1110 Apr 27 2006 bs_text_2_5_2.png
-rwxr-xr-x 1 root root 1111 Apr 27 2006 bs_text_3_1_1.png
-rwxr-xr-x 1 root root 1010 Apr 27 2006 bs_text_3_1_2.png
-rwxr-xr-x 1 root root 1086 Apr 27 2006 bs_text_3_1_3.png
-rwxr-xr-x 1 root root 592 Apr 27 2006 bs_text_3_1_4_1.png
-rwxr-xr-x 1 root root 818 Apr 27 2006 bs_text_3_1_4_2.png
-rwxr-xr-x 1 root root 779 Apr 27 2006 bs_text_3_1_4.png
-rwxr-xr-x 1 root root 831 Apr 27 2006 bs_text_3_2_1.png
-rwxr-xr-x 1 root root 1111 Apr 27 2006 bs_text_3_2_2.png
-rwxr-xr-x 1 root root 1086 Apr 27 2006 bs_text_3_2_3.png
-rwxr-xr-x 1 root root 592 Apr 27 2006 bs_text_3_2_4_1.png
-rwxr-xr-x 1 root root 818 Apr 27 2006 bs_text_3_2_4_2.png
-rwxr-xr-x 1 root root 779 Apr 27 2006 bs_text_3_2_4.png
-rwxr-xr-x 1 root root 1111 Apr 27 2006 bs_text_3_3_1.png
-rwxr-xr-x 1 root root 1086 Apr 27 2006 bs_text_3_3_2.png
-rwxr-xr-x 1 root root 592 Apr 27 2006 bs_text_3_3_3_1.png
-rwxr-xr-x 1 root root 818 Apr 27 2006 bs_text_3_3_3_2.png
-rwxr-xr-x 1 root root 779 Apr 27 2006 bs_text_3_3_3.png
-rwxr-xr-x 1 root root 1111 Apr 27 2006 bs_text_3_4_1.png
-rwxr-xr-x 1 root root 1010 Apr 27 2006 bs_text_3_4_2.png
-rwxr-xr-x 1 root root 1086 Apr 27 2006 bs_text_3_4_3.png
-rwxr-xr-x 1 root root 930 Apr 27 2006 bs_text_4_1_1.png
-rwxr-xr-x 1 root root 788 Apr 27 2006 bs_text_4_1_2.png


It keeps on going, more and more PNG's!

[HyperHacker]

As far as the USB flash drive, it is supposed to be locked with a 64bit RSA key, mine isnt (again, possibly due to the whole bricked unit thing)
64-bit? Isn't that extremely weak?

[sega32x]

Well, that is what the msystems PDF says, however the two I have arent locked at all, and work just fine (odd, I know, but it does!)

I beleive the key to moving forward is getting an image of the data off that 32mb spansion flash, but as to do it, not too sure. Thinking jtag the xilinx chip, but not sure on the pinout for it, and dont have a scope!

[awhitehead]

I finally picked up my HD-A1 today, and verified functionality (used unit). So about to start playing with the firmware on the thing (Pulling down a latest knoppix live DVD as we speak, since I live primarily in Solaris and MacOS world, and don't have a general purpose Linux system).

A couple of questions to sega32x:

You mention booting off a USB key. Did you remove the internal msystems USB flash, and just plugged a USB key with a copy of the image into one of the two USB slots on the front?

Did you dd the image from the internal flash to USB keyfob directly, or actually mke2fs'ed the USB key, and copied the files over? After digging around I can only find a 1 gig and 2 gig USB keys (from back when I used them with Asus wireless AP that run Linux on Broadcom to run general purpose Debian for mips on the thing, instead of busybox), so am curious what your experiences are.

As an aside: Documentation for HD-A1 provides a copy of GPL for Linux kernel and busybox components. So the thing runs busybox, which is great - easy to understand and recompile. Does Toshiba provide their copy of these components (together with libpng, etc) anywhere on their websites? I don't particularly care about GPL violations if they dont (although I should probably care more), but if they provide their modifications, it could help us to figure out what they did.

[sega32x]

1 -> Yes, I did (originally wired up the internal to a socket etc, and wired a usb cable to the msystems key), but then realised i could use a usb key

2-> Yeah, i did a simple DD, however i dont see why a copy of the filesystem etc wouldnt work

3-> Ive heard the same, mine (a new refurb) didnt, but it is not on there site at all, it would be a good start.

Furthermore, did some sniffing on the update procedure, it connects to https://dtv.ivcreation.com, but thats where I lost it, due to the whole SSL and all, and man in the middle attacks arent working yet (im blaming user error on this one!)

I really want to get this wide open, and get my other unit working too, baby steps though, first root access :)

Edit: seems like /usr/local/bin/exlauncherd may be busybox itself, but I am yet to be sure of that, basically, remove that file, and the system wont init at all, and that (3.1mb) is about the size of busybox + a kernel, stripped very light, of course. I also fear that the flash contents are encrypted per box, unless the other flash from the other box I have is corrupt (as the box is non-working!) If so, this just got alot harder.

[awhitehead]

Furthermore, did some sniffing on the update procedure, it connects to https://dtv.ivcreation.com, but thats where I lost it, due to the whole SSL and all, and man in the middle attacks arent working yet (im blaming user error on this one!)


Well, the realistic way of intercepting HTTPS requests is through a proxy (since decrypting SSL session packet captures can be a bit of a headache) . So maybe the way to see what's going on is not through sniffing, but through compiling squid, configuring squid to proxy ssl, and then telling the HD-A1 to use the proxy for net access. Check to make sure that squid generates verbose logs, and you should be able to see at least what the requests are.

Coincidentially, http://www.1080x1920.net/ has the firmware images of 1.2, 1.3, 1.4 and 2.0 firmware for HD-A1. Requires registration to download, though. I poked around the firmware, but it seems that after the header that identifies the hardware platform, there is just either compressed or encrypted binary, so I didn't get anything of interest.

[sega32x]

Yeah, I also have plenty of those, have the header with model number, version number, then a 512bit section (maybe crypto keys? dunno), then some null space, and some kinda crypted binary, just as you said.

But, even if the SSL was intercepted etc, decrypted (or whatever), that might help identify the update file etc, which is probably just as encrypted, so we need to look elsewhere!

[awhitehead]

Quick question:
I am poking at the m-systems flash board. Looking at the pinouts.
(9 on one side, and 5 on the other, you know what I am talking about)
Are the 9 pins just the standard USB 2 pinout, as used on motherboards, etc? In other words, if I plug it right in, I won't fry the flash, right?

The other 5 pins are marked as "NC", which I "translate" as "not connected"

[sega32x]

Yep, exactically, sorry on the late reply, a IM would be easier id bet, but yeah, its 100% usb pinout, I just wired it up!

[awhitehead]

Ok, got the image off of the flash. Thank you for all the advice.

Luckily one of the PCs at home had the USB pinouts on the motherboard that were not too crowded (I had to put the tape on a near-by capacitor to prevent any potential short), so Knoppix CD happily let me dd the device. Cursory fdisk check showed that it's kind of funnily partitioned - partition is flagged as Fat32 bootable (primary), yet the actual filesystem is ext2 (This might be important later on). Out of 256 megs on the flash, 19 are free (2.0 firmware). Gzipped image is ~90 megs.

I'll poke around at it some more tomorrow.

When I had the m-disk in the PC, and was selecting boot device, PC bios offered me a possibility of booting off of it. I didn't at the time, but this looks like something to try.

[jkenzie]

Here are a few links that might be a interest if you don't already have them.

http://www.m-systems.com/NR/rdonlyres/1E31358E-3E13-48DB-960E-61FC37F731EA/0/uDOC_DS_rev23.pdf

http://www.m-systems.com/site/en-US/Support/SoftwareDownload/uDOC_Boot_Files.htm

http://dvd.sourceforge.net/dvdinfo/sprm.html


http://sourceforge.net/projects/ext2fsd

[sega32x]

Yeah, I tried booting here = no luck. But if you can, give it a shot!

[awhitehead]

Yeah, I tried booting here = no luck. But if you can, give it a shot!

Boot block corresponds to boot block generated by Windows 95b/98/ME.
However filesystem on the primary partition is ext2.

On my copy:

00000000 33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C 3.....|.P.P....|
00000010 BF 1B 06 50 57 B9 E5 01 F3 A4 CB BE BE 07 B1 04 ...PW...........
00000020 38 2C 7C 09 75 15 83 C6 10 E2 F5 CD 18 8B 14 8B 8,|.u...........
00000030 EE 83 C6 10 49 74 16 38 2C 74 F6 BE 10 07 4E AC ....It.8,t....N.
00000040 3C 00 74 FA BB 07 00 B4 0E CD 10 EB F2 89 46 25 <.t...........F%
00000050 96 8A 46 04 B4 06 3C 0E 74 11 B4 0B 3C 0C 74 05 ..F...<.t...<.t.
00000060 3A C4 75 2B 40 C6 46 25 06 75 24 BB AA 55 50 B4 :.u+@.F%.u$..UP.
00000070 41 CD 13 58 72 16 81 FB 55 AA 75 10 F6 C1 01 74 A..Xr...U.u....t
00000080 0B 8A E0 88 56 24 C7 06 A1 06 EB 1E 88 66 04 BF ....V$.......f..
00000090 0A 00 B8 01 02 8B DC 33 C9 83 FF 05 7F 03 8B 4E .......3.......N
000000A0 25 03 4E 02 CD 13 72 29 BE 46 07 81 3E FE 7D 55 %.N...r).F..>.}U
000000B0 AA 74 5A 83 EF 05 7F DA 85 F6 75 83 BE 27 07 EB .tZ.......u..'..
000000C0 8A 98 91 52 99 03 46 08 13 56 0A E8 12 00 5A EB ...R..F..V....Z.
000000D0 D5 4F 74 E4 33 C0 CD 13 EB B8 00 00 00 00 00 00 .Ot.3...........
000000E0 56 33 F6 56 56 52 50 06 53 51 BE 10 00 56 8B F4 V3.VVRP.SQ...V..
000000F0 50 52 B8 00 42 8A 56 24 CD 13 5A 58 8D 64 10 72 PR..B.V$..ZX.d.r
00000100 0A 40 75 01 42 80 C7 02 E2 F7 F8 5E C3 EB 74 49 .@u.B......^..tI
00000110 6E 76 61 6C 69 64 20 70 61 72 74 69 74 69 6F 6E nvalid partition
00000120 20 74 61 62 6C 65 00 45 72 72 6F 72 20 6C 6F 61 table.Error loa
00000130 64 69 6E 67 20 6F 70 65 72 61 74 69 6E 67 20 73 ding operating s
00000140 79 73 74 65 6D 00 4D 69 73 73 69 6E 67 20 6F 70 ystem.Missing op
00000150 65 72 61 74 69 6E 67 20 73 79 73 74 65 6D 00 00 erating system..
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000180 00 00 00 8B FC 1E 57 8B F5 CB 00 00 00 00 00 00 ......W.........
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................


My information is based on this (http://209.85.165.104/search?q=cache:KAjjotKficAJ:www.geocities.com/thestarman3/asm/mbr/95BMEMBR.htm&hl=en)
site.

Based on my understanding of how embedded systems tend to work, most likely bootloader loads a kernel from a particular point in the (internal 32 meg?) flash, and passes kernel an argument where the root filesystem (on the m-systems flash?) is, and potentially where init is.

That's why we are having a hard time finding a kernel, as it's just not there.

So most likely what matters more is not the bootblock on the USB key (with which I am going to replace the internal m-systems flash), but the fact that it's the first (or the only) USB mass storage device on the USB bus (at least for now), and that filesystem is on the first primary partition on the disk. Since we can't (yet) change the arguments passed to the kernel, that aspect needs to be duplicated for things to work.

[sega32x]

Alas, I beleive your 100% correct, I thought the same too, and feared it. Our goodies (kernel etc) are in the 32mb flash, and we need a way to get them out. However, I havent a clue, except to "hack" the player, to get root access, there are some symoblic links to /mnt/ROM , im going to assume our ROM is that 32mb flash, not to mention all the links to modules in /tmp , that dont exist.

So, We can assume the boot process may be something like this.
Power on
Bios startup, (Possible, Read Crypto key from HD-DVD drive)
Read the kernel from 32mb flash (and possible decrypt w/ the key)
Mount the first partition on the first USB device
Decrypt and run /usr/local/exlauncherd

All that is done while the player still says "Welcome", and the exlauncherd is running when the HDMI/1080i output etc is shown on screen, then the HD-DVD animation, and then its live.

However, if this is correct, we need to get into this 32mb of flash, which only has three options, pulling and reading the chip (since its a BGA, not very practical), jtag'ing the connected xilinx chip (if it will even work), or the fun alternative, get a shell, and do it that way :)

[awhitehead]

Alas, I beleive your 100% correct, I thought the same too, and feared it. Our goodies (kernel etc) are in the 32mb flash, and we need a way to get them out. However, I havent a clue, except to "hack" the player, to get root access.

So next step is to get access to the system while it's running.

Currently the most promising, at least to me, is the 'eject' binary, that is unencrypted and is located in /usr/bin on the image.

Basically, while I have only a vague idea as to when the rest of the binaries in /usr/bin are run (pkill would run on shutdown, most likely, setserial might not be triggered at all, fsck.ext2 ditto, libpng-* might be
triggered if we are decrypting and uncompressing an ACA menu file, with PNGs in it, or might be used for every aspect of the operation of the player), eject most likely gets run when you press the correct button on the remote.

So this is what my next avenue of attack will be:

Compile stand alone shell (or some other shell that is easy to compile statically), and drop it into /usr/local. Compile netcat, drop it into /usr/local. Write a small C wrapper, that would call netcat and tell it to bind to a port and run sash. Compile the wrapper statically, call it "eject", and drop it in place of eject.

Boot the player, hit eject button, telnet to port, see what waits for us there.

Gotta start somewhere.

You know what's next if it fails, right? Praying that libpng Toshiba used is unpatched, and trying to overflow it with malformed png file. Or recompiling udf.ko with some additional modifications :)



BTW, file returns that the binaries are built under Linux 2.2.5 (or newer? I've not looked at elf signatures in years), however strings on the two unencrypted kernel objects in /share/excalibur/drivers returns

author=Ben Fennema
description=Universal Disk Format Filesystem
license=GPL
vermagic=2.6.10-R040 preempt PENTIUM4 16KSTACKS gcc-3.4

and

license=GPL
alias=iso9660
vermagic=2.6.10-R035 preempt PENTIUM4 16KSTACKS gcc-3.4
depends=


So most likely we are dealing with 2.6.10 kernel.

[awhitehead]

Come to think about it, busybox might be a better sash then sash :-)
sash: http://members.tip.net.au/~dbell/
busybox: http://www.busybox.net/

[sega32x]

I love the method of attack, I only have one issue, does the eject binary even run? As in, we need to start simple, rename the executable (or remove it), and see when eject makes it not work.

I think our manual eject button may not call eject, but more like doing an upgrade, hitting no, and it ejecting the disk = may be it! I will look into that in a few minutes, if so, I hope your compiler is warm :)

[sega32x]

Hrmm, I deleted our fun eject binary, and well, update disk, even the eject button = still work, question is, why are those still there!

[awhitehead]

Very weird. And frustrating. Looking at the various encrypted files (the ones that start with ex*, it seems like some sort of block cypher is used. Not feasible to break, unfortunately.

For a bit I was wondering about /var/spool/cron/crontabs, but it seems unlikely that the unit has a running crond. Maybe worth trying, though.

I have a couple of other ideas, but they are a bit farfetched.

I guess I shall poke around libpng source code, maybe backdooring that is the solution.

[sega32x]

Well, to our benefit, we may be able to replace the libpng modules with older versions (or ones compiled ourselves), and plant in a nice large exploit.

But if we can run the code, it can be run (if that makes sesne). I really want to revert to like 1.2, I'd beleive there would be more remnants mostlilkely, but I am not sure if reverting is possible w/o bricking the unit.

Also need to look into how the box reads data from the 32mb flash. Not to mention the serial port, the southbridge = legacy free, datasheets suggest it uses the LPC bus for most stuff (including COM), its very possible the 32mb flash and xilinx chip is on that bus , which might make it easier, or harder!

[awhitehead]

So this evening I recreated the fileystem on a 1 gig USB flash key (Apacer, but it doesn't matter), and yanked the internal m-systems flash out. Indeed, all system cares about is for the data it expects to be on the first partition, and partition to be formatted ext2.

After that I tried to give the thing an IP, and spent about an hour cursing at the f*&^en mac os, that ships with bloody non-standard DHCP server. Of course I want to hand the HD-A1 an IP address, but not let it connect to internet yet. This way I can sniff all traffic going through. Didn't get anywhere as bootpd wasn't cooperating (and mac os x one ships with some weird dialect of bootpd, that doesn't use the normal /etc/bootptab and /etc/dhcptab). Eventually she who must be obeyed told me that she wants to watch a movie, and that I should let it go for the night.

So I'll poke around at it some more tomorrow, once I compile ISC dhcpd on the macbook.

In the meanwhile, here is what the DHCP packet looks like:

22:41:48.063928 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], length: 576) 0.0.0.0.bootpc > broadcasthost.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:0e:7c:d4:02:fe, length: 548, xid:0xf4337f74, flags: [none] (0x0000)
Client Ethernet Address: 00:0e:7c:d4:02:fe
Vendor-rfc1048:
DHCP:DISCOVER
CID:[ether]00:0e:7c:d4:02:fe
VC:"udhcp 0.9.9-pre"
PR:SM+DG+NS+HN+DN+BR


Google search for udhcp results in top hit leading to busybox.

Unit tries three times during bootup (before the HD-DVD logo shows), and then 3 more times about 30 seconds later. After that it stops (there might be a way to trigger DHCP requests through the menus - I didn't try).

Re: Rolling back the firmware: Sadly I got mine with 2.0 pre-installed (And probably would have had to upgrade pretty soon - SWMBO wanted to watch some HD-DVDs that were created using standard authoring support, which got supported in 2.0). However, /usr/local/version.conf contains this:

USER=T
LANGUAGE=E
HARD=HD-XA1
VERNUM=2.001N
MODULE=0001


One experiment I am thinking about, is manually decreasing the number to 1.4, and telling the unit to attempt an update, and see what happens. It the unit happily upgrades, then it's maybe possible to also downgrade it using a CD-R.

Question: Are all HD-A1s encrypted with the same key, or is the key host specific (might even be the MAC of the NIC, or the drive serial number or the USB device serial number, it's there and it's different)? Anyone who has a copy of the firmware wants to do some comparisons? I can privately send my image. If the key is unique, then how are the update images rolled out? Encrypted with Toshiba key, they get decrypted and re-encrypted?

[sega32x]

Very nice read, I heard an update will take (even a downgrade) w/o mucking with the FW version numbers, but that you loose HD-DVD playback (until you reupgrade possibly), so I have yet to go that far.

Well, we can trade if you want, but I am nearly 100% sure they are different per box, which is bad. I can only assume that the files are stored encrypted on update disk, decrypted, then reencrypted with the key, as you say, which isnt that well.

I have made a little progress however, the udf and isofs kernel modules, delete them, disks wont read, replace them, they do. I have been able to (for now) a simple hex edit, change a few lines of plaintext, and they still work. Which would possibly mean theres no check, or crc etc. I am working on installing 2.6.10 kernel source, and will recompile the module, if it works, we just might have a way in!

Since the motherboard, HD-DVD , and contents on the flash are tied per key, I am really thinking its on the idea of the 360 , key in the dvd drive, key for the flash etc, however this case, the key would not be in the CPU, which is a start. If the HD-DVD drive is not plugged in, the unit fails to boot, so, we can hope thats where its stored, and we can dump that FW possibly too!

[awhitehead]

If you go into setup, ethernet, ntp server, and toggle that option off and on again, unit starts initiating connections to dtv.ivcreation.com (Hrm. Maybe a static /etc/hosts entry, pointing at a system controlled by me?) , and portscan reports that port 10570 is now open, and listening.

Since I did the portscan from the system that also acted as a DNS server and DHCP server for the unit, it's possible that it's still waiting on a DNS reply, etc, however opening port 10570 is a consistent behavior across reboots.


root@hostname:/opt/nmap/bin[03:10 PM]# ./nmap -v -sS -p 1-61337 -O 192.168.2.8

Starting nmap 3.93 ( http://www.insecure.org/nmap/ ) at 2007-03-24 15:10 EDT
Initiating ARP Ping Scan against 192.168.2.8 [1 port] at 15:10
The ARP Ping Scan took 0.03s to scan 1 total hosts.
Initiating SYN Stealth Scan against 192.168.2.8 [61337 ports] at 15:10
Discovered open port 10570/tcp on 192.168.2.8
The SYN Stealth Scan took 52.66s to scan 61337 total ports.
For OSScan assuming port 10570 is open, 1 is closed, and neither are firewalled
Host 192.168.2.8 appears to be up ... good.
Interesting ports on 192.168.2.8:
(The 61336 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
10570/tcp open unknown
MAC Address: 00:0E:7C:D4:02:FE (Toshiba)
Device type: general purpose
Running: Linux 2.4.X|2.5.X|2.6.X
OS details: Linux 2.4.7 - 2.6.11
Uptime 0.004 days (since Sat Mar 24 15:05:35 2007)
TCP Sequence Prediction: Class=random positive increments
Difficulty=4807373 (Good luck!)
IPID Sequence Generation: All zeros

Nmap finished: 1 IP address (1 host up) scanned in 57.847 seconds
Raw packets sent: 61353 (2.45MB) | Rcvd: 61351 (3.07MB)
root@hostname:/opt/nmap/bin[03:11 PM]#


Yes, I tried connecting to it, but I have no idea what it expects after connection is opened. Standard HTTP and FTP commands and random ascii strings did not result in anything. Googling for what usually binds to port 10570 didn't return any obvious/useful results, although I didn't check IANA port allocations database.

P.S. I've tried to subvert the ntp update script, using the logic that files with prefix "ex" are actually decrypted first, and then executed, as opposed to decrypted on the fly. So far, that proved to be wrong, but I don't know if that's because I wrote bad scripts, compiled binaries that are unliked by OS, or something else.

[sega32x]

Well, the dtv.icreation.com site, a fake DNS entry would be simple to do (arp poisoning anyone?), or even just changing the DNS servers, the issue is it (on update, dunno on others, didnt sniff) tries to go over HTTPS.

But, looking through my capture, it contacts a dns server, gets the IP for that site, and runs from there, however, very nice find at that open port, its the first one!

I am nearly sure we can throw in a hook in the isofs or udf kernel modules, the problem is, I am not that skilled w/ asm (im only good with editing stuff to bypass, not go externally). Ideally, we could create a dev enviroment thats nearly 100% the same, and go from there, but if any modifications were made to there code, they would fail to compile, and run (it seems).

About that port, google suggested some sorta VPN, seems terribly illogical for something like that, but a port is a port is a port!

Edit: What I find really interesting is the fact that you got an OS hit etc off of that port, with ports closed, I couldnt get a thing!

Edit 2: Got a hit off the same port, so its not a fluke! Key is, what is that port!

[awhitehead]

I am nearly sure we can throw in a hook in the isofs or udf kernel modules, the problem is, I am not that skilled w/ asm (im only good with editing stuff to bypass, not go externally). Ideally, we could create a dev enviroment thats nearly 100% the same, and go from there, but if any modifications were made to there code, they would fail to compile, and run (it seems).


I thought about it myself, and recompiling the kernel module for the iso 9660 filesystem is not that hard (I'd rather touch that, then patched UDF 2.5 kernel extension). Problem is that then we have access to the system in the kernel mode, and kernel mode is significantly different from user mode (I never coded anything in Linux kernel mode), since you have access to kernel memory, and can easily hose the system, switching from kernel mode to user mode (so as to, for example, run a service binding to the network port) is pretty complicated.

Seriously, I'd still rather try to replace the libpng, since we have a rough idea when PNGs get loaded (when we trigger setup, or when we put in an HD-DVD with menus, or during the bootup, when it shows a nice picture of HD-DVD logo), and it's already in a user mode, but running with root priviledges.

Edit: Maybe first step is to just add an extra routine to the libpng procedure that decodes the image, and in process runs a system call, outputing results of uname -a; ps auxww; dmesg and friends to a file in /usr/local. Then we can yank the flash, and just read it, and then re-compile it again with additional information that is now known.


About that port, google suggested some sorta VPN, seems terribly illogical for something like that, but a port is a port is a port!


It would make sense that any and all data transfers from toshiba's update site would be encrypted/tunnelled. So it just might be the VPN


Edit: What I find really interesting is the fact that you got an OS hit etc off of that port, with ports closed, I couldnt get a thing!
System only opens this port when I toggle the NTP service off and then on again. Could you try and see if it works for you? In my case HD-A1 had limited IP connectivity - I handed it IP over DHCP, however I didn't give it a route to the internet.

[sega32x]

Well, I just did some scanning, that port opens upon going into the DHCP menu (enabling), and also when I am in the NTP setting menu, but going into system update etc, it closes!

Edit: Just did a DNS hijack to my own SSL server, its refusing the certificate, that isnt too good!

[sega32x]

Well, downgraded to 1.2, HD-DVD playback broke (of course), replaced w/ 2.0 executable (hddvd player that is) , no luck, edited config files for proper version and drive/aacs numbers = nothing.

However, stick my 2.0 flash usb stick in there, everything works fine!

Seems 1.00 will be the best, if we can get ahold of it (alot of extra files on the root, stuff for the VFD display etc), but alas, no upgrade disk for that :/

Edit: Same ports are open, seem it opens up only while in setup = hrmm!

Edit 2: Went to upgrade to 2.0, player bricked, went to 50% and died! = @_@, luckily I kept a backup of the flash, all still works (at 2.0!)

[sega32x]

Well, lets bump up a thread, with some more info, player works again (as before)

Seems theres a LPC -> super IO chip on the XA1, backside, but havent a clue as to what it is (anyone?)

Also, seems the northbridge has an active VGA output (but not used), it may be possible to tap and view the output of that, for possible debug messages etc (anything would be a help!) However doing that = tough, need to sort the BGA pinout, wire it up to a cable etc = a pain, as the points are very small, and they dont adjust well (as its on the bottom of the board!)

[gonesuper]

Hi guys i've been reading ur posts as i have a damaged rca version of the player (a rebadged xa1)

I'm in the uk so a failing stepdown transformer blew out the players power supply. I've repaired this but my system is hanging at boot prob due to a corrupt flash. would it be possible to use ur dump to reimage mine.

I also took out the hd-dvd drive to see if i could use it for movie viewing coupled with vista and anydvdHD but the drive wouldn't read any disk i put in. be it cd dvd or hd-dvd. Vista sees it fine and know its a hd-dvd drive but won't see any disks in it

I think a binflash dump of this drive would have me running again if any of u have access to one.

After reading ur progress i'm very intersted in trying to help out as i see a hacked linux kernel or a machine runing anydvd hd as a way of getting 1080p from this machine.

If any of u can offer a copy of the dumped hr-1100a firmware and/or the dumped flash files then i'd be glad to try and further ur progress with the aid of my hopefully repaired machine.

[sega32x]

Thanks, but the issue is that the HD-DVD drive, the motherboard, and the flash are all keyed to eachother, even with our dumps of the drive and flash, yours still will not work, until we can figgure out how to reprogram the motherboard :/

[gonesuper]

i'm pretty sure the hd-dvd firmware will be identical. tho i see ur point with the flash drive.

i've been playing about with mine today and it seems to be booting now. it had a hand shake issue and was stuck on hdmi 1080i but the drive still won't read discs.

If i had a firmware dump then i could compare it with my drives dump in windows and see if i can flash it to get disc access back.

According to other forums normal dvd playback works but with my drive it says unrecognised disc. It still seems to know if disc is iso9660 or udf and also disc size but no fille access is possible.

Have u tried the HR-1100a in windows?

[sega32x]

Have yet to dump the drive (got two here, a working A1, and a Broken!), It may be possible to do it however!

What Firmware are you running on? if it was upgraded to 2.00, then downgraded to like 1.2, it wont read disks (usually).

However, if your bored, take out the motherboard, flip it around, there is an 86 pin chip near the top left, can you take a picture of it? Its the LPC interface chip (to provide the serial port, among other things, like a floppy drive, keyboard etc!)


Edit: Just tried it, alas it shows the drive as unsupported, ideas?

[gonesuper]

ok got the drive out to dump drives firmware with binflash. when i plug it into windows it works fine. dvdinfo reports its as a hd-dvd drive and all the specs match what i have found on the web. just the disk access seems to be the problem.

my machine was updated to 2.0 using an iso i got from 1080x1920.com as mine is an rca machine the network update only gives ur there approved file which is 1.4 or there abouts the toshiba dvd update works fines tho

I think i can see the lpc port on the main board. i'll get some pics uploaded later this afternoon

[awhitehead]

(I am still around, however being exceedingly busy with finals, and with life in general. But I am continuing to tinker with HD-A1 on and off, and am still reading this thread)

ok got the drive out to dump drives firmware with binflash. when i plug it into windows it works fine. dvdinfo reports its as a hd-dvd drive and all the specs match what i have found on the web. just the disk access seems to be the problem.


gonesuper, could you clarify a little thing for me?
When you say "disk access seems to be the problem", do you mean that if you plug the HD-DVD drive into a PC, it will be detected, but PC will not read HD-DVD disks? If that's the case, could it be lack of the UDF 2.5 filesystem driver (Look in the sticky in the Decryption forum, called "HD-DVD (and Blu-Ray) decrypting tools" for a pointer where to find the drivers for XP and for Linux)?


my machine was updated to 2.0 using an iso i got from 1080x1920.com as mine is an rca machine the network update only gives ur there approved file which is 1.4 or there abouts the toshiba dvd update works fines tho

In one of the threads on avsforums it was mentioned that if you have an RCA rebadged Toshiba, you can call up Toshiba technical support, and they will send you a "special" disk, that will remove the RCA rebadging, and make it behave like a normal OEM Toshiba unit.


I think i can see the lpc port on the main board. i'll get some pics uploaded later this afternoon

Myself, I am waiting for 2.1 firmware for the first gen players to come out, in hopes that it will provide further insight in the system.

We know that the two unencrypted kernel modules - udf.ko and isofs.ko are being used, since the system doesn't mount respective disk types if these kernel modules are absent. I loath touching these, however, since my Linux kernel kung-fu is very weak.

In the meanwhile, I am still confused if the binaries in /usr/bin are actually used. sega32x tested the effects of removal of eject binary, and concluded that /usr/bin/eject is not being triggered by anything.

I suspect that /usr/bin/setserial and /usr/bin/pkill are dead end as well, since there is no serial in the HD-A1 (OK, there is a serial port in HD-XA1, so you might be able to get further along there), and pkill, if used, is likely used only during shutdown routines (Although pkill *MIGHT* be useful to try replacing, since even during shutdown it can do exciting things, like dump process listing, dmesg and list of kernel modules to disk)

It is possible that fsck.ext2 actually does get run by the system in some situtations, and thus can be useful, however.

I've been toying around with an idea of generating a linux filesystem, using tunefs to force it to be fscked next time it gets mounted. This should trigger fsck.ext2. But then what? Burn it onto a CD, and put CD in the player? Technically nothing forces one to use UDF or ISO9660 filesystem to store data on CD or DVD, so ext2 filesystem should work.

So many unknowns, and I have so little time until I am done with finals..... :(

[gonesuper]

When i say i have no drive access what i mean is when i put the HR-1100a in my desktop pc the drive is seen be windows xp and vista but no disks can be read. As far as any software reports the drive is fine and has all functions working but when i try to put any disks in it they fail to read.

I believe this is because my firmware is corrupt from the above meantioned power fault and the main reason why i'm looking for a binflash firmware dump.

This thread (http://www.avsforum.com/avs-vb/showthread.php?t=667995) shows that when the poster tried the same thing with his windows pc, dvd and cd access was fine but no hd-dvd access was avalible. I have both xp and vista machines here so i've been able to try it with the vista udf driver and the generic xp udf driver thats doing the rounds but there is still no change.

Up until the power supply problem the player was working fine on the toshiba 2.0 update so i don't really have any concerns there. If i wait for the 2.1 update is it likely to reflash the drive firmware or just the os side of things?

[awhitehead]

If i wait for the 2.1 update is it likely to reflash the drive firmware or just the os side of things?

Honestly, I don't know. Technically flashing a drive firmware is not a complicated process: You need to have a firmware file, and then send the CDBs to the drive to get it into flash mode ("Boot mode" on Toshiba drives, don't know what NEC uses), and then send a bunch of vendor specific CDBs intermixed with firmware. Since Linux allowes you to compose arbitrary CDBs, and send them to the drive....

The point of the above is that if you have a firmware image and know the vendor specific CDBs, it's not that complicated to flash a drive. So I don't know. If Toshiba has a reason to flash a drive, they probably will.

Here might be something to try:

You have your NEC HD-1100a in a PC, right? It gets a drive letter assigned, right? Can you try KenD00's dumpvid.exe (http://forum.doom9.org/attachment.php?attachmentid=6824&d=1171837753), and see if you get anything in the file bca.bin?

Dumpvid is supposed to get you the first 8 bytes of the 16 byte volume id (that you need to decrypt the AACS on HD-DVD), but here it can be used to test if the drive actually deals with AACS mandated commands properly. If it does, then there is probably a vendor specific firmware that is used by the Toshiba. If it doesn't, then maybe indeed your drive got it's firmware scrambed (but how? it's not that commonly written to).

Just thinking out loud.

P.S. Here is the bca.bin generated on "Relentless Enemies" HD-DVD.

10011104481200001002100840000115
20072036000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
000000000000000000000000


the bytes 40 00 01 15 20 07 20 36 are the first 8 bytes of 16 byte volume id

You should get something similar, where the first two bytes of the 8 byte ID is generally 40 00
to the best of my knowledge.