Smartcard interface with TDA IC

[Bust3D]

Hi to all.

I got a double smartcard interface from a Sony TS1A model satellite receiver with TDA8004 and TDA8006.

The conectors i got on this interface is:
GND,RESET,TX,RX,GND,+5V,12V

MY question is, it is possible to add max232 for connecting to serial, and if it works with newcs ?

PS.
Or somebody have a good working schematics with TDA8004 smartcard interface. I readed about TDA 8004 IC interface is the best way for hardware card detection and compatible with all the card's on the market.

Sorry for my English ... is poor.
Best Regards.

[Bust3D]

Some data from TDA 8004T


And the double smatcard interface with TDA 8004 and TDA 8006


And here is a picture of mine



If not work this double interface with cccam or newcs somebody could make drivers or something to work with ?

I'm interested in single card interface with TDA8004.

[gw1]

You haven't mentioned what service or cryptosystem you're trying to receive, and that's the crucial thing. For the sake of argument, let's suppose it's Seca Mediaguard.

Let's suppose your "Sony TS-1A" receiver is , aka Sony GoldBox. I've no experience with it, but it appears to have a Seca softcam. That means it should work with most Seca smartcards.

To use that receiver with a cardsharing network, you should first confirm with the cardsharing network administrator that the satellite service you want to decode is compatible with your Sony receiver. ie, if you were to borrow his legit smartcard and plug it into your receiver, would it work? If not then in most cases your receiver cannot be used, regardless of what cardsharing software you might add.

Next, you would need to find a Seca cardsharing client program (for Windows or Linux) that supports RS232 season interface and which is known to work with the service you are after. Such programs are seldom used in Australia, so I can't speak from experience, but no doubt they exist in Europe. Your cardsharing server administrator would be able to advise you.

Then you would also need a login account to a cardsharing server running that Seca service. Your server administrator would provide this, either because he's a friend or because you've paid him. He would advise on network settings and any other configuration your cardsharing client program might need.

And finally you would need a season interface, to connect between your PC serial port and the receiver smartcard slot. These use standard ISO7816 protocol, and so the smartcard controller IC (TDA8004 etc) is irrelevant.

Once you had all that working, you would have the option of making connections to the smartcard PCB inside your receiver, which would allow you to mount your season interface either inside the receiver or behind it. That would be an alternative to having the season interface sticking out the front of your receiver's slot. That's about the only option you have for modifying the internals of the receiver, except for updating it's firmware (a few receivers have hacked firmware versions available).

But your problem I think is that you don't really understand satellite encryption, or cardsharing. You have looked at the smartcard interface and are hoping to find a way to modify it or somehow connect it to other programs to magically unlock channels and get free pay tv. Well it just doesn't work that way. The only ways to decrypt pay tv are:

• using a legit subscriber card in a card slot of compatible receiver (or CI receiver + CAM)
• using a clone card, with valid keys, in the above card slot
• using hacked firmware together with valid keys, where the cryptosystem has been broken and hacked firmware is available for that receiver
• using a Dreambox or similar receiver with inbuilt cardsharing client, connecting over TCP/IP to a server that has a legit subscriber card, clone card, or valid keys
• using a receiver with compatible embedded CAM (or CI CAM) in conjunction with a season interface and suitable cardsharing client application on a PC
• using a compatible receiver in conjunction with a cardsplitter, ie a simple home cardsharing product, that supports the cryptosystem you want, together with a legit or clone subscriber card.

There's no way to get pictures without either a valid subscriber card, or working keys, or a clone card containing working keys.

So in your case, unless you know someone who has a valid subscriber card or clone card that he's prepared to share with you, you won't be able to get pictures regardless of what receiver, firmware, interface, client app or protocol you use.

[Bust3D]

Thanx for your reply GW1 , sorry i haven't mentioned that , i want to adapt this cardreader to a linux based router on RS232 port.
I want to make a NEWCS cardsharing server width this reader.
So if it possible to make or modify this smartcard reader type to work as a phoenix interace or somehow to work with NEWCS or other Soft based CAM.
Or make a reader based on schematic from PDF files witch is phoenix compatible.

Best regards.

You haven't mentioned what service or cryptosystem you're trying to receive, and that's the crucial thing. For the sake of argument, let's suppose it's Seca Mediaguard.

...

[LeroyPatrol]

I think you will find it easier if you buy a phoenix programmer like this


Cheers,
Leroy

[Bust3D]

If it is possible i want to use interface with this TDA IC cause it's used on many satellite receivers interfaces based on this IC.

And i't hardware card detection stuff and more stable then any phoenix interface on the market (this is my opinion).

I think you will find it easier if you buy a phoenix programmer like this


Cheers,
Leroy

