Added pictures for track data formats, legal disclaimer, intro, etc

This commit is contained in:
Dionysus 2024-05-12 01:04:14 -04:00
parent 6b05b3e215
commit 24f4329d7a
Signed by: acidvegas
GPG Key ID: EF4B922DB85DC9DE
3 changed files with 39 additions and 12 deletions

BIN
.screens/track1.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 60 KiB

BIN
.screens/track2.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 50 KiB

View File

@ -4,19 +4,38 @@
#### WORK IN PROGRESS #### WORK IN PROGRESS
**Hardware:** [Deftun MSR90 3 Track Reader](https://www.amazon.com/MSR90-Magnetic-Credit-Reader-Deftun/dp/B01DUB4GVO/) **Hardware:** [Deftun MSR90 3 Track Reader](https://www.amazon.com/MSR90-Magnetic-Credit-Reader-Deftun/dp/B01DUB4GVO/)
## Legal Disclaimer
The information and code provided in this repository are intended for educational and research purposes only, focusing on magnetic stripe data security and the documentation of the MSR90 magnetic card reader. The author of this repository does not endorse or promote the use of this information for fraudulent or illegal activities. The content is provided "as is" without warranty of any kind, express or implied. Neither the author nor the contributors shall be held liable for any damages arising from the use of this information. Users are encouraged to comply with all applicable laws and regulations regarding magnetic stripe data usage.
## Information ## Information
To startoff, this is not for committing fraud. I will be documenting all my research on magnetic strip data aswell at writing code for it. For some reason it seems hard to find code or any valid documentation on working with magnetic strip data on Linux, so this will attempt to be a deep dive into understanding the capabilities. This is simply academic research & for testing on your own data. This repository serves as a personal exploration of magnetic stripe data as used in modern payment systems. The focus is on understanding the formatting of magnetic strip data, the mechanics of how systems interpret this data, and the associated security risks and vulnerabilities.
Despite the widespread use of magnetic stripe technology in financial transactions, there is a notable scarcity of accessible information and practical code examples on this topic.
Let's hope we don't get Banned 🤷
###### Initial discover & observances
To my suprise, most of these card readers act as an HID that mimics a keyboard. Simply put, you swipe a card and it types the data out that is on the magnetic strip. Also to my suprise these work out of the box on Linux & Android systems.
## Financial Cards ## Financial Cards
#### Track 1 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, and often is not 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
Track 1 is written with code known as DEC SIXBIT plus odd parity.
![](./.screens/track1.png)
###### Format A
Reserved for proprietary use of the card issuer
###### Format B ###### Format B
| Item | Description | | Item | Description |
| ----------------------------------- | ----------- | | ----------------------------------- | ---------------------------------------------------- |
| Start sentinel | one character (generally '%') | | Start sentinel | 1 byte *(the % character)* |
| Format code="B" | one character (alpha only) | | Format code | 1 byte alpha |
| Primary account number (PAN) | up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card. | | Primary account number (PAN) | up to 19 characters *(may contain spaces sometimes)* |
| Field Separator | one character (generally '^') | | Field Separator | 1 byte *(the ^ character)* |
| Name | 2 to 26 characters, surnames separated by space if necessary, Surname separator: / | | Name | 2 to 26 characters, surnames separated by space if necessary, Surname separator: / |
| Field Separator | one character (generally '^') | | Field Separator | one character (generally '^') |
| Expiration date | four characters in the form YYMM. | | Expiration date | four characters in the form YYMM. |
@ -25,8 +44,16 @@ To startoff, this is not for committing fraud. I will be documenting all my rese
| End sentine | one character (generally '?') | | End sentine | one character (generally '?') |
| Longitudinal redundancy check (LRC) | it is one character and a validity character calculated from other data on the track | | Longitudinal redundancy check (LRC) | it is one character and a validity character calculated from other data on the track |
#### Track 2 ###### Format C-M
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 09, plus the six characters : ; < = > ? . (It may seem odd that these particular punctuation symbols were selected, but by using them the set of sixteen characters matches the ASCII range 0x30 through 0x3f.) The data format is as follows: Reserved for use by ANSI Subcommittee X3B10
###### Format N-Z
Available for use by individual card issuers
### Track 2
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 16 possible characters, which are the numbers 09, plus the six characters : ; < = > ? . *(ASCII range 0x30 through 0x3f)*
![](./.screens/track2.png)
| Item | Description | | Item | Description |
| ----------------------------------- | ----------- | | ----------------------------------- | ----------- |
@ -65,7 +92,7 @@ This format was developed by the banking industry (ABA). This track is written w
| 2 | Goods and services only *(no cash)* | | 2 | Goods and services only *(no cash)* |
| 3 | ATM only, PIN required | | 3 | ATM only, PIN required |
| 4 | Cash only | | 4 | Cash only |
| 5 | Goods and services only (no cash), PIN required | | 5 | Goods and services only *(no cash)*, PIN required |
| 6 | No restrictions, use PIN where feasible | | 6 | No restrictions, use PIN where feasible |
| 7 | Goods and services only *(no cash)*, use PIN where feasible | | 7 | Goods and services only *(no cash)*, use PIN where feasible |
___ ___