## Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z

# alt.2600 FAQ Revision .014 (4/4)

( Part1 - Part2 - Part3 - Part4 )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Houses ]
Archive-Name: alt-2600/faq/part4
Posting-Frequency: Random
Last-Modified: 2000/05/29
Version: .014

`View all headers`
```TDT     The Dream Team
THG     The Humble Guys
THP     The Hill People
TRSI    Tristar Red Sector Inc.
UUDW    Union of United Death Workers

---------------------------------------------------------------------------

G-02. How do I determine if I have a valid credit card number?
[Note from Markus McKenna: "I tried the credit card algorithm on one of
my credit card numbers... it's out of date." H.]

Credit cards use the Luhn Check Digit Algorithm.  The main purpose of
this algorithm is to catch data entry errors, but it does double duty
here as a weak security tool.

For a card with an even number of digits, double every odd numbered
digit (1st digit, 3rd digit, 5th digit, etc...) and subtract 9 if the
product is greater than 9.  Add up all the even digits (2nd digit, 4th
digit, 6th digit, etc...) as well as the doubled-odd digits, and the
result must be a multiple of 10 or it's not a valid card.  If the card
has an odd number of digits, perform the same addition doubling the even

[Note from Dan Mellem: This really needs an example; it reads like all
the odds should be handled first. E.g.:
* *  * *  * *  * *
1234 9876 0000 0008
2264 9856 0000 0008; sum = 50 H.]

This program, presented in C source code form, will perform this math
for you. Feed it all but the last digit of your credit card number, and
it will give you the last digit.  If it gives you a last digit different
from the one you have, you have an invalid credit card number.

#include        <stdio.h>

/*
* Return last digit of a bank card (e.g. credit card)
* Receives all the digits, but the last one as input
* By Diomidis Spinellis <dds@doc.ic.ac.uk>
*/
int bank (u)
char *u;
{
register i, s = 0;
int l, t;

l = strlen(u);
for(i = 0; i < l ; i++)
{
t = (u[l - i - 1] - '0') * (1 + ((i + 1) % 2));
s += t < 10 ? t : t - 9;
}
return 10 - s % 10;
}

void main (argc, argv)
int  argc;
char **argv;
{
while (--argc)
printf ("%d\n", bank (*++argv));
}

---------------------------------------------------------------------------

G-03. What is the layout of data on magnetic stripe cards?

This FAQ answer was written largely with information supplied by
wea\$el:

Data is laid out on a standard magnetic car in three tracks.  A card may
have any of these tracks, or a combination of these tracks.

Track 1 was the first track standardized.  It was developed by the
International Air Transportation Association (IATA) and is still
reserved for their use.  It is 210bpi with room for 79 7-bit characters.

Track 1 is encoded with a 7-bit scheme (6 data bits plus one parity bit)
that's based on ASCII.  If your reader does not perform the ASCII
conversion, all you have to do is add 0x20 to each byte to turn it into
ASCII (there are no "control" characters). The seventh bit is an odd
parity bit at the end of each byte.

Track 1 Fields

.-----------------------------------------------------------------------.
| Start sentinel  |  1 byte (the % character)
|
|                 |
|
| Format code     |  1 byte alpha (The standard for financial
|
|                 |  institutions specifies format code is "B")
|
|                 |
|
| Primary Account |  Up to 19 characters.  American Express inserts]
|
| number          |  space characters in here in the same places the
|
|                 |  digits are broken up on the face of your card.
|
|                 |
|
| Separator       |  1 byte (the ^ character)
|
|                 |
|
| Country code    |  3 bytes, if used.  (The United States is 840)
|
|                 |  This is only used if the account number begins
|
|                 |  with "59."
|
|                 |
|
| Surname         |
|
|                 |
|
| Surname         |  (the / character)
|
| separator       |
|
|                 |
|
| First name      |
|
| or initial      |
|
|                 |
|
| Space           |  (when followed by more data)
|
|                 |
|
| Middle name     |
|
| or initial      |
|
|                 |
|
| Period          |  (when followed by a title)
|
|                 |
|
| Title           |  (when used)
|
|                 |
|
| Separator       |  1 byte (^)
|
|                 |
|
| Expiration date |  4 bytes (YYMM) or the one byte separator if a
|
| or separator    |  non-expiring card.
|
|                 |
|
| Discretionary   |  Optional data can be encoded here by the issuer.
|
| data            |
|
|                 |
|
| End Sentinel    |  1 byte (the ? character)
|
|                 |
|
| Longitudinal    |  1 byte.  The LRC is made up of parity bits for
|
| Redundancy      |  each "row" of bytes, making the total even. That
|
| Check (LRC)     |  means that the total of all the bit 1s of each
|
|                 |  byte has to come out to an even number.  Same for
|
|                 |  bit 2, etc.  The LRC's parity bit is not the sum
|
|                 |  of the parity bits of the message, but only the
|
|                 |  parity bit for the LRC character itself.  (It's
|
|                 |  odd, just like any other single byte's parity
|
|                 |  bit.)
|
`-----------------------------------------------------------------------'

