Guide to CCcam As of October 10, 2006

Install CCcam

Starting off with something for beginners:

For crafting the box, we need some small programs. One should take a look at them before starting.
acquire
A Linux compliant editor, such as ultraedit32 or Crimson Editor (freeware)
2. An ftp program like FlashFXP
3. A syslog tool for Windows like 3csyslog (freeware)
4. A Telnet tool, as it is included in Windows.

Installation of CCcam
Essentially, the CCcam consists of 2 files, the binary (executable) and the .config. In the original .rar
The file offered by the creators is called the binary for the Dreambox [Link], the .config is for everyone.
Versions the same.
I recommend renaming the binary to CCcam, as it simplifies handling later in Telnet, the file
should then be copied to /var/bin. The permissions must be set to 755 in order for it to be executable.
This can be done in FlashFXP under Attributes.
The [Link] is copied to /var/etc/.

First start of the Emus

Now the Emu would actually be ready to start, but without a script, this can only be done from the telnet console. This is
quite practical if you want to see what the emu is doing.
Start -> execute -> telnet [Link] (=IP of the box)
Login of user (=root) and password (=dreambox, if it hasn't been changed)
Now let's climb our way to /var/bin (input /var/bin) and check if our bin is also there.
you can really tell (ls = dir in linux) by the colors what attributes a file has, our CCcam should
to be green.
To start CCcam -d enter (Attention case sensitivity!) the parameter is for the output of the
logs in the telnet console. This shows what the CC is currently doing, it should look something like this:

Quote:
[Link].209 CCcam: ===================================
[Link].212 CCcam: starting CCcam 1.2.0 compiled on Jul 5 2006@[Link]
[Link].212 CCcam: ===================================
[Link].276 CCcam: online using nodeId 578103ff60952939
[Link].305 CCcam: DM70x0 detected
[Link].307 CCcam: create 2 cam device(s)
CCcam: provider num: fff830
[Link].120 CCcam: provider num: 021c00
[Link].215 CCcam: card added to broker with caid 500
[Link].018 CCcam: card added to broker with caid 4a70
[Link].072 CCcam: added 389 keys from /var/keys/[Link]
[Link].132 CCcam: added 541 keys from /var/keys/[Link]
[Link].133 CCcam: static cw not found or bad
[Link].134 CCcam: read_ignorefile: cannot open /var/keys/[Link] or not found
[Link].135 CCcam: server started on port 12000

If the prompt comes up here, something has gone wrong and CCcam has crashed, in
In normal operation, messages about the ECMS (key requests) of the EMUs appear here while channel surfing.
If you want to know exactly if the emu is still running, just open a second telnet window and type in.
enter, then all running processes will be displayed, it looks something like this:
 Quote:
root@dm7020:~# ps
PID Uid VmSize Stat Command
1 root 608 S init [2]
2 root SWN [ksoftirqd/0]
3 root SW< [events/0]
4 root SW< [khelper]
--- there I cut out some irrelevant lines ---
599 root 2100 S /var/bin/CCcam_1.2.1
600 root 2100 S /var/bin/CCcam_1.2.1

The entries in the log:

online using nodeId 578103ff60952939 every start receives each CCcam server/client a
Identification number that is unique and distinguishes only this node.

create 2 cam device(s) the 7020 has 2 active card slots that have been detected, the following lines will follow
the data of the cards

provider num: 021c00d this is the number of the provider in this case Redlight/FullX

Card added to broker with caid 500 this is the caid (encryption standard) of the current card
is supported, in this case Viaccess. The card is identified by the combination of caid/provider in
this example 0500:021c00
Some providers sell cards with different caids, so Redlight/FullX is also available as Irdeto.
Version available, this is then the 0600:021c00.
The caid/provider system will become very important later, so remember it well.

added 389 keys 389 keys were successfully read from the keyfile

static cw not found or bades is no [Link] file present, is not further tragic as it's optional

read_ignorefile: cannot open /var/keys/[Link] or not found. This file is optional, so it's not a big deal.
tragic when it is missing

server started on port 12000 The server is running on port 12000 TCP (this is important for sharing in
Router/Firewall

Keyfiles
The key files go into the /var/keys directory (unless you change that in the config). The CCcam
uses the widely used [Link]/[Link] format, which is also used by other emulators,
Therefore, one is not bound to a specific key format. Keyfiles are optional, the emulation works.
even without.

CCcam and Cardsharing

Now we connect the CCcams. To do this, the /etc/[Link] must be edited (not Windows Notepad)
use, see above). The standard config also serves as a guide. Everything that starts with # will be
is ignored by the emu and is only there to read.
The order of the individual lines is irrelevant; when starting, the emulator loads the config and interprets the
Lines by their initial letter.
F: Friends

Quote:
F: user1 pass1 1

This is an F (friends) Line, which comes on the server box, where you define users who have access to your own
The box may be accessed, the number after user and pass defines how far user1 is over my server box.
Out to the boxes of my friends who can also be seen hanging with me. In the example above, user1
only see my cards. With a 2 behind it, mine and all the friends directly connected to my box,
with 3 the cards of my friends' friends etc.... this is called Cascading, and it can quickly lead to a
a whole bunch of cards come together.

C: Connect

Quote:
C: [Link] 12000 user1 pass1

This is a C (connect) line, which connects the CCcam on the client box to a server box.
The URL or IP right after the C: identifies the server box on the network, 12000 is the port on which the server is running.
works and user1 pass1 identify the user.
Important: A user is only accepted on the server once; they cannot be logged in multiple times simultaneously.
connect!

If you only want to connect the client to the server, it is sufficient to do F: on the server and C: on the client.
If you want to see the cards from the client box on the server box, it is also possible additionally.
Reversed. So now each box has a C: and an F: line.

Diagnostics in the log

Once all of that is done, you can start the two CCcams from the Telnet with CCcam -dv, and
see if a connection is established. Initially, it should be tried in Telnet, the script for BP
comes when everything runs as it should.
This is how the log in Telnet looks between the two test boxes in the house:

Quote:
[Link].977 CCcam: found betacrypt caid: 0x1702 ecmpid: 0x100a id: 0x0
[Link].978 CCcam: found betacrypt caid: 0x1722 ecmpid: 0x100a id: 0x0
[Link].978 CCcam: found nagra caid: 0x1801 ecmpid: 0x1642 id: 0x0
[Link].978 CCcam: cam[0] set PMT for sid=a
[Link].979 CCcam: start EMM
[Link].996
(19E) tunneled Nagra (took 0.0010 seconds)
[Link].061 CCcam: cam[0] ecm evennokcaid:0x1722 id:0x0 pid:0x100a Premiere Cable
(19E) tunneled Nagra (took 0.0003 seconds)

The first three lines show how the channel is encrypted. Pre***e will come with 3 soon.
possible caids to:
1801 pure Nagra (currently not used or only with s04 cards) = irrelevant
1702 this is tunneled Nagra = betacrypt for satellite
1722 this is tunneled Nagra = betacrypt for cable

The provider ID is at Pre***e, id:0x0, in the usual format with 6 digits (just add 0x in front)
leave out and fill from the left with 0) 000000

