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?

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:

02ED01801F4C2800839B%*6010********8765^0254/SERVICERECOVERYUSD^*******************************?*;6010********8765=********************?*95025C86987E4F7DD07D58730EB79FDFB90AB7F23E6ECA6F4F04A67BF511EE13F950903BDE77624680C460E9C36C4F9136256BB93A38CB98F95626DCFAF9335CE0A213074CC1CD84CC911398E06756C464AB036B694228ADA7EC018F495A013AF8A04C976288FE2F80271E6E53D987DE19ACA2707BFF2C78000000000000000000000000000000000000000000000000000000000000000000000000000000003631335435333536313862994900750002A00308108E03

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:

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:

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

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:

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!