GB2482735A

GB2482735A - Data recovery for a magnetic stripe reader

Info

Publication number: GB2482735A
Application number: GB1013640.6A
Authority: GB
Inventors: Alexandru Ion Sovu
Original assignee: Individual
Current assignee: Individual
Priority date: 2010-08-13
Filing date: 2010-08-13
Publication date: 2012-02-15
Also published as: GB201013640D0

Abstract

An algorithm that analyses, decodes and recovers data from partially-read or damaged magnetic stripes. The method may comprise: determining the longest sequence of valid characters in a signal; using data about swipe-direction from other swipes; looking for known valid characters in the data; or, looking for sequences of common characters from the previous or next swipe, if they are close in time. The algorithm may be operable entirely within a stripe reader, or may reside on another device such as a PC.

Description

Magnetic Stripe Data Recovery fabie ol ntens

Introduction. 1

Description. 1

Implementation 2 Decoding data with parity bit 3 Data without parity bit 6 Building a valid swipe from several invalid swipes 6 The Magnetic Stripe Reader 7 Forensic Reader 7 Reader with incorporated F2F decoder 8 Compact reader 9 The external device 10 Claims 11 Abstract 12 In Iuct on This invention describes how to build a device that reads and recovers the data from an improperly swiped or damaged magnetic stripe. This device is also capable of reading all types of magnetic cards even if the format is unknown None of the current readers are able to read a magnetic stripe that they have no knowledge about or to read any partial data from a magnetic stripe.

The present invention is a step forward in forensic investigations and enhances the accuracy and usability of magnetic stripe readers. It also allows users that are unable to complete a swipe to use magnetic stripe systems (e.g.: suffering from Parkinson disease). It is doing this by using a heuristic decoding algorithm described below.

Description

In order to be able to read and recover the data from a magnetic stripe a special kind of reader has to be built. This device has to read the signals from a magnetic stripe, interpret them using the standard algorithm that is used to encode magnetic stripes (Frequency-Double-Frequency) and process the resulting binary data with a special algorithm (described below) in order to be able to decode the whole data entirely.

All the other magnetic stripe readers expect the data to fit within certain parameters. If the read data does not match with the expected standard, it is dropped and the user is not even aware of its existence.

The purpose of this invention is to read and interpret any kind of data found on the magnetic stripe. For this reason we will not assume that the data complies with any standard. We will try to match it with the known standards, but we will expect reading errors (e.g. that the card might have been improperly or partially swiped). Based on the recovered data and the other read swipes we will be able to match and/or recover it and this will allow us read the whole contents of one card from several failed swipes.

Even if we are not able to match the data with other swipes, storing an incomplete swipe will prove of value into forensic investigations, classroom attendance or monitoring applications. For

example:

* if the police enforcement needs to investigate a crime where a magnetic stripe is involved they can recover the data from a shredded or cut magnetic stripe using this invention * if this system is used for monitoring attendance on a class, a partially read card could be enough to determine if the student was present or not * An application might need to store binary data onto the cards (e.g. encrypted). As no current standard allow this, they will be unable to do so unless they use this technology to read non-standard formats.

The best hardware implementation of a magnetic stripe reader that implements this technology is to record the raw voltage produced by the magnetic head during a swipe at a decent sample rate. This will ensure that no data is lost and will allow fine tuning of the F2F decoding algorithm. To fine tune this algorithm we can use several sound filters like noise reduction, normalising and others.

I recommend over 22000 samples per second for 75bpi tracks although even lower rate samples might work. Tracks with higher density will require higher sampling rate. Increasing the rate will produce better results but would also require more storage space and/or processing power.

To skip this step it is easier to use an F2F decoder chip which is available on the market from several vendors. This chip will do the above work for you but will not allow you to fine tune it. If the decoder chip decides that the data cannot be decoded, it will drop it and will not allow anybody to change its algorithm.

If the raw data is to be decoded by this reader, we will have to implement our own F2F (Frequency-Double-Frequency) decoder.

Data decoded with F2F decoders is a series of 1. and 0 which makes no sense without further analysis. Due to the nature of magnetic stripe medium this has to go through a series of checks in order to ensure that the contents are accurate.

In order to automatically decode the data we will have to match it against known standards.