the pid is the program identifier, in this case 100a (without the 0x) that is Pre***e 1
With the start of EMM, the key search is initiated.
The next two lines contain the answers from local. The responses are negative (!) ... ecm even
nok caid:0x1722 ... because there is no card in this box. The request took 0.0003s.

Then the requests to the server box follow:

Quote:
[Link].194 CCcam: remote ecm -> [Link]:12000 0x1702(0x000)
[Link].331 CCcam: remote ecm <- [Link]:12000 ok (took 0.1364 seconds)
[Link].333 CCcam: cam[0] ecm evenokcaid:0x1702 id:0x0 pid:0x100a Premiere Sat
(19E) tunneled Nagra (took 0.1383 seconds)

this request was successful, ...ecm even ok caid:0x1702... and took 0.1383s in the local LAN

Stopping the server

As long as you are in the Telnet console where the log is running, simply press Ctrl+c.
Otherwise, it must be terminated with killall CCcam from telnet.

Status of the Emus

The integrated web server

CCcam offers a web server from which you can check the current status of the Emus and their connections.
can be queried. With default settings, the web server runs on port 16001. When accessing with the
Don't forget the protocol browser[Link] to write.
The web server can display active clients, clients, the status of the servers, etc.
In our example, there should be one entry for Clients and one for Servers. If the entry is present,
the connection is established and the image must brighten.

This is how the Active Clients page should look, in the first part the users are listed who have been active in the last 20.
How many seconds they were active and how many ECM they pulled.
In the second part, all users and their traffic are listed, and there is even a distinction made regarding which traffic
which could be resolved locally and which had to be queried remotely

