Track 2 data chip card

Track 2 data chip card DEFAULT

How to Decode Magstripe Data

Until recently, reading credit card data was as easy as swiping a card through a reader (such as one of the many readers made by ID TECH) and having a virtual-terminal app (or other apps) slurp up the track data as it comes straight out of the reader. The data in question would simply show up as keystrokes on a screen, unencrypted.

Those were the days!

Suffice it to say, things have changed. Today, magstripe readers generally output encrypted data, over USB (often in HID mode, rather than keyboard mode), and most card readers today have to handle chip cards in addition to magnetic-stripe cards. Chip card data takes the form of TLVs (tags, length, values) and can look quite a bit different from the “plain old magstripe data” of years past. Also, it’s invariably encrypted.

In recent posts, I showed how to decrypt credit card data using industry-standard TDES and AES decryption algorithms in conjunction with industry-standard (ANSI X9.24) DUKPT key derivation techniques, but we didn’t talk about how to obtain decoded magstripe data in the first place. What does “credit card magstripe data” look like now? How can you obtain it and decode it? How do you know which parts are encrypted?

Today, card readers generally output encrypted data, over USB (often in HID mode, rather than keyboard mode), and most card readers today have to handle chip cards in addition to magnetic-stripe cards.

The answer to the first question (what does magstripe data look like?) varies a lot, depending not only on the make and model of the card-reading equipment you’re using but on whether the transaction in question was done via mag swipe, dip (contact EMV), or contactless/NFC interaction. In general, you’re doing a lot more than just reading raw track data. You’re also obtaining a KSN (Key Serial Number), which is needed for decryption, and harvesting various kinds of metadata pertaining to the transaction. It’s true, you might only be interested in obtaining (say) raw Track 2 data, but in the process of obtaining it, you’re going to have to deal with lots of other data, too.

Let’s take a quick look at a real-world example using a Starbucks gift card given to me by a guilt-ridden barista as a makegood after unexpectedly running out of Mesopotamian Kumquat-Absinthe Latte. If we swipe the Starbucks card through ID TECH’s Augusta card reader operating in keyboard mode, with Notepad window open (and the cursor in the text window), we get the following data in Notepad:

 

 

This is a lot more than “raw track data.” You can recognize the masked track data (which begins with B% and contains many asterisks, finally ending in ?*), but that conceals the Primary Account Number (PAN), which is actually encrypted. Most of what you’re seeing here is a hexadecimal representation of the binary data coming out of the reader.

Parsing this big block of stuff is easy if you know-how. The fastest way to decode it is to run the data through ID TECH’s free Parsomatic tool, which is an HTML form that can render all the pieces of data in an intelligible fashion.

Every card reader has its own proprietary way of representing card data. ID TECH represents magstripe data in a format known as Enhanced Encrypted MSR format. The format includes 26 fields of data; all 26 fields are described in detail in document P/N 80000502-001, ID TECH Encrypted Data Output.

To give you an idea of what’s on the card, let’s consider the first 5 bytes of data (02 ED 01 80 1F). According to Parsomatic, these 5 bytes contain the following information:

STX02
LENGTHED 01
Card Encode Type80
Track Status (1F)0------- 0 Reserved for future use -0------ 1: Field 10 optional bytes length exists (0: No Field 10) --0----- 1: Track 3 sampling data exists (0: Track 3 sampling data does not exist)

 

The first byte (02) is simply STX, the “start” byte. The next two bytes (ED 01) represent the length, in hex, of the overall data payload (little-endian: ED 01 actually means 0x01ED or 493 bytes of data). The Card Encode type is 0x80, which (in English) means our reader considers this is a financial card. Track Status (value: 0x1F) is a status byte containing eight-bit flags, to let you know which tracks were present on the magnetic stripe (there can be up to 3) and which ones were read successfully. In this case, all 3 physical tracks were read successfully, but data exists only on tracks 1 and 2.

Let’s quickly look at the next 5 bytes. According to Parsomatic, those bytes, and their meanings are as follows:

Track 1 Length4C
Track 2 Length28
Track 3 Length00
Clear/Mask Data Sent Status (83)-0------ Bit 6: 1 PIN Encryption Key; 0 Data Encryption Key --0----- Bit 5: 1 Chip present on card. (First byte of service code was '2' or '6'.) Use EMV transaction if possible. ---0---- Bit 4: 0 TDES; 1 AES ----0--- Bit 3: 1 if fixed key; 0 DUKPT Key Management -----0-- Bit 2: 1 if Track3 clear/mask data present
Encrypted/Hash Data Sent Status (9B)-0------ Bit 6: if 1, session ID present --0----- Bit 5: if 1, track3 hash data (SHA digest) present -----0-- Bit 2: if 1, track3 encrypted data present

On a financial card, Track 1 can be up to 79 bytes long; Track 2 can be up to 40 bytes long; Track 3 can be up to 107 bytes. In this case, we’ve got 76 bytes (hex 0x4C) of data for Track 1 and 40 bytes (0x28) of data for Track 2. (Track 3 had zero bytes.) These lengths are important to know, not only for parsing out the masked track data but for determining the lengths of the encrypted versions of the tracks. The encrypted length is different than the actual native track length because track data must be padded to a final length that’s a multiple of 8 for TDES encryption, or a multiple of 16 for AES.

