VMcam – IPTV softcam

VMcam – IPTV softcam

VMcam – IPTV softcam

The instructions below DO NOT WORK with the new protocol version 1155. If anybody has some info or documentation on this new version, please contact us on info@jeweet.net

On the local fiber network, my ISP is providing IPTV streams which can be viewed with the help of their proprietary box called Amino. However, the problem with the Amino is that its interface is horrible and the box in general is just plain slow.
Time to find a solution for this and sniff some traffic on this thing. I quickly found out that the streams it uses are UDP multicast, but unfortunately they did seem to be encrypted. Luckily we have a solution for that and it’s called VMcam. VMcam is a small program which connects to the provider’s key server pretending to be the dreaded Amino in order to obtain the decryption keys for the IPTV streams. Here’s a short explanation on how to set it up, including some small hurdles I had to pass before it worked.

First of all you will have to obtain the program itself. You can either get the source from GitHub or https://jeweet.net/repo/source or you can choose to install a compiled version from the jeweet.net debian repo (amd64 only at the time of writing). Compiling your own binary from source is as easy as executing the following commands.

$ git clone https://github.com/macm00v/vmcam.git
$ cd vmcam
$ ./configure
$ make && make install

Now you should have your vmcam binary in /usr/local/bin and you just have to set it up for proper use. To accomplish this, you should create /etc/vmcam.ini and adjust the following values to your need.

CACHE_DIR=[Cache directory, default /var/cache/vmcam]
DEBUG_LEVEL=[Debug level]
AMINOMAC=[MAC address of your Amino, format 010203040506]
VCASSERVERADDRESS=[VCAS address]
VCASSERVERPORT=[VCAS port]
VKSSERVERADDRESS=[VKS address]
VKSSERVERPORT=[VKS port]
COMPANY=[Company name]
KEY_INTERVAL=[Key update interval in seconds]
NEWCAMD_PORT=[Newcamd listening port, default 15050, 0 to disable]
CS378X_PORT=[CS378x listening port, default 15080, 0 to disable]
LISTEN_IP=[Address to listen for Newcamd/CS378x connections, default 0.0.0.0 (all interfaces)]
USERNAME=[Newcamd/CS378x username]
PASSWORD=[Newcamd/CS378x password]
DES_KEY=[DES key for Newcamd]

Now, pay special attention to the AMINOMAC and the various VKS and VCAS options. If you don’t know what to put here you can find out by sniffing the connections your Amino makes when it is connected to your ISP’s IPTV network. It will first connect to the VCAS server on two subsequent ports, followed by a connection to the VKS server on another port. In your config file, VCASSERVERPORT should be set to the very first port in the sequence and VKSSERVERPORT should be the third port number.

Note that from this point forward you should be connected to the network on which the IPTV streams are provided. This may require a special configuration of your network interface and DHCP client to mimic the Amino’s behaviour, which is outside the scope of this article.

The COMPANY option is a bit tricky to find out if you don’t know where to look. You can find it in plaintext in the packets captured from the Amino as a part of the following sequence:

1154~<COMPANY>~<TIMESTAMP>~<AMINOMAC>~#

Of course <COMPANY> here is your company name, <TIMESTAMP> is the current date and time (format: d/m/Y H:M:S) and <AMINOMAC> should be obvious.

The rest of the options should be pretty straightforward, but make sure that the cache directory exists and that the user that will be running vmcam has write permissions on it.

Now on some (if not all) setups, the encryption used on the key servers is terribly outdated, so newer versions of libssl will simply refuse to connect. This can be worked around by overriding the libssl library used by vmcam to an older version which supports DH keys smaller than 768 bits. Once you have this library, you should run vmcam as follows:

LD_PRELOAD="/path/to/old/libssl.so" vmcam

After setting this all up correctly, you should have a running softcam for your IPTV streams. You can connect either via Newcamd or CS378x to obtain the keys and use them to decode the streams in your favourite streaming server or DVR.
The addresses of the streams can be obtained either by sniffing traffic from the Amino while cycling through all the channels or by analyzing the original Amino interface data which is referenced in the DHCP lease message you will get when connecting to the IPTV network.

