can't be done with this programmer......
Just a quick question,
I have recently bought a Smartmouse/Phoenix reader programmer from
I can see how you can change the jumpers from;
Smartmouse to Phoenix,
& from 3.57 to 6,
& I can read a goldie with FM Card no worries,
but I am wondering how do I change between reading & writing to the eeprom,
& reading & writing the to PIC
On the Jaycar MK II it has a white switch to change between these,
Has anyone successfully used one of these to make a Goldie,
Thanking you for any help in advance,
Look Here -> |
can't be done with this programmer......
well....that was a quick thread,
thanks hoe
You can copy and write a goldie with GGedit and that programmer in phoenix mode alone.
KK
Yeah you need an Elvis or Emprom programmer to load the Ghost hex file.
DM500s Black with rear on/off switch $99 inc post , DM800 sim 82 $250 inc post, DM800SE $310 inc
Osiris,
I have just bought on e from Sattronics too. While I can find the dip switch to switch between smart mouse and pheonic hz values 6 & 3.58 , I havent found any jumpers and I cant get my unit to work in load me 2 .
Can you asist with what is required to change the config from smartmouse to pheonix other than the dip switch ??
cheers
Ramp
You can update a preprogrammed goldie using phoenix mode, but you can't do anything with a blank card using phoenix mode alone. The card must have already had a loader of some kind in it.
Phoenix mode just sends ISO7816 commands and receives their responses. A blank card, or one which has been incorrectly programmed, cannot send ATR properly at powerup nor can it listen to commands, act on them or send replies. Phoenix mode cannot write to a card's code or data eeprom spaces directly - all it can do is send commands to a loader that's already running on the card and ask it to perform the writes on its behalf.
PIC based cards (eg gold, silver, emerald, green, blue & zen wafers), like PIC chips, require special voltages and logic sequences for programming. In the old days people would buy special programming hardware from Microchip (the makers of PIC) to do this. The original JDM/Ludipipo programmer was devised as a cheap way of doing the same thing using voltages coming out of an RS232 serial port. It set a convention for mapping RS232 signals to PIC pins which tools such as ICProg adhere to when you configure them to use 'JDM interface'. The Jaycar Mk II programmer uses a completely different circuit to that of the (which was designed to get power solely from the serial port) but when you switch the Mk II into JDM mode (button out) it adopts the same RS232-to-PIC signal mapping as the JDM. In that way the Jaycar kit is compatible with tools such as ICProg in JDM mode.
Atmel AVR based cards (eg funcard, jupiter, x-card, atmega, blackcard) also need special logic sequencing to be programmed and can't be programmed from blank using a Phoenix programmer. Unlike PIC they don't require 12V though. JDM mode is specific to PIC cards, not AVR, which is why the Jaycar Mk II kit can't program blank funcards. You can build a for parallel port very cheaply (it uses the C4 and C8 smartcard socket pins in addition to clock and reset), and it's programmed in ICProg by choosing 'fun card programmer' as its hardware type. There's also a serial port based programming system for AVR called which is very popular.
Normally to get a gold wafer going you'd program three hex files to the card: code, internal data and external eeprom data. Programs such as ICProg have a 'smart card' option which you can choose in conjunction with processor type. When selected, ICProg lets you load up three files for those three memory areas and write them all at once. To do that it, using JDM mode, ICProg first erases the code area and writes its own tiny loader into the code area. It then communicates with the loader and gets it to write to the external eeprom on its behalf (on most wafer cards the external eeprom isn't directly accessible from the card contacts - it can only be controlled via the smartcard processor). When that's done it erases the code area again, writes the code, then writes the card processor's internal eeprom data. To finish it optionally writes processor-specific fuses which control various things like clock options, watchdog or brownout auto-reset features, or copy protection. The same principle applies when programming blank AVR based cards using ICProg and suitable hardware.
Of course, not all smartcard programs require three files. Some only use the code and internal eeprom areas. Ghostsilver is an example of this. The 16F876/877 processor had enough eeprom on-chip that there was no need for the external eeprom to be used. It makes sense for programmers not to use the external eeprom if they can avoid doing so: internal eeprom is faster and more secure. (Not that any smart card processors are any more.)
But besides writing all three hex files to the card using ICProg, it's also possible to get many wafers going by just writing the code hex file using ICProg and then loading up the others in Phoenix mode using FMCard or similar. This is possible because Irdeto 1 emulator programs such as ghostgold, ghostfun and ausgold support special commands (commands not part of Irdeto) to provide loading functionality. Where this has been done you'll usually find ".crd" files are supplied by the emulator author in addition to the hex files. The crd files (short for 'card' files) contain commands that send the equivalent hex data to the card, in a series of small pieces. Unlike the hex files, the crd files are written using Phoenix mode. Each command specifies the size of the data to be written, the target address and whether it's going to the internal or external area (the card's loader code has to do completely different things depending on where the data is headed). If you look at the crd files closely you'll see the commands contain data which matches the equivalent hex files for internal and external eeprom data, and that each crd command includes the address to which the data string is to be written.
As I mentioned, many cryptosystem emulators contain additional 'back door' commands for accessing memory. They can be used to initialise large slabs of data for card programming, or for targeted updates of specific data such as keys, provider id, serial number or even the ATR. Programs such as ggedit and LMEdit use those commands to read and update card keys. Note however that the access always require the address to be specified. The address depends on the particular emulator program and version. Occasionally emulator authors will take steps to preserve their memory layout between versions, but generally that's not the case. ggedit and LMEdit were written specifically for Ghost's 1.0 code and won't work with other emulators (they contain the addresses needed for GhostGold and for GhostSilver, GhostEmerald and GhostFun - the latter three using the same addresses, which is why you don't need to specify which of the three you're using).
AusGold is worth mentioning. It was another Irdeto 1 emulator, predating Ghost's work, for Silver wafers [sic]. What's interesting is that it was distributed as a single hex file (containing code and data) and that data sent through its backdoor loader commands was encrypted to discourage unskilled pirates from extracting its keys. That meant it didn't use CRD files. Instead it came with its own "Ausgold Card Writer" program which encrypted the user's keys and sent them to the card.
Old timers will know all of this, it's no secret. But I figure it's worth recounting for the benefit of newcomers, especially those who weren't around in the heyday of Irdeto 1.
gw1
informative post.
thankyou
Thanks gw1
an Excellent post,
hope you don't mind if I save a copy for future reference,
very much appreciated
Thankyou
For those who want to program a blank silver or gold you can use the silicon chip pic programmer .Left over from the cable days it has 2 headers just add a card slot to one and it works fine .
Bookmarks