Stuck with decrypting

[A_n_g_e_l_a]

I went here:-
https://player.stv.tv/episode/48d2/sony-commons
to get this:-
https://manifest.prod.boltdns.net/manifest/v1/dash/live-baseurl/bccenc/6204867266001/b...QzMzdkNDNjNg==

and used yt-dlp to download an mp4 and m4a file of 563 parts

The manifest response had this between <cenc: pssh>:-

AAAAVnBzc2gAAAAA7e+LqXnWSs6jyCfc1R0h7QAAADYIARIQr3ljevwPRLO70nM7c1OFPRoNd2lkZXZpbmVfdGVzdCIIMTIzNDU2NzgyB2RlZmF1bHQ=

which I used at getwvkeys - to provide:-

af79637afc0f44b3bbd2733b7353853d:25a89c8c61df0f8f760d3fb5f2b3543c

Here I get stuck because any combination I seem to try with bento4 mp4decrypt does nothing.
typically:_

./mp4decrypt --show-progress --key 1:25a89c8c61df0f8f760d3fb5f2b3543c /home/angela/input.mp4 /homeangela/output.mp4

writes a zero byte output file.

Where am I going wrong?

I made prat fall. I'd moved the downloaded mp4 with a long file name to something shorter ~ input.mp4 Somehow that file became zero bytes?? Just re-downloased and it decrypted fine. I'll leave this here with egg on my face!

[ridibunda]

Correct command-line:

mp4decrypt --key af79637afc0f44b3bbd2733b7353853d:25a89c8c61df0f8f7 60d3fb5f2b3543c input.mp4 output.mp4

Place "mp4decrypt.exe" and "input.mp4" in the same folder.

[A_n_g_e_l_a]

Correct command-line:

mp4decrypt --key af79637afc0f44b3bbd2733b7353853d:25a89c8c61df0f8f7 60d3fb5f2b3543c input.mp4 output.mp4

Place "mp4decrypt.exe" and "input.mp4" in the same folder.

Thanks, but as I already noted in my edit, my line eventually worked and decoded fine. Programs can reference files anywhere on the file system - at least in Linux.

[ridibunda]

Decrypting without writing KID, that's interesting

[A_n_g_e_l_a]

So flushed with success I went on to episode 2!

And got this with three sets of keyid:keys and none seem work.


[Attachment 63468 - Click to enlarge]

And @ridibunda suggested the keys in the form <KID:KEY> whereas i found only <1:KEY> to work - I'm on linux - is mp4decrypt different in this incarnation?

Now thoroughly confused.

[A_n_g_e_l_a]

Decrypting without writing KID, that's interesting

usage: mp4decrypt [options] <input> <output>
Options are:
--show-progress : show progress details
--key <id>:<k>
<id> is either a track ID in decimal or a 128-bit KID in hex,
<k> is a 128-bit key in hex
(several --key options can be used, one for each track or KID)
note: for dcf files, use 1 as the track index
note: for Marlin IPMP/ACGK, use 0 as the track ID
note: KIDs are only applicable to some encryption methods like MPEG-CENC
--fragments-info <filename>
Decrypt the fragments read from <input>, with track info read
from <filename>.

[ElCap]

So flushed with success I went on to episode 2!

And got this with three sets of keyid:keys and none seem work.

Now thoroughly confused.

Keys are from the wrong license server, untick cache tick box on ghosts site and try again

[A_n_g_e_l_a]

Keys are from the wrong license server, untick cache tick box on ghosts site and try again

Thanks! That unnoticed check-box has been driving me mad.

[Sorenb]

So flushed with success I went on to episode 2!

And got this with three sets of keyid:keys and none seem work.


[Attachment 63468 - Click to enlarge]

And @ridibunda suggested the keys in the form <KID:KEY> whereas i found only <1:KEY> to work - I'm on linux - is mp4decrypt different in this incarnation?

Now thoroughly confused.

on linux

mp4decrypt --key 1:<key> <encrypted file> <decrypted name>

