Almost 2 years ago, I wrote an article about vmcam and how to use it. Unfortunately, later that year a lot of providers made some changes in their IPTV setups, rendering vmcam rather useless. What happened is that their servers dropped support for the old protocol (1154) in favor of a newer version (1155) which vmcam did not support at that time.
Recently there have been quite some developments on this issue. One of our readers (marri) reported in the comments on his progress in reverse engineering the Amino firmware update process and managed to obtain root access to his box. Another reader mailed us last week with what turned out to be a rather crucial piece of information about the new protocol.
I started looking into this tip and found the apparent solution almost too easy to be true. From the information provided, it seemed that the only difference between protocol 1154 and 1155 was the start of each message. Where messages in protocol 1154 would start with:
1154~
protocol 1155 would start them with:
1155~[length]~
where [length] is a 5 digit string containing the length of the entire message.
After updating vmcam to support this change it turned out to be correct! The replies from the server are unchanged between protocols, so the only necessary change was this small addition to the start of each sent message.
With this updated version of vmcam, both protocols are supported. 1154 is still the default, so if you need to use 1155 you will either have to specify it on the command line:
vmcam -m 1155
or in the config file:
PROTOCOL=1155
The updated source code can be found on github or from our own source repo. A binary version is available as well from our debian repo (amd64 only).
Note that vmcam is not compatible with libssl1.1, so you’ll need an older version to compile the program. Also, like in my previous vmcam article, the server keys are now even more outdated (~2 years more) than they were back then. I have successfully compiled vmcam this time with libssl-dev_1.0.1e-2+deb7u20_amd64 (download .deb), which also requires libssl1.0.0_1.0.1e-2+deb7u20_amd64 (download .deb) to be available.
I still need to test whether this works for my ISP or not, but I remain skeptical for now. My ISP T*lf*rt or GHM for that matter only provides a boot address with port 12686 and also prior to authenticating with the VCAS servers fetches a Conditional Access PIN or CA_PIN from an API. I think the CA_PIN is only used to generate an unique client id, but not sure if they actually check if it’s valid. I’ll update this as soon as I tried this vmcam version.
Indeed I saw the same connection from my amino in the dumps. However, it does not seem to prevent the keyblock retrieval process from succeeding on my setup. We’ll see how it turns out for you.
Port 12686 is used for provisioning, 0xb7 0xcd are the start bytes of a message (note that there may be several messages in a message) the following 2 bytes represent the encryption method used (0x01 is none).
Then comes the length of the message. As you already found, the first message contains the certificate in DER format.
The second message is encrypted (0x02) with the private key of the above certificate, you can decrypt it with the public key of the certificate (yes seriously, see https://www.openssl.org/docs/man1.1.0/man3/ RSA_public_decrypt.html)
I tested this version with 1155 protocol on T*lf*rt this morning and it worked untill the last step where the keyblock is fetched. I only receive 8 bytes. I used the aminomac as machineid, but I doubt this is right. Is this a config issue? I can send you the debug log if it’s helpfull.
Too bad it doesn’t work for you. Hopefully marri can make some progress with the first request to port 12686 to see what we’re missing.
In the meantime I have updated the github repo last night to include a configurable machine ID in the software. Just now I also updated the readme to reflect this new option.
You should be able to find this value in plaintext in a couple of the requests to the server. In my case it’s a 16-character string, and it is sent twice in the request to port 12686, once in the request to port 12698 and another time in the request to port 12700.
Also, it might help if your Amino has been connected and registered (with the pin you got from your provider) before attempting any of this.
To be honest though, I don’t think the above will change anything. I am able to request a keyblock with any combination of mac address and machine ID.
I couldn’t find any trace of a machine id anywhere in my requests. Care to clarify where and what exactly you are talking about?
I see some requests similar to the ones from the old 1154 protocol in my dumps. One of them has the form of 1155~[length]~[company]~[timestamp]~[machineid]~.
With previous versions, this would show the mac address of the amino, but vmcam will put the machineid in this place. I see the same string of characters (machineid) in other requests as well.
No machine id here. Just the MAC address.
I’m using the (old) Gl*sh*rt platform with the *mino decoders. I don’t have to enter a pin to connect a new decoder. I’m quite sure there is a request to port 12686. I can have a look on that to see if there is a machineid in it. What provider do you use? Is it on the newer K*N platform?
Just compiled from the Github repo and I’m also only receiving 8 bytes of data on the last step. I noticed that the requests vmcam sends are significantly shorter in size as the requests from a genuine STB. It looks like however that 1155 indeed is quite similar to 1154 so it might be an easy fix. Not sure when I will look into it, but I’ll report back if I get it working.
So you don’t see any plaintext in the whole sequence from the STB? Do you see SSL handshakes on all of the requests? VMcam only uses SSL on the first port it connects to…
I might have access to a T*lf*rt platform soon, so I will look into this when I get a chance.
Only the requests on the first port are indeed over SSL. The rest is plaintext however after the MAC address (in your case machine id I guess) everything is just giberish. These requests sizes (in bytes) also are far greater than the ones vmcam produces.
Really good news, unfortunately I recently switched from Ons***bantnet to a K*N connection, do you think this could also work on the new routed TV platform?
Recently I dug a bit deeper into the whole exchange of information to and from the Amino. In the mean time I also have access to a T*lf*rt platform for testing and I found the following so far:
-My own provider’s amino makes a connection to port 12686. It retrieves what looks like a configuration structure. Interestingly, part of this structure is the DER-format CA chain that is used for the connection to port 12697.
-On the T*lf*rt platform, I see no connection to port 12686 (might be due to a different region), but it still obtains the CA chain from an external source.
With the above information, I am currently trying to intercept and decrypt the SSL traffic on port 12697, where I hope to find the RC4 key that is used to encrypt the non-plaintext parts in the subsequent requests.
Is it possible to somehow contact you privately?
Would it be possible to connect to IPTV on the X54A77 platform as well? The thing is, I don’t have an Amino STB, but an Arc@dy@n. Will a MAC from that STB work as well?
HI,
On witch D*tch provider wil VCAM work ?
Can confirm, got it working with L*tvi*n IPTV provider L*tt*l*c*m.
Thanks for your great work!
VMCam apears to get stuck at the GetAllChannelKeys call for me at X*4*LL.
[API] Using Subject Key Identifier: D905A8D2C5E7F8716C3A98DB9A14CBCA0205250E
[API] Private key found
[API] Requesting master keys: 1155~00398~K*N~06/13/2018 21:56:47~00029BBEE5A2~00029BBEE5A2~GetAllChannelKeys~K*N~D905A8D2C5E7F8716C3A98DB9A14CBCA0205250E~c832da46fb53878601e3f6d6bea96335ab45e7cb0a6f1d86be70cf309139cc4b77ab59e3355034d027082f86e1d2aee4fc1269b65179007c240695c7a98a6ff2356ccc15de0ec21b7cf93b0d007f5234bef1524167659396fb294726de194c92d6a724c6e2fc4d7c0b9cb76d88b56dee210250c95e90d26c830edaea1cf5961e~00029BBEE5A2~ ~ ~
[tcp-client] Connect to 213.75.116.132:12700
[tcp-client] Received 8
[API] GetAllChannelKeys failed
I have obfuscated the company name in the log message.
I have configured TVheadend to use VMcam and VMcam shows successful ECm decode messages, but IPTV stream is still scrambled.
Same here since yesterday! It has been working flawlessly for months. Something changed apparently. My key block fetcher still fetches a key block, and the iptv proxy still seems to get the right key, but the image remains scrambled…
Having the same issue. Did you solve it?
Hey! I had the same problem! It seems that V*r*m*tr*x software get out of sync from time to time. I tested with Vi*wR*ght and there’s another way to get channels keys. In this case ChannelKeyFromDB is used. The format is: 1155~[length]~[api_company]~[timestamp]~[api_machineID]~[api_clientID]~GetChannelKeyFromDB~[api_company]~[ski]~[signedhash]~[keytimestamp]~[channel]~[api_machineID]~NULL~NULL~
I think it should also work with GetSingleKey instead of GetChannelKeyFromDB or GetMovieKey for VOD.
I had to change the code and add new functions to do GetChannelKeyFromDB as well as bypass the time check. Now it is working!
See log
I have
[KEYBLOCK] Keyblock is to old
very often now…
Who wants, can use my patch for oscam 11517, for vdr->dvbapi->oscam->vmcam
http://www.streamboard.tv/wbb2/thread.php?postid=585951#post585951
And yet.
If local time on you vmcam not UTC, but server gives keys with UTC, you can have [KEYBLOCK] Keyblock is to old.
Need correct time_now in keyblock.c
time_now = time(NULL) – utc_diff_sec;
where utc_diff_sec is difference between local time and UTC in sec.
I keep getting: [API] GetAllChannelKeys failed
Any ideas?
logfile: https://pastebin.com/qCJvuC51
I’m stuck at:
[tcp-client] Connect to vks7.stb.itvonline.nl:12700
[tcp-client] Received 8
[API] GetAllChannelKeys failed
Im using KPN DSL TV. Is this a configuration issue or bug in the code?
I need help to get my stuff work in norway. Can somebody help me to find Ip and port in tcpdump i have. Send me email if somebody want to help me. mortenhegrenes@gmail.com
What’s the status on this? Does it work? Did you manage to resolve the Keyblock issue?
i’ve been following this article and configure tvheadend to use vmcam.
but in tvheadend log it says “will not forward emms (not allowed by server)”. i’m stuck here.
anyone has facing this? maybe someone can give me some advices?
what could it be??????
It worked for a long time. No complaints.
”
[tcp-client] Connect to vmx.svc.***.***.***:12700
[tcp-client] Received 106064
[API] GetAllChannelKeys completed, size: 106060
double free or corruption (!prev)
“
I suspect the difference between these two lines. Before that, in the log, the numbers received by [tcp-client] and [API] were the same:
[tcp-client] Received 106064
[API] GetAllChannelKeys completed, size: 106060
in
vm_api.c
#define GETKEYS_BUFFSIZE (1024 * 100 * 2)
And “Hi R0stelek0m” :)
TNX!
Andrey, hello. Can I ask you for a corrected deb package under R%t?
1: There are several issues with the current codebase when using recent libc/gcc (segfaults) but I’ve been able to work around these. I’ve (seemlingly) been unable to get my CSR processed and get past the below step, any ideas?
2: The ISP vcas service is listening on multiple ports, some of which present a VCI (V******* Client Interface) certificate, others present a VKS certificate (V******* Key Server). Judging from the limited official documentation that’s out there it seems likely that it is the VCI service that handles this?
3: Also, there seems to be no cleartext communication that I can sniff to determine the STBs parameters. I’m fairly sure I’m using the correct $COMPANY, anything but the ISPs name doesn’t get even this far.
VMCam – VCAS SoftCAM for IPTV
[API] Requesting Session Key: 1155~000**~************~CreateSessionKey~COMPANY~************~
[ssl-client] Connect to csm.COMPANY.foo:126**
[ssl-client] SSL connection using AES256-SHA
[ssl-client] Server certificate:
subject: /C=NA/ST=NA/O=COMPANY/OU=unknown/CN=VCI.verimatrix.com/emailAddress=VCI.ravinder.kumar@huawei.com
issuer: /C=NA/ST=NA/O=COMPANY/OU=unknown/CN=SUBCA.verimatrix.com/emailAddress=SUBCA.ravinder.kumar@huawei.com
[ssl-client] Received 45
[API] Session key obtained, timestamp: 03/01/2022 12:00:00
[API] Generating CSR
[API] Using email: ************.**********@Verimatrix.com
[API] Private key found
[API] CSR created:—–BEGIN CERTIFICATE REQUEST—–
***
—–END CERTIFICATE REQUEST—–
U
[API] CSR generated, sending…
[API] Requesting Certificate: 1155~00**~************~getCertificate~COMPANY~NA~NA~—–BEGIN CERTIFICATE REQUEST—–
***
—–END CERTIFICATE REQUEST—–
U~STB~~*~~NA~~NA~~************.**********@Verimatrix.com~************~~
[ssl-client] Connect to csm.COMPANY.foo:126**
[ssl-client] SSL connection using AES256-SHA
[ssl-client] Server certificate:
subject: /C=NA/ST=NA/O=COMPANY/OU=unknown/CN=VCI.verimatrix.com/emailAddress=VCI.ravinder.kumar@huawei.com
issuer: /C=NA/ST=NA/O=COMPANY/OU=unknown/CN=SUBCA.verimatrix.com/emailAddress=SUBCA.ravinder.kumar@huawei.com
[ssl-client] Received 0
[API] Unable to get Signed Certificate
Im in the same exact situation Robert. Failing at this step. Get in touch via email and we can discuss further, perhaps we can solve this. Reach out at drosancam@protonmail.com.
Check your inbox/spamfilter.
Ehm, seems there’s an issue with the mx provider. You wouldn’t happen to be on IRC (libera/oftc)?
Thus far we’ve determined that there is a new protocol (1156) in play, anyone wanna chime in?
did you make any progress here? K*N seems to have changed to new protocol as well…
I have been trying all sorts of things myself as well. I am getting stuck at the requesting master keys step, with an only 8 byte long response. I am using the same provider as you are. Is this also where you get stuck?
I have been trying to sniff my STB communication by using Wireshark, but it seems as almost all communication is being encrypted. I did notice that there is a message being sent by the STB which contains some identification. There are some IDs in there as well, which I have tried as machine ID, but that doesn’t seem to make a difference either. I have also noticed in the dump that other ports are being used than the default ports by my STB. These however throw the error that there is no certificate presented by the server.
Right now I’m kind of lost. Did you make some progress already?
Unfortunately not, I have been trying some stuff out, but have not been able to make any progress… Except for figuring out the protocol is 1156 now.
if needed, you can reach met a [myusername]@hotmail.com
Hello. I’m not good at this, that’s why I’m asking here. Does anyone have a corrected image for docker?
in
vm_api.c
#define GETKEYS_BUFFSIZE (1024 * 100 * 2)
Does anyone have a clue how to get ve*im*at*ix certificates out of android apk? Or maybe from vi*e*ri*ht plugin?
I want to stream the video using vmcam to decrypt it and send the video stream to another machine on my network. Has anyone been able to do this? I tried TVheadend, but couldn’t find a way to do it. I also tried some other command-line tools (speaking newcamd) but they failed to decrypt the video properly.
Hi.
Until last week, vmcam (nwcamd) + tvneadend everything worked. The IPTV channels were decoded.
The TVheadend server crashed and had to reinstall everything (latest version downloaded: 4.3-2117~gf32c7c59a)
After setting, Rostelecom channels are not decoded, you can see in the vm?am:
[KEYBLOCK] Master key 1 selected
[KEYBLOCK] AES Key bc 61 1a e3 32 a0
[KEYBLOCK] DEC 43 45 42 2 1 2 0 21 2 f9 74 d8 b9 77 b5 7b
[KEYBLOCK] DEC 8b 98 5a 14 74 f2 74 55 6d 31 f9 29 c3 bf 38 8a
[KEYBLOCK] DEC f1 50 d7 e5 e 3a f9 a4 17 2 3 0 1 0 2 4
[KEYBLOCK] ECM 80 b0 79 56 0 e5
[KEYBLOCK] Key 1 f9 74 d8 b9 77 b5
[KEYBLOCK] Key 2 31 f9 29 c3 bf 38
[KEYBLOCK] ECM decrypt check passed
[NEWCAMD] Send message msgid: 8186, serviceid: 1, providerid: 5636352, length: 45
[NEWCAMD] sended data 1f fa 00 01 56 01 00 00 00 00 80 00 20 f9 74 d8 b9 77 b5 7b 8b 98 5a 14 74 f2 74 55 6d 31 f9 29 c3 bf 38 8a f1 50 d7 e5 0e 3a f9 a4 17 29 5e
[NEWCAMD] Read message of 144 bytes
[NEWCAMD] Received message msgid: 8187, serviceid: 1, providerid: 5636352, length: 124
[NEWCAMD] received data 1f fb 00 01 56 01 00 00 00 00 81 b0 79 56 00 e7 00 00 56 4d 45 43 4d 02 00 02 00 00 25 58 23 14 aa 00 11 eb ba dd 18 9b 00 1a 84 42 f3 df ab 2f b9 4e 32 f8 6a 65 88 b0 18 d4 45 81 38 e3 38 af 62 15 e9 36 c1 4f ca 03 6f 3a 5f d6 36 4d 8b fd f2 82 1a 0f b4 4c 75 cc 43 6a 36 a6 03 76 fd 32 d1 2b 02 3a ff 1a 4c 36 65 fe f2 c2 0f 0a 7c de 0a a5 81 df 17 37 ad d9 1c 62 82 c3 22 f9 ae 04 49 f5 4e 76 d9 ac 25 a8
[KEYBLOCK] Find control word for Channel 9560 table 0x81
[KEYBLOCK] Master keys found for Channel: 9560. Valid till: Tue Apr 25 00:00:00 2023
I don’t remember what version of tvheadend was before…
All works for me, nothing changed.
But I use vdr.
Hi. Andrey.
Maybe it’s in the tvheadend itself?
On various forums they write that with each release they break something in it. Now I’m looking for a version on which everything works, so far without results.
Looked at the vdr. but have yet to understand how it works.
Thank you.
Hi. I figured out the decoding of TV channels in tvheadend.
Is it possible to do more decoding of VOD content?