• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

What We Know So Far ...

With encryption you need to know the algorithm used to encrypt and a passphrase of some sort. With encoding you just need the algorithm.

Thanks - it may all be a waste of time. Barry at MyHumax reports ftp on the FV-4000T is very iffy (frequently shows no files within the recording folder). Samba though does appear to work.
 
What makes you think they're encrypted? I haven't tried to decode it yet but it looks like a combination of base64 and URL encoding.
The first 0x6A bytes are the same, but after that they're quite different. Nothing recognisable to me, but I'm no expert with this stuff.
Code:
00000000  9d 08 b0 7a 48 a1 0f 6c  f8 fb 51 11 8d 4d e9 54  |...zH..l..Q..M.T|
00000010  7c 5b bc 9f 8b 2f 9c 06  c1 80 53 62 b1 5a 4d 1f  ||[.../....Sb.ZM.|
00000020  ac 0e 48 df 2f 8f f1 32  cb 4a fd 26 c9 df ff e1  |..H./..2.J.&....|
00000030  38 38 9b 74 0a 95 9f be  c7 79 08 aa d0 40 1b a7  |88.t.....y...@..|
00000040  bc 9d b2 35 fc bf 01 7f  63 0a 92 e4 23 65 a6 5c  |...5....c...#e.\|
00000050  59 fb a9 4e 8a b7 f9 c5  49 d0 bf 8e 84 46 40 95  |Y..N....I....F@.|
00000060  94 6e 0c 42 61 c3 4a e9  c5 81 55 03 5d 29 10 56  |.n.Ba.J...U.]).V|
00000070  e6 d4 82 b2 54 e8 29 ea  05 63 53 7f 18 32 a0 3a  |....T.)..cS..2.:|
00000080  46 17 85 a5 7a 35 04 7f  d0 5e 92 70 63 ce 09 9e  |F...z5...^.pc...|
00000090  d4 47 95 63 25 92 47 45  4c 4c ea 70 ea d3 c3 16  |.G.c%.GELL.p....|
000000a0  79 50 d8 ba 8d cb 67 cb  ef 45 41 f4 e4 e1 a8 ee  |yP....g..EA.....|

00000000  9d 08 b0 7a 48 a1 0f 6c  f8 fb 51 11 8d 4d e9 54  |...zH..l..Q..M.T|
00000010  7c 5b bc 9f 8b 2f 9c 06  c1 80 53 62 b1 5a 4d 1f  ||[.../....Sb.ZM.|
00000020  ac 0e 48 df 2f 8f f1 32  cb 4a fd 26 c9 df ff e1  |..H./..2.J.&....|
00000030  38 38 9b 74 0a 95 9f be  c7 79 08 aa d0 40 1b a7  |88.t.....y...@..|
00000040  bc 9d b2 35 fc bf 01 7f  63 0a 92 e4 23 65 a6 5c  |...5....c...#e.\|
00000050  59 fb a9 4e 8a b7 f9 c5  49 d0 bf 8e 84 46 40 95  |Y..N....I....F@.|
00000060  94 6e 0c 42 61 c3 4a e9  c5 81 07 03 5d 2f 10 04  |.n.Ba.J.....]/..|
00000070  6d d7 fd 0c c9 43 50 51  50 91 5f e7 b7 c4 eb 3e  |m....CPQP._....>|
00000080  93 0c 69 41 68 1b 50 c8  1b f6 77 be 0f 3b 50 70  |..iAh.P...w..;Pp|
00000090  24 6b 41 58 32 50 d8 33  ad 21 a5 98 69 d0 48 3c  |$kAX2P.3.!..i.H<|
000000a0  f2 ca e3 a3 63 49 6d 3b  09 e5 da 64 08 20 f9 4a  |....cIm;...d. .J|
 
Here's a screenshot from one of the hjm files (Click_20151107_1230.hjm):
Click_20151107_1230.jpg
This is just a portion (free app won't let me copy all of the file as text). From the above file: 22 = ", 7b = {, 7d = }, 68 = h, 6a = j, 6d = m. So the character set is standard ASCII. If the programme synopsis is embedded in the file it might be possible to find out where by comparing a few different files. As the synopsis text is easily obtained in English this may allow the encoding to be deduced, if it is just a simple cypher.
 
Not sure what decoder you (prpr) are using, but when I view the 2 files I see a much longer matching sequence.
The basic format is {"hjm":"***"}0 where 0 is a final null character and the *** represents the file except the first 8 and final 3 characters. The content is entirely in the range 34 to 128, suggesting that it has been deliberately limited or converted to printable ASCII characters. All we need is to decode the *** part!. Probably not going to work, but I would try a common binary/text convertor such as uudecode on it (haven't got access to anything that will do that at the moment).
 
Not sure what decoder you (prpr) are using, but when I view the 2 files I see a much longer matching sequence.
The basic format is {"hjm":"***"}0 where 0 is a
That's just the encoded text though, prpr has posted the decoded binary data.

It's just base64 with the +, / and = characters replaced by %xx escape sequences.
 
The first 0x6A bytes are the same, but after that they're quite different. Nothing recognisable to me, but I'm no expert with this stuff.
I agree. If it was just bare recording data I'd expect to at least see 5644 in there somewhere for today's date. I've tried running it through zlib uncompress and LH5 decompress without success (although I can't see why they would choose to compress such a small thing anyway).
 
We could do with a sample from another box to see if the common bit is the same at least...
 
I have never worked with php; nice solution. I guess that how easy the next layer is depends on how much Humax wanted to keep hidden from communities like this one.
 
My T2 has been playing up and I rely on my remote web access for recordings. I have been looking at the 4000 and downloaded the so called apps, but like other reports have not been able to even get them registered. Has anyone tried the apps and remote recording and had it working?
 
Last edited:
My T2 has been playing up and I rely on my remote web access for recordings. I have been looking at the 4000 and downloaded the so called apps, but like other reports have not been able to even get them registered. Has anyone tried the apps and remote recording and had it working?

No remote recording currently available. There is an app that allows SD recordings and live TV to be viewed on tablets/smartphones.
 
Thanks Graham, do you know if its epg is accessible by a web browser on the local network as I could come in on the VPN and make a recording?
 
Back
Top