Introduction
In this chapter, I will try to explain why there are different file types and how they function. Please keep in mind that this explanation will fit the majority of the files found on the Internet, not all of them. I am absolutely convinced that if you look for exceptions to these general rules, you will find them.
This chapter is constructed as follows:
- On this introduction page I will explain (among others) how files generally work
- On the underlying pages I will explain which file types are available for which cards
1. How does the software work
2. What is the purpose of the Eeprom on the card
3. What is Allcam or DS9
4. What files are there and which do you need:. hex or. bin or. crd files
How does the Software work:
A file set always contains a combination of Software and accompanying Variables.
The Software is stored in the processor of the card, the Variables (in most cases) in the Eeprom of the card.
On a PIC card (Goldwafer, Silvercard etc.) the processor is called PIC......
- the processor on a Goldwafer for instance is called PIC-16F84
On a Fun- or Jupiter card, an AVR processor is used. They are called AVR-90S......
- the processor on a Funcard for instance is called AVR-90S8515
The Software:
The software is static. Just as with any software program for your PC, it doesn't change. Look at a text editor for instance. No matter how much text you enter and regardless of the number of times you edit the text, the software doesn't change. Only the text is variable and does change. That is how your Smart Card works too. The Variables may change, but no matter how often they are changed, the Software remains unchanged.
However, as with software for your PC, updates are sometimes necessary for whatever reason. The most compelling reason to bring software updates, is when the software does not respond to an instruction, the way an original card does. Because that is when the card (file set) is vulnerable and can be disabled by the provider.
Providers send ECM's (Entitlement Control Messages) to update your card. When a pirate card is not capable of handling the instructions in that ECM correctly, the card could be disabled. You may expect providers to be constantly looking for ways to shut down pirate cards. If they find an instructions that does affect pirate card without affecting the original cards, you can be sure they will start sending those instructions (or ECM's) in regular intervals to disable all pirate cards that do not respond correctly. That is why some people call an ECM an Electronic Counter Measure.But that is incorrect. Anyway, if a file set turns out to be vulnerable to a certain ECM, it is analyzed and the software is updated to handle the instructions correctly in the future.
There is another way to prevent providers from shutting down your card though: the so called blocker.
Simply put: a blocker ensures that the content of the Eeprom (the Variables) doesn't get changed. That way, the card gets invulnerable to ECM's, but it does of course also mean that the card cannot Auto Update. So if you use a file set with built-in blocker, you need to manually edit your keys (in the Eeprom file on your PC) whenever they change, and then write the new Eeprom file to your card. That is no problem when a key is changed only occasionally, but it is a whole lot of hassle when it changes daily (or even more often).
Click here for a brief explanation, by using an example source code
The Variables:
The software won't do anything without Variables. In other words, if the Eeprom does not contain the required data, or the correct layout, the software doesn't have any valid data (Variables) to work with. In that case, your files won't work properly and your screen will remain black. Or it will show a warning that you are not authorized to view that channel.
You can imagine that it is of the utmost importance that the data in the Eeprom is stored using a layout specification, dictated by the software. The Eeprom is nothing else but a very simple database, containing all the information to decode a channel. The database structure could be regarded as 1 long line containing all the data. The begin- and end position in the database is predefined for every variable contained. It is a database containing 1 record which in turn contains many fixed length fields.
In the Secanix source, explained above, the structure is as follows:
- positions 0 through 7 contain the serial number
- positions 8 through 15 contain the number of supported providers
- positions 16 through 393 contain all kind of data about all providers (prov. ID, name etc.)
- all kind of other data is stored on positions 394 through 1023
- from position 1024 through the end, all keys per provider are listed
The relation:
As should be clear now, there is a strict relation between the software (the processor file) and the Variables (the Eeprom file). If, for example, you would use an Eeprom file in which the keys are at the beginning of the file and the rest of the data at the end, the Secanix software would not read the required data from the Eeprom. A request for the serial number is read from position 0 through 7. But if you use an Eeprom file that starts with the keys, the value returned would be the content of the first key. In this case, key 00 of provider 00 00 (the Seca provider).
That is the reason for the large number of different file formats in Picbined. Look at the screen shot down here. They are all files that use different Eeprom layouts. In other words, the files in all the file sets mentioned in this list, are not interchangeable.If you would use the processor file of one with the eeprom file of another, it will not work.
This is equally true for all other files for all other coding systems (Irdeto, Viaccess etc.).
Then there is one last file type to be explained.
The kind of files that don't try to behave like an original card, but use emulation to reach their goal.
Allcam or DS9:
For use with PIC-2 cards (like Silvercards) the files are called DS9 files. If they are meant for the funcard, they are called Allcam files. But DS9 is the name of the original project. DS9 = Deep Space 9. It started of as an attempt to emulate Seca in an Irdeto CAM. The system has evolved to support ever more coding systems in 1 CAM and with the use of only 1 card. Nowadays, these files are often named by the number of coding systems they can emulate: 3-in-1, 4-in-1, 5-in-1 etc.
Just have a look at the Picbined screenshot below.
The Allcam technique:
Allcam requires 2 parts to work together:
1. The Allcam patchof the CAM
2. The DS9/Allcam files
Allcam patch:
The Allcam patch is a software modification to the CAM, to enable it to decode multiple coding systems. But....... there is only a small selection of CAM's for which a patch exists. New patches for other CAM's are created every now and then though.
The Allcam patch uses emulation. Emulation in this case means that the software doesn't try to decode the present coding the way a MOSC would. It just tries to understand the question en then give the proper answer. The difficulty in this method is that there is only 1 CAM involved, and that CAM is an Irdeto CAM. So the questions and answers need to be in the Irdeto "language", even when the current channel is broadcasting in Seca, Viaccess or whatever.
That is where the Allcam patch (the altered CAM software) comes in. The Allcam patch makes sure that the questions by, and answers to the receiver/CAM, are translated into the proper syntax. If you switch on a Seca coded channel, the receiver/CAM will communicate in Seca. An ordinary Irdeto CAM wouldn't understand the communication. The Allcam patch however, translates the Seca commands into their Irdeto equivalent. The CAM will then communicate with the card as if it were an original Irdeto type card. When the card has responded with the requested information, the Allcam patch will translate back the answer again from Irdeto into its Seca equivalent, and pass it to the receiver.
Allcam files:
Allcam files will only work in combination with an Allcam patched CAM. The Allcam patch does not affect the way the CAM behaves when used as a normal Irdeto CAM. So even when patched it will handle Irdeto MOSC just as it would before it was patched.
At the moment of writing this page, most Allcam files are capable of handling Irdeto, Betacrypt, Seca, Viaccess and Nagra Vision, hence the name 5-in-1 as these files are often called. It is likely that in due time, more coding systems will be added to this list.
Although there are many people that offer Allcam file sets, most of them are based on only very few really different software. In other words, there are only very few truly original Allcam file set authors. The consequence is that all files always fall victim to the same problems, bugs, attacks etc. at the same time. Changing from one file set to another doesn't solve the problem as they all use the same software.
Another consequence of Allcam technology is that Allcam files cannot be made to Auto Update.
Because they use emulation, the question-answer strategy is limited to only the most elementary answers (like the necessary keys). The limited program space in the CAM and on the card, makes it impossible to create a software that could really decode all the supported coding systems, the same way their MOSC equivalents would. But maybe new technologies with more program space will make it possible somewhere in the future. Who knows.
File formats:
If we discard the program specific (non standard) file formats, there are generally 3 different file formats in use:. hex,. bin and. crd.
The software (PIC- of AVR file) is always distributed in. hex format.
The eeprom file can be in all 3 mentioned file formats.
It doesn't matter which of the 3 formats you use, they all contain the same content.
So if your file set offers an Eeprom file in both. bin and. hex format, you may use either one. The final Eeprom content will be identical, regardless of the file you used. The software will always translate the format used into a format to be written to the Eeprom.
If you use Chipcat for example, you can load all 3 file formats for the Eeprom.
Not all programmer software will allow you to load all these file formats though.
So in some cases it might be necessary to convert the file format you have, into a file format supported by the programmer software.
You can use Picbined to convert between file formats.
In the Software chapter (sub section Divers) there is an explanation about file format conversion on the Hex2Bin2CRD page.
A. hex file contains data in hexadecimal format.
A. bin file contains data in binary format.
A. crd file has a completely other structure, but in essence carries hexadecimal data.
You could regard a. crd file as a kind of macro command file like the ones you can create in most spreadsheet programs.
It is a description of all variables, generally documented for better readability, containing the exact location in the Eeprom (the offset) where the variable has to be stored.
This makes. crd files especially useful for partially updating an Eeprom instead of reprogramming the whole Eeprom. If you need to change only 1 key for only 1 provider for instance, it is a lot faster to use a. crd file to update only those few bytes. Changing the Eeprom file on your hard disk and then writing that complete file to the card, takes much more time.
All other file formats you might encounter are program specific. Chipcat for instance can handle the. obj file type for programming AVR type processors. As these file types are seldom (never??????) used, I discard them here.