How do we know if the data is TDES-encrypted versus AES-encrypted? That information is in bit 4 of the Clear/Mask Data Sent Status byte (as shown above). There’s also an Encrypted/Hash Data Sent status byte (shown above) to let you know whether encrypted track data (and validation hashes) are present and whether a KSN exists.

Now we get to Track 1 and Track 2 masked data, followed by the encrypted versions of those, followed by some hash data (in this case, all zeros), and some other data (described below). Note that Parsomatic has converted the ASCII track data to a hex representation below:

Track1 Data25 2A 36 30 31 30 2A 2A 2A 2A 2A 2A 2A 2A 38 37 36 35 5E 30 32 35 34 2F 53 45 52 56 49 43 45 52 45 43 4F 56 45 52 59 55 53 44 5E 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 3F 2A
Track2 Data3B 36 30 31 30 2A 2A 2A 2A 2A 2A 2A 2A 38 37 36 35 3D 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 3F 2A
Track1 Encrypted Data95 02 5C 86 98 7E 4F 7D D0 7D 58 73 0E B7 9F DF B9 0A B7 F2 3E 6E CA 6F 4F 04 A6 7B F5 11 EE 13 F9 50 90 3B DE 77 62 46 80 C4 60 E9 C3 6C 4F 91 36 25 6B B9 3A 38 CB 98 F9 56 26 DC FA F9 33 5C E0 A2 13 07 4C C1 CD 84 CC 91 13 98 E0 67 56 C4   Decrypt this data
Track2 Encrypted Data64 AB 03 6B 69 42 28 AD A7 EC 01 8F 49 5A 01 3A F8 A0 4C 97 62 88 FE 2F 80 27 1E 6E 53 D9 87 DE 19 AC A2 70 7B FF 2C 78   Decrypt this data
Track 1 Hashed00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Track 2 Hashed00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Reader Serial Number36 31 33 54 35 33 35 36 31 38
KSN62 99 49 00 75 00 02 A0 03 08
LRC10
Checksum8E
ETX03

 

Notice that Parsomatic inserts a “Decrypt this data” link next to encrypted data (see above). If you click the link, it takes you to ID TECH’s Encrypt/Decrypt Tool, where the data in question can be viewed in decrypted form.

The final fields of data include the Reader Serial Number, the Key Serial Number (KSN), an LRC, a checksum, and ETX (end of transmission). The LRC is simply a byte value representing the XOR (exclusive OR) of all payload data bytes, while the checksum is a one-byte arithmetic sum (neglecting overflow, obviously) of all bytes in the payload. The LRC and checksum can be used to check the integrity of the data payload. (They’re somewhat easier and quicker to calculate than a proper CRC.)

Conclusion

So as you can see, there’s a lot more to a magstripe data than “track data.” We haven’t even touched on the significance of some of the data fields (maybe we can go there in a future post). Nor have we said anything about EMV data (which is definitely going to take another post). But this should get you started if you’re trying to decode data coming out of an ID TECH credit card reader.

For more information, be sure (as I said earlier) to consult our technical documentation on the Enhanced Encrypted MSR data format: ID TECH Encrypted Data Output. OR click the link below to take the first step towards streamlined payments!

 

Sours: https://idtechproducts.com/technical-post/how-to-decode-magstripe-data/

ISO/IEC 7813

International standard for cash cards and credit cards

ISO/IEC 7813 is an international standard codified by the International Organization for Standardization and International Electrotechnical Commission that defines properties of financial transaction cards, such as ATM or credit cards.[1]

Scope[edit]

The standard defines:[citation needed]

  • physical characteristics, such as size, shape, location of magnetic stripe, etc.
  • magnetic track data structures

Physical characteristics[edit]

ISO/IEC 7813 specifies the following physical characteristics of the card, mostly by reference to other standards:[citation needed]

Embossed characters
by reference to ISO/IEC 7811
Embossing of expiration date
the format (MM/YY or MM-YY)
Magnetic stripe
by reference to ISO/IEC 7811
Integrated circuit with contacts
by reference to ISO/IEC 7816-1
Integrated circuit without contacts
by reference to ISO/IEC 10536-1, ISO/IEC 14443-1, and ISO/IEC 15693-1

Magnetic tracks[edit]

Track 1[edit]

The Track 1 structure is specified as:[citation needed]

  • STX : Start sentinel "%"
  • FC : Format code "B" (The format described here. Format "A" is reserved for proprietary use.)
  • PAN : Payment card number 4400664987366029, up to 19 digits
  • FS : Separator "^"
  • NM : Name, 2 to 26 characters (including separators, where appropriate, between surname, first name etc.)
  • FS : Separator "^"
  • ED : Expiration data, 4 digits or "^"
  • SC : Service code, 3 digits or "^"
  • DD : Discretionary data, balance of characters
  • ETX : End sentinel "?"
  • LRC : Longitudinal redundancy check, calculated according to ISO/IEC 7811-2

The maximum record length is 79 alphanumeric characters.

Examples[edit]

Track 2[edit]

The Track 2 structure is specified as:[citation needed]

  • STX : Start sentinel ";"
  • PAN : Primary Account Number, up to 19 digits, as defined in ISO/IEC 7812-1
  • FS : Separator "="
  • ED : Expiration date, YYMM or "=" if not present
  • SC : Service code, 3 digits or "=" if not present
  • DD : Discretionary data, balance of available digits
  • ETX : End sentinel "?"
  • LRC : Longitudinal redundancy check, calculated according to ISO/IEC 7811-2