[LeroyPatrol]

well I think you may be wrong with your assumption.

Leroy

[gw1]

OK. Now I understand what you mean. You want to produce a Phoenix-like interface using that PCB, removed from an old satellite receiver, to drive the smartcards. Doing it would offer a number of advantages, such as multivoltage (5V,3V) support, software programmable clock and overcurrent protection.

Though it's technically possible a LOT of work would be needed. The problem is the code in the TDA8006 microcontroller (which is mask programmed ROM, not flash) is almost certainly undocumented and Sony proprietary, which means you'd have to reverse engineer it by extensive trial and error to figure out the serial command protocol between it and the Sony receiver's main processor.

Once you had figured out that protocol you could then hook it up to a linux device using a MAX232/MAX3232, using data lines only without handshaking, assuming you had skill and time to write your own driver to communicate with the TDA8006 (using the reverse engineered command protocol).

Alternatively you could program a separate microcontroller to sit between the TDA8006 and an RS232 connector, to implement a two-card version of the sc8in1 protocol supported by NewCS. That would translate between the (reverse engineered) TDA8006 command protocol and the RS232 handshaking & command convention used by sc8in1 (which is more or less documented).

The TDA8004 smartcard controller (and similar chips from various other manufacturers) has lots of advantages over simple "dumb" Phoenix/SmartMouse interfaces. But such controller ICs are all designed to be driven by a microprocessor, for clock divisor selection, card voltage selection, startup/shutdown control, etc. The Phoenix interface convention was never designed to handle such things: it does RxD/TxD data, card presence signalling, reset control, and that's it. Nothing more. The reason you don't see any Phoenix interfaces using those controller ICs is because they would need not only a microcontroller to drive them, but more importantly a convention for communicating with them. There is no such convention. The closest thing is sc8in1, which handles card selection, card presence and data ready signalling but doesn't (AFAIK) have anything for control of card clock frequency or card voltage.

When interfacing with something like NewCS there is also the potential for timing problems. To illustrate, ask yourself, how exactly are you going to control the 3V/5V card voltage? What you're supposed to do is program the card slot for 5V, start the card, parse the ATR, and if it requires a lower voltage (3V or 1.8V) then you should immediately shut down the card, reconfigure the card slot's voltage, and restart. But while your interface attempts to perform that sequence you may find that the cardserver software times out. There are usually ways around it, but that's an example of how things often aren't as simple as they might seem.

If you decide to try and reverse engineer the protocol then check out the TDA8006 [90K PDF] by Keil - it's possible that Sony used Keil's sample code closely, which may give you a head start interpreting their message format, commands and error codes.

[Bust3D]

GW1 thanks for your reply
I understand that not quiet simple to make this interface to work with NEWCS

Please offer me a schematic from the best stable phoenix interface witch you know.

[LeroyPatrol]

do a search on here for Jaycar and there was another that a guy recently designed.

Leroy

[gw1]

there was another that a guy recently designed

You're probably referring to . I wouldn't say his interface design is any more stable than a regular phoenix. His adaptation was to switch between Phoenix and JDM modes electronically using a momentary push button, which he did mainly because in his country it's hard to get parts and he had no 4PDT switch. Because of the 12.5 Vpp the change opened a can of worms. They were sorted out, but if stability is your prime concern then I wouldn't go with msay's design because extra complexity means scope for things to go wrong.

Stability hasn't really been a problem for any of the Phoenix / SmartMouse interfaces. Which is actually surprising, given how many of them have poor supply decoupling across their card socket Vcc and GND pins.

Fully ISO7816-compliant smartcard interfaces that use dedicated controller ICs are more robust than simple Phoenixes, for a couple of reasons. The main one is the careful sequencing of power, clock, reset and data signals, which avoids the damage and data corruption that can occur when devices are inserted or removed from powered systems. Also they usually have better protection against electrostatic discharge. Those are very real problems in financial applications where cards are inserted and removed many times each day, in rugged environments.

Ideally every smartcard interface would use such chips (or at least only apply card power after the socket switch activates!). But for hobby purposes the simple and cheap Phoenix design is adequate for experiments, card programming and card serving.

The main problems people have had with various Phoenixes:

