Hacking the Salora HDD2510

Well, not much news lately, I was very busy with other things. Anyway, I bought a 500 GB hard drive, and put it in the Salora. It works! More later… 

I made 5 short recordings one the 2GB disc.  Below is the log of directory entries, followed by the interesting fields of the name entries. Followed by some analysis of the recorded data.
Field n2[8] contains the recording quality (sp=2,sp+=3,lp=4).

The MPEG data is recorded in 16MB blocks starting at adresses 0x….71ee00. When more than one MPEG block is needed the next one is apparently the previous 16MB block on the disk.


entry: 1 address: 0x5b006300 name: /rtav/VOB00001.ttm
entry: 2 address: 0x59006300 name: /rtav/VOB00001.vtm
entry: 3 address: 0x58006300 name: /rtav/VOB00002.ttm
entry: 4 address: 0x5a006300 name: /rtav/VOB00002.vtm
entry: 5 address: 0x59006300 name: /rtav/VOB00003.ttm
entry: 6 address: 0x5b006300 name: /rtav/VOB00003.vtm
entry: 7 address: 0x5e006300 name: /rtav/VOB00004.ttm
entry: 8 address: 0x5c006300 name: /rtav/VOB00004.vtm

With a recording experiment on an almost full disk, I found that recorder videos are clipped up in parts of 8 minutes 59 seconds when recorded in long play. These parts are actual split entries in the menu. Does this mean that videos are always stored in consecutive blocks? Would be weird, because the first block is not at the end…

Don’t know yet how this relates to the earlier directory entries, but further on the disk, there’s a list of tv-shows, including the names of the shows and the names of the channels (both in plain ascii, or maybe UTF8). Each name entry has a size of 8192 bytes (wow!). After some hexdump staring, I found the following data structure:


typedef struct _tfs2_name_entry
{
uint32 some_numbers1[4];
char title[64];
char station[80]; // 5 bytes + '\0'
uint32 some_numbers2[24];
uint32 some_numbers3[128][6]; //var length list of groups of 6 ints
uint32 some_numbers4[304][4]; //var length list of groups of 4 ints
} TFS2_NAME_ENTRY;


So, it starts with 16 bytes of something with a lot of zeroes in it. Then we have the title you enter when programming a tv-show in the timetable, there’s space for 64 bytes although you cannot enter more than 8 I believe (except when you rename a title, duh). Okay, then there’s the name of the tv station. The station name contains 5 characters, unused ones become spaces. The remaining 75 characters are zeroes. Then there are 11 32-bit integers containing some data followed by 13 integers that I all found to be 0. After that there are 2 things that look like variable length lists. The first list consists of up to 128 groups of 6 integers, the second list contains up to 304 entries of 4 integers. Each name has at least one entry for both lists, in most cases only one. Maybe the exceptions are videos I clipped or merged?

I wrote some tooling to visualize it:


entry: 0 title : Title 0 station: V8
n1 1-tuples[0]:01000100 [3]:00011d00
n2 1-tuples[0]:1f01d807 [1]:000a2514 [8]:00000400 [9]:00010050 [10]:09014000
n3 6-tuples[0]:00000300 00000000 00000000 a84c0000 00000000 a84d1d00
n4 4-tuples[0]:00000100 00000000 00000000 a84c0000
entry: 1 title : Title 1 station: DISCO
n1 1-tuples[0]:01000100 [3]:00d44900
n2 1-tuples[0]:0509d707 [1]:003b2e15 [8]:00000200 [9]:00010050 [10]:09014000
n3 6-tuples[0]:00000100 00000000 00000000 a84c0000 00000000 a8204a00
n4 4-tuples[0]:00000100 00000000 00000000 a84c0000
entry: 2 title : Title 2 station: NED1
n1 1-tuples[0]:01000100 [3]:00d20f00
n2 1-tuples[0]:0101d707 [1]:00240a0c [8]:00000200 [9]:00010050 [10]:09014000
n3 6-tuples[0]:00000100 00000000 00000000 a84c0000 00000000 a81e1000
n4 4-tuples[0]:00000100 00000000 00000000 a84c0000
entry: 3 title : Title 3 station: NED1
n1 1-tuples[0]:01000100 [3]:402c6600
n2 1-tuples[0]:0101d707 [1]:00230b0c [8]:00000200 [9]:00010050 [10]:09014000
n3 6-tuples[0]:00000300 00000000 00000000 68c71000 00000000 a8f37600
n4 4-tuples[0]:00000100 00000000 00000000 68c71000
entry: 4 title : Title 4 station: S-014
n1 1-tuples[0]:01000100 [3]:c0d82a00
n2 1-tuples[0]:0101d707 [1]:0028150c [8]:00000200 [9]:00010050 [10]:09014000
n3 6-tuples[0]:00000200 00000000 00000000 a84c0000 00000000 68252b00
n4 4-tuples[0]:00000100 00000000 00000000 a84c0000
entry: 5 title : Seinfeld station: V8
n1 1-tuples[0]:03000100 [3]:00059100
n2 1-tuples[0]:0b09d707 [1]:00013713 [6]:00000500 [8]:00000200 [9]:00010050 [10]:09014000
n3 6-tuples[0]:00001800 00000000 00000000 28cf4800 00000000 28d4d900
n4 4-tuples[0]:00000100 00000000 00000000 28cf4800
n4 4-tuples[1]:00000100 00000201 00000000 58a45200
n4 4-tuples[2]:00000100 00000200 00000000 68365600
...


