1845 lines
78 KiB
Plaintext
1845 lines
78 KiB
Plaintext
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: brian@ucsd.edu (Brian Kantor)
|
||
Newsgroups: sci.electronics
|
||
Subject: Re: Encoding Scheme of Mag Stripe Cards?
|
||
Message-ID: <kms26oINNojs@network.ucsd.edu>
|
||
Date: 10 Jan 92 20:58:00 GMT
|
||
References: <1992Jan10.202240.2789@ux1.cso.uiuc.edu>
|
||
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: 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
|
||
|
||
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
|
||
|
||
|
||
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 <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 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 atn@cory.berkeley.edu ...!ucbvax!cory!atn
|
||
974 Tulare Avenue, Albany CA 94707-2540 37'52N/122'15W +1 415 526 1818
|
||
|
||
|
||
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 tmkk@uiuc.edu). 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 tmkk@uiuc.edu.
|
||
|
||
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 <stdio.h>
|
||
#include <conio.h>
|
||
#include <process.h>
|
||
#include <dos.h>
|
||
#include <math.h>
|
||
#include <stdlib.h>
|
||
#include <assert.h>
|
||
#include <string.h>
|
||
|
||
/* 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 <ENTER> 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 <ENTER> to dump data.\r\n\r\n");
|
||
getchar();
|
||
|
||
/* dump data to stdout */
|
||
for (i=0; i<nsamp; ++i)
|
||
if (kbhit())
|
||
break;
|
||
else
|
||
printf("%u\n", databuf[i]);
|
||
|
||
free (databuf);
|
||
|
||
}
|
||
|
||
--- CUT HERE ---
|
||
|
||
;
|
||
; S W I P E I S R . A S M
|
||
;
|
||
; Interrupt Service Routine to sample swipe reader.
|
||
;
|
||
|
||
_TEXT segment byte public 'CODE'
|
||
DGROUP group _DATA,_BSS
|
||
assume cs:_TEXT,ds:DGROUP,ss:DGROUP
|
||
_TEXT ends
|
||
|
||
_DATA segment word public 'DATA'
|
||
; Nuthin' in here!
|
||
_DATA ends
|
||
|
||
_BSS segment word public 'BSS'
|
||
; Nuthin' in here either!
|
||
_BSS ends
|
||
|
||
_TEXT segment byte public 'CODE'
|
||
;
|
||
; S H A N D
|
||
;
|
||
; Description: Sample interrupt handler for timer extension interrupt 0x1c.
|
||
;
|
||
; Note: Assumes that the /CARD DETECT line appears on bit 7 of the input
|
||
; port. This bit corresponds to pin 11 on the standard PC printer port.
|
||
; Also, the PC printer port card inverts the signal on this pin; thus,
|
||
; bit 7 is *set* when a card is in the reader, even though /CARD DETECT
|
||
; is an active low signal.
|
||
;
|
||
_shand proc far
|
||
push ax
|
||
push bx
|
||
push dx
|
||
push ds
|
||
push si
|
||
push di
|
||
push bp
|
||
mov bp,DGROUP
|
||
mov ds,bp
|
||
|
||
cmp word ptr DGROUP:_enab, 0 ; Are we turned on?
|
||
je ciao ; Nope - goodbye!
|
||
|
||
mov dx, word ptr DGROUP:_port ; Get port address
|
||
cmp word ptr DGROUP:_start, 0 ; Has sampling begun?
|
||
jne doit ; Yup - hop to it!
|
||
|
||
;
|
||
; Sampling is enabled but has not actually begun because no card has yet been
|
||
; detected in the slot of the reader. Check to see if a card has arrived
|
||
; yet and, if it has, set the flag to indicate that sampling should begin.
|
||
;
|
||
in al, dx ; sample port
|
||
test al, 80h ; card detected?
|
||
jz ciao ; nope - later!
|
||
|
||
mov word ptr DGROUP:_start, 1 ; card's there,
|
||
; start reading it
|
||
jmp saveit
|
||
;
|
||
doit:
|
||
in al, dx ; Read the port
|
||
test al, 80h ; card detect bit set?
|
||
jz disable ; if not, quit
|
||
;
|
||
; Data is still valid; get buffer pointer and save the data
|
||
;
|
||
saveit:
|
||
mov bx,word ptr DGROUP:_bufp ; get addr. to write
|
||
mov byte ptr [bx],al ; save sampled value
|
||
inc word ptr DGROUP:_bufp ; and bump the ptr
|
||
|
||
inc word ptr DGROUP:_nsamp ; update sample count
|
||
jmp ciao ; and skeedaddle
|
||
|
||
disable:
|
||
mov word ptr DGROUP:_enab,0 ; card no longer
|
||
; detected - disable
|
||
; sampling
|
||
ciao:
|
||
pop bp ; restore context
|
||
pop di
|
||
pop si
|
||
pop ds
|
||
pop dx
|
||
pop bx
|
||
pop ax
|
||
iret
|
||
_shand endp
|
||
_TEXT ends
|
||
|
||
_DATA segment word public 'DATA'
|
||
;s@ label byte
|
||
_DATA ends
|
||
extrn _nsamp:word
|
||
extrn _port:word
|
||
extrn _bufp:word
|
||
extrn _enab:word
|
||
extrn _start:word
|
||
_TEXT segment byte public 'CODE'
|
||
extrn _inportb:near
|
||
_TEXT ends
|
||
public _shand
|
||
end
|
||
|
||
=== END OF SUMMARY ===
|
||
|
||
From count0@spica.bu.edu Sat Jan 18 19:44:46 1992
|
||
Received: from mrcnext.cso.uiuc.edu by ux1.cso.uiuc.edu with SMTP id AA13550
|
||
(5.65d/IDA-1.4.4 for <khan@ux1.cso.uiuc.edu>); 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: count0@spica.bu.edu (Bobby Newmark)
|
||
Message-Id: <9201190143.AA12820@spica.bu.edu>
|
||
To: khan@mrcnext.cso.uiuc.edu
|
||
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 <gasp>
|
||
"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:
|
||
--------- <edge of card>
|
||
_________________________________________________________________
|
||
| ^ ^ ^
|
||
|------------------| 0.223"--|---------|-------------------------
|
||
| | | 0.353" | ^
|
||
|..................|.........|.........| 0.493" |
|
||
| Track #1 0.110" | | |
|
||
|............................|.........|... <MAGSTRIPE>
|
||
| | | |
|
||
|............................|.........|... |
|
||
| Track #2 0.110" | |
|
||
|......................................|... |
|
||
| | |
|
||
|......................................|... |
|
||
| Track #3 0.110" |
|
||
|.......................................... |
|
||
| |
|
||
|------------------------------------------------------------------
|
||
|
|
||
| <body of card>
|
||
|
|
||
|
||
|
||
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
|
||
count0@world.std.com
|
||
count0@spica.bu.edu
|
||
count0@atdt.org
|
||
|
||
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... ;)
|
||
|
||
|