Decoding magnetic cards

Path: ux1.cso.uiuc.edu!uwm.edu!wupost!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!agate!dog.ee.lbl.gov!network.ucsd.edu!ucsd.edu!brian
From: [email protected] (Brian Kantor)
Newsgroups: sci.electronics
Subject: Re: Encoding Scheme of Mag Stripe Cards?
Message-ID: 
Date: 10 Jan 92 20:58:00 GMT
References: <[email protected]>
Organization: The Avant-Garde of the Now, Ltd.
Lines: 373
NNTP-Posting-Host: ucsd.edu


Path: ucsd!usc!cs.utexas.edu!uunet!mcsun!hp4nl!ooc.uva.nl!ropg
~From: [email protected] (Rop Gonggrijp)
~Newsgroups: sci.electronics
~Subject: Re: Credit card encoding
Message-ID: <[email protected]>
~Date: 26 Sep 90 13:09:59 GMT
~References: <[email protected]>
Organization: uvabick
~Lines: 28

[email protected] (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 ([email protected]) 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


From ucsd!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!psuvax1!rutgers!dayton!jad Fri Sep 28 04:18:32 PDT 1990

> Article <[email protected]> From: [email protected]
> (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	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:  [email protected]   Then,                       //
UUCP:  ...!bungia!dayton!jad         ask me about my Amiga!  \\ //
ICBM:  44^58'36"N by 93^16'12"W                               \X/


From ucsd!dog.ee.lbl.gov!pasteur!cory.Berkeley.EDU!atn Wed May  8 07:41:21 PDT 1991


Just got my new California driver's license.  No, I'm not 17, but I take the
bus a lot.

It has a holographic plastic laminate of "DMV" and the California Seal.

My color picture was digitized into and IBM computer as was my thumb print
and my signature.  The mag stripe on the back has three tracks.

Just for fun, I thought I'd try to read it.  I had previously been able
to read bank cards (with help from sci.electronics).  I found that the
information encoded is basically just what is printed on the card.  Kinda
uninteresting.  Of course I couldn't figure out what little extra information
was encoded.... (marked unidentified below)

It took me a little while to figure out the format, and I suppose it is
documented somewhere (anyone know where?) but it was fun.

Bank Cards -- conform to ANSI/ISO 7810-1985 ($10)
Track 1:    6 bit word with 1 bit parity.  LSB first.
            code offset 32 below ASCII code.
Track 2:    4 bit word with 1 bit parity.  LSB first.  Numbers only.

Driver's License --
Track 1:    6 bit word with no parity.  Otherwise same as Bank Card.
Track 2:    Same as Bank Card.

California Driver's License:
---------------------------
Track 2:    (low density)
    8 unidentified digits
    License Number
    Separator
    Expiration Date (YYMM)
    Separator
    Date of Birth (YYYYMMDD)

Track 1:    (High density)
DALAN TAKEO NISHIOKA                                       $
974 TULARE AVE               ALBANY       
    Name (58 characters)
    Address (29 characters)
    City (13 characters)

Track 3:    (High density.  Can't reposition read head. );

Great Western Bank ATM Card:
---------------------------
Track 2:
    Account number on the front of the card
    Separator
    Expiration date (no country code)
    Other (propietary) data

Track 1:
    Format B
    Account number
    Separator
    Name (from front of card)
    Separator
    Expiration date (no country code)
    Other data

AT&T Universal Card:
-------------------
Track 1:
    Format B
    Account Number
    Separator
    Name
    Separator
    Expiration Date (YYMM)
    6 Unknown chars
    Calling Card Number (10 digits)

Track 2:
    Account Number
    Separator
    Expiration Date (YYMM)
    3 Unknown chars

Citibank ATM Card:
-----------------
Track 1:
    Format A (proprietary)
    Name
    Separator
    Account Number
    Separator
    Expiration Date (MMYY)
    7 Unidentified chars 

Track 2:
    Account Number
    Separator
    Expiration Date (MMYY)
    7 Unidentified chars

-----------------------------------------------------------------------------
Alan Nishioka      KC6KHV      [email protected]      ...!ucbvax!cory!atn
974 Tulare Avenue, Albany CA 94707-2540     37'52N/122'15W    +1 415 526 1818

Newsgroups: sci.electronics
From: [email protected] (Ala-M{yry Pekka,,,OHJ,52774,1052)
Subject: Re: Magnetic Stripe Cards
Originator: [email protected]
Nntp-Posting-Host: kaarne.cs.tut.fi
Reply-To: [email protected]
Organization: Tampere University of Technology, Dep. of Computer Science
Date: Sat, 14 May 1994 22:42:32 GMT

From article , by [email protected] (Lance Ware):
> A while back I saw some info on mag stripe cards here. Can anyone point
> me to it? I am interested in how much data the various (Credit, Hotel
> Room, etc . . .)stripes can hold.
>
> Lance Ware
> IS Manager & VOXEL Guru
> VOXEL

 I have a copy of a German version (EN 27 811) of a standard ISO 7811-2
 and German version of standard ISO 4909. And English version of ISO 7830.
 The quotes of the original are in parenthesis. I'm not very good at German
 so please correct if I am wrong.


 EN 27 811 (ISO 7811-2)

 The data density (Bit-Dichte) at three of the tracks:
 Alphanumeric track (Alphanumerische Spur 1): 8,3bits/mm [210 bits/inch]
 Numeric track (Numerische Spur 2): 3bits/mm [75 bits/inch]
 Read-Write track (Schreib-Lesespur 3): 8,3bits/mm [210 bits/inch]

 Format of track 1 data: 6 bits of data with odd parity
 (6-Bit-Zeichencode mit ungerader Paritat)

 Format of tracks 2 and 3: BCD-4 bit code with odd parity
 (BCD-4-Bit-Code mit ungerader Paritat)


 ISO 7830

 Track 1 - Structure B: 79 characters
 Track 2 - Standard structure: 40 digits


 ISO 4909

 Track 3 - Max. 107 characters (Maximal Gesamt 107)

--
[email protected]
Pekka Ala-Mayry         Tampere Univ. of Tech.   Tampere, FINLAND


Summary of replies to the following request:

Subject: Mag Card Swipe Reader: Need Help!

Hello, Everybody.

I just picked up one of those swipe readers for mag stripes on credit
cards etc. from a surplus outfit (American Science & Surplus in
Evanston, IL  708/475-8440 for those who are interested). It's not the
complete unit with keypad, display, etc. but rather just the guts of the
subassembly which actually reads the card (hey, what do you expect for
$2.50?? ;-) Since it's surplus and taken out of a larger piece of
equipment, I have no docs for this sucker. My hope is that someone else
picked up one of these things to play with and has some docs or has figured
out enough about it to get it to work, OR can tell me who to contact to get
more info on this beast. I figured this would be a good place to ask
since I've seen people asking about swipe card readers recently.

Anyway, here's a description:
The unit is about 6" long, 1" wide, and maybe 2" high. It consists of a
metal backing plate, attached to which is a black plastic guide channel
through which you swipe the card. On one side of the plastic channel is a
read head for the mag stripe; on the opposite side is a small printed circuit
board.

Removing the plastic guide from the mounting plate reveals that the
manufacturer is SR&D corporation of Tokyo, Japan. The model number is
MCR-175-1R-0803; a serial number is also listed. The SR&D logo-lettering
appears on the component side of the PC board, and on the foil side of
the board the SR&D is repeated along with the code "FNC -065-1" in the
upper right hand corner. The board has one IC on it (I can't easily see
what the numbers are on this chip, so I'm not sure what kind it is other
than a 16 pin DIP). There is a spot for another chip, an 8-pin DIP for
which the screened label reads "IC2 6914", but this chip and some other
resistors, capacitors, etc. are missing.

Finally, there are 5 wires coming from the assembly and terminating in a
small connector similar to power supply connectors for 3.5" floppy drives.
The wires are red, yellow, green, blue, and black.

I haven't hacked on this thing at all yet, since I don't know what its
power requirements are or even which are power leads and which are data
leads. If anyone has any information on this puppy which might help me,
I'd love to hear from you! Please email me. I'll share whatever I find
out with anyone who's interested.

Thanks!

---

[Editor's Note: The following is a concatenation of the replies I received
to the net.request above. After the replies I have included information
which was posted to the net on how mag stripe cards are encoded (in case
anyone missed it). Finally, I have included some software that I threw
together to play with the card reader. This file contains all the information
I have on this subject. Additions are most welcome.

You'll notice I didn't get any farther than simply reading the raw signal
from the card; of the two card readers I ordered, one was completely DOA,
and the other had a faulty clock output (at least I assume that it was a
clock output; I was never able to read any sort of signal from that line).
Someone with a fully functional reader can easily extend what I wrote to get
it to decode the actual data content of the card. If you do decide to make
modifications and/or extensions, I'd appreciate a copy of whatever
changes you make (email to [email protected]).  Enjoy!]


Subject: Re: Mag Card Swipe Reader: Need Help!

I am truly amazed that someone else is trying to use this device!  I got
mine about 2 years ago and spent some time trying to find the manufacturer.
I found a listing for SR&D in the Noth America technical directory at 
the public library.  I found the listing for the American sales office
in Los Angeles.  I tried calling but the company had gone out of 
business.  There was no listing in the local phone directory either.
I then tried calling the head office in Japan, but they also had
gone out of business.  I haven't seen the company listed in any recent
electronics directories, so I think they really are gone.

I have spent about an hour looking at the signals on the outputs
of the device.  One signal line is a /STATUS line which indicates
when a card is been moved through the unit.  The other 2 lines
pulse in response to a magnetic card.  I believe the IC performs
Manchester decoding and clock recovery for the read channel, so one
output line is DATA and the other is CLOCK.  

That is as far as I got 2 years ago and I had forgot about it until
now.  If you receive any other info, please send a copy to me!

---

>Finally, there are 5 wires coming from the assembly and terminating in a
>small connector similar to power supply connectors for 3.5" floppy drives.
>The wires are red, yellow, green, blue, and black.

If its anything like the units I worked with, I think you  will find
that the five wires are:

        +5v
	Gnd
	Clock
	Data
	Card detected

But I don't know active levels, or which wire is what.

---

I picked few week ago a magnetic credit card reader from a 
another surplus outfit. It cost about the sam es yours. 
My card reader was made by MAGTEK and was diffrent from
your reder in many ways. The reader I have has 4 ICs and
some of them are standard TTL chip, so I could easily 
quess the power requiments (5V) and power connectors.
My card reader had 6 pin connector. 
I put the power to the reader and started to examine 
the signals with multimeter and a little crystal
earphine (my favourite electronics hacking tool).
I found that output signals were something like
that: data out, data clock out, data readable and
and card ath the end of the reader.
Then I connected the reader to the joystick port
of my 386SX and made a little Turbo Pascal program
for reading the card.

Spare printer port is the interface I use very often to connect
diffrent hardware circuit to my computer. This time I decided
to use game port beacuse it can also provide the power to the
reader.

My program simply prints out the bits from the card. I have not
found the way to decode the bits to corresponding numbers. The
program so prints all 237 bits form the card to screen.
If you have any information about data coding, I an interrested
in hearing that.

Here is the meanings of the bytes in port $201:
D7: 0 -> card pushed to the end of the reader
D6: the read data from card
D5: 0 -> data stream readable
D4: the data clock

Program CardReader;
 
Uses Crt,Binary;
 
Const
   gameport=$201;
 
 
Procedure Wait_start;
Begin
   Repeat Until (Port[gameport] and 32)=0;
End;
 
Function data_readable:boolean;
Begin
   data_readable:=((Port[gameport] and 32)=0);
End;
 
Procedure Wait_clock;
Begin
   Repeat Until (Port[gameport] and 16)=0;
End;
 
Procedure Wait_clock_end;
Begin
   Repeat Until (Port[gameport] and 16)=16;
End;
 
Function data_input:byte;
Begin
   If (Port[gameport] and 64)=0 Then data_input:=0
      Else data_input:=1;
End;
 
Function card_at_end:boolean;
Begin
   card_at_end:=((Port[gameport] and 128)=0);
End;
 
Procedure test;
Begin
   Wait_start;
   Repeat
      Writeln(ByteBin(Port[$201]));
   Until keypressed;
End;
 
Begin
   ClrScr;
   Wait_start;
   While data_readable Do Begin
      Wait_clock;
      Write(data_input);
      Wait_clock_end;
   End;
   Repeat Until KeyPressed;
End.

---

Wiring color code for the SR&D MCR-175-1R-0803 mag stripe card reader:

   Red:         +5V
 Black:         Gnd
Yellow:         /Card Detect
 Green:         Clock (?? - non-functional on the unit I have)
  Blue:         /Data


The leading '/' indicates an active low TTL signal.


---

           Quick 'n Dirty guide to the enclosed reader software
           ----------------------------------------------------

Hooking the SR&D MCR-175-1R-0803 card reader to your PC:

The included software is written specifically for the following
configuration; if your wiring is different, you'll need to make
corresponding changes to the software. Note also that the port
address is hard-coded to look for LPT2's status port (at address
0x279). If you're using a different port address, be sure to change the
port address value.

SR&D Wire       Printer Port Pin        Port Bit        Signal
---------       ----------------        --------        ------
Yellow          11                      7               /CARD DETECT
Blue            10                      6               /DATA
Black           18                      N/A             (Ground)

Power to the reader was provided by a separate power supply, basically
one of those black plastic DC power packs fed through a 7805 regulator
chip.


Compiling the software:

Compile SWIPE.C (using SMALL memory model), assemble SWIPEISR.ASM, and
link the two together.


Using the software:

To use SWIPE.EXE, simply hook the reader up to your LPT2: port, power it
up, then run SWIPE. When you're ready, press the ENTER key, and swipe a
card through the reader. The program will read the data from the card and
store it in a buffer (but will not decode the data; that is left as an
excercise ;-). After the card has been read, press ENTER again and the
contents of the buffer will be dumped to stdout. To save the card data to
a file, simply redirect SWIPE's output on the command line, e.g.

SWIPE > citibank.out

Please let me know of any changes, bug fixes, or improvements you make to
this code. Send email to [email protected].

Thanks, and have fun!

--- CUT HERE ---

/*
 * S W I P E . C
 *
 * Written:
 *     1/11/92
 *
 * Description: Quick 'n Dirty reader program for SR&D mag stripe card reader.
 *     Reads data from the input port as long as a card is detected in the
 *     card slot. After sampling, the data is dumped to stdout, and may
 *     be redirected to a file if desired.
 *
 * Note: Written for Borland C++ 3.0 - may require changes to compile under
 *     MSC or others. Compile in SMALL model.
 *
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

/* timer chip programming register port addresses */
#define COMMAND_REG 0x43
#define CHANNEL0 0x40

/* size of sample buffer */
#define MAXSAMPLE 4096

typedef unsigned char byte;


/* global variables */
byte *databuf;  /* buffer for the sampled data */

/* interprocess communication data */
byte *bufp;         /* data buffer pointer */
unsigned nsamp;     /* number of samples to be made */
unsigned port;      /* input port address */
int enab=0;         /* flag to enable/disable sampling */
int start=0;        /* flag indicating that sampling has begun */

/* ISR prototype */
extern void interrupt shand(void);



void program_timer(int channel, unsigned count)
/*
 * P R O G R A M _ T I M E R
 *
 * Description: Programs the given count value into the specified channel of
 *     the IBM 825x timer chip. Channel 0 is the time-of-day-clock interrupt;
 *     channel 2 is the speaker pulser.
 *
 * Parameter:
 *     channel (in) - Channel to be programmed.
 *     count (in) - Count value with which to program timer chip.
 *
 */
{

    outportb(COMMAND_REG, 0x36);  /* set up for reprogramming */
    outportb(CHANNEL0 + channel, count & 0xff);  /* lo byte first */
    outportb(CHANNEL0 + channel, count >> 8);  /* then hi byte */
}

void sample_data(int count)
/*
 * S A M P L E _ D A T A
 *
 * Description: Sets up for data collection from the printer port using
 *     the SHAND interrupt service routine (see SWIPEISR.ASM). This routine
 *     reprograms the timer chip for the desired sampling rate, sets up
 *     the interprocess communication area, and starts the sampling process.
 *     The actual sampling is done in the SHAND procedure. This routine
 *     waits until sampling has been completed before returning.
 *
 */
{
void interrupt (*oldhand)(void);  /* pointer to old interrupt vector */

    /* save old interrupt vector */
    oldhand = getvect(0x1c);

    /* clear enable flag */
    enab = 0;
    start = 0;

    /* install new vector */
    setvect(0x1c, shand);

    /* set up interprocess communications area */
    nsamp = 0;
    bufp = databuf;
    port = 0x279;  /* address of printer status register */

    cprintf("Sampling at %fHz (= %fms)....",
       1193180.0 / (float)count, (float)count / 1193.18);

    /* reprogram timer chip */
    program_timer(0, count);

    /* enable sampling */
    enab = 1;

    /* wait until sampling is completed */
    while (enab) ;

    /* restore standard timing value */
    program_timer(0, 0);

    /* reinstall old handler vector */
    setvect(0x1c, oldhand);

    cprintf(" completed.\r\n");

}


void main()
{
unsigned i;

    /* allocate memory */
    databuf = calloc(MAXSAMPLE, sizeof(byte));
    assert (databuf != NULL);

    cprintf("Press  when ready to swipe card:");
    getchar();
    sample_data(12);  /* This works out to about a 100kHz sampling rate  */

    cprintf("Sampling completed, %u samples total.\r\n", nsamp);
    cprintf("Press  to dump data.\r\n\r\n");
    getchar();

    /* dump data to stdout */
    for (i=0; i); Sat, 18 Jan 1992 19:44:44 -0600
Received: from spica.bu.edu by mrcnext.cso.uiuc.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
	id AA02279; Sat, 18 Jan 92 19:42:18 CST
Received: by spica.bu.edu (5.61+++/Spike-2.1)
	id AA12820; Sat, 18 Jan 92 20:43:39 -0500
Date: Sat, 18 Jan 92 20:43:39 -0500
From: [email protected] (Bobby Newmark)
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: Encoding Scheme of Mag Stripe Cards?


*******************************************************************************
*                                                                             *
*              Card-O-Rama: Magnetic Stripe Technology and Beyond             *
*                                                                             *
*                                  or                                         *
*                                                                             *
*                  "A Day in the Life of a Flux Reversal"                     *
*                                                                             *
*                                                                             *
*                                                                             *
*                     by: ..oooOO Count Zero OOooo.. .RDT.       11/22/91     *
*                                                                             *
*******************************************************************************
 
---A production of :    -=Restricted -=Data -=Transmissions    :
                   :                                           :
                   : "Truth is cheap, but information costs."  :
                    
   Look in your wallet.  Chances are you own at least 3 cards that have 
magnetic stripes on the back.  ATM cards, credit cards, calling cards, 
frequent flyer cards, ID cards, passcards,...cards, cards, cards!  And chances
are you have NO idea what information is on those stripes or how they are
encoded.  This detailed document will enlighten you and hopefully spark your 
interest in this fascinating field.  None of this info is 'illegal'...but
MANY organizations (government, credit card companies, security firms,
etc.) would rather keep you in the dark.  Also, many people will IMMEDIATELY 
assume that you are a CRIMINAL if you merely "mention" that you are
"interested in how magnetic stripe cards work."  Watch yourself, ok?  Just 
remember that there's nothing wrong with wanting to know how things work, altho
in our present society, you may be labelled a "deviant" (or worse, a 
"hacker!").
    
   Anyway, I will explain in detail how magstripes are encoded and give
several examples of the data found on some common cards.  I will also cover the
technical theory behind magnetic encoding, and discuss magnetic encoding
alternatives to magstripes (Wiegand, barium ferrite).  Non-magnetic card
technology (bar code, infrared, etc.) will be described.  Finally, there will
be an end discussion on security systems and the ramifications of emergent
"smartcard" and biometric technologies.
   
                           *DISCLAIMER*

   Use this info to EXPLORE, not to EXPLOIT.  This text is presented for
informational purposes only, and I cannot be held responsible for anything you
do or any consequences thereof.  I do not condone fraud, larceny, or any other
criminal activities. 

                           *A WARNING*

   I've noticed lately a few "books" and "magazines" for sale that were
FILLED with PHILES on a variety of computer topics.  These philes were
originally released into the Net with the intention of distributing them for
FREE.  HOWEVER, these philes are now being PACKAGED and sold FOR PROFIT.  This
really pisses me off.  I am writing this to be SHARED for FREE, and I ask no
payment.  Feel free to reprint this in hardcopy format and sell it if you must,
but NO PROFITS must be made.  Not a fucking DIME!  If ANYONE reprints this
phile and tries to sell it FOR A PROFIT, I will hunt you down and make your
life miserable.  How?  Use your imagination.  The reality will be worse.  


                           






             **  MAGSTRIPE FIELDS, HEADS, ENCODING/READING **


   Whew!  I'll get down to business now.  First, I am going to explain the
basics behind fields, heads, encoding and reading.  Try and absorb the THEORY
behind encoding/reading.  This will help you greatly if you ever decide to 
build your own encoder/reader from scratch (more on that later). 
FERROMAGNETIC materials are substances that retain magnetism after an external
magnetizing field is removed.  This principle is the basis of ALL magnetic
recording and playback.  Magnetic POLES always occur in pairs within magnetized
material, and MAGNETIC FLUX lines emerge from the NORTH pole and
terminate at the SOUTH.  The elemental parts of MAGSTRIPES are ferromagnetic
particles about 20 millionths of an inch long, each of which acts like a tiny
bar magnet.  These particles are rigidly held together by a resin binder. 
The magnetic particles are made by companies which make coloring pigments
for the paint industry, and are usually called pigments.  When making the
magstripe media, the elemental magnetic particles are aligned with their
North-South axes parallel to the magnetic stripe by means of an external
magnetic fields while the binder hardens.

   These particles are actually permanent bar magnets with TWO STABLE
POLARITIES.  If a magnetic particle is placed in a strong external magnetic
field of the opposite polarity, it will FLIP its own polarity (North becomes
South, South becomes North).  The external magnetic field strength required to 
produce this flip is called the COERCIVE FORCE, or COERCIVITY of the particle.
Magnetic pigments are available in a variety of coercivities (more on that 
lateron).

   An unencoded magstripe is actually a series of North-South magnetic
domains (see Figure 1).  The adjacent N-S fluxes merge, and the entire stripe
acts as a single bar magnet with North and South poles at its ends.


Figure 1:               N-S.N-S.N-S.N-S.N-S.N-S.N-S.N-S <-particles in stripe
---------                        
       represented as-> N-----------------------------S
                                       

   However, if a S-S interface is created somewhere on the stripe, the fluxes
will REPEL, and we get a concentration of flux lines around the S-S interface.
(same with N-N interface)  ENCODING consists of creating S-S and N-N 
interfaces, and READING consists of (you guessed it) detecting 'em.  The S-S
and N-N interfaces are called FLUX REVERSALS.


                            ||| ||| <-flux lines
Figure 2:      N------------N-N-S-S-----------------S
---------     flux lines -> ||| |||


  The external magnetic field used to flip the polarities is produced by a 
SOLENOID, which can REVERSE its polarity by reversing the direction of CURRENT.
An ENCODING head solenoid looks like a bar magnet bent into the shape of a ring
so that the North/South poles are very close and face each other across a tiny
gap.  The field of the solenoid is concentrated across this gap, and when 
elemental magnetic particles of the magstripe are exposed to this field, they
polarize to the OPPOSITE (unlike poles attract).  Movement of the stripe past
the solenoid gap during which the polarity of the solenoid is REVERSED will
produce a SINGLE flux reversal (see Figure 3).  To erase a magstripe, the
encoding head is held at a CONSTANT polarity and the ENTIRE stripe is moved
past it.  No flux reversals, no data. 





                              | |  <----wires leading to solenoid      
                              | |       (wrapped around ring)
                            /-|-|-\                          
                           /       \
Figure 3:                  |       | <----solenoid (has JUST changed polarity)                           
---------                  \       /
                            \ N S / <---gap in ring.. NS polarity across gap
      N----------------------SS-N-------------------------S
                             ^^  
                   <<<<<-direction of stripe movement

          S-S flux reversal created at trailing edge of solenoid!


   So, we now know that flux reversals are only created the INSTANT the 
solenoid CHANGES its POLARITY.  If the solenoid in Figure 3 were to remain at 
its current polarity, no further flux reversals would be created as the 
magstripe moves from right to left.  But, if we were to change the solenoid
gap polarity from NS to *SN*, then (you guessed it) a *N-N* flux reversal would
instantly be created.  Just remember, for each and every reversal in solenoid
polarity, a single flux reversal is created (commit it to memory..impress your
friends..be a tech weenie!).  An encoded magstripe is therefore just a series 
of flux reversals (NN followed by SS followed by NN ...).

  DATA! DATA! DATA!  That's what you want!  How the hell are flux reversals 
read and interpreted as data?  Another solenoid called a READ HEAD is used to
detect these flux reversals.  The read head operates on the principle of
ELECTROMAGNETIC RECIPROCITY: current passing thru a solenoid produces a 
magnetic field at the gap, therefore, the presence of a magnetic field at the
gap of a solenoid coil will *produce a current in the coil*!  The strongest
magnetic fields on a magstrip are at the points of flux reversals.  These are
detected as voltage peaks by the reader, with +/- voltages corresponding to
NN/SS flux reversals (remember, flux reversals come in 2 flavors).  
See Figure 4.


              magstripe---> -------NN--------SS--------NN---------SS------
           
Figure 4:     voltage-----> .......+.........-.........+...........-.....
---------
                                   ----------          -------------
            peak readout-->        |        |          |           |
                           --------|        |----------|           |----
 
                                       
   The 'peak readout' square waveform is critical.  Notice that the voltage 
peak remains the same until a new flux reversal is encountered.   

   Now, how can we encode DATA?  The most common technique used is known as
Aiken Biphase, or 'two-frequency coherent-phase encoding' (sounds impressive,
eh?).  First, digest the diagrams in Figure 5.
                                                                             
















                                                                             
Figure 5:       ----------        ----------        ----------                                                      
---------       |        |        |        |        |        |  <- peak                           
         a)     |        |--------|        |--------|        |     readouts                                 
                                                                             
                *   0    *   0    *   0    *   0    *   0    *
                                                             
                                                                            
                -----    -----    -----    -----    -----    -
                |   |    |   |    |   |    |   |    |   |    |
        b)      |   |----|   |----|   |----|   |----|   |----|

                *   1    *   1    *   1    *   1    *   1    *

                -----    ----------        -----    -----    -
                |   |    |        |        |   |    |   |    |                          
        c)      |   |----|        |--------|   |----|   |----|                                               
                                                                            
                *   1    *   0    *   0    *   1    *   1    *
                                                               

   There ya have it.   Data is encoded in 'bit cells,' the frequency of which
is the frequency of '0' signals.  '1' signals are exacty TWICE the frequency
of '0' signals.  Therefore, while the actual frequency of the data passing
the read head will vary due to swipe speed, data density, etc, the '1'
frequency will ALWAYS be TWICE the '0' frequency.  Figure 5C shows exactly how
'1' and '0' data exists side by side.

   We're getting closer to read DATA!  Now, we're all familiar with binary
and how numbers and letters can be represented in binary fashion very easily.
There are obviously an *infinite* number of possible standards, but thankfully
the American National Standards Institute (ANSI) and the International
Standards Organization (ISO) have chosen 2 standards.  The first is


                   ** ANSI/ISO BCD Data format **

  This is a 5-bit Binary Coded Decimal format.  It uses a 16-character set,
which uses 4 of the 5 available bits.  The 5th bit is an ODD parity bit, which
means there must be an odd number of 1's in the 5-bit character..the parity bit
will 'force' the total to be odd.  Also, the Least Significant Bits are read
FIRST on the strip.  See Figure 6.

  The sum of the 1's in each case is odd, thanks to the parity bit.  If the
read system adds up the 5 bits and gets an EVEN number, it flags the read
as ERROR, and you gotta scan the card again.  (yeah, I *know* a lot of you
out there *already* understand parity, but I gotta cover all the bases...not
everyone sleeps with their modem and can recite the entire AT command set
at will, you know ;).  See Figure 6 for details of ANSI/ISO BCD.













Figure 6:        ANSI/ISO BCD Data Format
---------
 
 * Remember that b1 (bit #1) is the LSB (least significant bit)!
  * The LSB is read FIRST!
  * Hexadecimal conversions of the Data Bits are given in parenthesis (xH).
       
        --Data Bits--   Parity 
        b1  b2  b3  b4   b5    Character  Function
                                 
        0   0   0   0    1        0 (0H)    Data
        1   0   0   0    0        1 (1H)      " 
        0   1   0   0    0        2 (2H)      " 
        1   1   0   0    1        3 (3H)      " 
        0   0   1   0    0        4 (4H)      " 
        1   0   1   0    1        5 (5H)      " 
        0   1   1   0    1        6 (6H)      " 
        1   1   1   0    0        7 (7H)      " 
        0   0   0   1    0        8 (8H)      " 
        1   0   0   1    1        9 (9H)      " 
        0   1   0   1    1        : (AH)    Control
        1   1   0   1    0        ; (BH)    Start Sentinel
        0   0   1   1    1        < (CH)    Control
        1   0   1   1    0        = (DH)    Field Separator
        0   1   1   1    0        > (EH)    Control
        1   1   1   1    1        ? (FH)    End Sentinel


           ***** 16 Character 5-bit Set *****
                10 Numeric Data Characters
                3 Framing/Field Characters
                3 Control Characters
         

    The magstripe begins with a string of Zero bit-cells to permit the
self-clocking feature of biphase to "sync" and begin decoding.
A "Start Sentinel" character then tells the reformatting process where to start
grouping the decoded bitstream into groups of 5 bits each.  At the end of the
data, an "End Sentinel" is encountered, which is followed by an "Longitudinal
Redundancy Check (LRC) character.  The LRC is a parity check for the sums of 
all b1, b2, b3, and b4 data bits of all preceding characters.  The LRC 
character will catch the remote error that could occur if an individual
character had two compensating errors in its bit pattern (which would fool the
5th-bit parity check).  

   The START SENTINEL, END SENTINEL, and LRC are collectively called "Framing
Characters", and are discarded at the end of the reformatting process.

           
                  ** ANSI/ISO ALPHA Data Format **

   Alphanumeric data can also be encoded on magstripes.  The second ANSI/ISO
data format is ALPHA (alphanumeric) and involves a 7-bit character set with
64 characters.  As before, an odd parity bit is added to the required 6 data
bits for each of the 64 characters.  See Figure 7.










Figure 7:
---------             ANSI/ISO ALPHA Data Format

   * Remember that b1 (bit #1) is the LSB (least significant bit)!  
   * The LSB is read FIRST!
   * Hexadecimal conversions of the Data Bits are given in parenthesis (xH).

 
         ------Data Bits-------   Parity
         b1  b2  b3  b4  b5  b6     b7    Character   Function

          0   0   0   0   0   0     1      space (0H) Special
          1   0   0   0   0   0     0        ! (1H)      "
          0   1   0   0   0   0     0        " (2H)      "
          1   1   0   0   0   0     1        # (3H)      "
          0   0   1   0   0   0     0        $ (4H)      "
          1   0   1   0   0   0     1        % (5H)   Start Sentinel
          0   1   1   0   0   0     1        & (6H)   Special
          1   1   1   0   0   0     0        ' (7H)      "
          0   0   0   1   0   0     0        ( (8H)      "
          1   0   0   1   0   0     1        ) (9H)      "
          0   1   0   1   0   0     1        * (AH)      "
          1   1   0   1   0   0     0        + (BH)      "
          0   0   1   1   0   0     1        , (CH)      "
          1   0   1   1   0   0     0        - (DH)      "
          0   1   1   1   0   0     0        . (EH)      "
          1   1   1   1   0   0     1        / (FH)      "

          0   0   0   0   1   0     0        0 (10H)    Data (numeric)
          1   0   0   0   1   0     1        1 (11H)     "
          0   1   0   0   1   0     1        2 (12H)     "
          1   1   0   0   1   0     0        3 (13H)     "
          0   0   1   0   1   0     1        4 (14H)     "
          1   0   1   0   1   0     0        5 (15H)     " 
          0   1   1   0   1   0     0        6 (16H)     "
          1   1   1   0   1   0     1        7 (17H)     " 
          0   0   0   1   1   0     1        8 (18H)     "
          1   0   0   1   1   0     0        9 (19H)     "
                                               
          0   1   0   1   1   0     0        : (1AH)   Special
          1   1   0   1   1   0     1        ; (1BH)      "
          0   0   1   1   1   0     0        < (1CH)      "
          1   0   1   1   1   0     1        = (1DH)      "
          0   1   1   1   1   0     1        > (1EH)      "
          1   1   1   1   1   0     0        ? (1FH)   End Sentinel
          0   0   0   0   0   1     0        @ (20H)   Special   

          1   0   0   0   0   1     1        A (21H)   Data (alpha) 
          0   1   0   0   0   1     1        B (22H)     "
          1   1   0   0   0   1     0        C (23H)     "
          0   0   1   0   0   1     1        D (24H)     " 
          1   0   1   0   0   1     0        E (25H)     "
          0   1   1   0   0   1     0        F (26H)     "  
          1   1   1   0   0   1     1        G (27H)     "
          0   0   0   1   0   1     1        H (28H)     "
          1   0   0   1   0   1     0        I (29H)     "
          0   1   0   1   0   1     0        J (2AH)     "
          1   1   0   1   0   1     1        K (2BH)     "
          0   0   1   1   0   1     0        L (2CH)     "  
          1   0   1   1   0   1     1        M (2DH)     "
          0   1   1   1   0   1     1        N (2EH)     "   
          1   1   1   1   0   1     0        O (2FH)     " 
          0   0   0   0   1   1     1        P (30H)     "
          1   0   0   0   1   1     0        Q (31H)     "  
          0   1   0   0   1   1     0        R (32H)     "
          1   1   0   0   1   1     1        S (33H)     "
          0   0   1   0   1   1     0        T (34H)     "
          1   0   1   0   1   1     1        U (35H)     "
          0   1   1   0   1   1     1        V (36H)     "
          1   1   1   0   1   1     0        W (37H)     "
          0   0   0   1   1   1     0        X (38H)     "  
          1   0   0   1   1   1     1        Y (39H)     "
          0   1   0   1   1   1     1        Z (3AH)     "
 
          1   1   0   1   1   1     0        [ (3BH)    Special
          0   0   1   1   1   1     1        \ (3DH)    Special
          1   0   1   1   1   1     0        ] (3EH)    Special
          0   1   1   1   1   1     0        ^ (3FH)    Field Separator
          1   1   1   1   1   1     1        _ (40H)    Special
  
              ***** 64 Character 7-bit Set *****
                  * 43 Alphanumeric Data Characters
                  * 3 Framing/Field Characters
                  * 18 Control/Special Characters


   The two ANSI/ISO formats, ALPHA and BCD, allow a great variety of data to be
stored on magstripes.  Most cards with magstripes use these formats, but 
occasionally some do not.  More about those lateron.  


                   ** Tracks and Encoding Protocols **
 
   Now we know how the data is stored.  But WHERE is the data stored on the
magstripe?  ANSI/ISO standards define *3* Tracks, each of which is used for
different purposes.  These Tracks are defined only by their location on the
magstripe, since the magstripe as a whole is magnetically homogeneous.  See
Figure 8.


Figure 8:
---------          
         _________________________________________________________________
         |                  ^         ^         ^
         |------------------| 0.223"--|---------|-------------------------
         |                  |         | 0.353"  |            ^
         |..................|.........|.........| 0.493"     |         
         | Track #1  0.110"           |         |            |
         |............................|.........|...     
         |                            |         |            | 
         |............................|.........|...         |        
         | Track #2  0.110"                     |            |
         |......................................|...         |         
         |                                      |            | 
         |......................................|...         |          
         | Track #3  0.110"                                  |
         |..........................................         |               
         |                                                   |
         |------------------------------------------------------------------
         |
         |                   
         |
 

   You can see the exact distances of each track from the edge of the card, as
well as the uniform width and spacing.  Place a magstripe card in front of you
with the magstripe visible at the bottom of the card.  Data is encoded from
left to right (just like reading a book, eh?).  See Figure 9.


Figure 9:
---------          ANSI/ISO Track 1,2,3 Standards

     Track     Name     Density     Format    Characters     Function
   --------------------------------------------------------------------
       1       IATA     210 bpi     ALPHA        79        Read Name & Account
       2       ABA       75 bpi      BCD         40        Read Account
       3       THRIFT   210 bpi      BCD        107        Read Account &
                                                           *Encode* Transaction


   *** Track 1 Layout: ***     
 
             | SS | FC |  PAN  |   Name   | FS |  Additional Data | ES | LRC |

 SS=Start Sentinel "%"
 FC=Format Code
 PAN=Primary Acct. # (19 digits max)
 FS=Field Separator "^"
 Name=26 alphanumeric characters max.
 Additional Data=Expiration Date, offset, encrypted PIN, etc.
 ES=End Sentinel "?"
 LRC=Longitudinal Redundancy Check


   *** Track 2 Layout: ***

           | SS |  PAN  | FS |  Additional Data  | ES | LRC |

 SS=Start Sentinel ";"
 PAN=Primary Acct. # (19 digits max)
 FS=Field Separator "="
 Additional Data=Expiration Date, offset, encrypted PIN, etc.
 ES=End Sentinel "?"
 LRC=Longitudinal Redundancy Check 


   *** Track 3 Layout: **  Similar to tracks 1 and 2.  Almost never used.
                           Many different data standards used.


   Track 2, "American Banking Association," (ABA) is most commonly used.  This
is the track that is read by ATMs and credit card checkers.  The ABA designed
the specifications of this track and all world banks must abide by it.  It
contains the cardholder's account, encrypted PIN, plus other discretionary
data. 

   Track 1, named after the "International Air Transport Association," contains
the cardholder's name as well as account and other discretionary data.  This
track is sometimes used by the airlines when securing reservations with a
credit card; your name just "pops up" on their machine when they swipe your
card!
Since Track 1 can store MUCH more information, credit card companies are trying
to urge retailers to buy card readers that read Track 1.  The *problem* is that
most card readers read either Track 1 or Track 2, but NOT BOTH!  And the
installed base of readers currently is biased towards Track 2.  VISA USA is at
the front of this 'exodus' to Track 1, to the point where they are offering
Track 1 readers at reduced prices thru participating banks.  A spokesperson for
VISA commented:
                "We think that Track 1 represents more flexibility and the
                 potential to deliver more information, and we intend to 
                 build new services around the increased information."

   What new services?  We can only wait and see.

   Track 3 is unique.  It was intended to have data read and WRITTEN on it.
Cardholders would have account information UPDATED right on the magstripe.  
Unfortunately, Track 3 is pretty much an orphaned standard.  Its *original*
design was to control off-line ATM transactions, but since ATMs are now on-line
ALL THE TIME, it's pretty much useless.  Plus the fact that retailers and banks
would have to install NEW card readers to read that track, and that costs $$.

   Encoding protocol specifies that each track must begin and end with a length
of all Zero bits, called CLOCKING BITS.  These are used to synch the self-
clocking feature of biphase decoding.  See Figure 10.

Figure 10:                              end sentinel
                     start sentinel      |  longitudinal redundancy check
                      |                  |  |
      000000000000000 SS.................ES LRC 0000000000000000
       leading           data, data, data           trailing
       clocking bits                                clocking bits
       (length varies)                             (length varies)
  
   THAT'S IT!!!  There you have the ANSI/ISO STANDARDS!  Completely explained.
Now, the bad news.  NOT EVERY CARD USES IT!  Credit cards and ATM cards will
follow these standards.  BUT, there are many other types of cards out there.
Security passes, copy machine cards, ID badges, and EACH of them may use a
PROPRIETARY density/format/track-location system.  ANSI/ISO is REQUIRED for
financial transaction cards used in the international interbank network.  All
other cards can play their own game.

   The good news.  MOST other cards follow the standards, because it's EASY to
follow a standard instead of WORKING to make your OWN!  Most magstripe cards
other than credit cards and ATM cards will use the same Track specifications,
and use either BCD or ALPHA formats. 



                    ** A Bit About Magstripe Equipment **

  "Wow, now I know how to interpret all that data on magstripes!  But...
waitasec, what kind of equipment do I need to read the stripes?
Where can I buy a reader?  I don't see any in Radio Shack!!"

   Sorry, but magstripe equipment is hard to come by.  For obvious reasons,
card readers are not made commonly available to consumers.  How to
build one is the topic for another phile (and THIS phile is already too long!).
 
  Your best bets are to try and scope out Electronic Surplus Stores and flea
markets.  Don't even bother trying to buy one directly from a manufacturer,
since they will immediately assume you have "criminal motives."  And as for
getting your hands on a magstripe ENCODER...well, good luck!  Those rare 
beauties are worth their weight in gold.  Keep your eyes open and look around,
and MAYBE you'll get lucky!  A bit of social engineering can go a LONG way.

   There are different kinds of magstripe readers/encoders.  The most common
ones are "swipe" machines: the type you have to physically slide the card thru.
Others are "insertion" machines: like ATM machines they 'eat' your card, then
regurgitate it after the transaction.  Costs are in the thousands of dollars,
but like I said, flea markets and surplus stores will often have GREAT deals
on these things.  Another problem is documentation for these machines.  If you
call the manufacturer and simply ask for 'em, they will probably deny you the
literature. "Hey son, what are you doing with our model XYZ swipe reader?  That
belongs in the hands of a 'qualified' merchant or retailer, not some punk kid
trying to 'find out how things work!"  Again, some social engineering may be
required.  Tell 'em you're setting up a new business.  Tell 'em you're working
on a science project.  Tell 'em anything that works!

   2600 Magazine recently had a good article on how to build a machine that
copies magstripe cards.  Not much info on the actual data formats and encoding
schemes, but the device described is a start.  With some modifications, I bet
you could route the output to a dumb terminal (or thru a null modem cable) in
order to READ the data.  Worth checking out the schematics.
 
   As for making your own cards, just paste a length of VCR, reel-to-reel, or
audio cassette tape to a cut-out posterboard or plastic card.  Works just as
good as the real thing, and useful to experiment with if you have no expired or
'dead' ATM or calling cards lying around (SAVE them, don't TOSS them!).


             
                 ** Examples of Data on Magstripes **

   The real fun in experimenting with magstripe technology is READING cards to
find out WHAT THE HELL is ON them!  Haven't you wondered?  The following cards
are the result of my own 'research'.  Data such as specific account numbers and
names has been changed to protect the innocent.  None the cards used to make
this list were stolen or acquired illegally.

   Notice that I make careful note of 'common data'; data that I noticed was
the same for all cards of a particular type.  This is highlighted below the
data with asterisks (*).  Where I found varying data, I indicate it with "x"'s.
In those cases, NUMBER of CHARACTERS was consistent (the number of "x"'s equals
the number of characters...one to one relationship).

   I still don't know what some of the data fields are for, but hopefully I
will be following this phile with a sequel after I collect more data.  It ISN'T
easy to find lots of cards to examine. Ask your friends, family, and co-workers
to help!  "Hey, can I, um, like BORROW your MCI calling card tonite?  I'm
working on an, um, EXPERIMENT.  Please?"  Just...be honest!  Also, do some
trashing.  People will often BEND expired cards in half, then throw them out.
Simply bend 'em back into their normal shape, and they'll usually work (I've 
done it!).  They may be expired, but they're not ERASED!  
-------------------------------------------------------------------------------
-=Mastercard=-  Number on front of card -> 1111 2222 3333 4444
                Expiration date -> 12/99 

Track 2 (BCD,75 bpi)-> ;1111222233334444=99121010000000000000?
                                             ***
          
Track 1 (ALPHA,210 bpi)-> %B1111222233334444^PUBLIC/JOHN?
                           *
Note that the "101" was common to all MC cards checked, as well as the "B".
-------------------------------------------------------------------------------
-=VISA=-  Number on front of card -> 1111 2222 3333 4444
          Expiration date -> 12/99

Track 2 (BCD,75 bpi)-> ;1111222233334444=9912101xxxxxxxxxxxxx?
                                             ***
Track 1 (ALPHA,210 bpi)-> %B1111222233334444^PUBLIC/JOHN^9912101xxxxxxxxxxxxx?
                           *

Note that the "101" was common to all VISA cards checked, as well as the "B".
Also, the "xxx" indicates numeric data that varied from card to card, with no
apparent pattern.  I believe this is the encrypted pin for use when cardholders
get 'cash advances' from ATMs.  In every case, tho, I found *13* digits of the
stuff.
-------------------------------------------------------------------------------
-=Discover=-  Number on front of card -> 1111 2222 3333 4444
              Expiration date -> 12/99

Track 2 (BCD,75 bpi)-> ;1111222233334444=991210100000?
                                             ********

Track 1 (ALPHA,210 bpi)-> %B1111222233334444^PUBLIC/JOHN___^991210100000?
                                                                ******** 
Note, the "10100000" and "B" were common to most DISCOVER cards checked.
I found a few that had "10110000" instead.  Don't know the significance.
Note the underscores after the name JOHN.  I found consistently that the name
data field had *26* charaters.  Whatever was left of the field after the name
was "padded" with SPACES.  Soo...for all of you with names longer than 25 
(exclude the "/") charaters, PREPARE to be TRUNCATED! ;)
-------------------------------------------------------------------------------
-=US Sprint FON=-  Number on front of card -> 111 222 3333 4444

Track 2 (BCD,75 bpi)-> ;xxxxxx11122233339==xxx4444xxxxxxxxxx=?
                                        *

Track 1 (ALPHA,210 bpi)-> %B^ /^^xxxxxxxxxxxxxxxxx?
                           *

Strange.  None of the cards I check had names in the Track 1 fields.  Track 1
looks unused, yet it was always formatted with field separators.  The "xxx"
stuff varied from card to card, and I didn't see a pattern.  I know it isn't
a PIN, so it must be account data.
-------------------------------------------------------------------------------
-=Fleet Bank=-  Number on front of card -> 111111 222 3333333
                Expiration date -> 12/99

Track 2 (BCD,75 bpi)-> ;1111112223333333=9912120100000000xxxx?
                                             ****        

Track 1 (ALPHA,210 bpi) ->
         %B1111112223333333^PUBLIC/JOHN___^9912120100000000000000xxxx000000?
          *                                    ****

Note that the "xxx" data varied.  This is the encrypted PIN offset.  Always 4
digits (hrmmm...).  The "1201" was always the same.  In fact, I tried many
ATM cards from DIFFERENT BANKS...and they all had "1201".  
-------------------------------------------------------------------------------
(Can't leave *this* one out ;)
-=Radio Shack=-  Number on front of card -> 1111 222 333333
                 NO EXPIRATION data on card

Track 2 (BCD,75 dpi)-> ;1111222333333=9912101?
                                      *******

Note that the "9912101" was the SAME for EVERY Radio Shack card I saw.  Looks
like when they don't have 'real' data to put in the expiration date field, they
have to stick SOMETHING in there.
-------------------------------------------------------------------------------

  Well, that's all I'm going to put out right now.  As you can see, the major
types of cards (ATMs, CC) all follow the same rules more or less.  I checked
out a number of security passcards and timeclock entry cards..and they ALL had
random stuff written to Track 2.  Track 2 is by FAR the MOST utilized track on
the card.  And the format is pretty much always ANSI/ISO BCD.  I *did* run
into some hotel room access cards that, when scanned, were GARBLED.  They most
likely used a character set other than ASCII (if they were audio tones, my
reader would have put out NOTHING...as opposed to GARBLED data).  As you can
see, one could write a BOOK listing different types of card data.  I intended
only to give you some examples.  My research has been limited, but I tried to
make logical conclusions based on the data I received. 



                      ** Cards of All Flavors **

   People wanted to store A LOT of data on plastic cards.  And they wanted that
data to be 'invisible' to cardholders.  Here are the different card 
technologies that were invented and are available today.

HOLLERITH - With this system, holes are punched in a plastic or paper card and
            read optically.  One of the earliest technologies, it is now seen
            as an encoded room key in hotels.  The technology is not secure, 
            but cards are cheap to make.

BAR CODE -  The use of bar codes is limited.  They are cheap, but there is 
            virtually no security and the bar code strip can be easily damaged.
            
INFRARED -  Not in widespread use, cards are factory encoded by creating a
            "shadow pattern" within the card.  The card is passed thru a swipe
            or insertion reader that uses an infrared scanner.  Infrared card
            pricing is moderate to expensive, and encoding is pretty secure.
            Infrared scanners are optical and therefore vulnerable to 
            contamination.

PROXIMITY - Hands-free operation is the primary selling point of this card.
            Altho several different circuit designs are used, all proximity
            cards permit the transmission of a code simply by bringing the card
            near the reader (6-12").  These cards are quite thick, up to 
            0.15" (the ABA standard is 0.030"!).  

WIEGAND -   Named after its inventor, this technology uses a series of small
            diameter wires that, when subjected to a changing magnetic field, 
            induce a discrete voltage output in a sensing coil.  Two rows of
            wires are embedded in a coded strip.  When the wires move past
            the read head, a series of pulses is read and interpreted as binary
            code.  This technology prodces card that are VERY hard to copy
            or alter, and cards are moderately expensive to make.  Readers
            based on this tech are epoxy filled, making them immune to weather
            conditions, and neither card nor readers are affected by external
            magnetic fields (don't worry about leaving these cards on top of
            the television set...you can't hurt them!).  Here's an example of
            the layout of the wires in a Wiegand strip:

               ||| || ||   | ||| | || ||    |  ||  ||    |   |  ||  
                  |  |    | |   | |     ||||     ||  ||||     ||
           
            The wires are NOT visible from the outside of the card, but if
            your card is white, place it in front of a VERY bright light source
            and peer inside.  Notice that the spacings between the wires is
            uniform.

BARIUM FERRITE - The oldest magnetic encoding technology (been around for 40
                 yrs!) it uses small bits of magnetized barium ferrite that are
                 placed inside a plastic card.  The polarity and location of
                 the "spots" determines the coding.  These cards have a short
                 life cycle, and are used EXTENSIVELY in parking lots (high
                 turnover rate, minimal security).  Barium Ferrite cards are
                 ONLY used with INSERTION readers.

   There you have the most commonly used cards.  Magstripes are common because
they are CHEAP and relatively secure.  


                         ** Magstripe Coercivity **

   Magstripes themselves come in different flavors.  The COERCIVITY of the 
magnetic media must be specified.  The coercivity is the magnetic field 
strength required to demagnetize an encoded stripe, and therefore determines 
the encode head field strength required to encode the stripe.  A range of media
coerciviteis are available ranging from 300 Oersteds to 4,000 Oe.  That boils
down to HIGH-ENERGY magstripes (4,000 Oe) and LOW-ENERGY magstripes (300 Oe).

  REMEMBER: since all magstripes have the same magnetic remanence regardless of
their coercivity, readers CANNOT tell the difference between HIGH and LOW
energy stripes.  Both are read the same by the same machines.

   LOW-ENERGY media is most common.  It is used on all financial cards, but its
disadvantage is that it is subject to accidental demagnetization from contact
with common magnets (refrigerator, TV magnetic fields, etc.).  But these cards
are kept safe in wallets and purses most of the time.

   HIGH-ENERGY meda is used for ID Badges and access control cards, which are
commonly used in 'hostile' environments (worn on uniform, used in stockrooms).
Normal magnets will not affect these cards, and low-energy encoders cannot 
write to them.

  
                  ** Not All that Fluxes is Digital **
   
   Not all magstripe cards operate on a digital encoding method.  SOME cards
encode AUDIO TONES, as opposed to digital data.  These cards are usually 
used with old, outdated, industrial-strength equipment where security is not an
issue and not a great deal of data need be encoded on the card.  Some subway
passes are like this.  They require only expiration data on the magstripe, and
a short series of varying frequencies and durations are enough.  Frequencies
will vary with the speed of swiping, but RELATIVE frequencies will remain the
same (for instance, tone 1 is twice the freq. of tone 2, and .5 the freq of
tone 3, regardless of the original frequencies!).  Grab an oscilliscope to
visualize the tones, and listen to them on your stereo.  I haven't experimented
with these types of cards at all.

         
                      ** Security and Smartcards **
  
  Many security systems utilize magstripe cards, in the form of passcards and
ID cards.  It's interesting, but I found in a NUMBER of cases that there was
a serious FLAW in the security of the system.  In these cases, there was a
code number PRINTED on the card.  When scanned, I found this number encoded on 
the magstripe.  Problem was, the CODE NUMBER was ALL I found on the magstripe!
Meaning, by just looking at the face of the card, I immediately knew exactly 
what was encoded on it.  Ooops!  Makes it pretty damn easy to just glance at
Joe's card during lunch, then go home and pop out my OWN copy of Joe's access
card!  Fortunately, I found this flaw only in 'smaller' companies (sometimes
even universities).  Bigger companies seem to know better, and DON'T print 
ALL of the magstripe data right on card in big, easily legible numbers.  At
least the big companies *I* checked. ;)
  Other security blunders include passcard magstripes encoded ONLY with the
owner's social security number (yeah, real difficult to find out a person's
SS#...GREAT idea), and having passcards with only 3 or 4 digit codes.  

  Smartcard technology involves the use of chips embedded in plastic cards, 
with pinouts that temporarily contact the card reader equipment.  Obviously,
a GREAT deal of data could be stored in this way, and unauthorized duplication
would be very difficuly.  Interestingly enough, not much effort is being put
into smartcards by the major credit card companies.  They feel that the tech
is too expensive, and that still more data can be squeezed onto magstripe
cards in the future (especially Track 1).  I find this somewhat analagous to
the use of metallic oxide disk media.  Sure, it's not the greatest (compared
to erasable-writable optical disks), but it's CHEAP..and we just keep improving
it.  Magstripes will be around for a long time to come.  The media will be
refined, and data density increased.  But for conventional applications, the
vast storage capabilities of smartcards are just not needed.  


                   ** Biometrics: Throw yer cards away! **
  
  I'd like to end with a mention of biometrics: the technology based on reading
the physical attributes of an individual thru retina scanning, signature
verification, voice verification, and other means.  This was once limited to
government use and to supersensitive installations.  However, biometrics will
soon acquire a larger market share in access control sales because much of its
development stage has passed and costs will be within reach of more buyers.
Eventually, we can expect biometrics to replace pretty much ALL cards..because
all those plastic cards in your wallet are there JUST to help COMPANIES
*identify* YOU.  And with biometrics, they'll know you without having to read
cards.  I'm not paranoid, nor do I subscribe to any grand 'corporate 
conspiracy', but I find it a bit unsettling that our physical attributes will
most likely someday be sitting in the cool, vast electronic databases of
the CORPORATE world.  Accessable by anyone willing to pay.  Imagine CBI and TRW
databases with your retina image, fingerprint, and voice pattern online for
instant, convenient retrieval.  Today, a person can CHOOSE NOT to own a credit
card or a bank card...we can cut up our plastic ID cards!  Without a card, a
card reader is useless and cannot identify you.  Paying in cash makes you
invisible!  However, with biometrics, all a machine has to do is watch...
.listen...and record.  With government/corporate America pushing all the
buttons..  "Are you paying in cash?...thank you...please look into the camera.
Oh, I see your name is Mr. Smith...uh, oh...my computer tells me you haven't
paid your gas bill....afraid I'm going to have to keep this money and credit
your gas account with it....do you have any more cash?...or would you rather
I garnish your paycheck?"  heh heh


             ** Closing Notes (FINALLY!!!!) **

  Whew...this was one MOTHER of a phile.  I hope it was interesting, and I hope
you distribute it to all you friends.  This phile was a production of
"Restricted Data Transmissions"...a group of techies based in the Boston area
that feel that "Information is Power"...and we intend to release a number of
highly technical yet entertaining philes in the coming year....LOOK FOR THEM!!
Tomorrow I'm on my way to Xmascon '91.....we made some slick  buttons 
commemorating the event...if you ever see one of them (green wreath..XMASCON
1991 printed on it)..hang on to it!...it's a collector's item.. (hahahah)
Boy, I'm sleepy...

Remember....    "Truth is cheap, but information costs!"

But -=RDT is gonna change all that... ;)  set the info FREE!  

Peace.

                      ..oooOO Count Zero OOooo..
  
Usual greets to Magic Man, Brian Oblivion, Omega, White Knight, and anyone
else I ever bummed a cigarette off.....

(1/18/92 addition: Greets to everyone I met at Xmascon..incuding but not
excluding Crimson Death, Dispater, Sterling, Mackhammer, Erik Bloodaxe,
Holistic Hacker, Pain Hertz, Swamp Ratte, G.A.Ellsworth, Phaedrus, Moebius,
Lord MacDuff, Judge Dredd, and of course hats of to *Drunkfux* for organizing
and taking responsibility for the whole damn thing.  Hope to see all of you
at Summercon '92!  Look for Cyber-stripper GIFs at a BBS near you..heh heh) 

Comments, criticisms, and discussions about this phile are welcome.  I can be
reached at
                  [email protected]
                  [email protected]
                  [email protected]

Magic Man and I are the sysops of the BBS "ATDT"...located somewhere in
Massachusetts.  Great message bases, technical discussions...data made
flesh...electronic underground.....our own Internet address (atdt.org)...
.field trips to the tunnels under MIT in Cambridge.....give it a call..
..mail me for more info.. ;)

                    ATDT------(???)YOU-WISH  
   (You're not paranoid if they're REALLY out to get you... ;)