code:
Connected clients: 4
2 ACTIVE CLIENTS IN LAST 20 SECONDS
+---------+---------------+------------+------------+---------+-----+-----
1:
---+
2:
Username Connected EMM
3:
Version
4:
+---------+---------------+------------+------------+---------+-----+-----
5:
---+
6:
User1 00d [Link]
7:
|
8
User2 |00d [Link]|00d [Link]|174 (167)|0 (0)|1.2.0
9:
|
10:
+---------+---------------+------------+------------+---------+-----+-----
11:
---+
12:
13:
+---------+---------------------------------------+
14:
Username |
15:
+---------+---------------------------------------+
16:
User3 local 500:021500 1(0) |
17:
User4 | remote 919:000000 280(280) |
| |remote 1801:000501 2(0) |
+---------+---------------------------------------+

The server side should look like this, on the far right you can find the CAIDs of the servers with the number of
requested ECMs. Here too, local and remote cards are distinguished.
 1 Server connections: 1
:+-----------------+------------+---------+--------+----------------+-------
2 ------+-----------------------------+
Host Connected Version Number Of
3 Cards | CAID/Idents |
:+-----------------+------------+---------+--------+----------------+-------
4 ------+-----------------------------+
|[Link]:12000|00d [Link]|CCcam-s2s|1.2.1 |5d341729df599d5a|2
5 |remote 919:000000 60(46) |
:| | | | | |
6 |local 4a70:000000 67(0) |
:+-----------------+------------+---------+--------+----------------+-------
7 ------+-----------------------------+
:

Logging with Syslog

Anyone who has worked with the log in the Telnet console has surely recognized how helpful it is.
when one can watch the Emu working to look for errors.
To avoid having to start the Emu in -dv mode in the console every time to log, one should...
install the 3cSyslog (see link in the introduction of the first part).
In the config, set these two parameters to yes if needed:

Quote:
if timing should be shown in OSD and debug output
default is no (turned off)
#
SHOW TIMING : yes

turns debugging on and off

default is no (turned off)
#
DEBUG : yes

If you start CCcam now with the parameter -V, the Emu writes the log to the Syslog Daemon.
Box.
In order to view the box's syslog in the software on the PC, its output must be enabled in Gemini.
You can find the Sys/Kernel Log point in the Blue Panel under (3) Extra/Settings -> Sys/Kernel Log.
Here the Syslog daemon must be activated, then enable remote logging at the very bottom and the Host
Specify the IPs of the PCs with 3cSyslog, the port remains at 514 (UDP). Restart the service.
Now one should be able to follow the log live on the PC.

The 3cSyslog also works for other emulators, such as Camd3 or Newcs, as the configuration simply includes the
IP and the port (514) entered. The daemon on the box is not needed for the two.

Connection with strange Emus

Camd3
CCcam can read camd3 shares, but cannot serve as a server for that. However, it only works for
UDP shares (which are identified in the [Link] by the 357 at the front).
The L: Line connects CCcam with a camd3 server, for this the following data is needed: IP or Url of the
Servers
 Quote:
L: [Link] 567 user pass 0100 000080

Here, the caid/provider numbers come into play again (see first part), which need to be entered.
since Camd3 does not reveal on its own which cards it offers.
If the camd3 server offers multiple cards, a separate L: line must be written for each one.

Radegast

The R: Line connects CCcam with a radegast server, for which the following data is needed: IP or URL of the
Servers

Quote:
R: [Link] 678 0100 000080

Here too, like with camd3, a separate R: Line must be written for each card.

Newcamd (Newcs)
The connection to a Newcamd server is somewhat easier, as Newcamd provides the login with the
Client communicates what he offers.
The N: Line connects CCcam with a Newcamd server (e.g. NewCS or Newcamd), for this purpose
the following data needed: IP or URL of the server, server port, user and password, and the DesKey that is for the
Encryption of the communication is used.

Quote:
N: [Link] 10000 dummy dummy 01 02 03 04 05 06 07 08 09 10 11 12 13 14

Since CCcam (V 1.2.1) cannot read all cards at the moment, special cases are handled differently.
one of the card readers. One of the best card readers is certainly NewCS, which serves as a server in the Newcamd protocol.
works.
A special feature of the Newcamd protocol is the login, in which the client and server communicate bidirectionally.
Exchanging data, for example, the server is informed about which emulator the client is using, if one wants to.
do not output the server as CCcam, you can use the stealth mode:

Quote:
NEWCAMD STEALTH: yes

and disguise itself as Mgcamd.

If you already have a complex Newcamd setup running on the box, you can simply use

Quote:
NEWCAMD CONF : yes

parse server entries without entering everything again.

