Newcamd vs CCcam: a detailed comparison of card sharing protocols

The choice of card sharing protocol directly affects signal stability, decoding speed, and connection security. Newcamd and CCcam are the two most widely used protocols, each with its own architecture, strengths, and limitations. This article will help clarify the technical differences and choose the appropriate option for a specific task.

What is card sharing and why are protocols needed

Card sharing is a technology for sharing a conditional access module (CAM) card among multiple subscribers over a network. A server with a physical card generates control words (Control Words, CW) necessary for decoding the encrypted television signal. Client devices receive these words over the network and use them to decode content in real-time.

The protocol defines the data transmission format, authentication method, and encryption method for the communication channel. Its choice affects how quickly the client receives CW and how reliably the connection is protected from interception.

Newcamd Protocol: Architecture and Features

History and Operating Principle

Newcamd (New Camd) is a protocol developed as an improvement over the earlier Camd3 protocol. The main difference is built-in encryption based on the DES (Data Encryption Standard) algorithm with a 56-bit key. All data transmission between the server and client is encrypted, making traffic interception significantly more difficult compared to unencrypted protocols.

The architecture of Newcamd is strictly hierarchical: one server — one client. Cascading (transmitting CW from one server to another) is not provided at the protocol level in classic Newcamd.

Technical Parameters of Newcamd

Connecting Newcamd is defined by a set of parameters in the emulator's configuration file. A typical line in the filenewcamd.conf looks as follows:

Here, the last 14 bytes are the DES key, which must match on both the server and client. A key mismatch leads to an authentication error without any informative message, complicating diagnostics.

The standard port for Newcamd is 10000; however, administrators often change it to a non-standard one (e.g., 15000 or 28000) to reduce the load from automated scanners.

Encryption and Security of Newcamd

DES encryption in Newcamd provides a basic level of protection. It is important to understand that DES is considered an outdated standard, and with sufficient computational resources, the key can theoretically be cracked. Nevertheless, for household use, this level of protection remains sufficient — mass traffic interception in local networks or when using VPN is impractical.

Authentication in Newcamd is two-level: first, the DES key is checked, then the login and password. This reduces the risk of unauthorized access in the event of one factor being compromised.

CCcam Protocol: Architecture and Features

History and Operating Principle

CCcam (Cardsharing Client) is a protocol that has become the de facto industry standard for most Linux-based satellite receivers, primarily Dreambox. It was developed later than Newcamd and is initially aimed at supporting cascading networks.

The key architectural solution of CCcam is support for multi-level cascading. The CCcam server can receive CW from a higher-level server and transmit them to several lower-level clients, forming a tree of servers. The cascade depth (hop count) indicates how many servers the signal has passed through.

Technical Parameters of CCcam

The configuration of the CCcam client is defined in the fileCCcam.cfg. The connection string looks like this:

The standard port for CCcam is 12000. The protocol uses its own encryption mechanism based on SHA1 and RC6. A session key is generated with each connection, which theoretically provides greater cryptographic strength than the static DES key of Newcamd.

Cascading in CCcam: Advantages and Risks

Cascading is the main functional advantage of CCcam. Let's imagine the following scheme: server A has a physical Viasat card. Server B is connected to server A and receives CW for Viasat. Server C is connected to server B. Client D is connected to server C. In this scheme, client D has a hop count of 3.

Each additional level of cascading adds latency. With a hop count of 1–2, the latency is usually 50–150 ms, which is imperceptible to the viewer. With a hop count of 4–5, the latency can reach 400–600 ms, leading to freezes — brief image freezes when changing the control word (usually every 10 seconds for most conditional access systems).

Direct Comparison of Newcamd and CCcam

Response Speed

In a direct comparison when connecting to the same server, Newcamd usually shows slightly lower latency than CCcam. The reason is the simplified handshake protocol. When tested on typical European servers, Newcamd shows an average response time of 80–120 ms, while CCcam shows 100–160 ms with a direct connection (hop 0).