We can implement as many standards are we want (or know) into the reader (or into the decoding software). If everything fails we should keep the data as it is and present it to the user for further analysis. wh

As we assume that a swipe is not complete, we cannot rely that we will ever find SS', ES or LRC3 in the swipe. However, we can rely on the parity bit which is present after each character.

Data is encoded on a card by writing each character several bits. For example the IATA standard specifies that data is written within 7 bits (which include 1 parity bit); AMA standard specifies that one character in written within 5 bits (which include 1 parity bit). Other standards might specify 6 bits, etc. In order to determine the correct decode settings first we need to add zero bits in front of the swipe. The number of these bits is at least "BPC4" but it is safely to add more as they will be dropped later when they fail the parity bit check. 8 bits will usually suffice but 16 extra bits should be enough for any application.

Then, we will need to determine the correct parameters to decode the data: Variants There are "n" variants for each encoding. N = "bits per character". There is one variant for each bit to start from. As the encoding on the card does not show how many leading bits exist, any bit might be correct. However, if we try to generate more than BPC variants, we will notice that the solutions will start to repeat themselves with the only difference being losing one or more characters. For this reason we can only have a limited number of variants and that is BPC. In some cases there will be remaining bits which will be dropped.

Example of variants calculation Given the following sequence of bits (note: this sequence has been randomly typed in and is used here only as an example): 000000001O1O1O1111O1001O1O1111O1O111O1000100111O1O1O100000000 1 -Start Sentinel -this is usually one character long, predefined by most of the magnetic stripe encoding standards. It has been introduced to determine where the data starts 2 -End Sentinel -this is usually one character long, predefined by most of the magnetic stripe encoding standards. It has been introduced to determine where the data ends but it is usually followed by one more check character called LRC LRC -Longitudinal redundancy check -usually one character long, it is calculated based on the whole track and it is used by the readers to determine if the swiped data is correct BPC -Bits per character -the number of bits used to represent a character. In this document, if there is a parity bit involved, we include it into the BPC (5 bits = 4bits for the character and 1 parity bit) For a 5 BPC decoding we will have the following sequence of bits (the last bit of each sequence is the parity bit (marked with blue); the remaining bits are dropped): varianti: 000000001e1e1e1111®1001e1e1111®1®111e1000100111®1e1e100000000 variant2: Variant3: Variant4:

S

variants:

S

Variant6:

S

Note that Variant 6 (for 5 BPC) is exactly the same as Variant 1 with the exception that it is dropping the first character therefore we cannot have more than BPC variants per each encoding.

Directions There are 2 directions in which a magnetic stripe can be read (forward and backward). In order to interpret in the other direction the whole sequence of bits has to be read from the end to the beginning.

Example of direction calculation Using the bit sequence from Drawing 1, we will have: The sequence:

I

000000001o1o1o1111o1001o1o1111o1o111o1000100111o1o1o100000000 Will be read from backward: 000000001o1o1o1111o1001o1o1111o1o111o1000100111o1o1o100000000 Resulting in: 000000001o1o1o1110010001o111o1o1111o1o1001o1111o1o1o100000000 Magnetic Stripe Encoding There are several encodings (usually 4, 5, 6, 7, 8, 9 bits). If the character is represented on lower than 4 bits would mean that there are less than 4 characters in the dictionary which does not seem usable for any application. An encoding with more than 9 bits (8 usable bits + 1 parity bit) is unlikely to exist but someone might decide that it would be useful in some cases (e.g.: if the card is written with Unicode). Note: if you intend to process a BPC above 8bpc, do not forget to add 2 bytes (16 bits) containing 0 at the beginning and at the end of the decoded sequence.

Example of interpreting different encodings Using the bit sequence from Drawing 1, we will have: Varianti (4bpc): 000000001g1e1e1111®1001g1e1111®1®111g1000100111®1g1g100000000 varianti (Sbpc): varianti (6bpc): Varianti (7bpc): Varianti (8bpc): varianti (9bpc): Decoding To decode the data we need to calculate all the combinations of the variants from above (variants * directions * encodings). We will then need to determine the longest sequence of valid characters for each variant and calculate them a "rate" based on this value. We will need this rate to determine which decoding parameters are correct.