In the current version, the support for CCcam for external (at least for me) works.
Card reader does not work, with NewCS it works smoothly.
Configuration of NewCS
Actually, NewCS has nothing to do with CCcam, but it is a prerequisite to read cards that the
Emu (not) able to do it alone yet, for example Nagra 2. For this reason, I would like to elaborate on this a bit.
to go into
Newcs consists of 2 files like CCcam, the executable newcs (binary) which is located in /var/bin/newcs and
requires rights 755 and the configuration file located in /var/tuxbox/config/[Link] and in XML format
is built.
XML is structured like HTML; it consists of tags that are opened and also closed.
Tags are nested and contain the information for the card server.

Here is a small excerpt from the [Link]

Quote:
<device>
lower
Sci
/dev/sci0
even
yes
yes
no
no
no
<boxid></boxid>
no
no
no
no
34000
yes
round
</device>

This part contains the configuration of the lower slot (/dev/sci0) of the Dreambox. I want to continue here now.
not go into the individual tags in more detail, important for communication with the CCcam is the
underlined part, here the port of this port is defined, each port or card reader needs one
own port. This is the port that must be entered in the N: line in the [Link].

quote
newcamdserver
yes
01 02 03 04 05 06 07 08 09 10 11 12 13 14
newcs

dummy
dummy
on
lower
allow
</user>
</newcamdserver>
In this section, the Newcamd server is activated for the first time and the Deskey (for encryption of the
Communication) is defined, this also appears in the [Link].
The last thing missing for the N: Line is user/pass, which will be specified in the next subtag.
(dummy/dummy), it is also set here whether the user can perform AU (Autoupdate) and which ones
devices defined above that he is allowed to use.
Our N: Line should look like this, [Link] is the localhost, indicating that the newcs is local:

Quote:
N: [Link] 34000 dummy dummy 01 02 03 04 05 06 07 08 09 10 11 12 13 14

When using Newcs as a card server, it of course needs to be started before CCcam. I recommend
To do this, open 2 separate Telnet windows, one for Newcs and the other for CCcam.

Advanced settings

Friends (Clients) and Cascading

As briefly mentioned in part 1, CCcam can cascade excellently.
In our test setup, we have 4 boxes, the 1st is connected to the 2nd, the 2nd is connected to the 3rd, and the
3rd with the 4th. Those are the only connections of the boxes, the 1st is therefore not directly connected to the 4th.
connected.
Through cascading, box1 can also access box4.

box1 <----> box2 <----> box3 <----> box4

1 hop
2 hops
3 hops

Box1 retrieves the keys from box4 (this process is called ecm) the request and the response
jump over 3 boxes, that's called hops.

Quote:
user1

This user can see all local maps of the server and two hops further.
If you create this user on box2, box1 could see the cards from box2, box3, and box4.

Quote:
user1

Box1 could only see box2 and one hop further, so box3.

Reading local keyfiles and remote EMM

This is the simplest setting for a user; it can also be a bit more complex.

user2

the 3 numbers behind the user/pass have the following meaning:

The first is the uphops, as described above
The second indicates whether the user should have access to the local keyfiles.
This is a very practical option when you have several boxes at home and do not want to have them all on the
Wants to maintain [Link]. One only updates the server box and then accesses it from the client.
the following C: line to, what matters is that yes at the end

Quote:
C: [Link] 12000 user3 pass3yes

The default is that the second number is 1, meaning that if you have defined only a single user (with only one number)
behind this) CCcam assumes that the user is allowed to access the local key files. If you want to do that
A 0 must be inserted to prevent it.

The third number is responsible for remote emms. If there is a 1 here, the user is allowed to perform emm on the map.
Example: There is a key change, the new keys are broadcast with the TV signal. In order to
To update the map, the server box needs to be turned on and set to a certain channel.
If the user is allowed, it is sufficient for them to set the client box to the appropriate channel and
So the card updates, he plays the update remotely, this is called Remm (remote
emm)
The default is also 1 here, so if a simple user is defined with just one number at the end, the remm is allowed.
do.

Once again briefly summarized:

quotation
F: user1 pass1 3 0 0

This user sees the maps from the server and 3 hops behind, has no access to the key files on the server.
and must not make any emm (remm)

Rights for individual cards UP- and DOWNshare

So, now it gets a bit more complicated, it is possible for each shared card to individually follow
To define settings:

Quote:
user2