However, this advantage is negated when using CCcam with a hop count of 0–1 on a quality server. The real difference is imperceptible when watching standard television.

Compatibility with Equipment

CCcam was originally developed for Dreambox receivers and is supported by most emulators: OSCam, CCcam, MGCamd. Newcamd is also widely supported, but there are outdated receivers (for example, some models of Openbox and Starsat with firmware prior to 2015) where the implementation of CCcam is unstable, while Newcamd works correctly.

On modern receivers with OSCam, both protocols are supported equally well. OSCam can simultaneously accept connections via Newcamd and CCcam, broadcasting CW to clients regardless of the protocol they are using.

Server load

CCcam generates a slightly higher load on the server compared to Newcamd due to the more complex protocol and the need to maintain cascading connections. On a typical server with 50 simultaneous connections, the difference in CPU load is about 5-10% in favor of Newcamd. With 200+ connections, this difference becomes noticeable.

Diagnostics and logging

OSCam provides detailed logs for both protocols; however, additional information is available for CCcam: current hop count, number of active cascading connections, status of each connected reader. This simplifies troubleshooting issues in complex cascading configurations.

For Newcamd, diagnostics are simpler due to the more straightforward architecture: if the server is unavailable or the key is incorrect, the connection is immediately terminated with a corresponding log entry.

OSCam: a universal emulator for both protocols

Configuring Newcamd in OSCam

In OSCam, the connection to the Newcamd server is configured in the fileoscam.server:

The parameterkey is a 14-byte DES key in hexadecimal format. It must match the key on the server.

Configuring CCcam in OSCam

To connect to the CCcam server in the same fileoscam.server:

The parameterccchop limits the maximum hop count — useful for avoiding unstable cascading connections with high latency.

Typical problems and their solutions

Freezes when using CCcam

If periodic freezes occur every 10 seconds when using CCcam, the cause is almost always a high hop count or an overloaded intermediate server. Solutions:

• Check the hop count in the OSCam logs (lines withhop=)
• Set the parameterccchop = 2 to limit the maximum cascade
• Switch to a server with a direct connection (hop 0)

Newcamd authentication error

If OSCam reports a connection error to the Newcamd server without additional details, the first thing to check is:

• The correctness of the DES key (14 bytes, must match exactly with the server)
• The correctness of the login and password (case-sensitive)
• The availability of the port (check viatelnet host port)

High latency on both protocols

Latency above 300 ms on both protocols usually indicates a routing issue or server overload, rather than a protocol-specific issue. Check the latency to the server with the commandping and compare it with the latency shown by OSCam.

Which protocol to choose

Choosing Newcamd is justified if:

• An outdated receiver with an unstable CCcam implementation is used
• A maximally simple configuration without cascading is required
• The server provides only Newcamd access
• Minimal load on server hardware is important

Choosing CCcam is justified if:

• The server only supports CCcam connections
• A modern Dreambox or similar receiver is used
• Access to channels through a cascading network of servers is required
• Extended connection statistics through the OSCam web interface is needed

When the difference is insignificant

When using a quality server with a direct connection (hop 0 for CCcam) and a stable internet channel, the difference between protocols in everyday use is negligible. Both protocols provide stable decoding with a latency of up to 200–250 ms. Priority should be given to the quality of the server itself, rather than the choice of protocol.

Final comparison of protocols

Parameter	Newcamd	CCcam
Encryption	DES (static key)	SHA1 + RC6 (session key)
Cascading	Not supported	Supported (hop count)
Standard port	10000	12000
Server load	Lower	Higher
Compatibility with OSCam	Full	Full
Diagnostics	Simple	Extended

Both protocols are mature and well-supported. Newcamd is a simpler and more predictable option for direct connections. CCcam is more flexible when working in cascading networks and on modern equipment. If there is a choice, it is recommended to test both protocols with a specific server and choose the one that shows lower latency and works more stably on your receiver.