MGCamd DES Key Setup: newcamd.list & Config Guide

If you're here, you've already got MGCamd installed, you have server credentials in hand, and something is broken. The mgcamd DES key setup is where most people hit a wall — not because the concept is hard, but because one wrong character in one wrong field kills the entire handshake. This guide walks through exactly where the key goes, what it does, and how to read your logs to tell a key error from any other kind of failure.

What the DES Key Is and Why MGCamd Needs It

MGCamd talks to card servers using the newcamd protocol. That protocol uses Triple-DES encryption to protect the connection during login — specifically to encrypt the initial handshake and the subsequent session data. The DES key is the shared secret that makes that encryption work. Both sides need the same key, or the handshake produces garbage and the connection dies.

This is not your password. It is not your username. Those are separate fields. People mix these up constantly, and it's one of the top reasons a config file that looks almost right still fails.

The role of the DES key in the newcamd protocol

When MGCamd connects to a newcamd server, it doesn't send credentials in plaintext. The server and client use the DES key to set up an encrypted channel before anything else is exchanged. If the key doesn't match on both sides, neither party can decrypt what the other sends. From the client's perspective, the TCP connection opens, then drops — no error message, no authentication attempt, just silence.

The key is configured server-side — whether that's in OScam's oscam.server file or in a CCcam server's config. Whatever the server has, your client must have exactly that.

Where the key sits in the CWS handshake

The sequence goes: TCP connect → server sends a random challenge encrypted with the DES key → client decrypts it and responds with credentials → server validates and either accepts or drops. If the DES key is wrong, decryption of that first challenge fails. The client sends back nonsense, and the server closes the connection. You never even get to username/password verification. That's why a bad DES key looks identical to "connection refused" from the outside — the TCP handshake succeeds, but the newcamd auth handshake doesn't.

Why it must be exactly 28 hex characters (14 bytes)

Triple-DES with a 14-byte key is what the newcamd spec requires. 14 bytes × 2 hex characters per byte = 28 characters. Not 26, not 30. If your key is 27 characters, you pasted it wrong. If it's 29, there's a trailing character hiding somewhere. MGCamd will either reject the key outright or silently truncate/pad it — both outcomes break the connection.

Valid characters are 0–9 and A–F (or a–f). That's it. If you see a lowercase letter outside that range, or something that looks like a 1 but is actually an l, you have a typo.

Editing newcamd.list: Exact Line Format

The canonical CWS line looks like this:

CWS = hostname port username password 0102030405060708091011121314

Every field is separated by a single space. No tabs, no double spaces, no quotes around anything. The DES key is the last field. Most guides I've seen paste a sample line but never label the fields, so people put the key in the password slot and wonder why nothing works.

Anatomy of a CWS = line

Breaking it down left to right:

• CWS — the directive keyword, always uppercase
• = — literal equals sign with spaces around it
• hostname — the server's IP address or FQDN
• port — TCP port, commonly 15000, 15001, or 17000
• username — your account name on the server
• password — your account password (plaintext here)
• DES key — 28 hex characters, no spaces within the key itself

Six fields after the equals sign. The key is field six. Not field four, not field five.

Field order: host, port, user, password, DES key

If your credentials came from a web panel, they're sometimes presented in a table with columns in a different order than the CWS line expects. Pasting column by column from a badly laid out panel is where transpositions happen. Read the columns, type the line manually in the correct order. It takes thirty seconds and saves an hour of debugging.

Example line with placeholders

CWS = cardserver.example.net 15000 myuser mypassword 0A1B2C3D4E5F6A7B8C9D0E1F2A3B4C5D

That's a fictional server, but the format is exact. The key there is 32 characters, which is intentionally wrong to make the point — count yours. The real key you receive will be exactly 28.

File location on common firmwares

This trips people up more than the format does. Common paths:

• /var/keys/newcamd.list — most Enigma2 images (OpenATV, OpenPLi, DreamElite)
• /usr/keys/newcamd.list — some older images and non-Enigma builds
• /etc/tuxbox/config/newcamd.list — Tuxbox-based Enigma1 hardware
• /etc/mgcamd/newcamd.list — some custom MGCamd packages that bundle their own config dir