At this stage, the suggested formula for this calculated rate is the maximum number of consecutive valid characters. This rate can be increased or decreased a little bit if we have more information about the standard (see below) Due to the algorithm that calculates the parity bit, it is impossible to determine the direction as a character with valid parity bit is always valid if read forward or backward. For this reason there is a strong possibility that we will get two variants that have the same rate from which only one is the correct one. In order to determine which one is correct we should rely on the following factors: 1. If we have calculated other swipes for different tracks and we are absolutely positive which is the correct direction, we should be able to assume that the direction of the other track is the direction of this track. However, this might not work on unknown encoding where someone might decide to write one track in one direction and the others in the opposite direction.

2. Knowing the standard we should look for known valid characters (SS, ES, field separators like "=" etc.) or invalid characters (characters that are usually not present in the specified standard). Based on these values we can raise or lower the rate. The suggested formula is rate = rate + 2 for 55 and ES, rate = rate + 1 for correct characters and rate = rate -1 for invalid characters. Note that SS end ES have to be at the beginning or the end of the swipe; if they are in incorrect place they should not be treated as SS or ES.

3. Look for common characters from the previous swipe or next swipe if their timestamp is close to the current one. The longest string matched, might be the correct variant To complete the decoding of a swipe we need also to know what is the first character specified by the standard. We need this as if we use 0 as the first character we will get mostly non printable characters which is probably not what we want. For example the first character in IATA is 0x20 (32) (0000 means ASCII 32) and ABA uses 0x30 (48) (0000 means ASCII 48) Finally we will sort all the variants based on the rate and determine the proper one based on the best rate'. Due to parity calculation issue specified before, when we encounter 2 solutions with the same best rate we can choose to display both variants to the users and let them choose the correct solution. If this is not applicable for the desired application (e.g. it has to be automatic), we can simply choose to ignore the swipe and ask the user to swipe the card one more time.

A system that works without human supervision cannot be implemented for encodings without the parity bit unless we know exactly the specifications of the format.

Trying to decode encodings without parity bit is possible but the accuracy of the swipe cannot be determined without further information.

Once we know anything about the format that we are trying to decode we will use the algorithm explained in the previous chapter to determine the variants for the required BPC and determine the best rate.

For systems that are aimed to work without human supervision, we need to merge incomplete swipes into complete ones. It is advisable to try to merge consecutive swipes or swipes that have been read in a relative short time interval.

We will have to look for a common group of characters taking into consideration that 1 or 2 (and in very rare cases 3) characters at the beginning or the end of the swipe might be incorrect.

Once we have found a common group of characters we can merge the swipes to get a correct one.

Example of how to merge two swipes: Given the following two swipes: 1: %2039840 2: 12984=3409853; And assuming that they belong to the same card (e.g.: when the swipes were read in a short interval of time), we can determine that they have the following common sequence: %20 384.e 12984=34e9853; The last character from swipe 1 and the first 2 characters from swipe 2 are incorrect therefore they been dropped. We have determined that 984 are common characters into the sequence above therefore we can determine that the correct data on the card is: %203.4=3409853; n There are several types of readers that we can design based on this invention.

Note: The chapters below contain several examples of readers. They were provided for a better understanding and only as examples on how to use this invention. They are not intended in any way to limit this invention to these specific readers.

This reader will read and store and/or transmit the raw data to another device (usually PC).

It will not do any kind of data processing. This is the best approach to recover all the data from a magnetic stripe.

1. Advantage: processing can be done at a later time; if it fails the data can be reinterpreted all over again with different parameters (e.g. sound filters) 2. Advantage: this data can be used to determine the speed of the swipe and to match the machine used to write the card (huge advantage in forensics investigations) 3. Disadvantage: the data read from one track occupies quite a lot of space; storing it will require additional memory 4. Disadvantage: additional software that will run on an external device (e.g. PC) will have to be provided in order to interpret this data (f2f decoder and binary decoder) There are many ways this reader can be implemented. Please find below an example.

To build a simple reader we could use: * A microcontroller in which we will write an implementation of the software described above.

* One magnetic head * One or more sound amplifiers (one for each track) which are connected to the magnetic head and to the microcontroller * If portable use is desired, the microcontroller has to have access to flash memory to write the data into it. The memory has to be large enough to store data for at least one swipe. It will also have to be fast enough to keep up with the volume of data produced by the controller.

