← All talks

Decrypting IPTV

BSides Sofia · 202234:16559 viewsPublished 2022-04Watch on YouTube ↗
Speakers
Tags
Mentioned in this talk
About this talk
Radoslav Gerganov explores the security model of IPTV delivery systems used by Bulgarian ISPs, examining how set-top boxes decrypt scrambled video streams. Through reverse engineering of proprietary firmware and conditional-access libraries, the talk demonstrates practical vulnerabilities in authentication and stream encryption, including techniques for hardware console access, binary analysis, and key extraction.
Show original YouTube description
BSides Sofia 2022: Decrypting IPTV Many ISPs in Bulgaria are offering IPTV to their customers in addition to internet services. Usually IPTV is delivered with a set-top box device (STB) which is connected to the ISP network and the user's TV. by Radoslav Gerganov
Show transcript [en]

Hello everyone! I am Rado and in this presentation I will tell you how IPTV streams with various software and hardware hacks can be decrypted. To introduce myself in a few words, I work as a programmer in VMware, I deal with Confidential Computing, virtualization of HSEs. Coverage Guided Fusing. In this presentation, I want to make a disclaimer that I am not talking about VMware in any way. Everything I show is done in my free time and is freely accessible on GitHub. In fact, most of the things I do outside of work I publish as open source on GitHub. Let's start with what is IPTV. I'm sure you all know what IPTV is. It is a television that is delivered with IP networks. In Bulgaria

there have been many IPTV providers for a long time. There are different types of content. You can watch live streams and also video on demand. There is some interactivity, you can turn it, pause it, or start it, which makes it more attractive as a service to this TV, the ether one. And actually, what is very important from the security point of view is that usually it is shared with set-top boxes, which I will talk about a little later. Different sets of protocols are used, different suppliers use different things, but in general, IGMP, RTP, RTSP, UDP are used. In this presentation, I will show you, actually, the focus will be on the IPTV services that are delivered in Bulgaria, but in

general, these things are valid in general, because the software stack used here is used in many other places. What does the IPTV deployment look like? We have a set of boxes, which is connected to the Polan delivery. and to the HDMI TV. And you can control it with any other device. Now here I assume that IPTV provider is the same as the Internet Service Provider, which is usually the case, because in most cases the content is delivered on multicast, as we will see. So here we make a assumption that IPTV ISP provider is the same.

What is the security model of this thing? From my point of view, from the point of view of user experience, I have IPTV for a long time, I think it is mainly based on the fact that The providers rely on the fact that not only the set-top boxes know how to play this content. And that the set-top boxes can... the only user interface that the user has is actually some kind of remote, right? Which clicks. And as a whole, if you need to search for security, true obscurity, this is such an anti-pattern. which everyone knows that this is not working and in this presentation I will show you what the problems are. The problems are that it is not necessary to pay for

additional channels. Most IPTV providers have packages with TV channels and you can pay to watch more. Also, adding a set of boxes is not free. And in general, it is clear that it is not necessary to pay for IPTV. But first, what is a set of boxes that is used for IPTV? from the IPTV providers. In general, it is a cheap device, imported from China, which is cut to the maximum to be as cheap as possible, which is not bad. Almost for sure it runs on Linux with some ARM system on the chip. And now the interesting part is what kind of firmware is there. The firmware actually represents an HTML browser and a video player.

This video player is generally controlled with some kind of JavaScript. Here we are not writing a video player that is available in modern Internet browsers. In the Internet browsers there is already an HTML5 video player, but here it is something different. This video player is specially made for these devices. It is controlled by JavaScript and and there are hardware video decoders. We have some hardware video decoders in general. And the other thing is what the user interface of this whole thing actually is. It turns out that it actually represents HTML and JavaScript. That is, this thing you see is actually an HTML page and as we are talking about the distance, this is actually an interaction with some JavaScript.

And since I will start with a little history, since I have been wondering for a long time how the whole thing works, as well as the Internet at the beginning, most of it was not encrypted, so in 2016, when I decided to see what was going on on the network, it turned out that everything was going in plain text. Here on this screenshot you can see some kind of a capture, some kind of a dump of LARCHARK, in which we can clearly see what the top box sends. It sends some commands via RTSP. RTSP is Real Time Streaming Protocol. And it just says, here it is a bit truncated, but it says "Play" some IP, CH and some ID, which is 20 digit. And