Track 2 was developed by the American Bankers Association (ABA) for
on-line financial transactions.  It is 75bpi with room for 40 5-bit
numeric characters.

Track 2 is encoded with a 5-bit scheme (4 data bits plus one parity
bit.)  To convert this data into ASCII, add 0x30 to each byte.

Track 1 Fields

.-----------------------------------------------------------------------.
| Start sentinel  |  1 byte (0x0B, or a ; in ASCII)
|
|                 |
|
| Primary Account |  Up to 19 bytes
|
| number          |
|
|                 |
|
| Separator       |  1 byte (0x0D, or an = in ASCII)
|
|                 |
|
| Country code    |  3 bytes, if used.  (The United States is 840)
|
|                 |  This is only used if the account number begins
|
|                 |  with "59."
|
|                 |
|
| Expiration date |  4 bytes (YYMM) or the one byte separator if a
|
| or separator    |  non-expiring card
|
|                 |
|
| Discretionary   |  Optional data can be encoded here by the issuer.
|
| data            |
|
|                 |
|
| End Sentinel    |  1 byte (0x0F, or a ? in ASCII)
|
|                 |
|
| Longitudinal    |  1 byte.
|
| Redundancy      |
|
| Check (LRC)     |
|
`-----------------------------------------------------------------------'

Track 3 is also used for financial transactions.  The difference is its
read/write ability.  It is 210bpi with room for 107 numeric digits.
Track 3 is used to store the enciphered PIN, country code, currency
units, amount authorized, subsidiary account information, and other
account restrictions.

Track 3 has the same properties as track 1 (start and end sentinels and
an LRC byte), except that there is no standard for the data content or
format.  Track 3 is not currently used by any national bank card issuer.

In those rare systems where the PIN is stored on the card, this is the
track where it is stored.

This document is available from the American Bankers Association.

Other standards documents covering related topics include:

ANSI X3.92  Data Encryption Algorithm (DEA)
ANSI X3.106 Modems of DEA Operation
ANSI X4.16  American National Standard for financial services, financial
transaction cards, magnetic stripe encoding
ANSI X9.8   Personal Identification Number (PIN) Management and Security
ANSI X9.19  Financial Institution Retail Message Authentication (MAC)
ISO 7810
ISO 7811
ISO 7812
ISO 8583    Bank card originated messages
Interchange message specifications
Content for financial transactions.
ISO 8731-1  Banking: Approved algorithms for message authentication
Part 1 - DEA
Part 2 - Message Authentication algorithms
ISO 7816    Identification cards, Integrated circuit(s) with contacts
Part 1 - Physical Characteristics
Part 2 - Dimensions and locations of the contacts
Part 3 - Electronic signals and transmission protocols

---------------------------------------------------------------------------

Pirate radio is broadcasting outside of the rules laid down by the
Federal Communications Commission (FCC).  Pirate radio usually occurs on
the FM band because that is where the most receivers are.

Under Part 15 of the FCC rules, you can legally broadcast on the FM band
if you broadcast using less that 100 milliwatts of output power and and
antenna less than 3' long.  By contrast, commercial FM broadcasters are
required to broadcast using at least 100 watts of output power.  100
milliwatts will give your signal an effective range of less than one
mile.

You can build the gear needed to transmit pirate radio or you can buy
much of what you need from Radio Free Berkeley.  An entire broadcasting
system can be put together for well under \$1,000.

---------------------------------------------------------------------------

G-05. What are the ethics of hacking?

An excerpt from: Hackers: Heroes of the Computer Revolution
by Steven Levy

something about the way the world works -- should be unlimited
and total. Always yield to the Hands-On imperative.

All information should be free.

Mistrust Authority.  Promote Decentralization.

Hackers should be judged by their hacking, not bogus criteria
such as degrees, age, race, or position.

You can create art and beauty on a computer.

Computers can change your life for the better.

---------------------------------------------------------------------------

G-06. Why did you write this FAQ?

Hacking is an interest of mine.  Years ago, I would often communicate on
IRC with other people who were also interested in hacking and we would
discuss the topics covered in this FAQ.

Over time, I grew tired of having the same discussions again and again.
I wrote down these questions and answers with the hope that I would
never again have to explain the basics of hacking and that our
conversation would move on to more advanced and interesting topics.

In the beginning, this was the #hack FAQ.  Later, Tomes suggested that
we adopt it as the alt.2600 FAQ also.

I have enjoyed writing this FAQ, and I hope you enjoy it also.

---------------------------------------------------------------------------

G-07. Where can I get a copy of the alt.2600/#hack FAQ?

Get it on FTP at:
rtfm.mit.edu            /pub/usenet-by-group/alt.2600
ftp.primenet.com        /users/c/cracked/hacking/2600faq.zip

Get it on the World Wide Web at:

http://www-personal.engin.umich.edu/~jgotts/underground/hack-faq
http://www-personal.engin.umich.edu/~jgotts/underground/hack-faq.tar.gz
[and the HTMLised, bookmarked version on the alt.2600 Web site at
http://www.jssquires.freeserve.co.uk and
http://www.fictitious.net/alt2600. H.]

EOT
```

## User Contributions:

Part1 - Part2 - Part3 - Part4

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer: