The instructions below DO NOT WORK with the new protocol version 1155.
See VMcam – Part II for updated information.
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
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
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.
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).
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.
Nice article. What software can be used for decrypting the stream?
Tvheadend for example…
Thanks! jeweet
I keep getting the error:
[tcp-client] Connect to 82.139.***.***:12698
[tcp-client] Received 0
[API] Unable to get encrypted password
Any hints?
All I can tell from those 3 lines is that the server is closing the connection without sending any data.
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)
Can you send your config file and logs to info@jeweet.net?
Done, thanks!
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?
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.
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.
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… ;-)
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.
Disable the API get encrypted password
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?
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.
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.
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.
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.
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.
Correction: I saic https, but I mean SSL.
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.
Skoffie: what was your former provider, when it did work? I’m considering switching to a different provider.
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.
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
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.
Hi where can i finde the Company name im trying every thing but cant finde it.?
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.
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.
I meant “openssl s_client -connect [VCASADDRESS]:[VCASPORT] -verify 5â€
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)
“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.
Does anyone know if IPTV with VMCAM will work with T#LF#RD in the East of the NL ?
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?
Hi.
vdr plugin dvbapi can aes now.
for oscam use patch
http://www.streamboard.tv/oscam/ticket/4588
and
http://www.streamboard.tv/oscam/ticket/4587
Patched oscam works fine with vdr and tvheadend.
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 :)
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?
Same problem over here. Worked last time on 09-07. Any ideas?
Mark + Frits, which provider?
For me it is telf*rt.
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?
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)
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.
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.
Nvm the old firmware images. That’s probably not going to work. I just need a STB with the original firmware and console access.
Unless someone has old firmware for the a140 where console access is still enabled. That might actually work. Not sure…
Hint, 5 digits, total length…
Found the customer public key today. Was able to decrypt all encrypted files :). Making steady progress…
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.
Any progress?? with this project
Does anyone know if IPTV with VMCAM will work with t*m*bil in NL ?
Nope, V*d*f*n* before it was sold to t*m*bil used MA.
Thanks for the awnser , wat do you mean by MA ?, is there any IPTV provider in NL wich I can use with tvheadend ?
https://en.wikipedia.org/wiki/Mutual_authentication
And yes, there are providers which you can use, but only the channels where you have a abo on.
You can search on a name above on ***hub.com there you can find the right information.
Good luck!
So it’s been a while, but I managed to completely reverse engineer the firmware creation process and managed to get custom firmware running on my set-up box. Essentially I now have a decoder with (near stock firmware and) root access. This mean I can now research some processes more closely, but also completely customize my decoders menu and options (since that is essentially just static HTML and JS)
There is still a lot of work to do, but this is a good start. Also here is a little something I wanted to share: https://gist.github.com/marri5317/14b52301104674dc7378270a309a4633 It’s the public key used by Gl*sh*rt to encrypt all .enc files
Hi marri. How did you root your Amino? Mine is really well protected, both software and hardware! Only open ports are ACS and STBM*nit*r when is enabled in hidden menu. But I couldn’t root the box! How did you manage to access the system?
Hi there!
Many thanks for the awesome job you did! Works like a charm!
This last week i’m getting “[KEYBLOCK] ECM decrypt failed, wrong master key or unknown format”
on some channels (prox 10-15 out of 80). Do you know why and what i can do to try to fix it?
Those channels works on the tvbox with same udp that Im trying them.
Thanx in advance! :)
EDIT: From sniffin out of my tvbox I found out that only when tuning into those channels (that get that error on) the tvbox don’t use the masterkey but does a new connection to the VKS. Same IP and port as it does for the master key but with different answering ports from my box->VKS for every channel (those specific channels mentioned above)
Any idea how to get around this?
I have the same problem!
Can someone help me to decrypt the ssl on wireshark so I can understand the different connection the tvbox makes when decrypting those channels mention above compare to the connection it makes the first time to get the master key? Bcs It looks like it gets a new key for each of these channels (10-15channels) and stores them like the master key for the rest of the channels since it only connects to the VKS server first time I tune to the channels and then uses the same key for the rest of the time the box is on.
Hope Im clear enough :) And would really appreciate your help since I HATE to be forced to watch on the TvBox!
Perhaps we can figure this out together
Yeah we should try!
I’m trying to find the key to decrypt the ssl connection of the stb to be able to see what conversion is going on on those channels that can’t be decoded with the masterkey. After competing that task I think editing the code won’t be a big problem.
Saw that Marri posted a key for the device he is working on but that one doesn’t work with my provider T*lia.
Do you also have that provider Marcus?
So I’m not exactly site what is happening since our environments seem to different. Could you maybe link a pcap of what you’re seeing?
Can I send you a PM somehow since I don’t want to post it online here?
Sure, email me at martijn (at) vhoof (dot) com. I’m happy to help :)
Yes i have.
Send me a pm to trashpile@live.se and i can add you on fb or something.
Marri did you receive my email with the pcap file? :)
Yes I did, uhm I’m not exactly sure what goes wrong here. I haven’t looked too closely at the encryption of videostreams yet so I’m not too familiar with the process. Decrypting the TCP stream could be a hard task depending on the circumstances.
I understand! But theoretically speaking shouldn’t the solution in decrypting the TCP streams be in the vmcam script, since it clearly can read the conversations from the server when connecting to it through ssl to get the masterkey?
If it helps i can send you the debug from my vmcam when connecting to the server and receives the masterkey?
The reason vmcam can read those tcp streams so easily is because it performs the ssl handshake itself. It will be very hard to read the streams if you don’t have full access to the amino (and it should be, otherwise the ssl encryption is broken).
One way to read the encrypted traffic from the amino would be a man in the middle attack with sslsniff. This would require a self-signed ca to be installed on the amino.
I am willing to look into this, but I would need to root my amino first.
Marri, would you care to elaborate on your progress with the firmware so far? Maybe share your rooted firmware with some instructions on how to use it?
We might be able to arrange something like a dedicated article or an appendix to this one for your progress if you want. Send us an e-mail if you’re interested.
Pingback: VMcam – Part II – jeweet
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)
“