what actually happened? It turned out that there was no server site authorization. So this problem was in every presentation so far. We started with a school, where it turns out that when we change some ID to a post application, we can get access to some data that is not ours. Then with the CV chargers we saw that When we change something in the request, we can get... The general problem is that very often there is no server site authorization. The fact that you are authenticated means that you have the right to do something. And here in this case are not exactly APIs, so in this case the IPTV provider relies on the fact that only some devices with specific MAC addresses can access it. From

there on, everything is... there is no authorization, that is, if I decide to send an application to another channel, it is enough to know its ID. And these IDs are all in JavaScript, which runs on the network, which is also plaintext. Including various paid channels. And at that moment I started thinking about what could be done. My first idea was to replace the set top box with a device that speaks about protocol. and which can play the entire set of channels, assuming that I know all the IDs. But this is not very interesting and it takes some time. And actually what is easier to do is just to change these IDs to some kind of "man in the middle". that is to change

the traffic and simply replace the IDs with other IDs, because in most IPTV providers, with 200 channels, 80% of them are not for viewing. We can simply replace some channels that are not happening with some more interesting ones, which are paid in general. And for this thing So I created a small tool called FQset, which uses the Linux NetFilterQ library. This is a library that can intercept and modify network traffic. And this whole thing can be deployed on one Raspberry Pi. We have a Raspberry Pi that stands between the delivery and the box, runs the program and replaces some strings. And here the main thing is that these IDs are fixed length. That is, always with CH and a

20-digit number, which makes things easier. And it looks like this. Here on this picture a Raspberry that is built-in to the adapter, its network adapter is connected to the provider and there is a USB network adapter that is connected to the set-top box. The two adapters are bridged and the program that I use is running, which replaces some strings with the channel ID. But all this was six years ago, it is not that interesting. How do things work today? At the moment, most IPTV providers use multicast for live streams. Why multicast? Multicast is effective because you can send a package, not a copy to everyone, but you can send it immediately and the network infrastructure

will give it to everyone. and we use the IGMP protocol to join to multicast groups, that is, there is a join and leave, when we switch some channels, the set-top box makes IGMP requests. And that's why the multicast has a dedicated IP range from 224.0.0 to 239.255.0. So, actually, The first thing we would try to do is to see what is going on on the network. We can see that the IP of Multicast Ranger is ported, the protocol is RTP. And now, for example, let's see what happens if we plug it in with VLC and we see that nothing is visible. We don't watch the stream. However, VLC gives us some information about it. I don't know how well you can see

it, but VLC says there is an audio stream, which is MPEG-2, there is a video stream, which is MPEG-2, and the same interest is that it shows some metadata for this stream. The metadata is that, for example, the program is called 24 Kitchen, and the most interesting thing is that it is scrambled. This is somehow encrypted. Where do these metadata come from? They come from MPEG, MPEG Transport Stream, which represents multiplexing of so called elementary streams. Elementary stream is video stream, audio stream and various metadata streams. One of them is the program Map Table. From there we can take the name of the program, as we see it, VioSitum says it's 24kitchen. And the other interesting metadata, which are actually

the most interesting, are the so-called entitlement control messages or ECM packages, which participate in the decryption of the content. This is how an MPEG transport stream package looks like. It is 188 bytes long in total. It starts with a 4-byte header. At the beginning there is a sync byte. And here the interesting thing is that there are two bits in this header that are called Transport Scrambling Control and they say whether the payload, which is 184 bytes, is scrambled, that is, scripted. And in fact, when VLC tells us that it is a scrambled stream, these are actually the two bits in the header that show it.

So I started doing research on how it works and what kind of information is available for it. It turned out that there is the so-called conditional access system or CAS, which are standard methods for uploading digital streams and which are actually most often used for satellite television. They are also listed in Wikipedia, here I have taken a very small part of them. The idea is to give access only to users who are authorized in some way. And actually what the satellite TV's that use the Agenda Access System use is that there is such an algorithm called DVB Commons Kremlin algorithm which actually does this encryption. But it turns out that IPTV conditional access systems don't work