The maximum record length is 40 numeric digits (e.g., 5095700000000).[citation needed]

Track 3[edit]

Track 3 is virtually unused by the major worldwide networks and often isn't even physically present on the card by virtue of a narrower magnetic stripe.[citation needed]

A notable exception to this is Germany, where Track 3 content was used nationally as the primary source of authorization and clearing information for debit card processing prior to the adoption of the "SECCOS" ICC standards. Track 3 is standardized nationally to contain both the cardholder's bank account number and branch sort code (BLZ).[citation needed]

Programming[edit]

Parsing Track 1 and Track 2 can be done with Regular Expressions.

Track 1[edit]

This Regex will capture all of the important fields into the following groups:[citation needed]

  • Group 1: Payment card number (PAN)
  • Group 2: Name (NM)
  • Group 3: Expiration Date (ED)
  • Group 4: Service Code (SC)
  • Group 5: Discretionary data (DD)

Track 2[edit]

  • Group 1: Primary Account Number (PAN)
  • Group 2: Expiration date (ED)
  • Group 3: Service code (SC)
  • Group 4: Discretionary data (DD)

References[edit]

External links[edit]

Implementations[edit]

Sours: https://en.wikipedia.org/wiki/ISO/IEC_7813
  1. 2008 chevy silverado black rims
  2. Series 27 exam pass rate
  3. Gta v online player count
  4. Thank you card template photoshop
  5. Fatty acid synthase: structure

Format: LLVARans..37

Description: There are two track 2 data formats, ANSI X4.16 and ISO Standard 7813.

ANSI Standard Track 2 Data

The table below shows the ANSI X4.16 Track 2 layout:

Field Name

Length

Value

Start Sentinel

1

;

Card Number

up to 19

0 – 9

Field Separator

1

=

Expiration Date

4

YYMM

Effective Date

4

YYMM

Security Code

5

Authentication Code

End Sentinel

1

?

LRC Character

1

LRC Character

Note: The stop and start sentinels, and LRC are not sent with the Track 2 contents.

ISO 7813 Standard Track 2 Data

The table below shows the ISO 7813 Track 2 layout:

Field Name

Length

Value

Start Sentinel

1

;

Card Number

up to 19

0 – 9

Field Separator

1

=

Expiration Date

4

YYMM

Interchange Designator

1

Value

Description

1

Available for international interchange

2

Alternative technology (e.g. ICC) available on card

5

Available for interchange only in country of issue

7

Not available for general interchange

9

System test card

Service Code

2

Value

Description

01

No restrictions

02

No ATM service

03

ATM service only

10

No cash advance

11

No cash advance or ATM service

20

Requires positive authorisation by issuer or issuer's agent

Effective Date

4

YYMM

Security Code

5

Authentication Code

Zeros

3

000

Language Code

2

Undetermined

End Sentinel

1

?

LRC Character

1

LRC Character

Note: The stop and start sentinels and LRC are not sent with the Track 2 contents.

ICC Track 2 Equivalent Data

ICC cards can optionally contain a data element (Track 2 Equivalent Data) within the chip. This data element is identified as Tag 57 defined both by the EMV and American Express ICC Payment Specifications. It contains an image of the Track 2 Data present on the magnetic stripe of the card. See the tables above for a definition.

Note: That the start and end sentinels, and LRC that are present on the magnetic stripe are not present in the Track 2 Equivalent Data.

Sours: https://developer-eu.elavon.com/docs/eisop/field-descriptions/field-35-track-2
🚨 August 2021 EMV X2 TUTORIAL

Credit - Debit cards Track1 - Track2 generator

Generate Cards Track1 and Track2 by entering the information below.

To generate a dummy card number and some values, just enter the first digits of a card number, like your own. The generator will generate a new card number



Something not working or you have a suggestion to make this tool more useful? Give us a shout Please: Write to us

How Track1 and Track2 generation works

Track2 format Visa example

4000340099900505=2225111123400001230

Track2 information is loaded in the ISO8583 message in Field 35, and is made in the following format:
card number,
character "=",
card expiry date on 4 characters,
service Code on 3 characters,
Pin Verification Value on 4 characters,
Card Verification Value on 3 characters (iCvv for CHIP)
trailing "0"

Track2 format MasterCard example

5400340099900505=2225111123400001230

Track2 information is loaded in the ISO8583 message in Field 35, and is made in the following format:
optional character ";"
card number,
character "=",
card expiry date on 4 characters,
service code on 3 characters,
Discretionary Data
optional trailing "?"

Track1 format Visa example

B4000340099900505^John/Doe ^22251110000123000

Track1 information is loaded in the ISO8583 message in Field 45, and is made in the following format:
character "B",
card number,
character "^",
card name,
character "^",
card expiry date on 4 characters,
service Code on 3 characters,
characters "0000"
Card Verification Value on 3 characters (iCvv for CHIP)
trailing "000"

Track1 format MasterCard example

B4000340099900505^John/Doe ^22251110000123000

Track1 information is loaded in the ISO8583 message in Field 45, and is made in the following format:
character "B",
card number,
character "^",
card name,
character "^",
card expiry date on 4 characters,
service Code on 3 characters,
characters "0000"
Card Verification Value on 3 characters (iCvv for CHIP)
trailing "000"

Card number