If you edit the file and the changes never seem to apply, you're editing the wrong path. Run find / -name "newcamd.list" 2>/dev/null over telnet to find every copy on the filesystem. Then check which one MGCamd is actually reading — usually visible in the startup log or set in an init script via a path argument.

Adjacent lines you might see in the file: CWS_KEEPALIVE = 0 controls keep-alive pings, and CWS_INCOMING_IP locks the client to a specific local interface. Neither of these holds the DES key and neither needs to be edited for a basic connection.

Setting the DES Key in mg_cfg

Here's where a lot of confusion lives: people search through mg_cfg looking for somewhere to paste the DES key. It's not there. The key lives in newcamd.list. Full stop.

mg_cfg controls MGCamd's runtime behaviour — caching, EMM processing, debug output, and similar. It does not contain connection credentials.

The C { } global config block

The main config block in mg_cfg looks like:

C { 3 0 1 0 { 0 } }

Those numbers control cache TTL, AU (auto-update/EMM), and debug settings. None of them are the DES key. Don't put the key here. If you've been editing this file looking for a key field, you were in the wrong file entirely.

Relationship between mg_cfg and newcamd.list

Think of it this way: newcamd.list is your address book — who to connect to and how to authenticate. mg_cfg is MGCamd's internal preferences — how to behave once connected. They serve completely different purposes, and they're read separately at startup.

Common mg_cfg flags that affect key handling

The debug level bitmask is the one setting in mg_cfg that indirectly helps with mgcamd DES key setup troubleshooting. The M: lines in the log (connection, authentication, ECM) are controlled by the debug value in the C { } block. Setting it to a value like 7 or 255 gives you verbose output. You'll see the CWS connect attempt, the auth result, and exactly where it fails. Without that, you're guessing blind.

Some builds include a default key fallback — if no key is specified, MGCamd tries 0102030405060708091011121314. Don't rely on this. Most real servers use a custom key, and silently falling back to the default means a failed connection with no obvious explanation. Always put the actual key in the file explicitly.

Verifying the Connection and Reading the Logs

Once you've edited newcamd.list, restart MGCamd and watch the logs. If you can't read the logs, you're flying blind and fixing config issues becomes a guessing game.

Enabling verbose MGCamd logging

In mg_cfg, set your debug level high. A value of 255 in the C block's debug position gives maximum output. This is noisy, but for diagnosing a connection issue it's exactly what you want. Dial it back once the connection is stable.

The log file location varies by setup — common paths are /tmp/mgcamd.log, /var/log/mgcamd.log, or output to stdout captured by the init system. Check your init script to see where output is redirected.

What a successful CWS login looks like

A working connection produces log lines roughly like:

CWS connected to cardserver.example.net:15000CWS login OK, card: [CAID] [provider]ECM answer: CW OK, decode time 120ms

The exact wording varies between MGCamd builds, but the pattern is the same: connect → login OK → card detected → ECM answered with a decode time. If you see all three stages, your mgcamd DES key setup is correct and the connection is working.

Telnet and oscam-style log inspection

Over telnet (usually port 23 on the box), you can tail the log in real time:

tail -f /tmp/mgcamd.log

If you're running OScam alongside MGCamd, OScam's own log at /var/log/oscam/oscam.log will show the incoming connection from the client side. A failed DES key shows up as a rejected handshake in the OScam log too, which gives you a second data point. Cross-referencing both logs eliminates ambiguity quickly.

Confirming ECM responses and decode time

Decode times under 500ms are generally fine for most receivers. Times above 1000ms cause picture stuttering. If ECM lines appear in the log but decode time is listed as 0 or "no CW", the card is connected but not answering for that channel's CAID — that's a card rights issue, not a key issue. The distinction matters for troubleshooting.

Troubleshooting Wrong or Malformed DES Keys

The mgcamd DES key setup fails in a handful of predictable ways. Each symptom points to a different cause, and reading the log tells you which one you're dealing with.

Symptom: connects then instantly disconnects

TCP connects, you see the CWS line hit the server, then it drops within a second and MGCamd starts a reconnect loop. This is the DES key mismatch signature. The server tried to decrypt the client's response to its challenge, got garbage, and closed the connection. Check the key character by character against what the server expects. Then check the password — a wrong password causes the same disconnect but slightly later in the handshake sequence.

