• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

Extract HDR-2000T filesystem from HDF file

MontysEvilTwin

MontysEvilTwin

Well-Known Member
A few bootHDR conversations have been going on recently and it got me thinking about extracting the filesystem from the HDR-2000T update file (1.01.10). I remember af123 saying that this would not work with the tools currently available on the HD- and HDR-FOX, but I thought I'd have a little tinker anyway. I ran humidify and did manage to extract a BIN file from the HDF, though it did warn about an 'address offset error'. I then tried to unsquash the BIN file using squashfs but it failed with a message that it 'couldn't find the superblock'. I wonder if it is worth letting sasquatch have a crack at the BIN file? Is it possible to compile a version of sasquatch that will run on the HD- and HDR-FOX?
 
Code: 
# Extract
humax# humidify -x hdr2000t_upgrade_1.01.10.hdf

# Read length from first four bytes
humax# xxd < 1.hdfbin-1-80400000.raw | head -1
0000000: 0199 0000 6873 7173 310d 0000 35cd 6954  ....hsqs1...5.iT

# length is 0x1990000 here = 26804224 in decimal
# Extract

humax# dd if=1.hdfbin-1-80400000.raw bs=1 of=squashfs skip=4 count=26804224

# However, this is very slow on the Humax, reading a byte at a time.
# Can speed it up by using a blocksize of 4 bytes, skipping one block and reading fewer

humax# dd if=1.hdfbin-1-80400000.raw bs=4 of=squashfs skip=1 count=6701056

humax# file squashfs
squashfs: Squashfs filesystem, little endian, version 4.0, 6844849663 bytes, 3377 inodes, blocksize: 1 bytes, created: Fri Mar 19 19:33:20 1915

# Extract with unsquashfs4 (update squashfs-tools to get it)

humax# unsquashfs4 squashfs

The .raw file is actually a simple archive format containing the root filesystem and the kernel along with what look like cryptographic hashes for validation but this is an easy way of extracting the first object which happens to be the filesystem.
 
Thanks af123. I am interested to see if, by creating a HDRfs file from the HDR-2000T file, I can get bootHDR to boot the HDR-2000T humaxtv process on the HD-FOX: just for the sake of tinkering of course.
 
I've updated the humidify package to the latest version too - this one can handle the data holes in the new HDF format.
 
Thanks af123. The instructions worked a treat with the updated humidify and squashfs-tools packages. I used the extracted files with bootHDR on a HD-FOX to see if it would run the HDR-2000T code. It got as far as killing the humaxtv process and creating the necessary links, but then crashed. I guess the software and hardware aren't compatible. It was fun trying.
 
Out of interest I extracted the 2000T file system myself, just to have a poke around. Used version 1.01.06 as I didn't have a source for v1.01.10. Surely it would be a small step from here to create a custom firmware with telnet enabled to get root access to this box and everything else that is then possible ?
If I owned a 2000T I would definitely be giving it a try.
 
The problem is going to be recreating the digital signature to make the 2000T accept the modified firmware update. That's the sticking point.
 
I don't know what I am talking about, so I have the luxury of asking stupid questions. af123 said that there were some holes in the hdf file. Is it possible to hide telnet in one (or more) of the holes?
 
As I understand it, the .hdf is cryptographically signed to authenticate it. That means appending a signature (like a checksum) which is computed from the content of the payload using a secret algorithm. There is no problem reading the payload, or creating a new payload, but in order for the Humax to accept the file as a firmware update it has to compute the signature and compare it with the signature appended to the file. The algorithms for this kind of thing are specifically designed to cause a substantial change in the signature for even the smallest change in the payload (eg flipping one bit). This serves two purposes: to verify the file is not corrupt, and to authenticate its source.

Unless you know (or can work out) the algorithm to compute the signature for any given payload (including any encryption keys used), you can't create a .hdf that would authenticate as a valid firmware update. For the HD/HDR-FOX, the signature algorithm was easily guessable and I believe af123 also employed a little hardware jiggery-pokery to read some critical data. Humax have upped the game for the HDR-2000T.
 
Black Hole said:
As I understand it, the .hdf is cryptographically signed to authenticate it. That means appending a signature (like a checksum) which is computed from the content of the payload using a secret algorithm. There is no problem reading the payload, or creating a new payload, but in order for the Humax to accept the file as a firmware update it has to compute the signature and compare it with the signature appended to the file. The algorithms for this kind of thing are specifically designed to cause a substantial change in the signature for even the smallest change in the payload (eg flipping one bit). This serves two purposes: to verify the file is not corrupt, and to authenticate its source.

Unless you know (or can work out) the algorithm to compute the signature for any given payload (including any encryption keys used), you can't create a .hdf that would authenticate as a valid firmware update. For the HD/HDR-FOX, the signature algorithm was easily guessable and I believe af123 also employed a little hardware jiggery-pokery to read some critical data. Humax have upped the game for the HDR-2000T.
Click to expand...
Both the squashfs filesystem and the kernel blocks in the .raw file are immediately followed by a 264 byte block. The first 4 bytes are zeros and next 4 bytes is data size repeated again, so crypto hashes must be in the remaining 256 bytes.
Is has not been proven that these are essential but, like BH, I suspect that they are. Only way to find out for sure is to try and flash a modified .hdf and see what happens.
 
Last edited:
raydon said:
If I owned a 2000T I would definitely be giving it a try.
Click to expand...
So is there any scope for a number of people to club together to buy an HDR-2000T for Raydon to have a go? Perhaps raffle it to one of the subscribers if the attempt ultimately fails.
 
MartinLiddle said:
So is there any scope for a number of people to club together to buy an HDR-2000T for Raydon to have a go? Perhaps raffle it to one of the subscribers if the attempt ultimately fails.
Click to expand...
Sorry Martin, but there is no way I could agree to that. Besides, I believe others with more experience in crypto would have a much better chance of success with cracking the hashes. My experience with crypto is absolutely zilch.
 
Last edited:
You must log in or register to reply here.
Back
Top