First Step is to calculate the card number based on an in initial value or a prefix or BIN. If you just press the "Generate Cards" button, an initial card number is set by default. This is "4000340000000500", which is an invalid Card Number.

To make calculate a correct card number, we call a function that takes the first 15 characters of this card number, so without the last digit. This last digit is being calculated with Luhn algorythm. That is why it is called the Luhn Digit. The algorythm makes the Luhn check of the first 15 digits and appends the calculated digit, so the correct card number is 4000340000000504

Track1 is not really used anymore, but Track2 is always used and it is printed on the magnetic stripe of the back of the card, just like recording with a casette player recorder.

Are you ready to start or need help?


Ready to start your next project with us? Give us a call or send us an email and we will get back to you as soon as possible!

  Company   Contact

Payments Solutions. Made Simple


Cloud based payments products and services


Simple ISO8483 conversion to JSON, SQL, TLV, SWIFT or any custom format


Integration with Base24, Alaric, Postilion, Way4 and other payment systems.


 

Slack or Skype

 

       



Amsterdam Training Center
Hoogoorddreef 9, 1101 BA Amsterdam
Almere, Netherlands

Copyright © 2012 neaPay. neaPay Brand, web site data and content, products, training and material are all reserved, under ownership. All Rights Reserved. Content cannot be reproduced without written accord from neaPay.

Sours: https://neapay.com/online-tools/card-track1-track2-generator.html

Card data track 2 chip

Magnetic stripe card

Card which stores data on a stripe of magnetic material

An example of the reverse side of a typical credit card: Green circle #1 labels the magnetic stripe.
Visualization of magnetically stored information on a magnetic stripe card (recorded with CMOS-MagView, dark colors correspond to magnetic north, light colors correspond to magnetic south)

A magnetic stripe card is a type of card capable of storing data by modifying the magnetism of tiny iron-based magnetic particles on a band of magnetic material on the card. The magnetic stripe, sometimes called swipe card or magstripe, is read by swiping past a magnetic reading head. Magnetic stripe cards are commonly used in credit cards, identity cards, and transportation tickets. They may also contain an RFID tag, a transponder device and/or a microchip mostly used for business premises access control or electronic payment.

Magnetic recording on steel tape and wire was invented by Valdemar Poulsen in Denmark around 1900 for recording audio.[1] In the 1950s, magnetic recording of digital computer data on plastic tape coated with iron oxide was invented. In 1960, IBM used the magnetic tape idea to develop a reliable way of securing magnetic stripes to plastic cards,[2] under a contract with the US government for a security system. A number of International Organization for Standardization standards, ISO/IEC 7810, ISO/IEC 7811, ISO/IEC 7812, ISO/IEC 7813, ISO 8583, and ISO/IEC 4909, now define the physical properties of the card, including size, flexibility, location of the magstripe, magnetic characteristics, and data formats. They also provide the standards for financial cards, including the allocation of card number ranges to different card issuing institutions.

History[edit]

The first prototype of magnetic stripe card created by IBM in the late 1960s. A stripe of cellophane magnetic tape is fixed to a piece of cardboard with clear adhesive tape

Magnetic storage was known from World War II and computer data storage in the 1950s.[2]

In 1969 Forrest Parry, an IBM engineer, had the idea of securing a piece of magnetic tape, the predominant storage medium at the time, to a plastic card base. He became frustrated because every adhesive he tried produced unacceptable results. The tape strip either warped or its characteristics were affected by the adhesive, rendering the tape strip unusable. After a frustrating day in the laboratory, trying to get the right adhesive, he came home with several pieces of magnetic tape and several plastic cards. As he walked in the door at home, his wife Dorothea was ironing clothing. When he explained the source of his frustration: inability to get the tape to "stick" to the plastic in a way that would work, she suggested that he use the iron to melt the stripe on. He tried it and it worked.[3][4] The heat of the iron was just high enough to bond the tape to the card.

First magnetic striped plastic credit and badge access cards[edit]

Front side of the first magnetic stripe plastic credit card. Note that the narrow magnetic stripe is on the front of the card. It was later switched to the back side.
Back side of the first magnetic stripe plastic credit card
Back of early magnetic striped encoded paper card. The narrow magnetic stripe in the center of the card was applied using a magnetic slurry paint.

The major development of the magnetic striped plastic card began in 1969 at the IBM Information Records Division (IRD) headquartered in Dayton N.J. In 1970, the marketing organization was transferred by IBM DPD back to the Information Records Division in order to begin sales and marketing strategies for the magnetically striped and encoded cards being developed.[5] It took almost two years for IBM IRD engineers to not only develop the process for reliably applying the magnetic stripe to plastic cards via a hot stamping method, but also develop the process for encoding the magnetic stripe utilizing the IBM Delta Distance C Optical Bar Code format.[6][7] This engineering effort resulted in IBM IRD producing the first magnetic striped plastic credit and ID cards used by banks, insurance companies, hospitals and many others. Another result of this project was that IBM IRD and IBM Data Processing Division announced on February 24, 1971 the first Magnetic Credit Card Service Center and the IBM 2730-1 Transaction Validation Terminal.[5] Arthur E. Hahn Jr.[8] was hired by IBM IRD in Dayton, N.J. on Aug 12, 1969 to head up this engineering effort. Other members of the group were David Morgan (Manager), Billy House (Software Developer), William Creeden (Programmer), and E. J. Gillen (Mechanical Engineering/Machining).[citation needed] They were given a recently announced IBM 360 Model 30 computer with 50k of RAM for control of the encoding/embossing of the Magnetic Stripe Cards.[9] The IBM 360 computer was for scientific/business applications so the IRD engineers first had to convert the 360 into a "process control computer" and then develop software and hardware around it. Due to the limited RAM, the software was developed in 360 Assembler Language. This conversion enabled the 360 computer to monitor and control the entire production process the IRD engineers designed and built. The engineering design/build effort was carried out in a raised floor secured area of IBM IRD in Dayton, N.J. which was built specifically for the project. This tightly secured area with limited access was required because of the sensitivity of the data that would ultimately be used to encode and emboss the credit and ID cards.