To distinguish a port/firewall failure from an auth failure: if TCP doesn't even complete, you won't see a "CWS connected" line at all — just a timeout or "connection refused". If you see "connected" followed by an immediate close, the network is fine and the auth is broken. That's almost always the DES key or password.

Symptom: card opens but no picture / scrambled

If the connection succeeds (login OK, card detected) but channels are scrambled, the key is fine. Now you're looking at a different problem: the card doesn't have rights for that package, the ECM isn't being answered, or EMM hasn't updated the card's entitlements. Check the ECM lines in the log for "no CW" or long timeouts. This is not a DES key problem.

Whitespace, length, and hidden-character errors

This one gets people constantly. When you copy a key from a web panel or email, invisible characters come along for the ride. A trailing newline, a non-breaking space (0xA0), a carriage return — none of these are visible in most text editors, but they corrupt the key.

The fix: use dos2unix on the file after editing it on Windows, or edit directly on the box via telnet using vi or nano. If copy-paste consistently fails, retype the key manually. It's 28 characters — it takes ninety seconds. Also run:

cat -A /var/keys/newcamd.list

Any line ending in ^M$ instead of just $ has a Windows-style CR/LF. That trailing ^M is being appended to your DES key and breaking it. The dos2unix command strips those.

Copy-paste pitfalls from web panels

Some web panels render the DES key in a font where 0 and O look identical, or 1 and l are nearly indistinguishable. I've spent longer than I'd like to admit staring at a key that looked right but had a lowercase O where there should have been a zero. If the key came from a web interface, view the page source to see the raw value. Copy from there, not from the rendered display.

Also check: if you have multiple CWS lines in newcamd.list and edited the wrong one, the active entry is still using the old key. MGCamd reads all CWS lines and tries them in order. You could edit line 2 while line 1 is the one actually connecting. Check which server IP and port appear in the "CWS connected" log line and make sure that matches the line you edited.

One more edge case: some builds are case-sensitive about hex characters. If the server sends the key as uppercase and your file has lowercase (or vice versa), most modern builds handle it — but if you're on an older MGCamd binary, try matching case exactly to what the server provided. Uppercase is safer.

Clock issues are rare but real. On some setups, an incorrect system clock on the STB causes TLS or timing-sensitive handshake failures. If you've verified the key is correct and still get intermittent failures, check date on the box and sync with NTP if the time is way off.

Choosing a Reliable newcamd Server Source (Generically)

The technical side of mgcamd DES key setup only works if the server on the other end is actually reliable. A perfect config connecting to a broken server still gives you a broken experience.

Criteria that matter: uptime, ECM time, support

ECM response time is the number that matters most day-to-day. Under 300ms is good. Under 100ms is excellent. Anything over 800ms and you'll see channel changes stall. Ask for a trial period and measure actual ECM times in your logs before committing.

Uptime consistency matters more than peak uptime. A server that's up 99% of the time but goes down unpredictably during live sports is worse than one with scheduled maintenance windows. Find out how they handle downtime and whether there's redundancy.

Support responsiveness is hard to evaluate before you need it. Look at how quickly they respond to pre-sale questions. If they take three days to answer a simple inquiry, assume that's how fast they'll fix a broken connection at 9pm on a Saturday.

Red flags to avoid

Avoid any service that can't tell you their server's physical location or data center. Avoid providers who won't give you even a short trial before payment. Be wary of anyone advertising unrealistic ECM times that don't hold up under actual testing. And if a server is down when you first try to test it, that's a preview of what you're buying.

Why you should never share your DES key publicly

Your CWS line — the full line including DES key — is a complete authentication credential. Anyone with that line can connect to your server allocation as you. Posting it on a forum to ask for help is the equivalent of posting your password in plaintext. If you need to share credentials for debugging, generate a test account or mask the key. And if you've already posted it publicly, assume it's compromised and request a new key from the server operator immediately.

The same applies to pasting your config into any online tool or diagnostic site. The key doesn't need to be there for anyone to help you debug format issues — replace it with a placeholder before sharing.