The n1-n4 are the numbers1-numbers4 integer arrays. Only the non-zero tuples are shown. Interesting, isn’t it?

I have 209 filled in names entries, while the directory only showed 108 undeleted records.. So apparently, the names are not one-to-one related to the directory entries.

More decoding later, I guess the date and time should be in here as well, and maybe a pointer to the MPEG data?

When trying to write a tool to display the directory info, I found something interesting. Apparently, the harddisk (probably it’s an IDE property) doesn’t like to be seeked or read at addresses that are not 512-byte aligned. After adapting for that the tool worked, but showed some directory entries that had a name but no ‘address’, and some had no name but a valid-like address. The empty directory entries were probably caused by the fact that I deleted some movie clips when it was connected in the Salora. However, the mismatch of no-names and no-addresses and the problem with reading not 512-byte aligned made it all clear: my earlier assumption about where the directory entries start is slightly off. What if we assume it starts at 0×10005600 instead of 0×100054f0? Makes much more sense! First of all, each entry is 512-aligned. Also, the entry starts with the name. This makes the dir-entry structure look like:


typedef struct _tfs2_dir_entry
{
uint16 utf16_name[120];
uint32 unknown1[3];
uint32 address;
uint32 unknown2[64];
} TFS2_DIR_ENTRY;


So, here’s the tool with which you can try it yourself:

tfs2dir.c v1

Compile with gcc -o tfs2dir tfs2dir.c and run (as root) with ./tfs2dir /dev/ad3 or whatever your device is.

This is what the output looks like:

Disk /dev/ad3
entry: 0 address: 0x67002a00 name: /VR_MANGR.IFO
entry: 1 address: 0x5b006300 name: /rtav/VOB00001.ttm
entry: 2 address: 0x59006300 name: /rtav/VOB00001.vtm
entry: 3 address: 0x58006300 name: /rtav/VOB00002.ttm
entry: 4 address: 0x5a006300 name: /rtav/VOB00002.vtm
entry: 5 address: 0xffffffff name:
entry: 6 address: 0xffffffff name:
entry: 7 address: 0x5e006300 name: /rtav/VOB00004.ttm
entry: 8 address: 0x5c006300 name: /rtav/VOB00004.vtm
entry: 9 address: 0x5f006300 name: /rtav/VOB00005.ttm
entry: 10 address: 0x5d006300 name: /rtav/VOB00005.vtm
entry: 11 address: 0x5c006300 name: /rtav/VOB00006.ttm
entry: 12 address: 0x5e006300 name: /rtav/VOB00006.vtm
...


So there is kind of a fake directory structure embedded in the file names. Also the names are not very creative: If associated with an existing movie clip, the file /rtav/VOBx.ttm is stored at entry 2x-1, the file /rtav/VOBx.vtm at entry 2x.

The 32-bit addresses from the previous post don’t seem te be direct pointers onto the disk. When looking at a full 250GB disk with hundreds of files, most of the ‘addresses’ are of the form

xx006300
xx006200
xx006100
xx006000

Most of the xx’s are consecutive. Some 32-bit words even appear double, but I’m not sure if this has to do with deleted files.

I wrote a small tool that seeks to a given place on the disk and then starts outputting the data, which I then piped into mplayer. Turns out that short-play (SP) recorded movies are chopped up into 16MB blocks (about 28 seconds), which are stored in some non-constant order (although in the test most blocks were stored in decreasing but concatenated offset order).

If we put one short movie fragment on the disk, the ‘directory’ is as follows:

'address'  name
57004300 /VR_MANGR.IFO
67002a00 /rtav/VOB00001.ttm
5b006300 /rtav/VOB00001.vtm
59006300

So a movie consists of 2 VOB files, a .ttm and a .vtm file.”A VOB file (Video Object) is a container format contained in DVD-Video media. It contains the actual Video, Audio, Subtitle (VobSubs) and Menu contents in stream form.” (wikipedia).

The addresses are not in increasing order…

After some scanning I found that the movie starts at 4a71ee00 and is subdivided in 2K blocks, each starting with header ba010000. If we swap endianness, we get the MPEG pack header 000001ba. Apparently, the SALORA HDD2510 is a big-endian machine.

In our case the movie has a size of 2238 blocks, or 4583424 bytes.

So, let’s have a look at the 2GB formatted disk.