Bar code encoding developments[edit]

The IRD engineers first had to develop a reliable process of hot stamping the magnetic stripe to the plastic cards. This was necessary in order to meet the close tolerances required to reliably encode and read the data on the Magnetic Stripe Cards by magnetic write/read heads. The magnetic stripe was encoded with a single track of data utilizing the IBM Delta Distance C Optical Bar Code format.[6][7] The Delta Distance C Optical Bar Code was developed by the IBM Systems Development Division working at Research Triangle Park in Raleigh North Carolina headed up by George J. Laurer. Other members of the group were N. Joseph Woodland, Paul McEnroe, Dr. Robert Evans, Bernard Silver, Art Hamburgen, Heard Baumeister and Bill Crouse.[6] The IBM group in Raleigh was competing with RCA, Litton-Zellweger and other companies who were working with the National Retail Merchants Association NRMA to develop a standard optical bar code to be used in the retail industry. NRMA wanted an optically readable code that could be printed on products allowing purchasers to rapidly "check out" at the new electronic cash register/checkout counters being developed. The code would also be used for production and inventory control of products. Of the many optical bar codes submitted to NRMA by IBM and other companies, NRMA finally selected the later version of the IBM bar code known as the Delta Distance D Optical Bar Code format. The Delta Distance C Code was an earlier version of the Universal Product Code (UPC). The UPC code was selected in 1973 by NRMA as their standard and has become the World Wide Standard that we all know today as the UPC Uniform Product Code.[10]

Up until 1982 systems using magnetic cards for access control were called “Card Wipe “Systems. The continuous use of the mag strip made them unreliable. In 1983 a UK company Mirocache Ltd, run by ex retailer Norman Guiver, replaced the mag strip with a Type 39 dot matrix printed bar code for use in access control and as a membership card, and coined the name Swipe Card. The barcode proved very reliable and has been the standard format for Swipe cards ever since, for high use applications.

Production[edit]

In 1971, after the IBM IRD engineers completed the development and building phase of the project they began in 1969, they released the equipment to the IRD manufacturing group in Dayton N.J. to begin producing the plastic magnetic striped credit and ID cards. Because of the sensitivity of the customer data and the security requirements of banks, insurance companies and others, the manufacturing group decided to leave the entire line in the secured area where it was developed.

Banks, insurance companies, hospitals etc., supplied IBM IRD with "raw plastic cards" preprinted with their logos, contact information etc. They also supplied the data information which was to be encoded and embossed on the cards. This data was supplied to IRD on large 0.5 inch wide, 10.5 inch diameter IBM Magnetic Tape Reels which was the standard for computers at that time.[9] The manufacturing process started by first applying the magnetic stripe to the preprinted plastic cards via the hot stamping process developed by the IBM IRD engineers. This operation of applying the magnetic stripe to the plastic cards was done off line in another area of IBM IRD and not in the secured area. The cards were then brought into the secured area and placed in "hoppers" at the beginning of the production line. The tape reels containing the data were then installed on the modified IBM 360 computer prior to beginning the encoding, embossing and verification of the cards. After the 360 performed a check to verify that all systems and stations were loaded and ready to go, the computer began feeding the Magnetic Striped Plastic Cards from the hoppers at the front end of the production line down a motorized track. The entire operation was fully automated and controlled by the modified IBM 360 business computer. The line consisted of the following stations and operations:

  1. Plastic card feeder station: The cards were fed down a track in single file from card hoppers.
  2. Magnetic write/read encoding station: The IBM 360 computer sent over the data which was encoded on the magnetic stripe utilizing the IBM Delta Distance C Optical Bar Code format. The card passed under the read head and the encoded data was sent back to the 360 for verification.
  3. An embossing station: The IRD engineers purchased and modified a Data Card Corp embossing machine and interfaced it with the IBM 360 computer to emboss the cards.[9] The original design concept called for an Addressograph-Multigraph embossing machine, however, the IRD engineers quickly switched to a Data Card Corp embossing machine. Data Card Corp, a Minneapolis/St. Paul company, had just developed the first electronically controlled embossing machine for plastic cards and effectively obsoleted all other mechanical operated embossers.
  4. A topping station: To highlight the embossing.
  5. An imprinter station: To imprint the embossing on an automatically fed paper roll.
  6. An optical reader station: To read the embossed information off the paper roll and feed it back to the 360 computer for verification.
  7. A one card rejection station: If either the encoding or embossing data on the card was not verified by the 360 computer, that one card was rejected. If both the encoded and embossed data was confirmed by the 360 computer, the card proceeded down the line.
  8. A mailer station: A mailer was printed with the name and address of the card holder along with the date and other relevant card information. These mailers were also preprinted and die cut by IRD according to the customers specs and logo requirements and were fed into the line out of boxes in a continuous fan feed method.
  9. A card insertion station: Here the card was automatically inserted onto the mailer.
  10. A bursting and folding station: Here the mailers were burst apart and then folded into a 3 fold packet that would fit into a business size envelope.
  11. An envelope printer/insertion station: Here an envelope was printed with the name and address of the customer and the mailer containing the card was automatically inserted into the envelope and sealed.

