buglitter
August 24th, 2001, 02:39 PM
Here is a faq for newbies, I haven't try it out yet, but look very interesting
Give it a shot guys
The following text is a short newcomer-guide for programming a smartcard,
experts dont need it. It explains some basic facts of programmers and cards. You
will not become an instant expert by reading it, but it will help you to get the
files on the most common cards.
Generally seen, we use the following cards to program our files.
Wafercard: PIC 16F84 and EEPROM 24C16 (Twostone-Wafercard, Goldwafer)
AVR-Yupiter-Card: AT90S2323 and EEPROM 24C16 (Twostone AVR, 2323 is claimed to
be the "better" chip)
AVR-Yupiter-Card: AT90S2343 and EEPROM 24C16 (Twostone AVR)
Funcard: AT90S8515 and EEPROM 24C64 (Twostone-Funcard)
Jupiter 2 Card: AT90S8535 and EEPROM 24C64 (Twostone-Funcard)
PIC-Card: PIC 16F84 or 16C84 only useful for some D2Mac-Files, generally USELESS
FOR DIGITAL
Programming is done by using either a passive or active programmer. (AVR-Mouse,
PIC-programmer, Multiprog Quadro, Multiprog 2001, Multiprog 2001XL, Card-Maestro
etc.)
The easiest way for most cases is the use of a Wafer-card. Wafers exist in two
versions: The Goldwafer looks like a credit-card with built-in chip, the other
is the usual (green) pcb with the two chips (soldered or in two sockets) on it.
They do the same job. (Details for the cards see below).
The THREE steps of programming a genuine Wafer-card
---------------------------------------------------
1. the PIC needs to be programmed with the loader.hex (needed for step 2)
2. the EEPROM is programmed through the loader in the PIC with the EEPROM-File
(the keys)
3. the PIC is to be REprogrammed with the PIC-File (the card-program itself)
Step 1 is the most confusing one for beginners. Two chips and three files? For
an explanation see below "The loader/hex file". If you use "simple" hardware,
you need to switch them to the appropriate mode. (Picprog/Phoenix/Picprog) or
you will have to change devices if they dont support the programming of the
EEPROM and the PIC. Depending on the software you use, you will be told to do
that (eg. ChipCat) or you have to choose the appropriate software yourself. So,
you will have to do the following:
1. use hardware device Ludipipo to write Loader/Boot/Main file xxx.HEX to 16F84
PIC
2. use hardware device Phoenix to write key-file yyy.BIN to 24c16 EEPROM
3. use hardware device Ludipipo to write program-file zzz.HEX to 16F84 PIC
The most comfortable (and most expensive) way is the use of an active programmer
and its appropriate software, that does all these steps automatically (eg.
Multiprog.. and TwoProg-Software). They have a built-in "loader.hex", so you
will not come across step 1 at all and you will never need the "loader.hex" from
the files you download. You may also find PIC-files for SECA that have built-in
loaders, so step 1 can be omitted too. There are programs like "ChipCat" that
have built-in loaders as well AND work with almost any hardware.
Before using the programming-software, read the help or readme-files. You will
come accross the facts you read here.
In the programming-software you will see some switches, to be set. Dont change
them, unless you know, what you do. The correct settings are usually in the
hex-file, the switches will be set accordingly. If everything works well, you
end up with your working smartcard. If not, consult the detailed explanations
below and the troubleshooting section at the bottom of this file.
Solution 1 for programming Funcards
-----------------------------------
This has to be done in a somewhat different way. This is a working method with
Multiprog 2000, it should work with Multiprog 2001 as well.
Seca and Viaccess:
1. write the loader.hex file into the Atmel 90S8515 with Twoprog 2.2b (
www.2stone.de)
2. Convert the ee_ext.hex or the ee_ext_noleds.hex File with CRDconv12 into a
CRD.(www.funcard.net)
3. Use Cardhunter to write the CRD into the 24C64.
4. Write the flash.hex File and the ee_int.hex into the Atmel 90S8515 with
Twoprog 2.2b.
There comes no loader.hex with the Funcard files, right. It is a genuine
irdeto-loader (irdeto hex from www.funcard.net), but it works.
Irdeto:
1. Write the flash.hex File into the Atmel 90S8515 with Twoprog 2.2b. The
ee_int.hex is not needed.
2. Use Cardhunter to write the CRD into the 24C64.
Solution 2 for programming Funcards
-----------------------------------
The entire programming can be done using only ChipCat. But how do you get the
three files into the chip, as there are only two files to be selected in
Chipcat?
1. rename the ee_int.hex to flash.eep
2. load flash.hex into the program-memory (1),
>> the renamed flash.eep is automatically loaded into the data-section.
3. load ee_ext-hex into the external EEPROM (2)
4. write everything to the card.
I can confirm solution 2 working, ChipCat tells you when you have to change the
programming device or it needs to be set to another mode.
Some word about the aston-cam: if you program a funcard for seca, dont forget to
cover contacts 1 and 5 with a piece of scotch-tape or use the downside contacts
if you have the double-sided funcard. if you dont do that it may not be working,
as the aston is shortcut. below a top-view of the card.
-----
1234
5678
-----
upper
side
chips
-----
Maybe it looks complicated, to program your own card, but it is not. Maybe you
will need two or more attempts to get your card working. Write down, what you
did, you can use it as a reference. If you have one of these special recievers,
that need special files, the programming-proces itself does not change. Happy
viewing!
-----------------------------------------------------------------------------------------
In the following sections you will find more details about the facts you have
read above.
Read them, and use them as a glossary for answers.
-----------------------------------------------------------------------------------------
General Requirements
--------------------
* Windows PC with COM port & cable (e.g. COM1 port and the same serial cable to
connect a modem)
* Wafer card. Several formats are useable. Typically a "goldwafer" is needed.
* Programmer device that operates in "Ludipipo" mode for programming loose DIL
chips (PIC and/or EEPROM).
* Programmer device which can operate in Phoenix/Smartmouse mode for programming
embedded EEPROM chips
- if using a card with dismountable chips, no Phoenix/Smartmouse device is
required.
- these Ludi & Phoenix programmers can be 2 separate devices or a single "combi"
device.
* PIC programming software to operate the Ludipipo device
* Phoenix/Smartmouse software to operate any Phoenix/Smartmouse programming
device you need.
Details on suitable cards
-------------------------
Basically there are three main types.
1. Wafer cards
These are the traditional plastic credit-card type. They contain chips which are
etched into the layer sandwiched between the plastic, and so are invisible. They
follow international (ISO 7816) standards. The word "wafer" itself arises from
the fact that they are wafer thin. There are various kinds of such cards.
"Wafer" or "PIC-cards" usually refers to a card containing just one chip. These
can NOT be used for digital decryption unless for OD UK terrestrial services..
They were used for D2MAC analogue channels, and were known as MultiMacI (MM1)
cards.
"Goldwafer" is a card that contains 2 chips: one PIC and one EEPROM. They first
became popular as auto-updating D2MAC analogue pirate cards, and were known as
MultiMacII (MM2) cards. The name arose because most of these class of wafer
cards are gold coloured. But not all. Some are white, for example. In fact it
doesn't matter what colour they are so long as they contain the right chips. But
beware: many (most) of the white wafers are actually single-chip wafers, and
that is not sufficient. The PIC is type 16F84. Some older D2MAC wafer cards have
a 16C84. This is NOT ok, since it contains insufficient RAM memory to hold the
files that will be loaded. The EEPROM is a 24C16. Some variations are ok. For
example, the 24LC16 where the "L" indicates "low power consumption".
There are also "Triple" or "Quad"-wafers, but we are not talking about them
here.
2. SMD cards - Surface Mount Devices.
These are the same dimensions and layout as a plastic wafer card, but they
contain visible surface-mounted chips (i.e. chips whose pins are soldered onto
the surface of the card rather than through holes. The chips are very low
profile, so this card - like the wafers - fits into a CAM slot with the flap (if
any) closed. Some SMD cards are badly soldered and can give problems.
3. PCBs - Printed Circuit Board cards, or Print-cards (or PIC-cards)
These are normal circuit boards shaped to fit into the CAM slot and etched with
tracks which match the internally etched tracks of a wafer. They usually hold
sockets soldered onto the PCB, into which dismoutable chips are pushed. The
disadvantage of PCBs is that the size of socket+chips means they do not slide
completely out of sight into the CAM slot. They have to be made longer than a
normal card, with the sockets/chips at the end so that they stick out of the
CAM. This means that any flap over the CAM can not be closed (a minor
inconvenience). They have two significant advantages though. First, the chips
can be removed - and so can be programmed separately on a Ludipipo device. This
contrasts with the normal wafers, where the EEPROM chip can only indirectly be
programmed using a technique known as "through-PIC". More of that later. Second,
they can be made from standard electronic parts by the hobbyist.
More details on programmers
---------------------------
Most but not all programming devices work through the serial port using a
standard serial cable. Some (typically the more expensive models) work through
the parallel printer port, using a bespoke cable. The required power-supply is
typically 9v or 12v DC, delivering 300mA.
In order to program plastic cards, both the Ludi and Phoenix devices should be
equipped with a smartcard reader (i.e. a slot into which the wafer can be slid
in order to program it). Not all such devices have this as standard. If you are
intending only to work with PCB cards (with dismountable chips) then a Ludi
without card-reader will be all you need - assuming it has one or more sockets
suitable for inserting loose EEPROMs and PICs.
If you are working with plastic cards, you MUST have a Phoenix/Smartmouse
device, since that is the only device which can program the embedded EEPROM. It
will also have to operate at the lower speed of 3.57MHz. The higher speed of
6.00MHz is ok for modern MOSCs BUT CAN DAMAGE WAFER CARDS. Not all such devices
have a 3.57MHz oscillator - some only have a 6.00 MHz. But a 6.00MHz programmer
can be turned into a 3.57MHz programmer simply by swapping the oscillator
crystal - no other modifications are required. Note: a device in Ludipipo mode
does not use the crystal. Popular Ludipipos (also referred to as a "Hi/Lo
programmer") are the DL20 & JDM (Jens Dyekjær Madsen).
More details on programming software
------------------------------------
These programs offer features for programming, reading, and erasing the chips.
The HEX or BIN file is read from the pc-media into a buffer, and from there
piped across the COM-port/cable to the programming device and into the chip.
Most programs use checksums to verify what they are writing. There are a vast
range of utilities available, some Ludi-only, some Phoenix-only, some combined.
Some have additional handy features such as HEX disassemblers. Some programming
devices come with their own dedicated software. Note: whatever
Phoenix/Smartmouse software you use, it SHOULD support the 3.57MHz speed - and
not all do!
Overview of the programming process
-----------------------------------
The goal is to get a key file into the EEPROM, and a software file (including
key-decryption algorithms) into the PIC. The software file is usually a
hexadecimal (xxx.HEX) file. The key file is usually a binary (xxx.BIN) file.
A loader (or "boot") file may also be needed in order to pass the key file
through the PIC and into the EEPROM. The loader will typically be a HEX file.
Some programming utilities will demand that the file for the EEPROM is indeed a
BIN file, and the others are HEX. But if the downloaded files are not in those
formats, don't worry: there are utilities available for converting from one to
the other. There are also wafer software files available which allow the keys to
be loaded using new pseudo-nano-commands in CRD format as familiar to people who
have played with MOSCs.
The loader/hex file in the PIC
------------------------------
When working with non-removable chips (i.e. SMD cards, or plastic wafers), there
is a problem to be overcome: how to gain access to the EEPROM, since it sits
"behind" the PIC. The solution is to use "Through-PIC" technique. This means
loading a special file onto the PIC whose sole purpose is to pass the key/bin
file through to the EEPROM. This loader (or boot) file exists in many different
versions, with names like LOADER.HEX, MAIN.HEX, 16F84.HEX and so on. Often the
wafer-software files are packaged with a loader. But don't think you have to use
the loader which comes with the particular package. Once you've found a loader
which is reliable for you, save it and reuse it for all future through-PIC
programming. When the EEPROM has been successfully programmed, the loader has
fulfilled its purpose and can be overwritten with the program/hex which you
really wanted on the PIC in the first place.
In the case of many Seca wafer-software files, the loader is built-into the seca
hex. So there is no need to load a loader as a separate step: simply load the
final HEX file, and that will allow the EEPROM to be programmed as well.
However, this is not always reliable, and in any event, there is no harm in
going though the extra separate loader step. It is adviceable, always to use a
the same dedicated loader for through-PIC programming, whether Irdeto or Seca.
The key/bin file in the EEPROM
------------------------------
The key file contains some data which mimic a MOSC (Manufacturer's Original
Smart Card). For example, an ATR, a country-code, a hex-serial number, an
ascii-serial. It also contains a pack of keys. In the case of Irdeto, maximum 8
packs. For Seca, maximum 16 packs. These packs can contain plainkeys,
plainmasterkeys, hexmasterkeys, providerids, dates, channel-ids (for Irdeto
beacon channels) and so on.
The key file can be edited on the PC prior to loading into the card's EEPROM. To
edit, use a standard hex-editor or - better - one of the various recently
developed utilities. This can be useful if you have found a stable version of
the software for your receiver, and now simply want to update/add one or more
keys to meet your needs (rather than blindly loading full hex/bin sets again
hoping they give you what you want).
Some versions of the Seca software once loaded onto a wafer allow new keys to be
entered (in a rather tortuous manner admittedly) using the remote control. Other
versions (both Seca and Irdeto) are "auto-updating" - they generate new key and
store them on the wafer as necessary (i.e. when the provider changes keys - as
happens regularly). Auto-Update only works, if you have valid masterkeys in your
software. For good reason, they often come WITHOUT them: If they are publicly
available, the tv-operater can get them as well and switch them off. So it not a
big disadvantage, it you only have the keys and get the updates if they are
changed from someone, who has a "secret" masterkey.
The program/hex file in the PIC
-------------------------------
This mimics an official card to a degree, but also offers more functionality.
For example, it can process many more providers than official cards. It
incorporates the decryption algorithms for the keys that are used to interrogate
or activate the cards in order to grant access to the encrypted channels. Many
different versions exist and they are constantly being tweaked, to create new
versions. More often than not they are matched in some subtle way to the
associated key/bin file. So best advice is to use the hex/bin pair as a pair -
don't mix and match.
Troubleshooting
---------------
There are so many variations of card, software, programming device, PC, CAMs and
receivers, that it is inevitable that problems arise. Sometimes problems are due
to faulty hardware, or mismatched hardware. Sometimes bugs in the software, or
the firmware of the CAM. When problems do arise, it can be difficult to find out
the cause. Here are a few known problems.
Some programming devices (such as the VP-2) can not work with laptops. This may
be due to the com-port settings, or to power-management of the COM-port. Always
switch off any power-management utilities you have running, and ensure that the
COM port you are using is powered-up.
Some programming devices (such as the VP-2) can not work reliably (or at all)
with fast computers - which can be anything from a Pentium 90 upwards. Such
problems may originate with bad (too fast) timing pulses generated within the
programming software, so that some software will work, others not.
Not all combinations of programming software and programming device are
compatible. There are lots of different PIC and EEPROM programming utilities to
try out, so when you find one that works, keep it.
Often small variations in voltage or timing pulses might cause read/write
errors, and verify-failures. The solution will usually be simply to start the
operation again (perhaps after re-inserting the chip, or cleaning the card's
contacts, or switching the programmer off/on).
Some wafer software is not compatible with some receivers or their embedded
decrypting-system.
Some CAM firmware is unstable in combination with wafer software. Astoncrypt
v1.03 is more stable than the earlier v1.00.
Different receivers behave in different ways. Some are more tolerant of wafer
files or flaky CAM firmware. Some receivers' firmware is itself buggy. The
Echostar ad3000ip is an example - it regularly hangs on Seca PPV channels.
Some loaders/boot-hex files work well, some don't. When you have found one that
works for you, keep it and always use it in preference to any that is supplied
with the other bin/hex wafer files.
Most embedded Seca CAMs can work with more providers' keys in the package than
can most (Aston) CI CAMs. A CI-CAM can typically only work reliably with maximum
9 providers, an embedded CAM with 14 or more. A Seca auto-update on a normal
goldwafer (1 PIC, 1 EEPROM) will usually only hold maximum 7 providers' keys in
any case.
some wafer files are known to contain addressing errors. So they will never work
properly. The best strategy is to keep hold of one that does work on your
receiver, and edit/add new keys as required - rather than having to hunt out
hex/bin files - which will certainly have new keys, but may also be badly
programmed software.
Give it a shot guys
The following text is a short newcomer-guide for programming a smartcard,
experts dont need it. It explains some basic facts of programmers and cards. You
will not become an instant expert by reading it, but it will help you to get the
files on the most common cards.
Generally seen, we use the following cards to program our files.
Wafercard: PIC 16F84 and EEPROM 24C16 (Twostone-Wafercard, Goldwafer)
AVR-Yupiter-Card: AT90S2323 and EEPROM 24C16 (Twostone AVR, 2323 is claimed to
be the "better" chip)
AVR-Yupiter-Card: AT90S2343 and EEPROM 24C16 (Twostone AVR)
Funcard: AT90S8515 and EEPROM 24C64 (Twostone-Funcard)
Jupiter 2 Card: AT90S8535 and EEPROM 24C64 (Twostone-Funcard)
PIC-Card: PIC 16F84 or 16C84 only useful for some D2Mac-Files, generally USELESS
FOR DIGITAL
Programming is done by using either a passive or active programmer. (AVR-Mouse,
PIC-programmer, Multiprog Quadro, Multiprog 2001, Multiprog 2001XL, Card-Maestro
etc.)
The easiest way for most cases is the use of a Wafer-card. Wafers exist in two
versions: The Goldwafer looks like a credit-card with built-in chip, the other
is the usual (green) pcb with the two chips (soldered or in two sockets) on it.
They do the same job. (Details for the cards see below).
The THREE steps of programming a genuine Wafer-card
---------------------------------------------------
1. the PIC needs to be programmed with the loader.hex (needed for step 2)
2. the EEPROM is programmed through the loader in the PIC with the EEPROM-File
(the keys)
3. the PIC is to be REprogrammed with the PIC-File (the card-program itself)
Step 1 is the most confusing one for beginners. Two chips and three files? For
an explanation see below "The loader/hex file". If you use "simple" hardware,
you need to switch them to the appropriate mode. (Picprog/Phoenix/Picprog) or
you will have to change devices if they dont support the programming of the
EEPROM and the PIC. Depending on the software you use, you will be told to do
that (eg. ChipCat) or you have to choose the appropriate software yourself. So,
you will have to do the following:
1. use hardware device Ludipipo to write Loader/Boot/Main file xxx.HEX to 16F84
PIC
2. use hardware device Phoenix to write key-file yyy.BIN to 24c16 EEPROM
3. use hardware device Ludipipo to write program-file zzz.HEX to 16F84 PIC
The most comfortable (and most expensive) way is the use of an active programmer
and its appropriate software, that does all these steps automatically (eg.
Multiprog.. and TwoProg-Software). They have a built-in "loader.hex", so you
will not come across step 1 at all and you will never need the "loader.hex" from
the files you download. You may also find PIC-files for SECA that have built-in
loaders, so step 1 can be omitted too. There are programs like "ChipCat" that
have built-in loaders as well AND work with almost any hardware.
Before using the programming-software, read the help or readme-files. You will
come accross the facts you read here.
In the programming-software you will see some switches, to be set. Dont change
them, unless you know, what you do. The correct settings are usually in the
hex-file, the switches will be set accordingly. If everything works well, you
end up with your working smartcard. If not, consult the detailed explanations
below and the troubleshooting section at the bottom of this file.
Solution 1 for programming Funcards
-----------------------------------
This has to be done in a somewhat different way. This is a working method with
Multiprog 2000, it should work with Multiprog 2001 as well.
Seca and Viaccess:
1. write the loader.hex file into the Atmel 90S8515 with Twoprog 2.2b (
www.2stone.de)
2. Convert the ee_ext.hex or the ee_ext_noleds.hex File with CRDconv12 into a
CRD.(www.funcard.net)
3. Use Cardhunter to write the CRD into the 24C64.
4. Write the flash.hex File and the ee_int.hex into the Atmel 90S8515 with
Twoprog 2.2b.
There comes no loader.hex with the Funcard files, right. It is a genuine
irdeto-loader (irdeto hex from www.funcard.net), but it works.
Irdeto:
1. Write the flash.hex File into the Atmel 90S8515 with Twoprog 2.2b. The
ee_int.hex is not needed.
2. Use Cardhunter to write the CRD into the 24C64.
Solution 2 for programming Funcards
-----------------------------------
The entire programming can be done using only ChipCat. But how do you get the
three files into the chip, as there are only two files to be selected in
Chipcat?
1. rename the ee_int.hex to flash.eep
2. load flash.hex into the program-memory (1),
>> the renamed flash.eep is automatically loaded into the data-section.
3. load ee_ext-hex into the external EEPROM (2)
4. write everything to the card.
I can confirm solution 2 working, ChipCat tells you when you have to change the
programming device or it needs to be set to another mode.
Some word about the aston-cam: if you program a funcard for seca, dont forget to
cover contacts 1 and 5 with a piece of scotch-tape or use the downside contacts
if you have the double-sided funcard. if you dont do that it may not be working,
as the aston is shortcut. below a top-view of the card.
-----
1234
5678
-----
upper
side
chips
-----
Maybe it looks complicated, to program your own card, but it is not. Maybe you
will need two or more attempts to get your card working. Write down, what you
did, you can use it as a reference. If you have one of these special recievers,
that need special files, the programming-proces itself does not change. Happy
viewing!
-----------------------------------------------------------------------------------------
In the following sections you will find more details about the facts you have
read above.
Read them, and use them as a glossary for answers.
-----------------------------------------------------------------------------------------
General Requirements
--------------------
* Windows PC with COM port & cable (e.g. COM1 port and the same serial cable to
connect a modem)
* Wafer card. Several formats are useable. Typically a "goldwafer" is needed.
* Programmer device that operates in "Ludipipo" mode for programming loose DIL
chips (PIC and/or EEPROM).
* Programmer device which can operate in Phoenix/Smartmouse mode for programming
embedded EEPROM chips
- if using a card with dismountable chips, no Phoenix/Smartmouse device is
required.
- these Ludi & Phoenix programmers can be 2 separate devices or a single "combi"
device.
* PIC programming software to operate the Ludipipo device
* Phoenix/Smartmouse software to operate any Phoenix/Smartmouse programming
device you need.
Details on suitable cards
-------------------------
Basically there are three main types.
1. Wafer cards
These are the traditional plastic credit-card type. They contain chips which are
etched into the layer sandwiched between the plastic, and so are invisible. They
follow international (ISO 7816) standards. The word "wafer" itself arises from
the fact that they are wafer thin. There are various kinds of such cards.
"Wafer" or "PIC-cards" usually refers to a card containing just one chip. These
can NOT be used for digital decryption unless for OD UK terrestrial services..
They were used for D2MAC analogue channels, and were known as MultiMacI (MM1)
cards.
"Goldwafer" is a card that contains 2 chips: one PIC and one EEPROM. They first
became popular as auto-updating D2MAC analogue pirate cards, and were known as
MultiMacII (MM2) cards. The name arose because most of these class of wafer
cards are gold coloured. But not all. Some are white, for example. In fact it
doesn't matter what colour they are so long as they contain the right chips. But
beware: many (most) of the white wafers are actually single-chip wafers, and
that is not sufficient. The PIC is type 16F84. Some older D2MAC wafer cards have
a 16C84. This is NOT ok, since it contains insufficient RAM memory to hold the
files that will be loaded. The EEPROM is a 24C16. Some variations are ok. For
example, the 24LC16 where the "L" indicates "low power consumption".
There are also "Triple" or "Quad"-wafers, but we are not talking about them
here.
2. SMD cards - Surface Mount Devices.
These are the same dimensions and layout as a plastic wafer card, but they
contain visible surface-mounted chips (i.e. chips whose pins are soldered onto
the surface of the card rather than through holes. The chips are very low
profile, so this card - like the wafers - fits into a CAM slot with the flap (if
any) closed. Some SMD cards are badly soldered and can give problems.
3. PCBs - Printed Circuit Board cards, or Print-cards (or PIC-cards)
These are normal circuit boards shaped to fit into the CAM slot and etched with
tracks which match the internally etched tracks of a wafer. They usually hold
sockets soldered onto the PCB, into which dismoutable chips are pushed. The
disadvantage of PCBs is that the size of socket+chips means they do not slide
completely out of sight into the CAM slot. They have to be made longer than a
normal card, with the sockets/chips at the end so that they stick out of the
CAM. This means that any flap over the CAM can not be closed (a minor
inconvenience). They have two significant advantages though. First, the chips
can be removed - and so can be programmed separately on a Ludipipo device. This
contrasts with the normal wafers, where the EEPROM chip can only indirectly be
programmed using a technique known as "through-PIC". More of that later. Second,
they can be made from standard electronic parts by the hobbyist.
More details on programmers
---------------------------
Most but not all programming devices work through the serial port using a
standard serial cable. Some (typically the more expensive models) work through
the parallel printer port, using a bespoke cable. The required power-supply is
typically 9v or 12v DC, delivering 300mA.
In order to program plastic cards, both the Ludi and Phoenix devices should be
equipped with a smartcard reader (i.e. a slot into which the wafer can be slid
in order to program it). Not all such devices have this as standard. If you are
intending only to work with PCB cards (with dismountable chips) then a Ludi
without card-reader will be all you need - assuming it has one or more sockets
suitable for inserting loose EEPROMs and PICs.
If you are working with plastic cards, you MUST have a Phoenix/Smartmouse
device, since that is the only device which can program the embedded EEPROM. It
will also have to operate at the lower speed of 3.57MHz. The higher speed of
6.00MHz is ok for modern MOSCs BUT CAN DAMAGE WAFER CARDS. Not all such devices
have a 3.57MHz oscillator - some only have a 6.00 MHz. But a 6.00MHz programmer
can be turned into a 3.57MHz programmer simply by swapping the oscillator
crystal - no other modifications are required. Note: a device in Ludipipo mode
does not use the crystal. Popular Ludipipos (also referred to as a "Hi/Lo
programmer") are the DL20 & JDM (Jens Dyekjær Madsen).
More details on programming software
------------------------------------
These programs offer features for programming, reading, and erasing the chips.
The HEX or BIN file is read from the pc-media into a buffer, and from there
piped across the COM-port/cable to the programming device and into the chip.
Most programs use checksums to verify what they are writing. There are a vast
range of utilities available, some Ludi-only, some Phoenix-only, some combined.
Some have additional handy features such as HEX disassemblers. Some programming
devices come with their own dedicated software. Note: whatever
Phoenix/Smartmouse software you use, it SHOULD support the 3.57MHz speed - and
not all do!
Overview of the programming process
-----------------------------------
The goal is to get a key file into the EEPROM, and a software file (including
key-decryption algorithms) into the PIC. The software file is usually a
hexadecimal (xxx.HEX) file. The key file is usually a binary (xxx.BIN) file.
A loader (or "boot") file may also be needed in order to pass the key file
through the PIC and into the EEPROM. The loader will typically be a HEX file.
Some programming utilities will demand that the file for the EEPROM is indeed a
BIN file, and the others are HEX. But if the downloaded files are not in those
formats, don't worry: there are utilities available for converting from one to
the other. There are also wafer software files available which allow the keys to
be loaded using new pseudo-nano-commands in CRD format as familiar to people who
have played with MOSCs.
The loader/hex file in the PIC
------------------------------
When working with non-removable chips (i.e. SMD cards, or plastic wafers), there
is a problem to be overcome: how to gain access to the EEPROM, since it sits
"behind" the PIC. The solution is to use "Through-PIC" technique. This means
loading a special file onto the PIC whose sole purpose is to pass the key/bin
file through to the EEPROM. This loader (or boot) file exists in many different
versions, with names like LOADER.HEX, MAIN.HEX, 16F84.HEX and so on. Often the
wafer-software files are packaged with a loader. But don't think you have to use
the loader which comes with the particular package. Once you've found a loader
which is reliable for you, save it and reuse it for all future through-PIC
programming. When the EEPROM has been successfully programmed, the loader has
fulfilled its purpose and can be overwritten with the program/hex which you
really wanted on the PIC in the first place.
In the case of many Seca wafer-software files, the loader is built-into the seca
hex. So there is no need to load a loader as a separate step: simply load the
final HEX file, and that will allow the EEPROM to be programmed as well.
However, this is not always reliable, and in any event, there is no harm in
going though the extra separate loader step. It is adviceable, always to use a
the same dedicated loader for through-PIC programming, whether Irdeto or Seca.
The key/bin file in the EEPROM
------------------------------
The key file contains some data which mimic a MOSC (Manufacturer's Original
Smart Card). For example, an ATR, a country-code, a hex-serial number, an
ascii-serial. It also contains a pack of keys. In the case of Irdeto, maximum 8
packs. For Seca, maximum 16 packs. These packs can contain plainkeys,
plainmasterkeys, hexmasterkeys, providerids, dates, channel-ids (for Irdeto
beacon channels) and so on.
The key file can be edited on the PC prior to loading into the card's EEPROM. To
edit, use a standard hex-editor or - better - one of the various recently
developed utilities. This can be useful if you have found a stable version of
the software for your receiver, and now simply want to update/add one or more
keys to meet your needs (rather than blindly loading full hex/bin sets again
hoping they give you what you want).
Some versions of the Seca software once loaded onto a wafer allow new keys to be
entered (in a rather tortuous manner admittedly) using the remote control. Other
versions (both Seca and Irdeto) are "auto-updating" - they generate new key and
store them on the wafer as necessary (i.e. when the provider changes keys - as
happens regularly). Auto-Update only works, if you have valid masterkeys in your
software. For good reason, they often come WITHOUT them: If they are publicly
available, the tv-operater can get them as well and switch them off. So it not a
big disadvantage, it you only have the keys and get the updates if they are
changed from someone, who has a "secret" masterkey.
The program/hex file in the PIC
-------------------------------
This mimics an official card to a degree, but also offers more functionality.
For example, it can process many more providers than official cards. It
incorporates the decryption algorithms for the keys that are used to interrogate
or activate the cards in order to grant access to the encrypted channels. Many
different versions exist and they are constantly being tweaked, to create new
versions. More often than not they are matched in some subtle way to the
associated key/bin file. So best advice is to use the hex/bin pair as a pair -
don't mix and match.
Troubleshooting
---------------
There are so many variations of card, software, programming device, PC, CAMs and
receivers, that it is inevitable that problems arise. Sometimes problems are due
to faulty hardware, or mismatched hardware. Sometimes bugs in the software, or
the firmware of the CAM. When problems do arise, it can be difficult to find out
the cause. Here are a few known problems.
Some programming devices (such as the VP-2) can not work with laptops. This may
be due to the com-port settings, or to power-management of the COM-port. Always
switch off any power-management utilities you have running, and ensure that the
COM port you are using is powered-up.
Some programming devices (such as the VP-2) can not work reliably (or at all)
with fast computers - which can be anything from a Pentium 90 upwards. Such
problems may originate with bad (too fast) timing pulses generated within the
programming software, so that some software will work, others not.
Not all combinations of programming software and programming device are
compatible. There are lots of different PIC and EEPROM programming utilities to
try out, so when you find one that works, keep it.
Often small variations in voltage or timing pulses might cause read/write
errors, and verify-failures. The solution will usually be simply to start the
operation again (perhaps after re-inserting the chip, or cleaning the card's
contacts, or switching the programmer off/on).
Some wafer software is not compatible with some receivers or their embedded
decrypting-system.
Some CAM firmware is unstable in combination with wafer software. Astoncrypt
v1.03 is more stable than the earlier v1.00.
Different receivers behave in different ways. Some are more tolerant of wafer
files or flaky CAM firmware. Some receivers' firmware is itself buggy. The
Echostar ad3000ip is an example - it regularly hangs on Seca PPV channels.
Some loaders/boot-hex files work well, some don't. When you have found one that
works for you, keep it and always use it in preference to any that is supplied
with the other bin/hex wafer files.
Most embedded Seca CAMs can work with more providers' keys in the package than
can most (Aston) CI CAMs. A CI-CAM can typically only work reliably with maximum
9 providers, an embedded CAM with 14 or more. A Seca auto-update on a normal
goldwafer (1 PIC, 1 EEPROM) will usually only hold maximum 7 providers' keys in
any case.
some wafer files are known to contain addressing errors. So they will never work
properly. The best strategy is to keep hold of one that does work on your
receiver, and edit/add new keys as required - rather than having to hunt out
hex/bin files - which will certainly have new keys, but may also be badly
programmed software.