like that. For example, the big IPTV providers and various telecoms use the Verimatrix vendor, which Each system has an ID, which can be seen from the metadata on the stream. For example, I saw that the ID is 5601, so I understood that it was a matter of Verimatrix, a system for encryption. In general, there is no real information on how this thing works. The only public information is what I have downloaded on GitHub, except for some marketing bullshit. And this is exactly the thing that the whole thing works on the basis that people don't know exactly what is happening. If we have to look at how satellite TV works, we have an antenna that receives a signal from

a satellite, then there is a set-top box, but the difference is that the set-top box has a smart card, which you buy to watch some service. And the way this thing works is that These ECM packages carry the so-called decrypted codewords and then the topbox decrypts them using the smart card. And accordingly, it receives the decrypted codewords and decrypts them with this algorithm, the common scrabbling algorithm. For IPTV, things are very similar. We don't have a satellite, we have a provider that is one-way, delivering a stream, but through multicast. And we have a set-top box that doesn't have smart cards and, accordingly, in order to decrypt this stream, there are surely some keys somewhere that decrypt it

and can be viewed on TV. And now we started to understand where these keys come from. The only way is to to root the box and reverse engineer the form. There are well-known ways to root a Linux device. The most popular is to find a set of consoles which are actually some pins on the board that we can connect and get either access to the bootloader or directly to the road shell. This is something related to 3PIN, RX, TX and MASS. The only thing we need to know is the Baud rate, which also has fixed values. Most hardware vendors leave the console open. This is the most common method for routing Linux devices. Another method is JTAG. JTAG is a low-level debugging interface,

which vendors leave for debugging after the device is made. With it we can actually operate at a very low level, we can change the execution flow, we can change memory, For these two ways, we need to find some 3-pin of the board, for JTAG there are more. There is a tool called JTAGulator, which you can just install it to some pins and it will find these interfaces, for example, these 3 pins are for a console series, For example, these 4 pins are JTAG, which means that this thing is somewhat automated. And the most advanced way is with the so-called Power Glitch attack. This is when we give a certain transient voltage to the device for a certain number of nanoseconds. which makes him skip

some instructions in the form or skip some checks. This is quite advanced. The creator of this JTAGulator, Joe Grant, recently published a new video, how a man with a hardware wallet comes to him, holding keys for bitcoins worth a million dollars, and who has forgotten his PIN. Joe Grant managed to open it with a power glitch. It's very interesting to watch. I'm not a fan of it. What I use and what has been working for me for 10 years for these boxes that I have in Bulgaria is: you take an Arduino, remove the processor and it becomes only like a USB to serial converter. You take three wires, the ground is very easy to find and you just

need to find the Rx and Tx on the board. This is how it works. And we get a road shell. If we look at the set-top box, there is a 100 MHz ARMv6 processor, a very old kernel, NEO2635, and this thing has 512 MB of RAM. And now the question is how to reverse the formula. So why do we need to reverse the formula? We need to answer two basic questions: where do the keys that decrypt the stream come from and how do they use it? Because obviously it is not this common Kremlin algorithm, but something else. In my case, both things were done in a shared library called LibVM Client. And here VM is most often classified as VeriMatrix.

The tools I use for reverse engineering are Ghidra, an NSA tool, Disassembly Decompiler and GDB, a standard debugger. Hydra is used for static analysis, GDB for runtime analysis. What you actually need to do is to launch the GDB server on the box, to attach it to the process of the video player, which is actually linked to this library, and to attach to your machine remotely to the GDB server. And you can already set breakpoints, view memory, and so on. So, every thing that uses some kind of cryptography is very likely to use OpenSSL. And in this case, if we put OpenSSL in the strings of this library, we will see that OpenSSL version 1.0.0.d is used. And actually, the method that I use, which

works not only for... which as a whole, I think the most popular one is OpenSSL, because it is obviously static related to this library. We need to identify where in this library are the OpenSSL functions, for example, for encryption and signing. And when we know them, we can put breakpoints with GDB to see what the keys are and how the whole thing works. And this is actually part of the decompiled function with Hydra. It turns out to be some kind of pseudo-C code, which is quite readable. And for example, here in this function we can see that some function with four parameters, for example, we allocate some data on the stack, At row 16 we think that