This completed the manufacturing line for the magnetic striped encoded and embossed plastic credit and badge access cards. The envelopes were then taken to be posted and mailed directly to the customers of the companies who had ordered the cards from IRD.

What this small engineering group at IBM IRD and the IBM Bar Code development group in Raleigh accomplished in developing the first magnetic stripe credit and ID cards cannot be overstated. They laid the foundation for the entire magnetic stripe card industry that we know and use today through our use of credit cards, ATM cards, ID cards, hotel room and access cards, transportation tickets, and all the terminals and card readers that read the cards and enter the data into computers. Their developments resulted in every person having the ability to easily carry a card that connects them directly to computers with all the ramifications thereof.

Neither IBM nor anyone else applied for or received any patents pertaining to the magnetic stripe card, the delta-distance barcodes or even the Uniform Product Code (UPC). IBM felt that with an open architecture, it would enhance the growth of the media thereby resulting in more IBM computers and associated hardware being sold. As with all new technologies, the magnetic stripe card developed and produced by IBM IRD with one track of encoded data using the Delta Distance C Bar Code format was quickly obsolete. Because of the electronic ATM/reservation/check out/and access systems that were rapidly developing, the banks, airlines and other industries required more encoded data. A wider magnetic stripe enabling multiple tracks of encoding along with new encoding standards was required.

The first US Patents for the ATM were granted in 1972[11] and 1973.[12]

Other groups within IBM and other companies continued on with expanding the work done by this small group of engineers at IBM IRD, however, the contributions that these IBM IRD engineers made to the development of the magnetic stripe card is analogous to the Wright Brothers' contribution to the airline industry of today.

Further developments and encoding standards[edit]

There were a number of steps required to convert the magnetic striped media into an industry acceptable device. These steps included:

Example of a card from the late 1980s used in food vending machines in the UK
  1. Creating the international standards for stripe record content, including which information, in what format, and using which defining codes.
  2. Field testing the proposed device and standards for market acceptance.
  3. Developing the manufacturing steps needed to mass-produce the large number of cards required.
  4. Adding stripe issue and acceptance capabilities to available equipment.

These steps were initially managed by Jerome Svigals of the Advanced Systems Division of IBM, Los Gatos, California from 1966 to 1975.

In most magnetic stripe cards, the magnetic stripe is contained in a plastic-like film. The magnetic stripe is located 0.223 inches (5.66 mm) from the edge of the card, and is 0.375 inches (9.52 mm) wide. The magnetic stripe contains three tracks, each 0.110 inches (2.79 mm) wide. Tracks one and three are typically recorded at 210 bits per inch (8.27 bits per mm), while track two typically has a recording density of 75 bits per inch (2.95 bits per mm). Each track can either contain 7-bit alphanumeric characters, or 5-bit numeric characters. Track 1 standards were created by the airlines industry (IATA). Track 2 standards were created by the banking industry (ABA). Track 3 standards were created by the thrift-savings industry.

Magstripes following these specifications can typically be read by most point-of-sale hardware, which are simply general-purpose computers that can be programmed to perform specific tasks. Examples of cards adhering to these standards include ATM cards, bank cards (credit and debit cards including Visa and MasterCard), gift cards, loyalty cards, driver's licenses, telephone cards, membership cards, electronic benefit transfer cards (e.g. food stamps), and nearly any application in which value or secure information is not stored on the card itself. Many video game and amusement centers now use debit card systems based on magnetic stripe cards.

Magnetic stripe cloning can be detected by the implementation of magnetic card reader heads and firmware that can read a signature of magnetic noise permanently embedded in all magnetic stripes during the card production process. This signature can be used in conjunction with common two-factor authentication schemes utilized in ATM, debit/retail point-of-sale and prepaid card applications.[13]

Counterexamples of cards which intentionally ignore ISO standards include hotel key cards, most subway and bus cards, and some national prepaid calling cards (such as for the country of Cyprus) in which the balance is stored and maintained directly on the stripe and not retrieved from a remote database.

Magnetic stripe coercivity[edit]

Detailed visualization of magnetically stored information on a magnetic stripe card (recorded with CMOS-MagView, dark colors correspond to magnetic north, light colors correspond to magnetic south).

Magstripes come in two main varieties: high-coercivity (HiCo) at 4000 Oe and low-coercivity (LoCo) at 300 Oe, but it is not infrequent to have intermediate values at 2750 Oe. High-coercivity magstripes require a higher amount of magnetic energy to encode, and therefore are harder to erase. HiCo stripes are appropriate for cards that are frequently used, such as a credit card. Other card uses include time and attendance tracking, access control, library cards, employee ID cards and gift cards. Low-coercivity magstripes require a lower amount of magnetic energy to record, and hence the card writers are much cheaper than machines which are capable of recording high-coercivity magstripes. However, LoCo cards are much easier to erase and have a shorter lifespan. Typical LoCo applications include hotel room keys, time and attendance tracking, bus/transit tickets and season passes for theme parks. A card reader can read either type of magstripe, and a high-coercivity card writer may write both high and low-coercivity cards (most have two settings, but writing a LoCo card in HiCo may sometimes work), while a low-coercivity card writer may write only low-coercivity cards.

