Humax recording encryption

af123

af123

Administrator
Staff member
There seems to be a lot of interest in the way that the HD & HDR encrypt content when recording it off the air. I'm wondering whether we can work out how this is done with a view to developing a decryption process.

Just to be clear. I'm not talking about reverse engineering the propriety Humax code here, just analysing the file formats and the architecture and seeing what can be gleaned from it.

Here's what I've found so far:

Of the four files that make up a completed recording, only the .ts files that are encrypted.
The .ts files are made up of a sequence of 192 byte blocks. Each block has a 4 byte prefix which looks like some kind of time code followed by a standard 4 byte Transport Stream (TS) header and then a 184 byte payload. Only this payload section is encrypted - the first 8 bytes of each block are the same in the encrypted and decrypted version of a .ts file.

Not all packets are encrypted - those which have TS annotations are stored identically in the encrypted and decrypted versions.

The most likely algorithm is probably AES-128, two blocks at a time to give 23 encryption blocks. I've tried a basic brute force attack using all 16 byte blocks in flash and memory as possible encryption keys, but no luck there.

Considering the amount of encryption that the box has to do when recording two channels at the same time as playing back a recording, it seems likely that the encryption is done in hardware and it's also possible that the key is stored in a HSM..

The bcm 7405 platform includes...

... a memory-to-memory DMA security module [which] may be programmed for supporting different copy protection algorithms/standards (AES, 1DES, 3DES, CSS, CPRM, CPPM and DTCP).
Click to expand...
 
Would it be useful to compare memory dumps (of rom is particular) from a couple of different machines in case the unique key(s) are sitting around? Could be a long shot though, as I'd assume its all hidden away in the Hardware Security Module. I suspect the only way forward for the HD model is to work out how to use the HSM to decode the video on box, as the HDR does during a copy.

Steve
 
Drutt said:
Would it be useful to compare memory dumps (of rom is particular) from a couple of different machines...
Click to expand...

Definitely - the most useful would be a dump of /dev/mtd3 which is where the system ID seems to be stored.

Code: 
humax# cat /dev/mtd3 > /mod/mtd3.dump

is enough to extract it and if anyone is willing then either upload the results to somewhere like 4shared or I can provide logins to the hummypkg.org.uk FTP server if preferred.
 
Sorry, for HD models the interesting bit of flash is mtd6. mtd3 is for the HDR.
 
suarez said:
Well, at least for the FOXSAT-HDR, anyways! I am assuming they stuck to the same for the HDR-FOX T2...
Click to expand...
Does anyone who follows Foxsat forums know if any progress has been made with it that may be of use to us?
 
Certainly a more manageable number of differences between mine and moppets. Here are the diffs:

000C8C00 - file1: 00 03 78 9A FB A9

000C8C00 - file2: 00 03 78 9B 44 1D

000CB400 - file1: 01 10 02 BC 00 07 DE 84 72 1C A3 8E 18 77 34 40 CB BB A1 EA 40 3F EF A4 38 8F 1C 90 48 14 71 D1 10 2D B7 16 96 DE B3 4A 87 D7 47 C7 6D 8B F3 83 00 8D DE E2 24 12 D5 DB 18 66 77 F2 B1 D4 F5 2A 5C 0A 17 E2 01 CA 15 E6 85 8A 56 79 69 6C CE 2B E0 38 FC 23 F8 CA 69 37 01 4B 5F C1 03 F2 C3 0F AF 3D 8D B7 62 30 E9 55 6F B0 87 8C 6E 6E 94 C4

000CB400 - file2: 01 10 02 BC 00 08 72 48 0D 1C 0D F7 E9 B6 84 87 86 B1 43 25 D9 A2 5C DC 21 8E 63 31 91 9C A0 41 2E D7 B5 46 30 8E 72 54 13 15 09 A7 9F 9D 23 47 00 07 00 88 E2 76 98 05 5E A1 F5 67 04 5C E7 0B 59 4B A7 D2 01 9F 3C A5 F3 1F CB 8B 76 E9 E7 C3 19 94 42 3B 2C 3B 0E 97 01 D1 91 A0 C4 94 75 4D B9 CA C3 9C 2E D5 58 23 56 9A 9D 0B 6E 6E 94 C4

000CB800 - file1: 39 31 38 31 30 30 38 35 32 30 30 31 31 37 (91810085200117 in ascii)

000CB800 - file2: 39 31 38 31 30 30 39 32 31 30 33 39 38 35 (91810092103985 in ascii)
 
Drutt said:
Certainly a more manageable number of differences between mine and moppets. Here are the diffs:

000C8C00 - file1: 00 03 78 9A FB A9

000C8C00 - file2: 00 03 78 9B 44 1D

000CB400 - file1: 01 10 02 BC 00 07 DE 84 72 1C A3 8E 18 77 34 40 CB BB A1 EA 40 3F EF A4 38 8F 1C 90 48 14 71 D1 10 2D B7 16 96 DE B3 4A 87 D7 47 C7 6D 8B F3 83 00 8D DE E2 24 12 D5 DB 18 66 77 F2 B1 D4 F5 2A 5C 0A 17 E2 01 CA 15 E6 85 8A 56 79 69 6C CE 2B E0 38 FC 23 F8 CA 69 37 01 4B 5F C1 03 F2 C3 0F AF 3D 8D B7 62 30 E9 55 6F B0 87 8C 6E 6E 94 C4

