Smart Card Reverse Engineering Project ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ April, 2002 www.hcsw.org Some time ago, HardCore SoftWare acquired an American Magnetics 170 smart card device and an attempt at reverse engineering it was initiated. No real progress was made, however, until HCSW came into contact with a live smart card implementation. This document attempts to sum up our research into the fascinating field of smart cards. * Goals * Getting a 170 * Interfacing your 170 with a PC * Software * Tips on reversing a smart card implementation * Difficulties in writing * Other areas of research: We need your help! * References Goals ~~~~~ Smart card research is, for many people, a difficult area to get into. High prices and lack of information are the main obstacles to this interesting and rewarding field of experimentation. Many would-be hobbiests are turned away because of the credit card requirment for the purchasing of most equipment. A case could be made by citing free market ideologies and claiming that anyone who really wants a smart card reader will be able to get the money and means of purchasing one, but we at HardCore SoftWare feel this is absolutely unfounded. We believe this attitude is just another corporate strong-arm tactic with greater implications than are immediatley obvious. We believe that this is just another instance of corporations attempting to intellectually neuter the population so that they can maintain a technically elite upper class. We believe this is inexcusable, and must be fought every step of the way. Since it is looking increasingly likely that smart cards will become commonplace in North America, we feel that public participation and experimentation in this field are essential in order to keep large companies and possibly even our own government from abusing this flexible and powerful technology. Accordingly, this document attempts to give you a brief introduction to smart cards, and start your experimenting off by guiding you through the construction of a smart card-PC interface that should end up costing you virtually nothing. Getting a 170 ~~~~~~~~~~~~~ In 2000, an anonymous article [1] was posted to Hackcanada that suggested a cheap, easy, and effective method of obtaining 170s: Ripping them out of the new, obiquitous millenium payphones. The information in the article is for the most part accurate and should be consulted, but I found that attacking the yellow metal from all sides, continually weakening it's attachments, was a more effective and less risky method than the brute-force-and-ignorance (BF&I) method suggested in the article. The 170's seem to have been custom designed for nortel, as the American Magnetics website (www.magstripe.com) doesn't even mention them, and very little information is known about these readers. As such, you may have difficulty obtaining a 170 through legal channels. Should you entertain the common, if unfounded, idea that theft from your telco is immoral, you may have no choice but to ingest some malt liquor beforehand in order to sufficiently lower your fear of getting caught and to reduce your inhibitions. I suggest no more than one 40 isle: You ought to have your wits about you. Interfacing your 170 with a PC ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A crucial breakthrough in our understanding of the 170's pinouts was posted by skarface in [2]. It seems skarface had access to a 170 datasheet long enough to take a screenshot of the pinouts. Fortunatley, this now provides us with more than enough information to interface the smart card component with a PC, and possibly the magstripe too, although this has yet to be researched in depth. Here are the pinouts, thanks again to skarface: .-----.-------------------------. | pin | function | `-----'-------------------------' | 1 | IC CARD C7 (DATA) | | 2 | IC CARD C5 (GND) | | 3 | CARD SEATED SENSOR | | 4 | MAG READER VCC1 | | 5 | IC CARD C1 (POWER) | | 6 | CARD PRESENT SENSOR | | 7 | IC CARD C6 (PROG POWER) | | 8 | IC CARD C2 (RESET) | | 9 | MAG STROBE | | 10 | IC CARD C4 (NOT USED) | | 11 | MAG DATA | | 12 | IC CARD C8 (NOT USED) | | 13 | CIRCUIT GROUND | | 14 | IC CARD C3 (CLOCK) | `-----'-------------------------' NOTE: The RED wire on the ribbon cable of your 170 is considered pin #14. If, for whatever reason, your ribbon cable doesn't have a red pin (or you don't have a ribbon cable at all), pin #14 is the pin closest to the FRONT of the reader (where you insert your card). Reading Luis Padilla Visdomine's article [3], we learn that parallel ports and smart cards use roughly the same electrical levels, and as such can be almost directly connected. Unfortunatley, for most chip cards to work, we need to have a clocking mechanism, which the parallel port doesn't intrinsically provide. We can solve this in the software. We decide that this isn't a signifigant problem, and decide to use the parallel port. We also choose to use Visdomine's pin scheme so as to avoid any confusion. Consulting the ISO7816 standard [4], we find the pinouts of the chip card: 2.2.3) Pin Assignement: C1 : Vcc = 5V C5 : Gnd --------------- C2 : Reset C6 : Vpp C3 : Clock C7 : I/O C4 : RFU C8 : RFU Without getting too heavily into the theory, here's the procedure: 1) Get a bidirectional parallel cable (printer cable) that you don't mind cutting up (Incidentally, you can use any cable that has a DB-25 connector; we used a serial cable). Odds are, you already have at least one lying around in your house. If not, go down to your local used computer shop and you should be able to pick one up for a buck or less. Or you could steal it from Futureshop. Heh. 2) Find some way to make sure you know which pin on the connector goes to which wire. HCSW, like fools, cut the parallel cable in half and had to use an ohmmeter to test each single pin on the cable. This, as you can imagine, was tedious and unrewarding. Ideally, getting a female interface would be the best plan, but you might have to spend money on it, which defeats the whole purpose of this. Actually, if you can find a dead printer, rip the female DB-25 out of there. Check every connection that you make in this way with a ohmmeter, as many parallel cables don't correspond pinwise on either end of the cable (for example, Laplink cables). TIP: Ensure that none of the wires on either the parallel port or the 170 are crossed, as this can easily screw up your voltmeter testing. 3) Connect these pins on the parallel cable to these pins on the 170: Hopefully these badly drawn ASCII diargrams will help you: -------------------- 1 ----RED WIRE---------- \ 1 . . . . . 13 / 2 ---------------------- \ 14 . . . . 25 / . . . --------------- 14 ---------------------- Parallel Cable 170 -------------- --- 4........14 7........12 (OPTIONAL) 5........10 (OPTIONAL) 3.........8 6.........7 2.........5 25.........2 (*) 15.........1 (**) (*) Actually, any one of the numerous ground pins of the parallel port can be used. 25 seems like a good, out of the way one, though. (**) Double check that this connection actually goes through. This would be the most common pin for a parallel cable not to support. Software ~~~~~~~~ Luis Padilla Visdomine has written two BASIC programs [5,6] specifically designed to read european phonecards. Unfortunatley, I found his code difficult to understand, and even more difficult to extend and adapt. These BASIC programs DO work, however, and I suggest you check them out if you have an old tandy laptop or you run windows. Here is a program by HCSW, written in C for the Linux platform. It should be able to be ported to any x86 unix distribution that uses gcc. I imagine a DOS port would also be possible. NOTE: You must be root to run this program. This program is fairly specific towards the laundry cards that we were analyzing, but the code is very modular, and you shouldn't have much difficulty extending it for your own application. This program is covered under the General Public License (GPL). See the file LICENSE included with the program for details. We encourage you to adapt and extend this program. However, by the terms of the GPL, you must make this adapted code public. So, without any further ado, here's the tarball: http://www.hcsw.org/card/smart-1.0.tgz The programmer's interface is relatively straightforward, and you should be able to figure it out by reading the main() function. First off, you must must call the paropen() function, which will return 1 if you have appropriate privileges, and 0 if not. Please preform error checking on this call, otherwise your program will almost certainly segfault. Next, you must call open_sc(). This function will reset the card and prepare it for reading. After the card has been opened in this fashion, you are free to use the lower level I/O routines paraddrinc(), parsend(), and parget(), but be warned, parget() only returns 1 useful bit of information. Preform bitwise AND with parget() and 8, and if the result is positive, the bit is a 1, otherwise it's a 0. Luckily, we've provided a higher level routine, dump_sc(), which takes 2 arguments: an array of integers, and the maximum amount of bytes to read. Ideally, we ought to use unsigned chars instead of ints for this, as only 1 byte of information is stored in each int. Live with it, or change it yourself. So, each int will contain a value between 0 and 255. If the card isn't inserted properly, or the connection is bad, all ints will be 255. There is also a function, amount_on_sc(), which takes an array of integers dumped with dump_sc(), and tells you the amount of credit remaining on our card system (See next section). This is application dependant, and probably won't apply to your smart cards at all. Don't forget, when compiling programs that use outb() and inb() on linux, you must compile using either the -O or the -O2 switch in gcc (The Makefile takes care of this for you in our program). Tips on reversing a smart card implementation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We will take HCSW's experience with smart cards as an example here. We analyzed the CardMate laundry card system using the device and software described above. Naturally, we were all interested in the credit system, so that's what we pursued first. We were all stumped until one morning an HCSW member who wishes to remain anonymous excitedly came up to me and said he'd cracked it wide open. It looks like CardMate had tried some simple obfuscation techniques in order to hide the location of the credit. It was some excellent reverse engineering done by the anonymous member, and I was most impressed. Here's an abstraction from one of our memos: Bytes 52-54 seem to be the location where the credit is stored. Many dumps yield this: Both $4.00 cards: 00 3E 80 003E80 in decimal is 16000 in decimal. 16000 / 4000 = 4.00 A $5.00 card: 00 4E 20 004E20 in decimal is 20000 in decimal. 20000 / 4000 = 5.00 A $6.00 card: 00 5D C0 005DC0 in decimal is 24000 in decimal. 24000 / 4000 = 6.00 A $0.00 card: 00 00 00 00000000 in decimal is 0 in decimal. 0 / 4000 = 0.00 A $0.10 card: 00 01 90 00000190 in decimal is 400 in decimal. 400 / 4000 = 0.10 Since the cards use 3 bytes to store the credit and 4000 seems to be equivalent to $1, we can perform this calculation to find out the maxiumum amount of money a card can hold: FFFFFF in decimal is 16777215. 16777215/4000 = 4194.30375. Therefore, the largest amount possible would be $4194.30, which would be represented on the card by FF FF F0. We dug up a few other pieces of info on the cards. Interestingly enough, there were differences between the newer white cards and the older black cards. Here's another memo: -The first 2 bytes are always 39 and FF. This is probably an identifying header. -Byte 51 seems to be FA on the new, white cards after they've been initialized, but 7D on the older, black cards. Uninitialized cards have 00 at byte 51. -White cards hold exactly 200 bytes of readable storage, where black cards hold 128. All dumps from now on will take this into consideration. Exploring this was a very interesting experience. Had we known what we know now, we would have started off quite a bit differently though. Here are some tips that will hopefully help you in your reverse engineering: * BE ORGANIZED! I can't stress this enough. Label all your dumps well, and keep them catagorized and ordered. Also, mark your cards in some fashion so you don't get THEM confused. * Find out just how much data the cards actually hold early on. With our program, if you read past the end of the card, it will start repeating the stream of data again, so look for repetition of the first few bytes, then only dump that much data in all subsequent dumps. * Analyze the differences in various states of the card. For instance, if you're trying to find out where the credit is stored on the card, dump a card when it's empty, dump the same card with $1, with 2$, with 3$, etc. Then dump it after having spent money. Also, try to get dumps of different cards too. The more data, the better. * If you're analyzing several K of data, you might want to write up a little program that will look for consistent fluctuations in the data. * If you write any programs for your smart card experimentation (in fact, any programs at all) PLAN AHEAD. Make it modular and conceptual so that it will be easy to extend and fix. Difficulties in writing ~~~~~~~~~~~~~~~~~~~~~~~ Forunatley for us, laundry fraud was easy to commit despite the high tech credit system by exploiting a trivial mechanical flaw, so writing to a card wasn't always our top priority. We HAVE been looking into it, and it's now our main goal. Unfortunatley, there is very little information on writing to smart cards that we can find. We do have a few ideas about how to get this information though: See the next section. Other areas of research: We need your help! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * We're always interested in hearing about your success or failures in getting this method to work. Don't hesitate to contact us if you have any questions or comments. * We'd love to hear about other various smart card systems that you've figured out. * We're currently toying with the idea of building a sort of reverse smart card that we can stick into the actual laundry machines so that we can measure the actual electrical levels and signals used to deduct money from the card. The crediting process should be similar, but we don't have access to the machine that adds money on the cards, unfortunatley. Unfortunatley, the parallel port doesn't have enough inputs to measure all the pins at once, so some fanciness might be involved. Obviously some data recording software would have to be written too. * We'd also like to start messing around with the magstripe capabilities of the 170. If you have any info/stories on this, we'd love to hear from you. Contacts ~~~~~~~~ Come visit us at http://www.hcsw.org or E-Mail me, Fractal, at doug@bearcountry.cjb.net You can talk to my idle client as Fractal on irc.hcsw.org, EFNet, irc.h410g3n.com, irc.openprojects.net One other HCSW member. Bright guy. If he comes on IRC, I'll point him out. References ~~~~~~~~~~ [1] - Assaulting Payfones - Anonymous http://www.hackcanada.com/canadian/payphones/payfone_assault.html [2] - AMC 170 Pinout - Skarface http://www.lineman.bell-system.com/texts/amc170_pinout/ [3] - PC-smart card connection - Luis Padilla Visdomine http://www.gae.ucm.es/~padilla/extrawork/pcsmart.html [4] - ISO7816 asynchronous smartcard information - Stephane Bausson http://www.hackcanada.com/ice3/card/iso7816.txt [5] - Program to read/write 1st generation phone cards - Luis Padilla Visdomine http://www.gae.ucm.es/~padilla/extrawork/1smart.bas [6] - Program to read/write 2nd generation phone cards - Luis Padilla Visdomine http://www.gae.ucm.es/~padilla/extrawork/2smart.bas