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! b2ap3_thumbnail_DSC00843.jpg

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?

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:

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)
---1----  1: Track 2 sampling data exists (0: Track 2 sampling data does not exist)
----1---  1: Track 1 sampling data exists (0: Track 1 sampling data does not exist)
-----1--  1: Track 3 decode success (0: Track 3 decode fail)
------1-  1: Track 2 decode success (0: Track 2 decode fail)
-------1  1: Track 1 decode success (0: Track 1 decode fail)


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)
1-------  Bit 7: 1   Serial Number present; 0 not present
-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
------1-  Bit 1: 1  if Track2 clear/mask data present
-------1  Bit 0: 1  if Track1 clear/mask data present
Encrypted/Hash Data Sent Status (9B)
1-------  Bit 7: if 1, KSN present
-0------  Bit 6: if 1, session ID present 
--0-----  Bit 5: if 1, track3 hash data (SHA digest) present
---1----  Bit 4: if 1, track2 hash data (SHA digest) present
----1---  Bit 3: if 1, track1 hash data (SHA digest) present
-----0--  Bit 2: if 1, track3 encrypted data present
------1-  Bit 1: if 1, track2 encrypted data present
-------1  Bit 0: if 1, track1 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


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.)


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!


Related Articles