In practical terms, usually low coercivity magnetic stripes are a light brown color, and high coercivity stripes are nearly black; exceptions include a proprietary silver-colored formulation on transparent American Express cards. High coercivity stripes are resistant to damage from most magnets likely to be owned by consumers. Low coercivity stripes are easily damaged by even a brief contact with a magnetic purse strap or fastener. Because of this, virtually all bank cards today are encoded on high coercivity stripes despite a slightly higher per-unit cost.

Magnetic stripe cards are used in very high volumes in the mass transit sector, replacing paper based tickets with either a directly applied magnetic slurry or hot foil stripe. Slurry applied stripes are generally less expensive to produce and are less resilient but are suitable for cards meant to be disposed after a few uses.

Financial cards[edit]

Main article: ISO/IEC 7813

There are up to three tracks on magnetic cards known as tracks 1, 2, and 3. Track 3 is virtually unused by the major worldwide networks[citation needed], and often isn't even physically present on the card by virtue of a narrower magnetic stripe. Point-of-sale card readers almost always read track 1, or track 2, and sometimes both, in case one track is unreadable. The minimum cardholder account information needed to complete a transaction is present on both tracks. Track 1 has a higher bit density (210 bits per inch vs. 75), is the only track that may contain alphabetic text, and hence is the only track that contains the cardholder's name.

Track 1 is written with code known as DECSIXBIT plus odd parity. The information on track 1 on financial cards is contained in several formats: A, which is reserved for proprietary use of the card issuer, B, which is described below, C-M, which are reserved for use by ANSI Subcommittee X3B10 and N-Z, which are available for use by individual card issuers:

Track 1[edit]

Format B:

  • Start sentinel — one character (generally '%')
  • Format code="B" — one character (alpha only)
  • Primary account number (PAN) — up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card.
  • Field Separator — one character (generally '^')
  • Name — 2 to 26 characters, surnames separated by space if necessary, Surname separator: /
  • Field Separator — one character (generally '^')
  • Expiration date — four characters in the form YYMM.
  • Service code — three characters
  • Discretionary data — may include Pin Verification Key Indicator (PVKI, 1 character), PIN Verification Value (PVV, 4 characters), Card Verification Value or Card Verification Code (CVV or CVC, 3 characters)
  • End sentinel — one character (generally '?')
  • Longitudinal redundancy check (LRC) — it is one character and a validity character calculated from other data on the track.

Track 2[edit]

This format was developed by the banking industry (ABA). This track is written with a 5-bit scheme (4 data bits + 1 parity), which allows for sixteen possible characters, which are the numbers 0-9, plus the six characters . The selection of six punctuation symbols may seem odd, but in fact the sixteen codes simply map to the ASCII range 0x30 through 0x3f, which defines ten digit characters plus those six symbols. The data format is as follows:

  • Start sentinel — one character (generally ';')
  • Primary account number (PAN) — up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card.
  • Separator — one char (generally '=')
  • Expiration date — four characters in the form YYMM.
  • Service code — three digits. The first digit specifies the interchange rules, the second specifies authorization processing and the third specifies the range of services
  • Discretionary data — as in track one
  • End sentinel — one character (generally '?')
  • Longitudinal redundancy check (LRC) — it is one character and a validity character calculated from other data on the track. Most reader devices do not return this value when the card is swiped to the presentation layer, and use it only to verify the input internally to the reader.

Service code values common in financial cards:

First digit

1: International interchange OK
2: International interchange, use IC (chip) where feasible
5: National interchange only except under bilateral agreement
6: National interchange only except under bilateral agreement, use IC (chip) where feasible
7: No interchange except under bilateral agreement (closed loop)
9: Test

Second digit

0: Normal
2: Contact issuer via online means
4: Contact issuer via online means except under bilateral agreement

Third digit

0: No restrictions, PIN required
1: No restrictions
2: Goods and services only (no cash)
3: ATM only, PIN required
4: Cash only
5: Goods and services only (no cash), PIN required
6: No restrictions, use PIN where feasible
7: Goods and services only (no cash), use PIN where feasible

United States and Canada driver's licenses[edit]

The data stored on magnetic stripes on American and Canadian driver's licenses is specified by the American Association of Motor Vehicle Administrators. Not all states and provinces use a magnetic stripe on their driver's licenses. For a list of those that do, see the AAMVA list.[14][15]

The following data is stored on track 1:[16]

  • Start Sentinel - one character (generally '%')
  • State or Province - two characters
  • City - variable length (seems to max out at 13 characters)
  • Field Separator - one character (generally '^') (absent if city reaches max length)
  • Last Name - variable length
  • Field Separator - one character (generally '$')
  • First Name - variable length
  • Field Separator - one character (generally '$')
  • Middle Name - variable length
  • Field Separator - one character (generally '^')
  • Home Address (house number and street) - variable length
  • Field Separator - one character (generally '^')
  • Unknown - variable length
  • End Sentinel - one character (generally '?')

