1435 lines
71 KiB
Plaintext
1435 lines
71 KiB
Plaintext
Magnetic stripe technology
|
||
|
||
|
||
Figures and listings are at the end.
|
||
|
||
Because of their widespread use, most magnetic cards adhere to well-defined
|
||
standards that describe the physical and magnetic characteristics for a
|
||
magnetic stripe on a plastic card. These standards outline specifications for a
|
||
storage format and information interchange. This does not preclude other
|
||
encoding techniques or additional data tracks for specific applications, but in
|
||
most cases it makes sense to adhere to at least the basic constraints. This
|
||
gives you the choice of using any commercially available magnetic encoders for
|
||
your application. The technique used for encoding magnetic cards is known as
|
||
"Two-Frequency, Coherent Phase Recording". Allowing for the representation of
|
||
single-channel, self-clocking serial data, this methodology is generally
|
||
referred to as F/2F. Self-clocking is achieved by combining data and clock bits
|
||
together in a continuous, synchronous sequence. In this scheme, an intermediate
|
||
flux transition signifies a one bit and the absence of an intermediate flux
|
||
transition denotes a zero bit.
|
||
Three data tracks defined for use on standard magnetic cards each possess
|
||
different bit densities and encoded character sets. The average bit density of
|
||
track 1 is 210 bits per inch (bpi). Track 1 characters are made up of six data
|
||
bits and an odd parity bit, encoded with the least-significant bit first and
|
||
the parity bit last, yielding a 64-character set. Taking the number of bits per
|
||
inch and the number of bits per character, you can see track 1 has the capacity
|
||
to hold 79 characters.
|
||
Track 2 has a bit density of 75 bpi, and track 3 uses 210 bpi. Both of these
|
||
tracks allow the representation of a numeric-only character set. The characters
|
||
for tracks 2 and 3 are encoded using a 4-bit binary-coded decimal subset with
|
||
odd parity and, like track 1, are encoded with the least significant bit first
|
||
and the parity bit last. The lower density of track 2 allows up to 40 numeric
|
||
characters, where 107 numerics can be squeezed onto track 3. The actual number
|
||
of usable characters will be fewer since you also have the Start Sentinel, End
|
||
Sentinel, and LRC characters.
|
||
Though sometimes magnetic cards are moved past the read head mechanically,
|
||
most applications rely on manually moving the card, either through a slotted
|
||
reader or into an insertion-type reader. Typically the swipe rate is 5-20 inches
|
||
per second (ips), with 50 ips being the fastest most card readers can handle. Of
|
||
course, moving the card by hand will not only result in varying the absolute
|
||
card velocity but, will also introduce incremental speed changes as the card
|
||
accelerates and decelerates past the pickup. The F/2F scheme is very forgiving
|
||
of such speed fluctuations.
|
||
For all 3 tracks, the fundamental data format is similar and consists of the
|
||
following elements: First, leading zero bits are encoded to indicate the
|
||
presence of an encoded magnetic card and provide synchronization pulses to the
|
||
read head electronics and ultimately to the controller. Next, the Start Sentinel
|
||
character is encoded which indicates the start of the actual data. The coded
|
||
data follows. Next, the End Sentinel terminates the data portion of the card
|
||
and followed by an LRC byte (used for error detection). The LRC is essentially
|
||
a horizontal parity calculated by an exclusive-OR of all the data bits from the
|
||
Start Sentinel to the End Sentinel (inclusive). Finally, trailing zeros follow
|
||
the LRC and fill out the remainder of the card.
|
||
ANATOMY OF A MAGNETIC CARD
|
||
The magnetic tracks have inherent characteristics based on details such as
|
||
code set and bit and character densities. International organizations such as
|
||
Mastercard and VISA impose additional constraits for their participating members
|
||
and standards exist for bank debit cards and ATM cards as well. These rules
|
||
specify the exact content and format of each data field in aech track as well as
|
||
the intended uses for the tracks. Naturally, for nonfinancial uses, it is not
|
||
necessary to comply with these standards. For dedicated uses such as access
|
||
control, people tracking, and material tracking, adhering to the minimal
|
||
standards is adequate.
|
||
The most-often-used track is track 2, although it offers the lowest inform-
|
||
ation density of the three. It contains all the information that is normally
|
||
used for credit card transactions. When a customer name is required, track 1
|
||
must be used since it is the only track that permits alphanumeric data. Track 3
|
||
is specified for numeric-only data, but is unique. It is intended for change-
|
||
able data and consequently may not only be read but may be rewritten by the
|
||
transaction-handling equipment. A multitude of data fileds are contained in
|
||
these various tracks. Figure 1 shows a brief run-down of what is generally
|
||
placed on tracks 1 and 2.
|
||
REAL CARD READERS
|
||
The recovery of magnetically encoded F/2F data can be accomplished directly
|
||
with the use of just about any microcontroller. There are no particular
|
||
difficulties in deciphering the raw F/2F data stream and many early magnetic
|
||
read heads contained nothing more than signal amplifiers and line drivers.
|
||
These are now artifacts since all modern magnetic read heads contain integ-
|
||
rated F/2F bit recovery circuitry and interface with the host controller in a
|
||
standard fashion using three wires: CARD PRESENT, CLOCK, and DATA. The read
|
||
heads usually rely on a single chip to perform the linear signal conditioning,
|
||
sychronization, and recovery of individual bits from the data stream. The Mag-
|
||
Tek 21006505 IC is representative of this type of data recovery circuit and its
|
||
functionality is depicted in figure 2.
|
||
Linear conditioning consists of raising the level of the magnetic pickup's
|
||
input signal, rejecting common-mode noise, conditioning and detecting the
|
||
signal, and finally providing a digital output for susequent processing. The
|
||
enable/disable counters provide initialization for the recovery section. The
|
||
recovery section locks onto the data rate and recovers the individual data bits
|
||
from the data stream. The oscillator section provides the clocks for the recov-
|
||
ery section and for the enable/disable timers. Card present goes low after 8 or
|
||
9 flux reversals are seen from the magnetic pickup and will return high about
|
||
50 ms after the last flux reversal. The strobe line signals that data is valid
|
||
and is active low. The data pin indicates a one bit when it is low. Raw F/2F
|
||
data can also be picked directly off the chip.
|
||
The data rate for a high-density track scanned at 50 ips comes to 10500 bits
|
||
per second (bps). This results in a transfer rate of 1500 characters per second
|
||
for the 7-bit elements used on track 1, and 2100 characters per second using
|
||
the 5-bit elements of track 3. I either case, this translates to a new bit
|
||
arriving at the controller just under every 100 us (microsecond). Even the most
|
||
anemic controller should be able to keep up. With resonably good coding techni-
|
||
ques, there should be no problem handling the entire data sampling phase on an
|
||
interrupt-driven basis. The low-density (track 2) data flows at a more pedes-
|
||
trian 3750 bps, yielding 750 5-bit characters per second, or a new bit every
|
||
266 us. Since most dual-track read heads provide track 1 and track 2 data, this
|
||
indicates that handling both tracks simultaneously is feasible under interrupt
|
||
control. Keep in mind that 50 ips is a rather fast scan rate; 20-30 ips is
|
||
probably a more realistic limit.
|
||
MAGNETIC BIT STORMS
|
||
When approaching a problem such as decoding magnetic cards, it pays to spend
|
||
some time looking at the overall picture before starting to write the code. At
|
||
first glance, it would seem that organizing the data into the prevailing element
|
||
size during the sampling interval would make decoding easier. This could be
|
||
easily done by ignoring all the leading zeros, with actual data storage comm-
|
||
encing with the first one bit. Of course, this approach assumes you're getting
|
||
good data. The fact that the data recovery is handled using well-proven hard-
|
||
ware makes this assumption valid.
|
||
If all you need to do is decode the card in a forward direction, then going
|
||
about things as I just described makes sense and reduces the coding effort to a
|
||
trivial exercise. If you have to support reverse decoding then this is not the
|
||
optimal solution. Having considered the tradeoffs of being able to decode a
|
||
magnetic card in both forward and reverse directions, I decided to structure the
|
||
program to work equally well in either direction at the cost of a slight
|
||
increase in initial complexity.
|
||
The first step in decoding is to acquire the serial bit stream. This can be
|
||
done using a dedicated sample loop or, with a little more work, using interrupt
|
||
processing. Since the idea is the same regardless of the details, I decided to
|
||
use a sample loop in my demonstration program (listing 1). The code simply
|
||
records the incoming data stream and deposits the data in a sample buffer a byte
|
||
at a time. Sampling begins when Card Present returns idle. Any incomplete byte
|
||
that has been partially assembled at the time when sampling terminates is simply
|
||
discarded. The abundance of leading and trailing zeros allows losing some bits
|
||
at either end causing any problems.
|
||
Once the sampling interval completes, control is transferred to the decoding
|
||
algorithm. Presented in listing 2, the track-1 decode algorithm consists of
|
||
nothing more than some initialization and the essence of the decode logic.
|
||
Limiting the gyrations contained in the main body of this routine not only makes
|
||
the logic easy to follow, but permits the same code to handle the decoding in
|
||
either a forward or reverse direction.
|
||
The initial entry point assumes a forward decode attempt and sets up the
|
||
necessary flags, pointers, and counters before jumping into the main initial-
|
||
ization code. After initialization, the sample buffer is scanned for the first
|
||
one bit, at which time a 7-bit element is assembled. If the parity is correct
|
||
and the character code checks out to be a Start Sentinel, the code proceeds and
|
||
starts pulling successive data elements from the sample buffer. If the data
|
||
element is not an End Sentinel, the character is translated to ASCII and stored
|
||
in the decode buffer. Should an End Sentinel be detected, the program extracts
|
||
the next character, which is assumed to be the LRC byte, and finally checks the
|
||
calculated LRC for a value of zero.
|
||
The checks and balances included in the execution of this loop include things
|
||
such as parity, a cumulative LRC, and checking to make sure I haven't run out of
|
||
samples. If everything checks out, the program terminates and returns with the
|
||
DPTR pointing to the decoded data buffer and the character count contained in
|
||
ACC. Should a decode failure occur, a test is performed on the direction flag
|
||
and if this is an attempt at a forward decode, the routine jumps to the reverse
|
||
initialization entry point. The reverse entry is similar to the forward decode
|
||
entry but sets up the sample pointer to the end of the sample buffer and sets
|
||
the direction flag to indicate a reverse operation.
|
||
The routines contained in the intermediate layer are shown in listing 3. The
|
||
meaning and operation of these routines should be apparent. The key routine in
|
||
this section is GET_BIT, which picks off the next bit from the sample buffer,
|
||
essentially restoring the sequential nature of the initial magnetic bit stream.
|
||
FIND_START is used to synchronize with the first one bit. GET_CHAR first checks
|
||
to make sure it hasn't run out of samples, then assembles the next 7-bit data
|
||
element while doing a parity test and LRC calculation. Any problems encountered
|
||
here are sent back to the caller and are handled there. STORE_CHAR translates
|
||
and deposits the data character into its respective location in the decoded-data
|
||
buffer and increments the character counter.
|
||
Listing 4 shows the low-level code. These routines perform the most rudiment-
|
||
ary functions and operate in accordance with the direction flag. INDEX_PTR
|
||
either increments or decrements the sample pointer, POSITION_BIT likewise does
|
||
either a right or left shift and LOCATE_BIT returns the state of the least- or
|
||
most- significant bit of the accumulator.
|
||
GO AHEAD, TAKE A SWIPE
|
||
Let me touch on a few additional points that may not be immediately apparent
|
||
before signing off. Storing the sampled data in a continuous stream makes the
|
||
sample routine work equally well with the various bit configurations used for
|
||
the different recording tracks. This would not be easily attained if you tried
|
||
to generate a particular element format during sample time. Furthermore, if you
|
||
look at the differences between the encoded character sets and the bit formats
|
||
for the different tracks, you will find that they differ in only a few areas.
|
||
With a few minor changes, such as the defined Start Sentinel, number of bits per
|
||
element, and character translation method, the decode routine I've shown could
|
||
easily be coerced to handle the decoding of any of the standard magnetic tracks.
|
||
As a matter of fact, by recoding and redefining the hard-coded constants as
|
||
variables, these could be set up for the particular data track at execution
|
||
time before invoking the decode function. Doing so would not only save program
|
||
memory, but would also allow you to use a routine you were comfortable with.
|
||
|
||
*******************************************************************************
|
||
FIGURE 1
|
||
_____________________________________________________________________
|
||
TRACK 1 |SS|FC| PAN |FS| NAME |FS| ADDITIONAL DATA |ES|LRC|
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
Notes: Track 1 is limited to 79 characters including SS, ES, and LRC.
|
||
Mastercard PAN is variable up to 16 characters maximum. VISA is 13 or 16
|
||
characters, including mod-10 check digit.
|
||
SS: Start sentinel (%)
|
||
FC: Format code
|
||
FS: Field separator ({)
|
||
ES: End sentinel (?)
|
||
LRC: Longitudinal redundency check character
|
||
PAN (primary account number): 19 digits max.
|
||
NAME: 26 alphanumeric characters max.
|
||
ADDITIONAL DATA: Expiration date 4
|
||
Restriction or type 3
|
||
Offset or PVN 5
|
||
______________________________________________________________________
|
||
TRACK 2 |SS|FC| PAN |FS| ADDITIONAL DATA |ES|LRC|
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
SS: Start sentinel (;) (hex B)
|
||
FS: Field separator (=) (hex D)
|
||
ES: End sentinel (?) (hex F)
|
||
LRC: Longitudinal redundency check character
|
||
PAN (primary account number): 19 digits max.
|
||
ADDITIONAL DATA: Expiration date 4
|
||
Restriction or type 3
|
||
Offset or PVN 5
|
||
|
||
*****************************************************************************
|
||
FIGURE 2
|
||
HEAD SIGNAL __/~\__ __/~\__ __/~\__ __/~\__ __/~\__ __/~\_______
|
||
`-` `-` `-` `-` `-`
|
||
____ _______ __________ ____
|
||
CARD PRESENT |______________________________________________|
|
||
|
||
____ ____ _____________________ ____ ____ _____
|
||
READ DATA |____| |_________| |_________|
|
||
|
||
____ ______ __________ __ __ __ __ __ __ __ __ __ __
|
||
READ STROBE |__| |_| |_| |_| |_| |_| |_| |_| |_| |_| |
|
||
|
||
| 0| 1| 0| 1| 1| 0| 1| 1| 0| 0|
|
||
|
||
|
||
___
|
||
HEAD 1-----X---X--------13 |MAG| 9--C2-R3
|
||
R1 C1 |TEK| |
|
||
HEAD 2-----X---X--------12 | | 10-----X--X
|
||
| | | |
|
||
X---X------11 | | | R5
|
||
X-X R2 C6 | | 6------|--X
|
||
| | X---X-------8 | | |
|
||
+5VDC --------------X--R7--X--------X-|-----------------14 | | 7-----C3
|
||
| |+ | | | ____
|
||
R6 C5 | | | 16----DATA
|
||
| X----------|------------------5 | | ______
|
||
____ _______ | | X------------------2 | | 15----STROBE
|
||
CARD PRESENT -------X------|-----------------------------1 | |
|
||
| X----X-----3 | |
|
||
| C4 R4----4 | |
|
||
GND------------------------X------------------X |___|
|
||
|
||
R=RESISTOR(Values weren't given)
|
||
C=CAPACITOR(Values weren't given)
|
||
X=CONNECTION BETWEEN WIRES
|
||
MAG TEK is the Mag-Tek 21006505
|
||
|
||
*****************************************************************************
|
||
LISTING 1-- Using several externally defined routines, a sample program to
|
||
read a stripe and store it in a buffer is very short.
|
||
|
||
PUBLIC READ_MAG1
|
||
EXTERN MS1_BUF (XDATA) ;sample buffer
|
||
EXTERN MS1_LIM (NUMBER) ;sample limit
|
||
EXTERN MD1_BUF (XDATA) ;decode buffer
|
||
EXTERN CP (BIT) ;card present bit
|
||
EXTERN M1_CLK (BIT) ;clock bit
|
||
EXTERN M1_DQ (BIT) ;data bit
|
||
|
||
M1_SS EQU 5 ;start sentinel
|
||
M1_ES EQU 1FH ;end sentinel
|
||
;
|
||
SEG CODE
|
||
;Sample and decode magnetic track 1
|
||
; output: ACC contains character count.
|
||
; DPTR points to data buffer
|
||
READ_MAG1 PROC
|
||
CALL MAG_SAMPLE
|
||
JZ L?RM1
|
||
CALL MAG1_DECODE
|
||
L?RM1: RET
|
||
ENDPROC
|
||
;General-purpose magnetic sampling routine
|
||
; output: ACC contains sample count
|
||
MAG_SAMPLE PROC
|
||
MOV DPTR,#MS1_BUF
|
||
MOV R1,#0 ;sample counter
|
||
L?MS1: MOV R0,#8 ;bit counter
|
||
L?MS2: JB CP,L?MS4
|
||
JB M1_CLK,L?MS2
|
||
MOV C,M1_DQ
|
||
L?MS3: JB CP,L?MS4
|
||
JNB M1_CLK,L?MS3
|
||
CPL C
|
||
RRC A
|
||
DJNZ R0,L?MS2
|
||
MOVX @DPTR,A
|
||
INC DPTR
|
||
INC R1 ;sample counter
|
||
CJNE R1,#MS1_LIM,L?MS1
|
||
L?MS4: MOV A,R1 ;final sample count
|
||
RET
|
||
ENDPROC
|
||
|
||
*******************************************************************************
|
||
LISTING 2-- Once the serial bit stream has been acquired, the decoding
|
||
algorithm takes over.
|
||
|
||
;Bidirectional magnetic track 1 decode routine
|
||
;input: sample count in ACC, output: ACC contains character count
|
||
; DPTR points to decoded data buffer
|
||
;Reg. usage for this routine (includes subroutines) as follows:
|
||
;R5: Direction flag, 0=forward
|
||
;R4: Cumulative LRC register
|
||
;R3: Decoded character counter
|
||
;R2: Nondecrementing sample count
|
||
;R1: Decrementing sample count
|
||
;R0: Bit syncronizing counter
|
||
MAG1_DECODE PROC
|
||
;1st pass, setup for forward decode attempt
|
||
MOV R5,#0 ;indicate forward decode
|
||
MOV DPTR,#MS1_BUF ;point to start of buffer
|
||
MOV R1,A ;sample counter
|
||
MOV R2,A ;sample count
|
||
JMP L?M1D1
|
||
L?M1D0: ;2nd pass, setup for reverse decode attempt
|
||
MOV R5,#1 ;indicate reverse decode
|
||
MOV DPTR,#MS1_BUF
|
||
MOV A,R2 ;sample count
|
||
DEC A
|
||
ADD A,DPL
|
||
MOV DPL,A
|
||
CLR A
|
||
ADDC A,DPH
|
||
MOV DPH,A ;point to end of buffer
|
||
MOV R1,2 ;sample counter
|
||
L?M1D1: ;decode initialization
|
||
MOV R3,#0 ;character counter
|
||
MOV R4,#0 ;inital LRC
|
||
MOV R0,#0 ;bit syncronizer
|
||
CALL FIND_START ;main decode loop
|
||
JNC L?M1D5 ;start bit error
|
||
CALL GET_CHAR ;Start Sentinel
|
||
JB ACC.7,L?M1D5 ;format error
|
||
CJNE A,#M1_SS,L?M1D5 ;start setinel error
|
||
L?M1D2: ;data byte or End Sentinel
|
||
CALL GET_CHAR
|
||
JB ACC.7,L?M1D5 ;format error
|
||
CJNE A,#M1_ES,L?M1D3 ;end sentinel not found
|
||
JMP L?M1D4
|
||
L?M1D3:
|
||
CALL STORE_CHAR ;data character
|
||
JMP L?M1D2
|
||
L?M1D4: ;LRC
|
||
CALL GET_CHAR ;get LRC
|
||
JB ACC.7,L?M1D5 ;format error
|
||
MOV A,R4
|
||
JNZ L?M1D5 ;LRC error
|
||
MOV DPTR,#MD1_BUF ;good return
|
||
MOV A,R3 ;final character
|
||
RET
|
||
L?M1D5: ;decode error, check if 1st pass
|
||
CJNE R5,#1,L?M1D0 ;check direction
|
||
CLR A ;bad return
|
||
RET
|
||
ENDPROC
|
||
|
||
*******************************************************************************
|
||
LISTING 3-- The intermediate layer of software is one level removed from the
|
||
nitty-gritty details.
|
||
|
||
;Get the next bit from the sample buffer
|
||
;output: C contains data bit
|
||
GET_BIT PROC
|
||
CJNE R0,#0,L?GB1 ;bit synchronizer
|
||
MOV R0,#8
|
||
PUSH ACC
|
||
MOVX A,@DPTR
|
||
CALL INDEX_PTR
|
||
MOV B,A
|
||
POP ACC
|
||
DEC R1 ;sample counter
|
||
L?GB1: XCH A,B
|
||
CALL POSITION_BIT
|
||
XCH A,B
|
||
DEC R0 ;bit synchronizer
|
||
RET
|
||
ENDPROC
|
||
;
|
||
;Find the first '1' bit in the sample buffer
|
||
;output: C=1 if bit is found
|
||
FIND_START PROC
|
||
L?FS1:
|
||
CJNE R0,#0,L?FS2 ;bit synchronizer
|
||
MOV R0,#8
|
||
MOVX A,@DPTR
|
||
CALL INDEX_PTR
|
||
DJNZ R1,L?FS2 ;sample counter
|
||
JMP L?FS4 ;out of samples
|
||
L?FS2: CALL LOCATE_BIT ;test for a '1' bit
|
||
JC L?FS3
|
||
CALL POSITION_BIT
|
||
DEC R0 ;bit synchronizer
|
||
JMP L?FS1
|
||
L?FS3: ;good return
|
||
MOV B,A ;save copy in B
|
||
SETB C
|
||
RET
|
||
L?FS4: CLR C ;bad return
|
||
RET
|
||
ENDPROC
|
||
;
|
||
;Get the next 7 bit element from the sample buffer
|
||
;output: ACC contains data element
|
||
; error flag is ACC.7
|
||
GET_CHAR PROC
|
||
MOV A,R1 ;sample counter
|
||
JZ L?GC2 ;out of samples
|
||
MOV R7,#7 ;bit counter
|
||
CLR A
|
||
L?GC1: CALL GET_BIT ;next bit
|
||
RRC A
|
||
DJNZ R7,L?GC1
|
||
RR A
|
||
JNB P,L?GC2 ;parity error
|
||
ANL A,#3FH ;discard parity
|
||
PUSH ACC
|
||
XRL A,R4 ;calculate LRC
|
||
MOV R4,A
|
||
POP ACC ;good return
|
||
RET
|
||
L?GC2: SETB ACC.7 ;bad return
|
||
RET
|
||
ENDPROC
|
||
;Translate and store the data character
|
||
;input: ACC contains data character
|
||
STORE_CHAR PROC
|
||
PUSH DPL
|
||
PUSH DPH
|
||
PUSH ACC
|
||
MOV DPTR,#MD1_BUF
|
||
MOV A,R3 ;character counter
|
||
ADD A,DPL
|
||
MOV DPL,A
|
||
CLR A
|
||
ADDC A,DPH ;generate displacement
|
||
MOV DPH,A
|
||
POP ACC
|
||
ADD A,#' ' ;translate
|
||
MOVX @DPTR,A ;store
|
||
POP DPH
|
||
POP DPL
|
||
INC R3 ;character counter
|
||
RET
|
||
ENDPROC
|
||
|
||
*******************************************************************************
|
||
LISTING 4-- The low-level routines get right down to the ground and take care
|
||
of the gory details.
|
||
|
||
;Index the sample pointer either forward or backward
|
||
INDEX_PTR PROC
|
||
CJNE R5,#0,L?IP1 ;check direction
|
||
INC DPTR ;forward
|
||
RET
|
||
L?IP1: PUSH ACC ;backward
|
||
DEC DPL
|
||
MOV A,DPL
|
||
CJNE A,#-1,L?IP2
|
||
DEC DPH
|
||
L?IP2: POP ACC
|
||
RET
|
||
ENDPROC
|
||
|
||
;Position bit is in ACC into C in either a right or left shift
|
||
POSITION_BIT PROC
|
||
CJNE R5,#0,L?PB1 ;check direction
|
||
RRC A ;forward
|
||
RET
|
||
L?PB1: RLC A
|
||
RET
|
||
ENDPROC
|
||
|
||
;Locate a 1 bit, either msb or lsb
|
||
;output: C=1 if bit is a one
|
||
LOCATE_BIT PROC
|
||
CJNE R5,#0,L?LB1 ;check direction
|
||
MOV C,ACC.0 ;forward
|
||
RET
|
||
L?LB1: MOV C,ACC.7 ;backward
|
||
RET
|
||
ENDPROC
|
||
|
||
*******************************************************************************
|
||
Contact:
|
||
Mag-Tek, Inc.
|
||
20725 S. Annalee Ave.
|
||
Carson, CA 90746
|
||
(213) 631-8602
|
||
fax: (213) 631-3956
|
||
*******************************************************************************
|
||
|
||
|
||
|
||
|
||
--
|
||
_
|
||
__ | __ | ` __ __ clafave@holonet.net
|
||
| | __| ~|~ __|| ||__| Beaverton, Oregon USA
|
||
|__ |_ |__| | |__| \/ |__. GO BLAZERS!
|
||
|
||
|
||
|
||
From clafave@iat.holonet.net (Christopher R LaFave)
|
||
Newsgroups: alt.2600
|
||
Subject: Magnetic stripe technology (2/2)
|
||
Date: Sat, 21 May 1994 06:23:54 GMT
|
||
|
||
>From PHRACK issue#37
|
||
|
||
*******************************************************************************
|
||
* *
|
||
* 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..
|
||
|
||
count0@world.std.com
|
||
count0@spica.bu.edu
|
||
count0@atdt.org
|
||
|
||
ATDT------(???)YOU-WISH
|
||
(You're not paranoid if they're REALLY out to get you... ;)
|
||
|
||
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
||
|
||
|
||
|
||
|
||
--
|
||
_
|
||
__ | __ | ` __ __ clafave@holonet.net
|
||
| | __| ~|~ __|| ||__| Beaverton, Oregon USA
|
||
|__ |_ |__| | |__| \/ |__. GO BLAZERS!
|
||
|
||
|
||
|