Examining the 8 files.

One of the 8 files extracted during the last blog entry is called "install_ide_pvrbox_pc_v2"

Well, this file has the familiar 3 letter word at the beginning... ELF!

Hmm, sounds like something that will install the PVR utilities... So I thought about it for a second, realized I had nothing on my SPP to lose right now anyway, so I went ahead and ran it.

PVR BOX from PC install v2 0......Aug 28 2008 19:05:32
It goes through a script and ultimately fails at the end. What it was trying to set up and run (which failed because I was logged into a drive that had mounted partitions) was the basic partitions that the screenplay starts with. So this is probably used for the initial setup to do everything required to set up the drive for the firmware installation. In fact, looking at the file in HxD, I see a bunch of interesting text. One seems to suggest that it can set up a FAT partition. So there may be some way to tell it to add PVR yet...

But this was also interesting: "tar -xjvf /mnt/hdc/ext3.img -C /mnt/hdc.ext3"
That is just a reference to the tarball in the install.img file. But that proves that his program is the one responsible for the update once you turn on the player after you've installed a firmware.

Video_firmware.bin is another one of the files in that set of 8. And I believe it is probably the microcode that gets flashed into the RTD 1262 chip itself. My basis for that belief is that if you look at the file using HxD in 16 bytes per row, you will find a graphical representation of the numbers 0-9, and then references to the decoders, MPEG-2, MPEG4, GOP, JPeg, YUV/RGB888/RGB565 -- these are all terms associated with encoders and decoders. My guess is that this will be the file we'll have to change to add H.264.

The GetUSBDev.dll, GetUSBDev.dat, and DeviceInfo.dll are probably just associated with hooking up to the ScreenPlay from the PC and transferring the information on. Arial.ttf, a font, is found on the screenplay itself, so it may just be there for when the installer wants to write some letters to the screen, such as "do not turn off".

That's all for now.

Cracking the upgrade.bin file

I needed to detail what I found out about the upgrade.bin file and how. If you want to know the format, just jump to the end of this post. I'm going to detail how I figured out the format.

For hacking this, HxD is one of the best programs in the world. And free, too!!

I set it to view 16 bytes at a time, both ascii and hex. Programmers like alignment on powers of two, and this is a very common one.

Right away, I see filenames near the beginning. And appearing in a fixed pattern too. The pattern repeats itself every 0x40 (64) bytes. It appears to start at 0x20, so there's some sort of header we'll have to decipher before that. But lets finish with the file structure.

Obviously the filename starts at offset 0x8 in that file structure. All of them are 24 bytes or less, and everything else is zeroes. So that remainder could be reserved for longer filename, but we don't know that for sure. The first part would have to identify where in the upgrade.bin it is, and how long it is. So looking at the easiest one: ChangeNote.txt. This is the easiest because it is searchable text. So we look through the file and find the text at the end of the file. Going back from the end, we find that the text likely starts at position 0x024a2ff8 in the file. Looking at the bytes before the filename we have f8 2f 4a 02 f9 08 00 00. At this point, it's pretty obvious to me. That's a simple lo-byte/hi-byte storage of the position first as a dword (32 bit), and if we apply that same thing to the second dword it's 0x000008f9, or 2297 bytes. That appears to be the length of the file.

So now to look at the header bytes. Based on the format of the file size and location, let's look at this as a group of dwords.

There a dword for 8. There's 8 files. Probably the number of files.

Nothing else seems familiar.

Looking at the differences in hex between the R1 and R1.1 upgrade.bin files, I see a change in offset 0x08-0x0b and another one at 0x10. Nothing else in that header changes. So those could easily be two different checksums. So I use HxD to highlight from 0x220 to the end of the file and calculate the checksums. Nothing matches. Hmmm. The checksum might include the file names and sizes. So I highlight from 0x20 to the end of the file and select to calculate the checksums. Checksum-32 FB4B0c59, it's a match with the 3rd dword! Doublecheck with R1.1 and it's a match! Ok, that solves part of the problem. Now, what about this one byte change at 0x10...
I change it in HxD and start DataInstaller.... The firmware package version number changed. So there we have it! Appears to be one word long that represents the number to the right of the decimal. Playing with the word at 0x0c, that appears to change the version to the left of the decimal.

Change the first dword and try to run. It says "Upgrade.bin not firmware update package, please check it then try again!" Ok, so this is a magic number for identifying the file. Tried it with the second dword. Same thing. Tried it with the other unknowns dwords. No change. Hmmm, well that's all I can research for now. So this is the structure as I've decoded it so far. I've written a small C program to extract out the individual files.

struct Header {
dword magic1 = 0x075bcd15
dword magic2 = 0x00002710
dword checksum
dword majorversion
dword minorversion
dword unknown1 = 0x00080001
dword unknown2 = 0x00000003
dword NumberOfFiles
}

struct FileList[8]
{
dword offset
dword FileSize
char FileName[24]
char Unknown[32] // this may be part of the filename, but none of the upgrades use it yet so it's not guaranteed.
}

Checksum is calculated by adding all of the bytes together, tracking up to 32 bits (ignoring overflow).