The following data is stored on track 2:

  • ISO Issuer Identifier Number (IIN) - 6 digits[17]
  • Drivers License / Identification Number - 13 digits
  • Field Separator — generally '='
  • Expiration Date (YYMM) - 4 digits
  • Birth date (YYYYMMDD) - 8 digits
  • DL/ID# overflow- 5 digits (If no information is used then a field separator is used in this field.)
  • End Sentinel - one character ('?')

The following data is stored on track 3:

  • Template V#
  • Security V#
  • Postal Code
  • Class
  • Restrictions
  • Endorsements
  • Sex
  • Height
  • Weight
  • Hair Color
  • Eye Color
  • ID#
  • Reserved Space
  • Error Correction
  • Security

Note: Each state has a different selection of information they encode, not all states are the same. Note: Some states, such as Texas,[18] have laws restricting the access and use of electronically readable information encoded on driver's licenses or identification cards under certain circumstances.

Other card types[edit]

Smart cards are a newer generation of card that contain an integrated circuit. Some smart cards have metal contacts to electrically connect the card to the reader, and contactless cards use a magnetic field or radio frequency (RFID) for proximity reading.

Hybrid smart cards include a magnetic stripe in addition to the chip — this is most commonly found in a payment card, so that the cards are also compatible with payment terminals that do not include a smart card reader.

Cards with all three features: magnetic stripe, smart card chip, and RFID chip are also becoming common as more activities require the use of such cards.[19]

Vulnerabilities[edit]

DEF CON 24[edit]

During DEF CON 24, Weston Hecker presented Hacking Hotel Keys, and Point Of Sales Systems. In the talk, Hecker described the way magnetic strip cards function and utilised spoofing software,[20] and an Arduino to obtain administrative access from hotel keys, via service staff walking past him. Hecker claims he used administrative keys from POS systems on other systems, effectively providing access to any system with a magnetic stripe reader, providing access to run privileged commands.[citation needed]

See also[edit]

References[edit]

  1. ^"AES Historical Committee". www.aes.org.
  2. ^ abJerome Svigals, The long life and imminent death of the mag-stripe card, IEEE Spectrum, June 2012, p. 71
  3. ^"IBM100 - Click on "View all icons". Click on 8th row from the bottom titled "Magnetic Stripe Technology"". 2011-02-03. Retrieved 2011-02-03.
  4. ^"Article on Forrest Parry, pages 3-4"(PDF). Archived from the original(PDF) on 2011-10-27. Retrieved 2011-11-29.
  5. ^ ab"IBM Archives: DPD chronology - page 4". 03.ibm.com. Retrieved 2015-10-25.
  6. ^ abc"Who Made That Universal Product Code". The New York Times. Retrieved 2015-10-25.
  7. ^ ab"IBM100 - UPC". 03.ibm.com. Retrieved 2015-10-25.
  8. ^"Welcome to NJIT News | NJIT News". news.njit.edu. Archived from the original on September 7, 2013.
  9. ^ abc"IBM100 - System 360". 03.ibm.com. 1964-04-07. Retrieved 2015-10-25.
  10. ^"Retail Identification History Museum History of the UPC". Idhistory.com. Retrieved 2015-10-25.
  11. ^U.S. Patent 3,685,690, "Credit card automatic currency dispenser"; Thomas Barnes, George Chastain, and Marion Karecki; issued August 22, 1972
  12. ^U.S. Patent 3,761,682, "Credit card automatic currency dispenser"; Thomas Barnes, George Chastain, and Don Wetzel; issued September 25, 1973
  13. ^"Welcome to MagnePrint®: What is MagnePrint?". Magneprint.com. Retrieved 2011-11-29.
  14. ^"ID Security Technologies". AAMVA. Retrieved 2015-10-25.
  15. ^[1]Archived December 2, 2010, at the Wayback Machine
  16. ^2010 AAMVA DL/ID Card Design Standard Ver 1.0, Annex F.6, Aamva.org, June 2010, retrieved 2010-08-09
  17. ^"AAMVA - IIN and RID". www.aamva.org. Retrieved 2017-07-19.
  18. ^"Texas statutes, section 521.126, restricting use of electronically readable information from driver's licenses or personal identification certificates". Texas Legislature Online, State of Texas. June 2015. Retrieved 2016-04-04.
  19. ^"ID Card Supply Now Offers Triple-Secure ID Cards With Magnetic Strip, RFID and Smart Chip - Press Release". Digital Journal. 2014-07-09. Retrieved 2015-10-25.
  20. ^"Samy Kamkar: MagSpoof - credit card/magstripe spoofer". samy.pl. Retrieved 2016-12-02.

External links[edit]

Sours: https://en.wikipedia.org/wiki/Magnetic_stripe_card
how to write dumps (track1 and track 2 ) with pin

Moving in a frantic rhythm like animals and filling the whole house with cries of voluptuousness, we rushed into the abyss of pleasure. After a few extremely pleasant moments, the girl penetrated my vagina with several fingers, giving me new sensations. Without keeping myself waiting, I responded in kind, kissing her swollen clitoris, inner thighs and beautiful knees.

Pulling my fingers out of the hollow of pleasures and grabbing the girl's legs, I bent down and dug into the clitoris with force, sucking it like. A delicious lollipop, which made my sister beat up in convulsions of orgasm.

Now discussing:

Not in a hurry. Probably, first he thinks, and then he does. I will not rush, I will wait. I looked at the flowing water, which reflected the lights of the big city.



2569 2570 2571 2572 2573