UPDATE 09/11/2016:
-Updated config file example to match the latest vmcam version
-Changed the port configuration part (thanks timmtim)
-New way to obtain the company name

54 thoughts on “VMcam – IPTV softcam

  1. Neill

    Hi,

    I am interested in testing this with my configuration. But how can I ‘snif the connections of the Animo’? Is there a tool for this?

    Thanks a lot for your answer.

    Regards, Neill

    1. skoffie Post author

      Hi Neill,
      There’s plenty of tools around to sniff the traffic. I used tcpdump on linux, but if you prefer a graphical tool the same can be achieved using wireshark, which is also available on windows.
      Apart from the software tools, you’ll need to find a way to be able to intercept the transmissions as they are being sent back and forth between your Amino and the provider’s IPTV systems. The most straightforward way to achieve this is to sit in between either with a pc with (at least) two network cards and set it up as a transparent network bridge or with a switch that supports port monitoring/mirroring.

  2. Pieter

    Thanks for the article and a working git repro! I’m still struggling to find out the correct VCAS/VKS ip addresses for XS**LL/K*N. (Maybe my capture is incomplete).

  3. skoffie Post author

    Hi Pieter,

    I found that the easiest way to find out which host is doing what was to analyse the DNS requests from the Amino and continue from there, checking one host at a time. All traffic to and from the key servers is encrypted, so you won’t see anything useful right away, but in my case the DNS hostname contained a hint already. Apart from that, this article was particularly useful for me.

  4. Maarten

    I keep getting the error:
    [tcp-client] Connect to 82.139.***.***:12698
    [tcp-client] Received 0
    [API] Unable to get encrypted password

    Any hints?

    1. skoffie Post author

      All I can tell from those 3 lines is that the server is closing the connection without sending any data.

      1. Maarten

        I can send or post complete logs if you would be willing to look at them, the request just before this one is correct and receiving data (45)

  5. timmtim

    I have a interesting problem with getting this setup working with K*N IPTV. In your tutorial you mention that in your case it first connects to the VCAS server and then connects to the VKS server on 2 different ports.

    In my setup i see that it first connects two times to the same host but on a different port (12697 + 12698) after that i resolves the ip of a host prefixed with VKS. Should be the VKS but that does not support the flow you had. Also only 1 connection is made to that specific host.

    The interesting part is that when i configure the VCAS server host with port 12697 all VCI steps are working. I can create a session key and request a certificate. The script now throws an error while retrieving the channel keys.

    Any thoughts on this?

    1. skoffie Post author

      In my case both the VCAS and the VKS server were on the same host. VMcam uses the VCAS address for the first connection and the VKS address for the second and third connection. If the first two connections are OK and it fails while requesting the channel keys, you might want to check your VKSPORTDIFF setting. The default is a leftover from an old version when it was still hardcoded, it’s now configurable for a reason ;)
      If you are 100% sure that the two connections to the VKS server are made to two different hosts you’ll have to change the VMcam source code to reflect this to make it work.

    2. skoffie Post author

      Just looking into this again and indeed you are correct! I will update the article and the source code accordingly over the next few days.
      Apart from this I also found out that the described way of obtaining the company name is incorrect, this will also be adjusted.

  6. docki

    I’m experiencing the same issues as Maarten has ( 26/06/2016 at 22:34 ). Before that, it has been working flawless until about August, but after that no more…

    My log is very alike the one on http://pastebin.com/FGgauF1u

    Can anyone shed a light on this?
    Thanks in advance… ;-)

    1. skoffie Post author

      Has your provider recently changed their TV platform? If so, you might have to start over from the beginning to figure out their new setup and adjust your config accordingly.
      If nothing changed on their side, you can try to clear your cache dir and restart vmcam to see if that helps.

  7. Phlox

    I’m struggling with the last step: GetAllChannelKeys (I see some resemblance to timmtim) It does connect (to port 12700), and returns 8 bytes. But this does not seem to be correct as it then fails with GetAllChannelKeys. Are there any pointers on what to verify?

    1. skoffie Post author

      I will update the article and the source code in the coming days. If clearing the cache dir does not work then you can try again with the updated article in a few days.

      1. Phlox

        Thank you for the update. It makes the explanation a lot clearer, and although I already figured out the company name, the new method is indeed an improvement.

        It did not however solve the issue that I’m seeing. The first two connections seem to go ok (got a pass with size 8). But GetAllChannelKeys still fails after receiving 8 bytes. The connection is made to vks14.***:12700.

        It might be relevant that my box is using format version 1155 instead of 1154, but it seems that the servers accept the other communication just fine.

        1. skoffie Post author

          Actually, the first two connections should receive a longer reply.
          In your case it seems that it’s already failing on the first connection, but vmcam is not handling it accordingly and just continues. The input data for this request is the message format, amino mac address and company name.
          If you are sure that both the mac address and company name are correct then apparently the newer message format 1155 is not supported by vmcam.

  8. Maximus

    It appears that some providers changed the protocol. I get the same behaviour as Phlox and I’ve actually seen the protocol change over time. It used the work as outlined above, but not anymore. The message format changed from 1154 to 1155 and the sequence contacting the servers is very different. The first few connections use https and only later the 1155 can be found, still in plain text. So, we’re out of luck.

    It would be interesting to know if this is provider or region dependent. Can we compare notes? I’m on T*lf*rt in the north east.

    1. skoffie Post author

      I recently switched to the same ISP, but in the east of the country. Same problem here. If anybody has some info on this new protocol version, please send it to info@jeweet.net.

  9. Maximus

    BTW, it could be we’re completely out of luck: since all providers are using the same IPTV service (Gl@sh@rt) and the same encoding technique (V#rim@trix) changes are they all updated the protocol or are in the process of updating it.

  10. Maximus

    Skoffie: what was your former provider, when it did work? I’m considering switching to a different provider.

    1. skoffie Post author

      It was still working with S*lc*n last time I checked. I changed providers because their internet connection was not very stable (short connection drops every night).
      S*lc*n recently changed their IPTV platform to use their own certificates instead of the old R#ggef!ber certificates amongst other things, but that does not necessarily mean that they will keep the old protocol version for much longer.

  11. marri

    So I’ve been working on this for the last couple of weeks now and I can confirm that vmcam still works with protocol 1154 (atleast for my provider T*lf*rt). I was able to get vmcam working together with tvheadend and decrypt every channel. However after a couple of connections my MAC address got blocked (atleast I seem to think so because I’m not getting an IP address from the DHCP server anymore). The reason for this “block” however can be anything since I had specified the wrong company name at the time, used the old protocol and connected to the server in less than 5 minutes (which an STB would never do). I’m currently looking at 1155, but if 1154 still works I don’t see why I would further investigate for now.
    Does somebody have any idea why my STB won’t get an IP address anymore or have any experience with his MAC being blocked?

    For the people that also have T*lf*rt (south) as ISP here is my working config for 1154:
    VCASSERVERADDRESS=vmx3.stb.zt6.nl
    VCASSERVERPORT=12697
    VKSSERVERADDRESS=vmx3.stb.zt6.nl
    VKSSERVERPORT=12700
    COMPANY=KPN-GHM

    1. marri

      I found out that the company your enter is depending on the address you enter as the vcassserver/vksserver (eventhough the ip might be the same). Turned out I made a mistake in my configuration up here.

      VCASSERVERADDRESS=k.zt6.nl
      VCASSERVERPORT=12697
      VKSSERVERADDRESS=k.zt6.nl
      VKSSERVERPORT=12700
      COMPANY=Reggefiber

      I successfully tested this configuration today with messageprotocol 1154. The MAC address “block” turned out not be a block, but just a coincidence.

  12. Andrey

    Hi. I have Fedora 25 and Ubuntu 16.04. vmcam compiled fine on both. On Fedora vmcam works fine, but on Ubuntu I have [ssl-client] error: -1 and [API] GetSessionKey failed. openssl version 1.0.2 is same on both distr. What could it be?
    Both computers are on the same network.

    1. marri

      I’m currently using OpenSSL version 1.0.1e and that works just fine. Are you trusting the rootca? Try “openssl s_client -connect : -verify 5”. It should display the error in detail.

  13. Andrey

    I have this:
    ….
    verify error:num=19:self signed certificate in certificate chain
    verify return:1
    —-
    3073889984:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3626:
    —-
    Secure Renegotiation IS NOT supported
    —–
    Verify return code: 19 (self signed certificate in certificate chain)

    1. marri

      “dh key too small”. This means the current version of OpenSSL you’re using is too new (it won’t except the certificate from the server since it’s lenght is too small). Try using version 1.0.1e.

  14. Andrey

    Hi.
    Tvheadend ->newcamd->vmcam works fine!
    But
    Tvheadend->newcamd->oscam->newcamd->vmcam not works :(
    Tvheadend->dvbapi->oscam->newcamd->vmcam not works :(
    vdr->dvbapi->oscam->newcamd->vmcam not works :(

    Have anybody some idea?

  15. barry

    Does anyone know if IPTV with VMCAM will work with VDSL telfort i only read about fiber but i guess that`s not really a deal since vdsl2 can work with serveral extra players so perhaps the same streams with be used from the backbone`s.
    I`m waiting for an answer before i will registrate my arcydan and start sniffing.
    This is because i perhaps better can add a Amino from the marktplaats and then follow the well documented guidings from this page :)

  16. Mark

    Since today, I’m getting a connection refused on all server addresses I know of. Already changed my mac to force new ip, but no luck. Anyone else have this problem?

    1. Mark

      OBN for me. Sniffed the stb today, which works. Connecting to same server as stb does still fails. What could be used to block it? Could it be missing vendor specific options in dhcp?

      1. Jan

        I also have the same problems since a couple of days.
        Searched for my amino box today. I start sniffing the network tomorrow.

        The DHCP is no problem for me, I still can access the network. The VC*S Server is blocking our TCP connection request.

        In my C# program I get, No connection could be made because the target machine actively refused it
        I guess they that there is something missing in the TCP message? (this is even before setting up ssl)

        1. Mark

          Yup, same here. I have no idea what the ‘filter’ is that causes the connection to be refused. I get an IP as usual as well and can ping the servers. Somehow the servers all block certain connections, but on what grounds? Not Mac, that’s for sure.

  17. marri

    So I’ve spent a couple days now trying to reverse the encryption of the firmware image in order to inspect the (new) 1155 message format. I’ve been able to successfully decrypt some V*rim*trix libraries however most configuration files with the .enc extesion are (not 100% sure) encrypted with the customer public key that is shipped with each STB device.
    At this point I’ve figured out which program is responsible for the encryption and the only missing piece of the puzzle is this public key. The key is stored in NOR flash address 0x10E87CCD, is signed by the PBL master key, can verify the signature on the STBrc key and has length=312. I assume that the same customer public key is used for all dutch providers, so just one for Gl*sh*rt.
    My question is: does anybody have or know somebody that still has an old firmware image (.mcfs) or a STB with console access to interact with the NOR flash memory? Or does somebody happend to have dumped the customer public key? I think we have a better chance to figure out 1155 once this encryption is broken.

    1. marri

      Nvm the old firmware images. That’s probably not going to work. I just need a STB with the original firmware and console access.

      1. marri

        Unless someone has old firmware for the a140 where console access is still enabled. That might actually work. Not sure…

  18. marri

    Found the customer public key today. Was able to decrypt all encrypted files :). Making steady progress…

    1. skoffie Post author

      Good to see someone is still working on this. I would love to use this setup again in the future, but reverse engineering the firmware is beyond my capabilities. If you can use some help with simple coding however, let me know.

Leave a Reply

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