grahamlthompson
Well-Known Member
But isn't that what you would expect if they are encoded rather than encrypted?
Ok perhaps should have said can't be easily read. It's rather a fine point, isn't encoding a form of encryption ?
But isn't that what you would expect if they are encoded rather than encrypted?
I have added xls to the list of file types accepted, so you will be able to upload it now.
With encryption you need to know the algorithm used to encrypt and a passphrase of some sort. With encoding you just need the algorithm.Ok perhaps should have said can't be easily read. It's rather a fine point, isn't encoding a form of encryption ?
With encryption you need to know the algorithm used to encrypt and a passphrase of some sort. With encoding you just need the algorithm.
So what's new? It's the usual bug-ridden crap from Humax....reports ftp on the FV-4000T is very iffy
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.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.
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|
That's just the encoded text though, prpr has posted the decoded binary data.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
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).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.
Nice : ) mine involved sed and OpenSSL base64 -d ..Here it is
I like simpleNice : ) mine involved sed and OpenSSL base64 -d ..
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?