* In order to connect to other device that is able to properly decode the data (for example a PC) we can choose to connect through wires or wireless. For wired connection I recommend USB. For wireless connection I recommend Bluetooth. If the micro controller does not have USB or Wireless built in, it will have to be connected to a USB to USART converter * A proper implementation of the F2F decoder and Binary decoder described above that will run on the external device (e.g. PC) There is an alternative to implement this reader without any other hardware: We can use any device capable to record audio (for example a mobile phone). The audio signal can be interpreted by the F2F decoder and then by the binary decoder described above to interpret the swipe.

This reader will decode the analogue data into digital binary data. However, it will not try to interpret further and it will just store or pass it to another device (usually a PC).

1. Advantage: processing of binary data can be done at a later time. If the format is not recognised or unknown it can still be processed later 2. Advantage: uses the lowest memory possible 3. Advantage: uses the lowest possible processing power 4. Disadvantage: data lost in the analogue to binary decoding process (F2F) cannot be recovered. On most applications is quite safe to drop the analogue data and store the binary (decoded) data.

5. Disadvantage: additional software that will run on an external device (e.g. PC) will have to be provided in order to interpret this data (binary decoder) There are many ways this reader can be implemented. Please find below an example.

To build a simple reader we could use: * A microcontroller capable and responsible for reading the sample voltage produced by the magnetic head while reading * One magnetic head * One hardware F2F decoder or a software implementation of this decoder in the microcontroller * If portable use is desired, the microcontroller has to has access to flash memory to write the data into it * In order to connect to other device that is able to properly decode the data (PC) we can choose to connect through wires or wireless. For wired connection I recommend USB.

For wireless connection I recommend Bluetooth. If the micro controller does not have USB or Wireless built in, it will have to be connected to a USB to USART converter * A proper implementation of the Binary decoder described above that will run on the external device (e.g. PC) This reader will decode everything and will not rely on another device or on a human to decide what the best swipe is.

1. Advantage: no additional software is required to operate this kind of device 2. Disadvantage: the analogue data will be lost 3. Disadvantage: as a record of previous reads has to be kept, it requires additional memory 4. Disadvantage: as all the processing is done on the device, it will require additional processing power, resulting in higher power consumed (making this not so efficient for battery operated devices) 5. Disadvantage: As we are reading incomplete swipes we can expect that we will have several swipes in a short amount of time. There is a chance of a buffer under run due to the device being busy decoding a swipe. In order to avoid this issue, a multitasking system will be required.

6. Disadvantage: There is a chance that the decoding algorithm will fail to decode properly due to misinterpreting the direction.

There are many ways this reader can be implemented. Please find below an example.

* One magnetic head * One hardware F2F decoder or a software implementation of this decoder in the microcontroller * If portable use is desired, the microcontroller has to has access to flash memory to write the data into it * In order to connect to other device that is able to properly decode the data (PC) we can choose to connect through wires or wireless. For wired connection I recommend USB.

For wireless connection I recommend Bluetooth. If the micro controller does not have USB or Wireless built in, it will have to be connected to a USB to USART converter In the readers from above I have been mentioning an external device and recommended a PC for that. However, the reason that I have not said that a PC is required is that we can also implement a second device (portable or not) responsible of reading (wired or wirelessly) and (if applicable) interpreting the data. This could serve as host for one device or a hub for multiple devices in order to implement a network of readers to be used for various applications.

Claims

(iiaims 1. An algorithm used to analyse, decode and recover partially read or damaged magnetic stripes.
2. A magnetic stripe reader that will provide enough data to allow an external device that implements the algorithm from claim 1 to analyse, decode and recover data from partially read or damaged magnetic stripes.
3. A magnetic stripe reader that will partially interpret the read data and pass it to a device that implements the algorithm from claim 1 which will be able to analyse, decode and recover data from partially read or damaged magnetic stripes.
4. A magnetic stripe reader that will fully interpret the data read from a partially read or damaged magnetic stripe in order to automatically recover the data.
5. A software or device that implements the algorithm from claim 1 to analyse, decode and recover the data provided by the reader from claims 2 and/or 3.