atn@cory.Berkeley.EDU (Alan Nishioka) (05/11/91)
Due to the amount of interest regarding reading the new California
driver's license and bank cards in general, I am posting the
information I used in the process.
I bought a card reader mechanism at Mike Quinn's (Oakland Airport), a
local surplus store. Unfortunately, when I went back to get another,
they didn't have any.
It outputs a serial stream and a clock for each track. In September
of 1990, I posted to sci.electronics asking for information on how to
use this device and received the following articles.
Since I didn't build the reader itself, I can't be of much help there.
The sender of the first article seems to have built his own reader.
The second and the fourth articles give some basics on the format of
the magnetic stripes.
The third article was the most useful for the project. It recaps
ANSI X4.16 which is essentially the same as the official ANSI/ISO
7810-1985. I sent for the latter and they said I could have it for
$8 plus $2 S&H. I discovered that our engineering library has ANSI
standards of microfiche.
I connected it to my Amiga serial port using a shift register (74LS164),
a counter (74LS163), a NAND gate (74LS00) and a UART (AY-5-1013A), since
the data rate was too fast to just use one bit of the UART, and decoded
in software.
The programs are in C and are simply an interface to my hardware
arrangement and some bit shuffling and parity checking to output the
information in a readable form. I don't think they would be useful to
anyone, but if someone is interested I could send them.
For track 1 of the drivers license I wrote a program to break the raw
output into words of different length. Then I stared at them until I
saw a pattern. Organic DSP, no clock, but faster than anything
mankind has produced yet.
I'd like to thank again all of the people on the net who helped me with
this project (those with articles below and others).
-----------------------------------------------------------------------------
Alan Nishioka KC6KHV atn@cory.berkeley.edu ...!ucbvax!cory!atn
974 Tulare Avenue, Albany CA 94707-2540 37'52N/122'15W +1 415 526 1818
From wolff@duteca.tudelft.nl Wed Sep 26 04:35:37 1990
Received: from ara.Berkeley.EDU by cory.Berkeley.EDU (5.63/1.42)
id AA23892; Wed, 26 Sep 90 04:35:29 -0700
Received: by ara.Berkeley.EDU (5.57/Ultrix2.4-C)
id AA03314; Wed, 26 Sep 90 04:35:17 PDT
Received: by hercules.Berkeley.EDU (5.57/Ultrix2.4-C)
id AA11690; Wed, 26 Sep 90 04:35:11 PDT
Received: by mcsun.EU.net with SMTP; Wed, 26 Sep 90 13:35:09 +0200
Received: from duteca.tudelft.nl by hp4nl.nluug.nl with UUCP via EUnet
id AA18531 (5.58.1.14/2.14); Wed, 26 Sep 90 13:37:49 MET
Received: by dutrun.uucp (5.57/1.10)
id AA12888; Wed, 26 Sep 90 12:37:44 +0200 (MET)
Organisation: Delft University of Technology, Delft The Netherlands.
Received: by duteca.tudelft.nl (AIX 2.1.2/4.03)
id AA23550; Wed, 26 Sep 90 12:40:59 +0100
Date: Wed, 26 Sep 90 12:40:59 +0100
From: wolff@duteca.tudelft.nl (Rogier Wolff)
Message-Id: <9009261140.AA23550@duteca.tudelft.nl>
To: e142-aq@hercules.berkeley.edu
Subject: Re: Credit card encoding
Status: RO
I have been interested in this same area for some weeks a few months ago. I
used a very old cassete recorder head, with some "fischer technik" mechanics,
and the cassete recorder's amplifier. I also built the sampler for my amiga,
but forgot about the why I was building the sampler in the first place. Anyway,
If you recieve any reply's I might want to continue, and write decoding programs
for my amiga..... I'd appreciate a summary, preferrably by mail, as to not
being able to miss it.
Roger Wolff.
From mtxinu!isc-br.isc-br.com!isc-br!jimc@ucbvax.berkeley.edu Wed Sep 26 11:30:48 1990
Received: from ara.Berkeley.EDU by cory.Berkeley.EDU (5.63/1.42)
id AA02129; Wed, 26 Sep 90 11:30:25 -0700
Received: by ara.Berkeley.EDU (5.57/Ultrix2.4-C)
id AA00279; Wed, 26 Sep 90 11:30:12 PDT
Received: by hercules.Berkeley.EDU (5.57/Ultrix2.4-C)
id AA11841; Wed, 26 Sep 90 10:54:19 PDT
Received: from mtxinu.UUCP by ucbvax.Berkeley.EDU (5.63/1.42)
id AA14627; Wed, 26 Sep 90 10:34:41 -0700
Received: from uunet.uu.net by mtxinu.COM (5.61/1.29-mls890331)
id AA11343; Wed, 26 Sep 90 10:34:20 -0700
Received: from isc-br.isc-br.com by uunet.uu.net (5.61/1.14) with UUCP
id AA06121; Wed, 26 Sep 90 13:33:51 -0400
Date: Wed, 26 Sep 90 07:46:43 PDT
From: mtxinu!uunet.UU.NET!isc-br!jimc@ucbvax.berkeley.edu (Jim Cathey)
Message-Id: <9009261446.AA16500@isc-br.ISC-BR.COM>
To: e142-aq@hercules.berkeley.edu
Subject: Re: Credit card encoding
Newsgroups: sci.electronics
In-Reply-To: <28174@pasteur.Berkeley.EDU>
Organization: ISC-Bunker Ramo, An Olivetti Company
Status: RO
In article <28174@pasteur.Berkeley.EDU> you write:
>Does anybody know how information is encoded on the magnetic stripe for
>credit cards, bank cards, my student id, etc.? Any references? A trip
>to the library and looking thru the reader 's guide didn't get me anywhere.
There are three tracks on the card. Track 1 is 'high' density and uses a
6-bit ASCII with parity. It is used by the airlines, so I'm told.
Tracks 2 and 3 are ABA (American Banking Association) tracks, and are
the most commonly used ones. There is a spec for these. The number on
your credit card is usually coded onto track 2.
Track 2 is low density (30 or so characters) with a 4-bit plus parity format.
I presume the low density is more immune to magnetic and physical damage.
Track 3 is high density (100 or so) 4-bit with parity characters. This
track is the one usually used when the card system also desires to
write on the card.
>I discovered that cards seem to use two different levels of stripe, for
>a total of 4 tracks on my bank card, but only two on my student id, which
>are at the wrong level for my reader.
My info is only good for cards that conform to the banking standards. I
believe this is most of the credit card type cards. There are only 3 tracks.
>The code must be self-clocking and I would guess just have simple
>error checking (parity) since the card can just be run thru again if
>necessary.
It is, it does, and an LRC (checksum type character) is appended as well.
>BTW, I just want to read, not commit bank fraud :-) I would have to build
>another card input/output assembly for that :-)
Writing on the cards is much trickier (you need a rubber wheel with a
shaft encoder to know how fast the card is moving moment-to-moment to
get the flux change spacing right), and of little point. Most banking
applications only have the card number on there anyhow, and magnetic
systems usually need a PIN (gotten from the main computer) before
they'll go further.
Disclaimer: I've worked with these things (we make banking terminals), but
it has been some time and I'm working entirely from memory here.
--
+----------------+
! II CCCCCC ! Jim Cathey
! II SSSSCC ! ISC-Bunker Ramo
! II CC ! TAF-C8; Spokane, WA 99220
! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.isc-br.com)
! II CCCCCC ! (509) 927-5757
+----------------+
"With excitement like this, who is needing enemas?"
From jad@dayton.UUCP Thu Sep 27 20:42:52 1990
Article: 15755 of sci.electronics:
Path: pasteur!dog.ee.lbl.gov!ucsd!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!psuvax1!rutgers!dayton!jad
From: jad@dayton.UUCP (J. Deters)
Newsgroups: sci.electronics
Subject: Re: Credit card encoding
Message-ID: <7515@dayton.UUCP>
Date: 27 Sep 90 20:42:52 GMT
References: <28174@pasteur.Berkeley.EDU>
Reply-To: jad@dayton.UUCP (J. Deters)
Organization: Dayton-Hudson Department Stores Co.
Lines: 225
Status: RO
> Article <28174@pasteur.Berkeley.EDU> From: e142-aq@hercules.Berkeley.EDU
> (Alan Nishioka)
>Does anybody know how information is encoded on the magnetic stripe for
>credit cards, bank cards, my student id, etc.? Any references? A trip
>to the library and looking thru the reader 's guide didn't get me anywhere.
You'll want to see the American National Standard X4.16 (which I
just happen to have sitting in my lap.) It is available from the
American National Standards Institute, Inc.
1430 Broadway
New York, NY 10018
My version is dated 1983. I suspect it has been superceded by now.
It details everything (everything!) you ever could possibly want to
know about mag stripe encoding for financial services cards.
>I just bought a card reader which had 5 ttl level outputs. Two for each
>of 2 head tracks and a 5th that goes low when a card is being run thru.
>The chips don't seem to be identifiable.
In most all of the MSR's I've taken apart, the chips are custom.
One of our vendor's configurations for the wiring looked like this:
1 RDT1 Data from track 1
2 RCL1 Clock from track 1
3 GND
4 +5V
5 n/c
6 RCL2 Clock from track 2
7 CLD Card Presence
8 RDT2 Data from track 2
You could use a scope to determine which is which -- track 2 is recorded
at 75 bits/inch while track 1 is 210 bits/inch. Just watch the blinking!
The data is self clocking.
_____ __ __ _____ __
| |_____| |__| |__| |__| |_____
^ ^ ^ ^ ^ ^ ^
0 0 1 1 0 1 0
>I discovered that cards seem to use two different levels of stripe, for
>a total of 4 tracks on my bank card, but only two on my student id, which
>are at the wrong level for my reader.
Your bank card will typically only use the read-only tracks one and two.
Track 3 is a read/write track that has the same electromagnetic properties
as track 1, but its usage is not standardized within the industry. Many
cards issued today do not even have magnetic media at the location for
track 3. (It was originally intended for off-line ATM authorization,
but guess what happened to that idea!)
>The code must be self-clocking and I would guess just have simple
>error checking (parity) since the card can just be run thru again if
>necessary.
The parity checking is pretty impressive. Track 1 characters are 6
bits plus one (odd) parity bit. There is also an LRC (Longitudinal
Redundancy Check) character after the end sentinel character. The
LRC bits are parity bits for all the characters in the track such
that the total one bits are odd. (The LRC parity bit is simply a
parity check on the LRC character.) This scheme protects against
almost all random card damage, as you would have to have four bits
wrong (the corners of a rectangle, physically) to escape detection.
Track 2 parity detection is the same, but track 2 characters are
only 4 bits plus one (odd) parity bit.
The character sets are fairly simple subsets of ASCII. Tracks 1 & 3
use this table:
0 1 2 3
00 01 10 11 <-MSD
0 0000 SP 0 @a P
1 0001 !a 1 A Q
2 0010 "a 2 B R
3 0011 #b 3 C S
4 0100 $ 4 D T
5 0101 %c 5 E U
6 0110 &a 6 F V
7 0111 'a 7 G W
8 1000 ( 8 H X
9 1001 ) 9 I Y
A 1010 *a :a J Z
B 1011 +a ;a K [d
C 1100 ,a <a L \d
D 1101 - =a M ]d
E 1110 . >a N ^c
F 1111 / ?c O _d
a For the encoding of data on magnetic stripe cards, these
character positions shall not contain information characters
(data content).
b Optional additional graphic.
c These characters shall have the following meaning for this application:
25 % represents start sentinel.
3F ? represents end sentinel.
5E ^ represents separator.
d These character positions are reserved for additional national
characters when required. They shall not be used internationally.
Track 1 format:
Format A. Reserved for proprietary use of card issuer.
Format B.
Start sentinel 1 character
Format code = "B" 1 character - alpha only
Primary Account Number Up to 19 characters (Note 1)
Separator 1 character
Country code 3 characters (Note 2)
Name 2-26 characters (note 3)
Surname
Surname separator="/"
First name or initial
Space (when required) (Note 4)
Middle name or initial
Period (when followed by title)
Title (when used)
Separator 1 character
Expiration date or 4 characters or 1 character
separator (Note 5)
Discretionary data The balance to maximum record length
End sentinel 1 character
LRC 1 character (see above for LRC calculation)
Total 79 characters max.
Notes:
1 In accordance with the account numbering scheme in ANSI X4.13-1983.
2 When the primary account number commences with major industry
identifier "5" followed by "9", the encoding of the country
in this position is mandatory. In all other situations, the
expiration date or separator shall immediately follow the
separator that terminates the primary account number. The
country code for the United States is 840.
3 The absolute minimum data encoded in the name field will be
a single alpha character in the surname area and the surname
separator (/).
4 The space character is required to separate the logical elements
of the name field other than the surname. The separator terminating
the name field should be encoded following the last logical element
of the name field. If only the surname is encoded, it will follow
the surname separator.
5 In accordance with ANSI X3.30-1971. If no expiration date is
associated with the card, a separator shall be encoded. The
format for the expiration date is YYMM.
Format Codes C through M. The format codes are reserved for use by
ANSI Subcommittee X3B10 in connection with other data formats of track 1.
Format Codes N through Z. Available for use by individual card issuers.
Track 2 uses the following 4 bit character set:
0 0000 0
1 0001 1
2 0010 2
3 0011 3
4 0100 4
5 0101 5
6 0110 6
7 0111 7
8 1000 8
9 1001 9
A 1010 Note 1
B 1011 Start sentinel (start character)
C 1100 Note 2
D 1101 Separator
E 1110 Note 1
F 1111 End sentinel (stop character)
Notes:
1 These characters are available for hardware control purposes
and shall not be used for data content.
2 This character is reserved for future definition in connection
with the data format on track 2.
Track 2 format:
Start sentinel 1 character
Primary Account Number Up to 19 characters (Note 1)
Separator 1 character
Country code 3 characters (Note 2)
Expiration date or 4 characters or 1 character
separator (Note 3)
Discretionary data The balance to maximum record length
End sentinel 1 character
LRC 1 character (see above for LRC calculation)
Total 40 characters max.
Notes:
1 In accordance with the account numbering scheme in ANSI X4.13-1983.
2 When the primary account number commences with major industry
identifier "5" followed by "9", the encoding of the country
in this position is mandatory. In all other situations, the
expiration date or separator shall immediately follow the
separator that terminates the primary account number. The
country code for the United States is 840.
3 In accordance with ANSI X3.30-1971. If no expiration date is
associated with the card, a separator shall be encoded. The
format for the expiration date is YYMM.
>BTW, I just want to read, not commit bank fraud :-) I would have to build
>another card input/output assembly for that :-)
I've seen some scams based on ATM card fraud, but it may be tough to
fool Mother Visa...particularily when you have to hand your card to
a living, breathing human.
Do me a favor and mail me a copy of your interface circuit when you
get it working, OK?
-j, now you know all our little secrets, eh?
--
J. Deters Ask me about my PS/2. //
INTERNET: jad@dayton.DHDSC.MN.ORG Then, //
UUCP: ...!bungia!dayton!jad ask me about my Amiga! \\ //
ICBM: 44^58'36"N by 93^16'12"W \X/
From ropg@ooc.uva.nl Wed Sep 26 13:09:59 1990
Article: 15722 of sci.electronics:
Path: pasteur!ucbvax!ucsd!usc!cs.utexas.edu!uunet!mcsun!hp4nl!ooc.uva.nl!ropg
From: ropg@ooc.uva.nl (Rop Gonggrijp)
Newsgroups: sci.electronics
Subject: Re: Credit card encoding
Message-ID: <13619@slice.ooc.uva.nl>
Date: 26 Sep 90 13:09:59 GMT
References: <28174@pasteur.Berkeley.EDU>
Organization: uvabick
Lines: 28
Status: RO
e142-aq@hercules.Berkeley.EDU (Alan Nishioka) writes:
>Does anybody know how information is encoded on the magnetic stripe for
>credit cards, bank cards, my student id, etc.? Any references? A trip
>to the library and looking thru the reader 's guide didn't get me anywhere.
Well, there's three tracks (ISO 3554), all 0.110" wide. The top one is
210 BPI and has 7 bits per chr. (incl. parity). Total 79 alpha-num. chrs.
The second track has 75 BPI, 5 bits per chr. (incl. par.) total 40 digits
The third track has agian 210 BPI, 5 bits per chr (yeah incl. par.) total
107 digits.
Data is coded reversing the polarity of the magnetic field once or twice in
the field for that bit. Since you cannot double of half the speed of the card
within the space for 1 bit, it all works.
>I just bought a card reader which had 5 ttl level outputs. Two for each
>of 2 head tracks and a 5th that goes low when a card is being run thru.
>The chips don't seem to be identifiable.
Well, the bad news is that you'll have to write the decoding software yourself.
Not much to it, I did it on a Commodore-64. Our magazine ("Hack-Tic") printed
the full specs on all this in the last issue.
--
Rop Gonggrijp (ropg@ooc.uva.nl) is also editor of Hack-Tic (hack/phreak mag.)
quote: "We don't care about freedom of the mind, | Postbus 22953 (in DUTCH)
freedom of signature will do just fine" | 1100 DL AMSTERDAM
Any opinions in this posting are wasted on you | tel: +31 20 6001480