Beta Offline decryption utility

Black Hole said:
So far as I can see, there has been no formal migration of stripts out of beta
Click to expand...
Where are you looking and what defines "formal"?
yet the mainstream WebIF is (I think) dependent on it.
Click to expand...
It is. And stripts isn't in beta and hasn't been for a long time.
Perusing the WebIF package management, it seems to me the beta tag has been quietly dropped on a number of packages, so it would be useful if their relevant threads were moved to the main forum or closed to make the status clear. It's a pain when I'm trying to keep definitive records.
Click to expand...
That's a decision for the forum moderators and/or the package authors. I'm not sure it's helpful to drop the Beta tag from the forum discussion (by moving the entire thread). It's probably best to lock the Beta thread and start a new one in the main CF section, with a reference to the previous one.
It just needs someone to go through the Beta sections and do it and/or request it of the moderators.
For reference, this page tells you what is currently in the Beta repository: https://hpkg.tv/hdrfoxt2/beta.html
and it isn't much.
 
I've produced updated Linux builds of stripts to match the one now available for the Humax in the Beta section.
They work for me, but please test for yourself, if you are so inclined and know what you're doing!
Both 32 and 64 bit versions are here: https://dl.dropbox.com/s/d6la3r13aq3ueaq/stripts.zip

These versions allow encryption as well as decryption, and also allow piping via standard input.
For example, if 'something' was outputting encrypted packets in .m2ts format, then you could decrypt on-the-fly by:
humax# something | stripts -@@ -- - file
which would create test.ts, or pipe into 'something-else':
humax# something | stripts -@@ -- - -|something-else
 
Last edited:
If libraries are going to change whenever they release a new core Linux, wouldn't it be better to include the appropriate elements in or with the executable?
 
Black Hole said:
If libraries are going to change whenever they release a new core Linux, wouldn't it be better to include the appropriate elements in or with the executable?
Click to expand...
As in static linking the library code into the executable? That would assume the old library code still does its job in a new release. In Windows that seems to work (as in the id3 code we cobbled together a while back). Whether the same is true for Linux I don't know. One can hope.
 
EEPhil said:
As in static linking the library code into the executable?
Click to expand...
Maybe, I'm not well versed in this stuff.

EEPhil said:
That would assume the old library code still does its job in a new release.
Click to expand...
I can understand that something which strongly interacted with OS services might break, and that this library might depend on other libraries, but shirley this is just a self-contained data processing function which is given some input and produces an output?
 
EEPhil said:
As in static linking the library code into the executable?
Click to expand...
I guess it's a possibility but it means more work and changing the makefile which is currently the same on the HDR as on any other Linux build.

Some people seem to hate static linking, viewing it as the most heinous crime. It does increase executable size and memory usage, but stops this other misery.
I have used it myself on some Windows stuff, where there was probably only going to be one instance of it running on many physical machines, and I specifically didn't want DLL misery. Then somebody changed how things were done and centralised everything and now there are 30+ instances running on one VM. No-one's complained though (yet), and I doubt they ever will as modern storage and memory are cheap and plentiful, and even with the overheads of being static it's still irrelevant in the grand scheme.
Black Hole said:
but shirley...
Click to expand...
? His name's (EE)Phil. But I guess that's not important right now.
 
prpr said:
I guess it's a possibility but it means more work
Click to expand...
So this is why not:
Code: 
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-dso_dlfcn.o): in function `dlfcn_globallookup':
(.text+0x17): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-bio_addr.o): in function `BIO_lookup_ex':
(.text+0xd7f): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-bio_sock.o): in function `BIO_gethostbyname':
(.text+0x75): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
and the file is nearly 100 times the size compared to a dynamic linked version.
It's much easier just to rebuild when it breaks.
 
prpr said:
So this is why not:
Click to expand...
Yikes! That's one hell of a jump in size.
Thing is, the other of BH's suggestions ( supplying the appropriate elements - the shared libraries?) would probably be even larger - assuming that could even be done. (It could be in an old Borland C for Windows, but whether such a thing is possible in Linux - don't ask me!)
prpr said:
It's much easier just to rebuild when it breaks
Click to expand...
Quite!
prpr said:
His name's (EE)Phil. But I guess that's not important right now.
Click to expand...
Correct. Other people would use two els (eg Jupitus) but I only use one. I was going to make a similar comment - but we've been here before.
 
EEPhil said:
Thing is, the other of BH's suggestions ( supplying the appropriate elements - the shared libraries?) would probably be even larger - assuming that could even be done.
Click to expand...
It could be, but the library in question has its own dependencies and so on. Then you've got to get all the bits in the right place (maybe platform dependent, as every Linux distribution has its own ideas). It quickly turns into a huge can of worms.
 
Also with static linking fixing of any (security) bugs in the library code becomes virtually impossible.

What is required is better support for backward compatibility and not to be so keen to drop support for older interfaces.
 
MymsMan said:
What is required is better support for backward compatibility and not to be so keen to drop support for older interfaces.
Click to expand...
Tell that to Microsoft, Apple, web browser developers, British Gas (flipping app :mad: ), etc, ad nauseam.
 
I'm trying to run stripts on my Mint system, and failing.

The version from post 423 produces error while loading shared libraries: libinotifytools.so.0: cannot open shared object file: No such file or directory,

from post 422 (64-bit) I get error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory,

and from post 1 I get error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory

This is Linux Mint 21.2 Victoria base: Ubuntu 22.04 jammy

What to do?
 
from post 422 (64-bit) I get error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory,
Click to expand...

That lib is installed with libssl1.1 package. A new-ish Debian system here comes with libssl3 and also has the earlier version, not that I've tried any stripts with it.
 
Black Hole said:
The version from post 423 produces error while loading shared libraries: libinotifytools.so.0: cannot open shared object file: No such file or directory,
This is Linux Mint 21.2 Victoria base: Ubuntu 22.04 jammy
What to do?
Click to expand...
Presumably sudo apt install libinotifytools0
from post 422 (64-bit) I get error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory,
and from post 1 I get error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
Click to expand...
These are obsolete and won't work on contemporary systems, as I thought had been made clear.
 
prpr said:
Presumably sudo apt install libinotifytools0
Click to expand...
That seems to have got it, thanks... but I say "seems" because although stripts didn't bomb out and (apparently) produced an output file (I presume it would have complained if I had got the key wrong), the product won't play in VLC.

For context, I have a couple of recordings made on HD-FOX which are too large to decrypt locally (or at least, they fail), so I imported them to my Linux system and got the above. Having failed there, I put the original files on a UPD and plugged it into a HDR-FOX (same key as the HD-FOX), and ran DLNA decryption via the WebIF media browser OPT+ button. Having decrypted by that means, they play in VLC on my Linux system.

How do you suggest I go about finding out what the difference is?
 
You must log in or register to reply here.
Back
Top