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.

33 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…

  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

Leave a Reply

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