000CB400 - file2: 01 10 02 BC 00 08 72 48 0D 1C 0D F7 E9 B6 84 87 86 B1 43 25 D9 A2 5C DC 21 8E 63 31 91 9C A0 41 2E D7 B5 46 30 8E 72 54 13 15 09 A7 9F 9D 23 47 00 07 00 88 E2 76 98 05 5E A1 F5 67 04 5C E7 0B 59 4B A7 D2 01 9F 3C A5 F3 1F CB 8B 76 E9 E7 C3 19 94 42 3B 2C 3B 0E 97 01 D1 91 A0 C4 94 75 4D B9 CA C3 9C 2E D5 58 23 56 9A 9D 0B 6E 6E 94 C4

000CB800 - file1: 39 31 38 31 30 30 38 35 32 30 30 31 31 37 (91810085200117 in ascii)

000CB800 - file2: 39 31 38 31 30 30 39 32 31 30 33 39 38 35 (91810092103985 in ascii)
Click to expand...

The first set of numbers are the MAC address. Is there any way to spoof the MAC address and see if the second and third sets change with it? Could the key be derived from the MAC?
 
Drutt said:
000CB800 - file1: 39 31 38 31 30 30 38 35 32 30 30 31 31 37 (91810085200117 in ascii)

000CB800 - file2: 39 31 38 31 30 30 39 32 31 30 33 39 38 35 (91810092103985 in ascii)
Click to expand...

Could this be linked to the box serial number?
 
I've just compared my HDR mtd3 with csudcy's. Similar findings to the HD, in that:
  • 00c8c00 is the MAC address.
  • 00cb800 is the serial number.
  • For completeness, the system ID is at 00c0400.
  • The block at offset 00cb400 is different:
Code: 
< 00cb400: 0110 02bc 000f 72c9 0394 adf7 c702 455d  ......r.......E]
< 00cb410: baf8 c26b de4c 931c 26fa b111 46d2 a005  ...k.L..&...F...
< 00cb420: a28e 0ace cc80 443e b443 9be3 3f72 6da3  ......D>.C..?rm.
< 00cb430: 018d 64f3 7587 bec2 34d3 068e c07c 0068  ..d.u...4....|.h
< 00cb440: 5662 9e17 0189 8370 2747 6eb6 fe7a f322  Vb.....p'Gn..z."
< 00cb450: e933 48c3 ba19 0bbf 00d5 8080 fdf1 195b  .3H............[
< 00cb460: c484 a46c bc5e 9eb6 035e 4d96 6e6e 94c4  ...l.^...^M.nn..
---
> 00cb400: 0110 02bc 0013 2fbb 0e2a e5f4 0232 37b3  ....../..*...27.
> 00cb410: 0e51 8a8c b838 1c0b ac1f 38d8 119f 1176  .Q...8....8....v
> 00cb420: 1be5 8f11 21b1 4b7d 729f 71dd e150 332d  ....!.K}r.q..P3-
> 00cb430: 01f2 94de 963d 3428 3234 76b2 6aef 50b2  .....=4(24v.j.P.
> 00cb440: 5d50 5bca 0146 71e2 9bc5 b2f6 fe19 7ff8  ]P[..Fq.........
> 00cb450: 2948 8004 814e 2f5d 006b 527c 3f98 c91e  )H...N/].kR|?...
> 00cb460: d674 5f88 77e2 4df0 35be a83c 6e6e 94c4  .t_.w.M.5..<nn..

There is also a fairly large block of differences at offset 00ca010 - 00cb120.
 
Just compared an HD dump with the HDR one from csudcy. As you might expect, there were a lot more differences early on in the file, but the interesting differences highlighted above remained, and at the same addresses - mac address at 000C8C00, serial number at 000CB800, and the other interesting block of data at 000CB400. I guess we now just need to try all the combinations of 3x64 bit keys out of that block and hope the 3 keys are in there. This needs to be done on a HDR as us poor HD owners don't have the unencrypted version to check for success. Af123, would you mind giving this a go? Sounds like you've already knocked up a little testbed for your AES-128 test :)​

Steve ​
 
DES keys usually have check parity bits so it's trivial to check if something is a possible DES key.

I need to find some time later to try decryption, but I ran this:

Code: 
int
main(int argc, char **argv)
{
        int cfe;
        struct stat st;
        char *test;
        int i;
        uint32_t sz;

        assert((cfe = open("../test", O_RDONLY)) >= 0);
        fstat(cfe, &st);
        sz = st.st_size;
        test = malloc(sz);
        assert(read(cfe, test, sz) == sz);

        for (i = 0; i < sz - KS; i++)
        {
                des_key_schedule ks;

                if (des_set_key_checked(test + i, ks) == 0)
                {
                        printf("Key: @%x\n", i);
                }
        }

which resulted in:

Key: @cb408
Key: @cb409
Key: @cb40a
Key: @cb40b
Key: @cb40c
Click to expand...

So it looks like the bytes between cb408 and cb414 have correct parity to be parts of a DES key - strange number of bytes (12) though.
 
You must log in or register to reply here.
Back
Top