Super has indicated in the comments of "fun with player" that inside the upgrade.bin file is a tarball of the first partition. This is actually embedded in the "install.img" file that comes out of the upgrade.bin. You can find the start of the tarball by looking for it's magic number "BZh9" which is at position 0x0854216 of the upgrade.bin file for R1 firmware, or 0x0674cc6 in the install.img file.

Here's the source code & executable for extracting out the 8 files in the upgrade.bin file. http://www.box.net/shared/3dn0szidjs
Whatever directory your current directory is when you run the executable is where the extracted files will end up. You specify the location of the upgrade.bin file on the command line.
For example:
split c:\upgrade.bin

Edit: Something else I figured I'd mention. When you run the firmware installer, it extracts those 8 files to c:\documents and settings\yourlogin\Local Settings\Temp\DATA and so there is another easy way to get that. When it's done or you click cancel, it automatically delete those files.

PROFTP

Just a quick note that I didn't mention. In that recently posted toolchain, I have the PROFTPD file compiled. It does run, and even starts up the way it is supposed to. I haven't taken the time to figure out all of the configuration requirements. But here are some:

1) addgroup nogroup
2) adduser ftp
3) move proftpd.conf file to /etc directory
4) make directory /home/ftp
5) make directory /var/ftp (this might not be right. I'm doing this from memory. And I was equipped with fuzzy memory. Oh, wait, that's fuzzy logic. Nevermind. There was some directory here that needed to be created).
6) Copy the S50proftpd file to the /etc directory, switch to the etc directory and type ./S50proftpd start to get it started, stop to stop it, restart to stop and start it again.

There's more required, but I didn't get to it. I'll probably try again another day. Just ran out of time before I got it totally working. If you run syslogd you can capture more information about the error messages it runs into.

G++ toolchain fixed

I finally found the headers I needed for g++. They were in the buildroot, but were not being copied to the root for inclusion in the toolchain. I had tried copying them before, but I must have copied the wrong ones. Tried again and this time it worked. So here's the new uclibc 2.6.12.6 toolchain for mipsel.

http://www.box.net/shared/cmtngtrfjn

One note on the g++ -- you need to make the libraries available before you can run anything you compile. Those libraries are in the usr/lib of the ext2. Create a symbolic link of that called /usr/lib and you won't have to copy it. Of course, if you want to distribute any g++ compiled program, you'll need to include that library as well or nobody else will be able to run it. You can probably link it in to the executable somehow.

edit: To get the compiled c++ programs to work, I had to copy libgcc_s.so.1 and libstdc++.so.6.0.9 to the /usr/lib directory, and also do the symbolic links of libgcc_s.so to libgcc_s.so.1 and libstdc++.so and libstdc++.so.6 to libstdc++.so.6.0.9.

I also got a chance to try out some stuff with an ext3 formatted hddmedia partition. And it was way worth it.

I used symbolic links to hook up folders from my USB drives. As a result, all of the information available on those drives appears under my main ScreenPlay Pro drive when I'm browsing. So I don't have to exit to the menu and go to the USB directory. And its allowed me to create simple categories for finding the movies by placing those categories at the root level.

This is something that I think would work really well as a web page, so I'm going to try to create something like that to make it easy to do symbolic links. And while I'm at it, I might as well make it intelligent enough to allow downloading those files and, in the case of a VIDEO_TS directory, automatically create a tarball of the entire directory for download when you click on it.

Fixing the Norton Internet Security problem, and an improved toolchain

At the request of cybermomo, I rebuilt the toolchain with g++ support. All non-windows binutils were already included. So I threw in a bunch of other utilities while I was at it. I haven't yet made this available.

I decided to tackle the issue of the Norton Internet Security problem. For those not familiar with the problems it has with the screenplay (of which neither side wants to fix): The ScreenPlay uses an older kernel driver. The NIS 2009 version of the program makes some change to the NTFS partition on the screenplay EVEN IF YOU EXCLUDE THE DRIVE and makes it so that the kernel driver can't read it anymore. So then when you boot the screenplay pro hd, it just sits there flashing at you.

The easiest way to solve this is to move over to the newer NTFS-3G driver, which will solve a bunch of other problems with the NTFS driver too. So I included that as well. Unfortunately, the buildroot needed several adjustments before I could finally include the driver. It required wchar support, so I had to rebuild the uClibc libraries with that. I had to adjust it to use the latest stable version of NTFS-3G. Then it was just a matter of figuring out how to install it into the existing screenplay. That's where I ran into trouble.

Apparently the NTFS-3G is requiring a fuse.ko module. I believe that's only going to be possible if I rebuild the kernel. I'm not sure if there's any other way around it. However, I'm just not familiar with the kernel modules and how to create them. So I'm somewhat stuck there.

I also tried reformatting the drive with the 8 partitions to see if it would mount the 6th partition under the livepause as it tries to do when you start dvdplayer. Unfortunately, it did not. I would format the partition as ext3, and it would turn around and do a mkudffs on it, and then try to mount it and fail. At least, the output appearing was similar to when you run a mkudffs.

So not very much success this time. I'm in process of reformatting my NTFS partition as EXT3 to do some other experiments.