Reply With QuoteAnd here's the for those who haven't seen it. I've no idea who published it and the best I can carbon date it is 1995-98.
Jaycar Mark I Phoenix revisited
The old Jaycar Mark I Phoenix interface was mentioned recently, and I thought it'd be nice to dust it off and indulge in some nostalgia. Newcomers may have missed it completely since it's no longer for sale from Jaycar, replaced by the Mark II (KC5361). Comparing it to the Mk II is instructive for those of us into electronics.
The original design was published in . It was a plain Phoenix interface with no JDM mode, which basically means it could be used to talk to preprogrammed smartcards but could not program blank ones. Its design is very similar to the original Phoenix schematic.
The original Phoenix design established a convention for mapping RS232 signals to ISO7816 smartcard pins: TXD and RXD send and receive commands, and asserting RTS resets the card. It didn't provide any means of sensing card presence - that was added later.
Card Detection
Most Phoenix implementations do detect card presence and signal it to software using the RS232 CD (carrier detect) line. The Jaycar Mk I, as you can see from the schematic, produces a logic 1 on IC1 pin 11 when the card is inserted. This translates to -9V on the RS232 CD wire and logic 1 in the UART register.
Not all Phoenixes agree on the polarity of CD however because the original was silent in that regard. The ambiguity wouldn't be so bad if applications offered users an "invert CD" option, but few do. Consequently there's an incompatibility hassle between phoenix interfaces and software that continues to this day. Some programs wait until you insert a card, which works great with some companies' Phoenixes but not others. Other software ignores CD completely and just reports an error if the card doesn't respond. That's probably the best you the user can hope for. Sometimes you can work around compatibility problems by withdrawing your card slightly from the socket, assuming the switch contacts open before the card contacts dislodge.
(By the way, if building your own Phoenix out of parts, beware that the smartcard sockets produced by some manufacturers contain normally-closed switches instead of the normally-open one used here.)
In the Jaycar Phoenix Mk II, published six months later, the design changed and the opposite polarity of CD was produced. Essentially instead of pulling the logic signal high when the card was inserted they pulled it low. The explanation given in the Silicon Chip July 2003 article was that this offered compatibility with a greater range of software. That may be, but more than a few users found the change confusing or inconvenient. In hindsight a better compromise might have been to make CD polarity a jumper configurable option.
Card Clock
Blank smartcard programmers (such as JDM and PonyProg) generate the card clock by software, but Phoenix interfaces do it by hardware. The ISO7816 spec restricts valid card clock ranges between 1 and 5 MHz, and specifies a ratio between clock speed and the initial bit rate. The ratio of 372 was chosen because this lets card readers use cheap 3.58MHz crystals in combination with the standard serial rate of 9600 baud. That didn't stop Irdeto doing their own thing though and using 6MHz, perhaps their cards were so inferior they needed to be overclocked to compete.This Phoenix implementation provided oscillators for both of those frequencies, with a jumper link to enable one or the other.
The Jaycar Mk I and Mk II both generate card clocks using inverting HCMOS gates of one kind or another. 1M feedback resistors bias them as linear amplifiers; 1K5 series resistors prevent excess current from stressing the crystals, and buffer stages provide important isolation between the sensitive amplifier and the noisy load of the card. The originally published Phoenix schematic contained an error in its clock circuit which these designs correct. The Mk II greatly simplified the clock circuit by putting the link directly in series with the crystal, rather than using it to switch a DC logic level. (Moving the frequency selector out to a front panel switch using flyleads would be safe on the Mk I but problematic for the Mk II.)
Fussy cards
Under the ISO7816 standard cards can dictate their preferred communication rates and operating voltages. They do this by supporting 9600 baud and 5V initially for the ATR and specifying their requirements for the host to observe in subsequent communication. For that reason you may encounter situations where the ATR is readable but subsequent logged communication is scrambled, or vice versa.
Card voltage is another story. The majority of older equipment, and every Phoenix interface I've ever seen, only supports 5V. In theory host software should check the ATR voltage specification and shut down cards it doesn't support. In practice that seldom occurs. The card overheating seen with certain combination of cards and hosts isn't necessarily because of voltage incompatibility. Some receivers overclock cards too high, while others have CAM firmware that send demanding commands more frequently than other receivers do.
Card I/O and the Schottky mod
One final important feature of the Jaycar Mk I is its use of a schottky diode to combine the two RS232 data lines onto the single half-duplex ISO7816 I/O line. There are other ways of doing this. The original Phoenix used an open collector buffer, and discrete transistors/MOSFETs would also work. The schottky approach is simple, cheap and effective (it's also what the original season interface used to perform the same task, AFAIK). The choice of a schottky type rather than a garden variety silicon one is advisable because if the forward voltage drop is too high the interface may not be low enough for the logic 0 input threshold of the card, depending on the card brand and/or temperature. The Mk I also has a 10K pullup resistor on I/O which is important because cards vary on their I/O impedance and without adequate pullup the data rise time deteriorates and also is more susceptible to noise.
The Jaycar Mk II designer for some reason replaced the diode and pullup resistor with a single 4K7 resistor in series between the logic TxD and the card I/O, but that was a bad move. With Mk II the card I/O level during a logic 0 write was no longer around 0.2V as it should be but much higher because the 4K7 forms a potential divider together with the card's internal pullup. This meant cards with stronger internal pullup may not receive logic 0 reliably from Mk II. That's why people experimenting with certain cards such as Irdeto V4.1 'Delta' found they worked with Mk I but not with Mk II, unless the 4K7 was pulled and replaced by a diode.
Props to the Austech member(s) who identified the 4K7 as being the cause of the Delta bug. If my memory serves correctly it was Nexus and/or Cwispy. It had us all stumped for a while there. Cheers fellas.
With the schottky mod in place the Mk II has no pullup on I/O apart from the one inside the card and a very weak one inside the MAX232. I anticipated that might be a problem (which is why some mod photos show an extra resistor between the schottky anode and +5V) but it hasn't been a problem in practice.
SmartMouse
Another interface design around the same time, called SmartMouse, was functionally identical except it used the opposite polarity RTS to perform the reset. The Jaycar Mk II added a SmartMouse jumper link option for compatibility with software written for that RTS convention. The Mk I didn't have it, but none of the applications I played with required it so I never missed it.
And that about covers it. The Mk I was a good, cheap, reliable kit with no problems to speak of besides its limitation of being unable to program blank cards.
| Look Here -> |
And here's the for those who haven't seen it. I've no idea who published it and the best I can carbon date it is 1995-98.
"The Black Book - European Scrambling Systems 5" written by John McCormac and published in 1995 has the original Season & Phoenix Interface schematics released spring 1994 and developed by Markus Kuhn
the season interface (so the author could watch the next season of Star Trek TNG) came 1st then was modified into a phoenix (risen from the ashes) so lazarus cards (original BSkyB Videocrypt cards sold pre-pay style) could be resurrected
The good old days of making your own season device, spliting the pcb board in half then etching it, then getting free samples of MAX232 sent to you from there website.
Adobe
Great information, thanks! That late 1994 date is supported by the batch numbers of ICs in the photo.Originally Posted by Mysterex
Poor Markus. Now that you've exposed him as the originator of those interfaces, Austar and Foxtel will go after him!
By the way, when Jaycar stocked this interface it was listed as KC5342. That number wasn't mentioned in the Silicon Chip article though.
Anyway now when you see old posts mention KC5342 you know what they're referring to
Here is a older one for you all that I put together a long long time ago in a cd rom.
sorry about the pics crap camera
Last edited by badass; 24-07-09 at 01:56 AM.
OSIRUS (24-07-09)
what's the best software to run this kit, I tried using the Elvis's Multiprog but no joy, which is funny seeing as the Multiprog worked on my MKII unit
Lmedit, ggedit,FMcard, and thats just a few.
This interface will work with any program written for Phoenix hardware, such as LMEdit, GGEdit, FMCard, AusGold Card Writer, NewCS, GreyWolf and many others, as badass said.
Some programs such as ICProg support multiple hardware types and multiple interface modes. Those programs can be used with Jaycar Mk I interface but only in phoenix mode. Their other modes won't work.
A few programs are written for SmartMouse interface and require SmartMouse mode, not Phoenix mode. Those will work with Jaycar Mk II but not the Mk I.
But since Phoenix mode only works with cards that have already had their code programmed, you can't use Jaycar Mk I to program blank cards. Brand new blank cards (gold, silver, emerald or fun) can't be used with the Mk I until they've had some code written to them using another device of some kind.
Gw1 you said something about the Jaycar MK1 could be used in a spare comport on the DM500
is this also able on the Strongs
mick
Ps added the USB supply + to the long link directly behind to card slot
have pic post later.
Last edited by mickcc; 31-07-09 at 09:35 PM.
Phoenix is a convention for accessing ISO7816 smartcards via RS232. Some softcams on Linux boxes can be configured to access smartcards via RS232. For example on DM500 you can configure mgcamd softcam to talk to newcs cardserver and configure newcs to use either a single card on the RS232 port via Phoenix protocol, or multiple cards on the RS232 port via 8-in-1 protocol.
But don't run Linux, AFAIK, so they can't run the softcams and cardservers Dream users are familiar with. The Irdeto / Conax CAS7 softcams used by Strong only work with the internal card slot, not with Phoenix interfaces on their serial port. They use the serial port only for loading firmware updates.
Over the years unofficial/hacked firmware has existed for some Strong receiver models, such as the SRT4800 II, to implement unofficial softcams and even card emulators. But AFAIK there aren't any which utilise the RS232 port for Phoenix interfaces. I could be wrong, but if such firmware exists I've not heard of it.
OSIRUS (31-07-09)
Some of you, particularly those with a hacking bent, might be interested to know that Markus G Kuhn is a specialist in the area of computer and smart card security and was instrumental in the cracking of the Dallas DS5002FP Secure Microcontroller, described at the time by one European signals intelligence agency as "the most secure processor available on general sale. The processor is Intel 8051 compatible and is used in financial transaction terminals and pay-TV access systems."
"The attack requires only a normal personal computer, a special read-out circuit built from standard electrical components for less than US$100, and a logic analyzer test clip for around US$200. It was performed in a student hardware laboratory . . ."
A few years ago, much to the consternation of banking security professionals, he exposed flaws in smart cards recently introduced to the U.K. banking system.
He is of German nationality and currently works as a lecturer in computer science at the University of Cambridge.
His biography is to be found here , his Cambridge details here and an impressive list of research papers here
Posting Permissions
Bookmarks