this user receives (because of the 0 right after the pass (...pass201 0 ...) only the local cards of the
To see servers (in the example there are 3 cards)
he is allowed to access the local keyfiles (...pass2 010 ...)
he must not do any emms (...pass2 0 10...)
He does not have access to the card 0100:000080 because there is nothing behind it (0100:000080,)
he has access to 0622:000000, but only for himself = 1 downhop (0622:000000:1)
he has access to 0500:000000 and is allowed to pass this one hop further = isng. 2 downhops (0500:000000:2)

In conclusion, one can not only set how far the client can see behind the server box (uphops), but also
also how far the client can further share these keys itself (downhops).

Another example:

Quote:
F: user3 pass3 5 0 1 { [Link], 0100:000080:1 }
This user receives the local cards due to the 5 right behind the pass (...pass250 1 ...)
Server box and all further nodes visible that are up to 5 hops behind the server box.
The user does not receive any local key files shared and is allowed to perform remote actions on the cards on the server.
In the parentheses here, 0 stands for Caid and 0 for services, these are jokers, meaning all caids and all.
services, which is the downshare depth after 3.
So this user can downshare all the cards he receives from the server box by 3 hops, except for the
0100:000080, which is explicitly authorized for a hop (...0000:1...), can therefore only be seen by itself.

This is a summary of the possible content of the C: Line.

Quote:
F: <username> <password> <uphops> <shareemus> <allowemm> ( { caid:id(:downhops),
caid:id(:downhops),... } )

Start and Stop Scripts

Since our Emu has always been started in Telnet so we can observe the log,
Now let's take a look at the scripts that allow us to start an emulator using the remote control.
or stop

The path to the scripts is different in each image.

Gemini
In the Gemini image, all scripts are located in /var/script. Scripts that concern an emu and in
BluePanel should be displayed, ending with _cam (e.g., CCcam_cam.sh).
WARNING: since scripts are executable, the attributes must be set to 755.

The original Gemini scripts start with a list of CAMIDs. Each emu is assigned a range.
assigned. This list is intended for orientation only and can be disregarded (deleted).

The current CAMID is defined further down in the script:

Quote:
6000

The CAMID determines the displayed order of the emus in the BluePanel. Each CAMID may only be used once.
occurs, as Gemini remembers the current Emu through this number.
When the box is restarted, Gemini looks for the script with the number saved during shutdown.
Go out and start it. If it does not find a script with this number, there will be an error message: 'cam id not found'
found." That's not a big deal, it simply means that no script with the searched CAMID.
has been found.
The reading of the existing scripts (with .sh extension) along with the corresponding numbers will be when
Made Enigmastart or when the user is in MenuCamSettings -> all cams -> Cam Linste
updates clicked.
So don't be surprised if a changed emu name doesn't appear in the Blue Panel right away.

Zitat:
CCcam-1.2.0

The CAMNAME is the string that is displayed in the Bluepanel. If you use skins that the active Emu
This string will also be displayed, so one should pay attention to the length.
 Quote:
ZAPTIME=6

Is the time that the emu needs before something brightens up on the screen after the emu change.

Quote:
[Link]

The file where the current ECM information is stored (in Gemini they can also be displayed in the skin)
will become

Now the actual script begins.

case "$1" in

First, the parameter (start or stop) is read with which the script was started.

Quote:
start)
[SCRIPT] $1: $CAMNAME
/var/bin/CCcam -v
;;

start) - is the parameter start, then the following happens

[SCRIPT] $1: $CAMNAME - simply outputs with script name, the parameter and the
Name the cams
/var/bin/CCcam -v- now CCcam is started, in this example the parameter -v (verbose) is also included
the log output in the syslog is present, but it is specific to this emu
;;- End of the start script

stop)
[SCRIPT] $1: $CAMNAME
killall CCcam
;;

stop) - the parameter stop then the following happens

[SCRIPT] $1: $CAMNAME - Output like at start
killall CCcam - the emulator is being terminated
;;- End of the stop scripts

Quote:
*)
$0 stop
exit 1
;;
case
Here it is still determined what should happen if no parameter is specified, in which case -> Emu
Stop and terminate the query.

If you want to start the Cardserver NewCS alongside CCcam, you simply have to
just the call to it, it's best to give Newcs some time to get going (sleep 3) that's 3
Seconds (so that CCcam doesn't snatch up the slots), afterwards CCcam will be started

..
[SCRIPT] $1: $CAMNAME
/var/bin/newcs
sleep 3
/var/bin/CCcam -v
..

When stopping, it looks similar.

Quote:
..
[SCRIPT] $1: $CAMNAME
killall newcs
killall CCcam
..

The file names of the executable files must be transmitted exactly (including case sensitivity)

To test the script simply in Telnet

Quote:
/var/scripts/emu_cam.sh start

If everything fits, the Emu should now start, the display in the Bluepanel will not update!

This guide was created by the author Tissa, from the Dream Pirates Board.
You are thanked for this great guide and the kind permission to
Publication on the DFB Board.