Is standard. It's confusing I know, and I've had to show exampes to others who refuse to believe it's the right syntax. <kid:key> may work for windows users, but <1:key> is the linux way. Especially with mp4decrypt, in fact all the bento4 tools, added to path.

[ElCap]

--key <id>:<k>
<id> is either a track ID in decimal or a 128-bit KID in hex,
<k> is a 128-bit key in hex

on linux

mp4decrypt --key 1:<key> <encrypted file> <decrypted name>

Is standard. It's confusing I know, and I've had to show exampes to others who refuse to believe it's the right syntax. <kid:key> may work for windows users, but <1:key> is the linux way. Especially with mp4decrypt, in fact all the bento4 tools, added to path.

As A_n_g_e_l_a posted, the id can be either specified by the track id or the kid in hex.
the majority of times i decrypt it is with the kid:key not 1:key and thats on linux.
there are some sites that you need to use 1:key as the kid doesnt match whats in the encrypted file but the key still decrypts but theyre in the minority.

the other problem with using 1:key is that if the key is incorrect you wont get a notification saying the decryption has failed and if you run mp4info on the output file, it doesnt show the [ENCRYPTED] tag, so you assume that its been decrypted but then you will get errors when trying to mux it.
At least with the kid:key method it will still show the [ENCRYPTED] tag if the kid doesnt match.

id be using kid:key first on either windows or linux and only using 1:key on specific sites or for troubleshooting/testing.

[A_n_g_e_l_a]

id be using kid:key first on either windows or linux and only using 1:key on specific sites or for troubleshooting/testing.

I think I got lucky with my first decrypt using 1:key. I hadn't understood Ghost's site so hadn't set everything there correctly. But my first series of attempts finally worked with 1:key. KID:KEY didn't seem to work at all. When I sent my Ghost query properly the full KiD:Key worked.

I moved on to Channel 5 and surprised myself when that worked too!

Now pondering what is needed for All4; happy days!

[ElCap]

Now pondering what is needed for All4; happy days!

http://getwvkeys.cc/scripts

[A_n_g_e_l_a]

....

Ah! Thanks!!

[Sorenb]

--key <id>:<k>
<id> is either a track ID in decimal or a 128-bit KID in hex,
<k> is a 128-bit key in hex

on linux

mp4decrypt --key 1:<key> <encrypted file> <decrypted name>

Is standard. It's confusing I know, and I've had to show exampes to others who refuse to believe it's the right syntax. <kid:key> may work for windows users, but <1:key> is the linux way. Especially with mp4decrypt, in fact all the bento4 tools, added to path.

As A_n_g_e_l_a posted, the id can be either specified by the track id or the kid in hex.
the majority of times i decrypt it is with the kid:key not 1:key and thats on linux.
there are some sites that you need to use 1:key as the kid doesnt match whats in the encrypted file but the key still decrypts but theyre in the minority.

the other problem with using 1:key is that if the key is incorrect you wont get a notification saying the decryption has failed and if you run mp4info on the output file, it doesnt show the [ENCRYPTED] tag, so you assume that its been decrypted but then you will get errors when trying to mux it.
At least with the kid:key method it will still show the [ENCRYPTED] tag if the kid doesnt match.

id be using kid:key first on either windows or linux and only using 1:key on specific sites or for troubleshooting/testing.

All true, but I've repeatedly faced
mp4decrypt --key <kid:key> <encrypted file> <decrypted file>
not work at all with content from all4, rte, ITV and ABC iView (from memory.)
instead
mp4decrypt --key 1:<key> <encrypted file> <decrypted file>
worked, with a variance of the integer after --key on ABC iView.

[ElCap]

All true, but I've repeatedly faced
mp4decrypt --key <kid:key> <encrypted file> <decrypted file>
not work at all with content from all4, rte, ITV and ABC iView (from memory.)
instead
mp4decrypt --key 1:<key> <encrypted file> <decrypted file>
worked, with a variance of the integer after --key on ABC iView.

wow, interesting.
i just grabbed some stuff last night from abc iview and it went fine with kid:key and it works fine for me for all4 too.
but whatever works for you