00000000-10003FFF 256MB of zeroes
10004000-1000406F block with 'CRedundantABS Copyright LSI Logic, Inc. 2004'
10004200-1000449F block with 'CLsiPMABS Copyright LSI Logic, Inc. 2004'
10004A00-10004A6F block with 'CRedundantABS Copyright LSI Logic, Inc. 2004'
10004C00-10004CAF block with 'CLsiPMABS Copyright LSI Logic, Inc. 2004'
100051E0-100052A0 block with 'TFS2'
10005400          57004300        30003000        30003000        00000000

From here we get 2048 blocks of 512 bytes each that look like directory entries.

100054f0          00000000        00000000        00000000        57004300
10005500          00000000        00000000        00000000        00002080
10005510          00000000        00000000        00000000        00000000
*
10005540          40000000        00000000        00000000        00000000
10005550          00000400        00000000        00000000        00000000
10005560          00000000        00000000        00000000        00000000
*
100055d0          00000000        00004000        00000000        00000000
100055e0          00004000        00000000        00000000        00000000
100055f0          00000000        00000000        00000000        00000004
10005600          56002f00        5f005200        41004d00        47004e00
10005610          2e005200        46004900        00004f00        00000000
10005620          00000000        00000000        00000000        00000000

The first entry differs from the following in that it contains a string. The string is

/VR_MANGR.IFO

with a 2-byte UTF-16 like encoding. This is clearly a file name, since an IFO file “contains headers that tell the DVD player what screen to
show at startup, where each chapter starts, where audio tracks are located
on the disc, etc; works in conjunction with .VOB and .VRO files, which
contain the actual audio and video data.” (http://www.fileinfo.net/extension/ifo).

The word on the top-right (57004300) looks like an address. The second directory entry has address 67002a00 and an empty string. The third until 2048th entry have address ffffffff.

The last entry starts at 101054f0 and is slightly different as its string is not all-zero:

10105600          0f0f100f        00000000        00000000        0f0f0000
10105610          00000000        00000000        00000000        0000100f

So we have 1MB of directory entries, each 512 bytes, so a total of 2048 entries. I guess this means that the number of movies on the disk is limited to 2048.

At 101056a0 starts another repeating pattern that looks like an allocation table:

101056a0          00000000        00000000        ffffffff        ffffffff
101056b0          ffffffff        ffffffff        fffeffff        ffffffff
101056c0          ffffffff        ffbffefb        ffff7fff        ffffffff
101056d0          ffffffff        ffffffff        ffffffff        ffffffff
101056e0          ffffffff        ffffffff        ffefffff        ffffffdf
101056f0          ffffffff        dfffffff        ffffffef        ffffffff
10105700          ffffffff        ffffffff        ffffffff        ffffffff
10105710          ffffffff        ffffffff        fffffbff        ffffffff
10105720          ffffffff        ffffffff        ffffffff        ffffffff
10105730          fffffffb        ffffffff        7fffffff        ffffffff
10105740          ffffffff        ffffffff        fffdffef        fffff7ff
10105750          ffffffff        ffffffff        ffffffff        ffffffff
10105760          ffffffff        ffffffff        ffffffef        ffffffff
10105770          ffffdfff        ffffffff        ffffffff        fffffffd
10105780          ffffffbf        ffffffff        f7ffffdf        ffffffff
10105790          ffffffff        fffffdff        ffffffff        7fffffff
101057a0          ffffffff        ffffffff        ffefffff        ffdfffff
101057b0          ffffffff        ffffffff        ffffffff        ffffffff
*
101057d0          ffffffff        fdfffffb        fbffffff        ffffffff
101057e0          ffffffff        ffffffff        ffffffff        ffffffff
101057f0          fffffeff        ffffffff        ffffffff        fffffbff
10105800          ef00f000        00000000        100f0000        ff0f0000
10105810          00000000        00000000        00000000        0000f000
10105820          00000000        00000000        00000000        00000000
*

I wondered what would happen when I insert another hard disc into the HD recorder. Using an old IDE 2 gigabyter I restarted the Salora. It remained in its boot sequence (blinking HELLO on the display) forever. Aha, the drive must be jumpered to master-mode. Now during booting, it makes a formatting-like noise. After a while, the boot sequence completes, and YES, the disc is ready for use.

Conclusion: if you want to use another hard disc, just put it in!

To remove the hard disk you don’t have to remove the entire top cover. There’s a small door at the bottom behind which the drive is located. It also has a warranty seal. When connected to a PC (I’m using FreeBSD), fdisk shows that there’s no valid partition table on the disk. Let’s see if there’s some text:

# cat /dev/ad3|strings|less

Amongst the output we see


CRedundantABS
Copyright LSI Logic, Inc. 2004
CLsiPMABS
Copyright LSI Logic, Inc. 2004
TFS2


Is TFS2 the name of the file system? I did some googling, but no luck.

Further on the disk, the names of the recorded videos appear.

Let’s see what’s inside the Salora HDD 2510. Byebye warranty…

The 250 GB hard drive turns out to be a common IDE drive. The CPU is hidden behind a cooling plate.