the third parameter is 0, then we call a function with the data from the stack, then we call another function with the data, for example, at row 18 and with the first parameter, and then in the next part, which is actually the joker, at row 29 we see a constant pi-sign.c. and then 0x7d. And in row 35, type "sign.c" and 0x83. This looks like a source file and a number line. And if we look at the source of OpenSSL, we already know that it is 00d, we just go to GitHub, open 00d, find the file "pysign.c", For example, if we look at the function Sign Final, which is used for signing, we will see that it takes four parameters. At the

beginning it allocates a context in the stack. At row 76 it sets the third parameter to 0. And then the context creates some other functions with it. And further on, there is a utility called EVP Error, which It is actually a macros that uses the file line macros to call some function that follows some error codes. And here, I don't know if you can see something, but on the left is the decompiled function in Hydra, on the right is the source of EVP Sign Final and it can be very clear to match. 0x7d, where it was written, is 16-strikes, it is exactly 125-strikes, as we can see, and 0x83 is actually 131-strikes in OpenSSL code. This is really true. And in

this way we can see the functions of OpenSSL, where they are in this library, we can set the breakpoints and see what happens. The signing with OpenSSL is done with these three functions. First, we initialize some context and some digest algorithm, then we call an update with some data and finally we say "sign final" as we give the private key. And we are interested in this private key. After we have identified which function is "sign final", we can put a breakpoint and see what the private key is and, accordingly, what is signed with it. And after we have this RSA key, which is used for authentication, what is the protocol to take the channel keys with which the stream

is created? And here we have a very basic protocol, which someone has designed in the 90s, I'm sure. This key server, which I call VCAS, First, the box tells him to give me a session key with my MAC address. He returns some RC4, a Cipher key and a timestamp. and then Box says "give me all the keys" and makes an MD5 on this timestamp, signs it with the RSA key and encrypts it with the RC4 session key and as a result of this it gets all the general keys, which are... one general key represents 128-bit asymmetric IS key. And this whole thing, because because the providers allow this key server to access it only after the boxes, i.e. they made some firewalls for their MAC

addresses. What I do is to use SSH and the box as a jump host. We run port forwarding with SSH. on these IPs and these ports, we can call the script that ran the keys to run it to the localhost. This way we bypass this firewall provider. How are these Channel Keys used? So, Channel Key decrypts the ECM packages. The ECM packages decrypt two keys, read and unread and these keys decrypt the S-Packages. The channel kills change every 24 hours, the other two keys rotate every 10 seconds and I implemented all of this in a small program of my GitHub called vndcrypt. The problem with the whole thing is that these channel kills rotate for 24 hours and can be shared very easily. That is,

it is enough for someone who has pulled them to upload them somewhere and then everyone who has access to Multicast streams can decrypt them. It turns out that these multi-cast cryptic streams reach absolutely all clients of the provider. Not only those who pay for IPTV, but everyone. It is enough for one person to publish these keys 24 hours at once and everyone can watch for free. There is also the same hack for satellite TV, there is the sharing of the keys from the smart cards. And finally, what should be done? True security usually doesn't work. As we saw, we need to have authentication and authorization. This problem some content to be delivered to multicast encrypted and

different hosts to decrypt it. In fact, it is called multicast encryption. Some people have researched it, there are written articles on the issue, it is not a simple problem. And in my opinion, one of the potential solutions for this to become secure is confidential computing. This in general represents Using what modern processors have, like secure enclaves, for example ARM has, ThreadZone, Intel has, SGX, AMD has, CEF. In general, this is a technology that allows some code to run in isolation and you can't just hook a debugger to it, nothing like a root. And that's all I have, if you have any questions. Yes?

No, actually what I see is that absolutely all paid channels, those that are paid, they go to multicast. The provider that does it is just to say to the set-top box to play them too. So, if you have the skills, you can watch all the channels that this delivery offers. - And if someone is buying these channels, there is no way to sell them? - Yes, if the dedication is left, it helps, so it should work. - And what is the main reason for this? - Yes. - What is the main reason for this?

Yes, for every Linux device it works. Ok, thank you.