• In many designs (eg , , and even the Phoenix design) the ICs that drive clock & reset are susceptible to damage if card is inserted or removed while power is applied, because they lack overcurrent protection. That's why the Jaycar Mk II kit has so many resistors. Both the HC04 clock IC and MAX232 can be destroyed in this way if you're unlucky, and I've seen it happen several times over the years. Whatever Phoenix you use, a good precaution is to remove power before inserting or removing the card.
• Sometimes the MAX232 gets killed, which can happen if you use a switchmode plugpack and apply power before hooking up the serial lead first. Connecting both ends of the serial lead before plugging in power will prevent that from happening.
• Sometimes people make the mistake of using an incorrect serial cable, eg a null modem cable plus gender changer, or a thin cheap mouse extension lead. For Phoenix interfaces you should use a fully wired (all 9 pins) male to female one. If unsure ask to test it with a multimeter in-store, or keep the receipt just in case.
• Using an underpowered plugpack, eg 100 or 150mA, could cause stability problems with some cards (eg perhaps gamma) that use a lot of current, especially if you're overclocking. In practice there have been very few reports of this though. A 300mA rated plugpack will be more than sufficient.
• Using a plugpack with insufficient voltage, eg 7.5V DC unregulated. Most Phoenix interfaces use a 7805 or similar linear voltage regulator to generate the card's 5V supply, and those regulators need a couple of volts headroom at the input. If using too low input voltage it's possible that stability could suffer. In practice there have been very few reports of this though, probably because unregulated plugpacks tend to produce higher-than-specified output voltage for low loads, and most of the time Phoenixes draw very little current. In general a 9V DC input is best, unless the Phoenix product specifies otherwise.
• There are a couple of cheap phoenix products out there (eg ) that require 5V regulated power input, either from USB cable or from 5V regulated plugpack. Some people make the mistake of using a 6V plugpack, which can kill the ICs.
• Some people try using Phoenixes through USB to RS232 adapters, not always with good results: . It's preferable to use a PC with DB9 RS232 port.
• Virtually all Phoenix interfaces only support 5V cards. The Phoenix protocol doesn't support programmatic control of card voltage, so if you need to use a 3V or 1.8V card then you should look for a more up-market card interface that supports multivoltage cards (such interfaces are relatively rare) or look at modifying the Phoenix. Modification may be as simple as replacing the regulator and MAX232 with 3V types, but not always; it depends on the design.
• In a few cases there have been design issues with the DC characteristics of the smartcard I/O line, resulting in incompatibility with certain cards. A case in point is the Jaycar Mk II, which drives down the I/O line only weakly during TXD, too weakly for some cards (eg Irdeto ACS 4 & 5) which have stronger internal pullups. Basically the Jaycar Mk II doesn't properly meet ISO7816 specification in that regard. A schottky diode mod fixes that problem.

is a very simple design really: a bare-bones method to connect ISO7816 to RS232. Whether you handle the I/O using a 7407, a schottky diode, a resistor or a transistor, it doesn't really make much difference to stability. Provided you decouple your regulator and card socket VCC/GND, and use a proper clock oscillator design, you won't have stability problems.

Stability problems are more often than not related to software, especially if used in a cardsharing server. There can be TCP/IP connection problems in the application, the router or even the OS. There can be memory leaks, glitches due to background processes, , card overheating due to EMM storms, fake ECM countermeasures, network latency glitches etc etc. None of which are the fault of the smartcard interface.

Please offer me a schematic from the best stable phoenix interface witch you know.

If you want to build your own Phoenix then the Jaycar Mk II kit is as good as any, IMO. Besides Jaycar stores, you can also order the Mk II kit from . Recommended mods, construction gotchas and troubleshooting steps are summarised .

As an alternative, for enthusiasts who enjoy veroboard construction I suggest the circuit design, with a couple of changes:

• add a 470R current limiting resistor on the smartcard socket RST pin
• add a 47R current limiting resistor on the smartcard socket CLK pin
• ensure one of the 100nF decoupling capacitors is placed directly across the smartcard socket VCC and GND pins.
• you can substitute other schottky diodes if you wish, eg or , if you can't find 1N5819. for best results don't use ordinary silicon diodes though: they will usually work but may be incompatible with some cards.

Phoenix current limiting was also discussed .

[Bust3D]

Hi gw1.

Here the interface schematic and data sheet for TDA8004 smartcard interface

Have a look

[gw1]

That sounds interesting but I can't access it. Can you please repost the PDF using Megaupload, or iFile.it, or similar? Thanks.

[Bust3D]

Here it is



Waiting for suggestions

[gw1]

No, that's actually a TDA8004 emulator I think. It provides a means for set top box engineers to evaluate Atmel's AT83C24 smartcard controller in future designs as an alternative to the TDA8004. You can read more about that .

[daemon123]

I would surely like to see phoenix interface built from TDA chips as i the smartcard slot that i salvaged came from old stb which had this chip.

With the help of GW1 i was able to built Phoenix based interface based on MK-1 Design with modification for clock driving IC as i couldn't find one on the MK-1 Design.

Here are the PICs of the reader, its enclosed in old PCMCIA based reader box perfectly fits in floppy drive bay.










Reads almost all card i have tried, specially white