VMA Crypt

Attached is my new VMA Crypt tool.

This is a simple TS encoder/decoder using a lightweight byte-wise cipher based on an 8-byte key (16 hex characters).

It takes a UDP input port and outputs the processed TS via a UDP output port.

One instance runs in encoder mode, the other instance in decoder mode. Both sides must use the same key.

The TS structure (188-byte packets, PIDs, timing) is preserved, making it compatible with standard DVB modulators and analysis tools.

With correct key:

With wrong key:

This serves two applications:

1. A simple and fast way to scramble a TS feed in controlled environments, without requiring hardware that supports standards such as BISS.
2. A proprietary, non-standard TS scrambling method for training and experimentation.

This is not DVB-CSA, BISS, or any official CA system.

Regarding security: this method is intentionally simple and not cryptographically secure. It should not be used for protecting valuable content. In a controlled lab or contribution environment, however, it may still be good enough for basic scrambling needs.

I will publish this later in the VMA Video Analyser Package.

DISCLAIMER

Nothing in this project is meant for illegal use. I am not decoding Pay TV, I am not using CSA, and I am not trying to enable any kind of unauthorized access.

This project is simply my own tool for encrypting selected services inside a DVB Transport Stream and decrypting those same services again with a user-defined key.

It is a proprietary method, made for testing, learning, and professional use in controlled environments. It has nothing to do with official CA systems and it is not intended as a replacement for them.

So once again: this is not a Pay TV decoding tool.

I have been having sleepless nights again, but finally I have the whole workflow working!

My very own "VMA Crypt". It can encode and decode selected services in DVB Transport Streams - more than one.

The decoding can be done globally (decoding more than one service) and forwarding the decoded TS via UDP or by means of an MD API style DLL, which is what took me so long, due to lack of documentation and apparent variations in the implementation by different software.

Here is an example of the complete workflow:

1) Reception of TS to be used as the source using VMA Stream Reader:

The TS is streamed via UDP to port 1234.

2) Encryption with VMA Crypt Pro:

This will encrypt the selected services (in this example "HSE Extra HD") using VMA Crypt. The resulting TS will be output via UDP to port 1235.

3) The TS is then modulated and output with DVB-S QPSK 3/4 34655SR modulation at 1023MHz using Dektec DtLoop and a DTA-2115 modulator:

4) Finally, I use AltDVB with the VmaCrypt.dll to decode the service:

The Plugins menu shows the CA name "VMA_CRYPT":

The plugin monitor shows:

If you enter the wrong key, no decryption happens:

Conclusion:

VMA Crypt is a simple DVB TS service encoder that can encrypt one or several services inside a transport stream and decrypt them again either with the same application in decode mode or through a DLL.

The main idea is practicality: it is cheap, does not require extra hardware, and can be useful whenever a TS needs to be sent over a link with some basic level of protection.

The other obvious use is educational and experimental. Since both ends are under full control, it becomes possible to test and understand a live encryption/decryption workflow in a much more direct way.

At the moment, the encryption itself is not strong. It is based on a simple cipher using a 256x256 matrix and a 16-byte key, so with a small dump it would probably be possible to recover the key by brute force or analysis.

Still, the important part is that the overall system is now working. That means the crypto layer can now be replaced or hardened later without changing the general concept.

Note: I have not published this, yet.

Attached is the VMA Crypt Pro software.

You just run the executable: one instance to encode an incoming UDP TS, a second instance to decode an incoming UDP TS. Make sure to set the IN/OUT ports accordingly. Use the Mode combo box to switch between Encode or Decode modes.

Instead of a second instance for decoding, you can use the included DLL with software that support MD API style plugins. Beware that the DLL is not compatible with all applications. For instance, it does not work with TSReader!

A valid VMA Video Analyser Package license is required.

Hot fix.

You need to enter the same code in the plugin!

Try to change one letter on the encoding or decoding side and you will see that you get no image.

But I think you will need to use a modulator, since most TV applications do not support UDP streaming as a source.

The plugin does NOT work with TSReader Pro.

This is an encryption/decryption solution for "VMA Crypt". It uses a 16 character or 32 hex digits key.

The same VMA Crypt Pro application can be used on both ends for encryption and decryption.

The DLL allows further client use for signals that have been modulated and are being received by a tuner.

As femi correctly mentions: This is NOT some PayTV decoder tool. It is my own system!

Here the disclaimer again:

DISCLAIMER

Nothing in this project is meant for illegal use. I am not decoding Pay TV, I am not using CSA, and I am not trying to enable any kind of unauthorized access.

This project is simply my own tool for encrypting selected services inside a DVB Transport Stream and decrypting those same services again with a user-defined key.

It is a proprietary method, made for testing, learning, and professional use in controlled environments. It has nothing to do with official CA systems and it is not intended as a replacement for them.

So once again: this is not a Pay TV decoding tool.

There is a specific reason I chose a simple cipher.

To implement proper encryption correctly, you typically need a per-packet nonce or counter (e.g. CTR/GCM modes). In a transport stream context, that immediately creates a problem: packet loss. If a counter-based scheme loses synchronization due to dropped packets, decryption breaks unless you introduce resynchronization mechanisms.

The alternative would be to carry additional crypto metadata (e.g. counters, IVs) alongside the payload. In MPEG-TS, that means either:

• modifying the 188-byte packet structure, or
• inserting external signaling and then fully demultiplexing/remultiplexing the stream

Both approaches significantly increase complexity and processing overhead, especially if the goal is to keep the pipeline lightweight and real-time.

My constraint is simple:
I receive a 188-byte TS packet and want to transform exactly those 188 bytes — no restructuring, no buffering dependencies, no external state.

Given that constraint, using something like DTLS/OpenSSL does not really solve the problem. If the same key/IV strategy is reused per packet without proper sequencing, you don’t gain meaningful security anyway — just complexity.

Time-based variation is possible, but introduces synchronization issues between endpoints and still doesn’t provide strong guarantees.

So this tool is intentionally not trying to be “secure” in a cryptographic sense. It’s a lightweight scrambling layer that preserves TS integrity and real-time behavior, without requiring full demux/remux or strict packet continuity.

And yes — this exercise really highlights why systems like CSA were designed the way they were, including tight hardware integration and controlled state handling.

And of course, I want to keep the TS compliant so that it can be modulated into a DVB-S/S2/T/T2/C/C2 transmission, as shown in one of the previous posts.

I do not want to use DVB-CSA, because it is protected IP and me using it would be illegal.

Also, I do not want to have to remux the TS - this is what I meant with performance.

Finally, I don't want to "protect" the UDP transmission, but the selected services inside the TS, while keeping the TS itself compliant for modulation and demodulation.

All of this has been achieved with "VMA Crypt": My demonstration encrypted selected services in a TS, modulated them into a DVB-S2 transponder and then received this signal using a TBS tuner, to be decrypted and finally played.

The only downside is that the key is fixed and it is possible to retrieve this key by capturing a few packets and using repeating structures of the embedded MPEG to derive the key.

To improve this, I would have to embed serialization in the packets, which would force me to remux the TS. Without it, the only improvement I can think of consists in using time on both ends, with an as narrow as possible time window (small enough to not allow capturing, big enough so that both ends are on the same time window).

Because of the way I implemented "VMA Crypt", it is possible to encrypt one or multiple services, and decrypt one, several or all of them on the receiving end.

The use case is my personal education and research. But as it is it could be a cheap and convenient substitute for BISS v1, but less secure.

This is a great idea: "keys could be exchanged via secure communication over internet"!

I like this.