Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Encoding Scheme of Mag Stripe Cards?

702 views
Skip to first unread message

K. Khan

unread,
Jan 10, 1992, 3:22:40 PM1/10/92
to
Hello again.

I asked earlier about interfacing to a swipe reader for the mag stripe
plastic cards. Thanks to several extremely helpful responses, I'm well
on my way to getting data from the cards (interested parties can contact
me for a summary).

One common question that seems to keep cropping up in the replies is how
the data on the cards are encoded. I seem to recall that there was some
information on this topic posted to the net (probably in this very group)
some time ago. If anyone has that writeup on how mag stripe cards work,
how they're encoded, how many tracks they have, etc., could you email it
to me (or post, since there are other readers of this group interested)?

Thank you!

Brian Kantor

unread,
Jan 10, 1992, 3:58:00 PM1/10/92
to

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

e14...@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 (ro...@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 <28...@pasteur.Berkeley.EDU> From: e14...@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: j...@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 a...@cory.berkeley.edu ...!ucbvax!cory!atn
974 Tulare Avenue, Albany CA 94707-2540 37'52N/122'15W +1 415 526 1818

K. Khan

unread,
Jan 14, 1992, 11:33:04 AM1/14/92
to

Summary of information on the SR&D MCR-175-1R-0803 mag stripe card
reader. Due to the large volume of summary requests I received, I am
posting this summary instead of mailing it. It's somewhat long, so hit
'n' now if you're not interested in this stuff.


[Editor's Note: The following is a concatenation of the replies I received
to a net.request about my mag stripe card reader. After the replies 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. Note also that there was another summary
post in recent days with information on how the data on the cards is
encoded. See article <kms26o...@network.ucsd.edu> for this info.

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 tm...@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 tm...@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 ===

Bobby Newmark

unread,
Jan 17, 1992, 12:02:32 PM1/17/92
to
I wrote an article that was published in Informatik magazine issue
#2...you can grab it on eff.org.....I researched it for a long
time...pretty much covers everything about Magstripe encoding and
such...I include data scanned from a number of 'popular'
cards...credit cards, ATM cards, etc....check it out and lemme know
if you have comments...
0 new messages