VMcam – Part II

VMcam – Part II

VMcam – Part II

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:


protocol 1155 would start them with:


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:


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.

51 thoughts on “VMcam – Part II

  1. marri

    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.

    1. skoffie Post author

      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.

    2. A

      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)

  2. Frits

    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.

    1. skoffie Post author

      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.

      1. marri

        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?

        1. skoffie Post author

          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.

  3. Frits

    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?

  4. marri

    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.

    1. skoffie Post author

      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.

      1. marri

        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.

  5. Maarten

    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?

  6. skoffie Post author

    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.

  7. Reynard

    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?

  8. ObjectiveEmployee

    Can confirm, got it working with L*tvi*n IPTV provider L*tt*l*c*m.
    Thanks for your great work!

  9. X*4*LL. customer

    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
    [tcp-client] Received 8
    [API] GetAllChannelKeys failed

    I have obfuscated the company name in the log message.

  10. aivar11

    I have configured TVheadend to use VMcam and VMcam shows successful ECm decode messages, but IPTV stream is still scrambled.

    1. Mark

      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…

        1. fperea

          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!

  11. henkvdt

    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?

  12. WPK

    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

  15. Robert

    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 generated, sending…
    [API] Requesting Certificate: 1155~00**~************~getCertificate~COMPANY~NA~NA~—–BEGIN CERTIFICATE REQUEST—–
    [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

      1. Robert

        Ehm, seems there’s an issue with the mx provider. You wouldn’t happen to be on IRC (libera/oftc)?

      1. Nick

        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?

        1. mr_blond18

          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

  16. Rustam

    Hello. I’m not good at this, that’s why I’m asking here. Does anyone have a corrected image for docker?
    #define GETKEYS_BUFFSIZE (1024 * 100 * 2)

  17. Marian

    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?

  18. anon

    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.

  19. Rustam

    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…

  20. Rusram

    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.

  21. Rustam

    Hi. I figured out the decoding of TV channels in tvheadend.
    Is it possible to do more decoding of VOD content?

Leave a Reply to Andrey Cancel reply

Your email address will not be published. Required fields are marked *