Check out what I found...
iPod Meets Reel by Evan Long
The goal was to combine old and new technology. In this case, to demonstrate that an iPod Touch could record and playback audio from a reel-to-reel machine.
The video below includes the audio recording dubbed in. The music was Art Kassel's band, recorded off the air sometime in the late 1940s. Enjoy!
More Projects by Evan Long...
- Tetris with Twilio
- Reject-Her-Him (custom rejection hotline)
- Dial-The-Joke (Google App Engine and Twilio)
- Tor-Gui (UI design)
- Chipmark2RSS (bookmark RSS feed)
- Chipmark (social bookmarker)
- CSCI 5161 (Introduction to Compilers)
- cfakestl (set of common data structures)
- Python Tetris (pygame framework)
- VLC Laser Gesture Control
- Sudoku Solver (with backtracking UI)
- Automatic Sprinkler Control (java and php)
- LBRAM: TI89 Riemann Sums Program
- FlameBin (NZB creator)
- Lego Record Player
Rhombus: Square skewed (How to use the Square dongle that you can plug in to your phone's mic jack)
2011 March 25
You've probably heard of Square, the company that makes it easy for you to do credit card processing through your cellphone. They send out a little dongle that you can plug in to your phone's mic jack, which can scan cards. They also provide an app which takes what the dongle sends as audio and decodes it into the credit card info. But of course, that only works for credit cards, and it doesn't actually show you all the data that it can read. I recently broke my first reader, and to make the best of a broken reader, here's an image of the insides.
As you can see, it's very simple. It's just a read head and two wires connected to mic and ground.
A couple of weeks ago, I solved an online puzzle to get invited to a Hacker Underground meet up at SXSW. Fortunately for me, I live in Austin, so getting there was no problem. I even brought some beer. Anyway, everyone that attended had to have a "hack" to show off, and I'd been intending to play with this Square reader for a while, so I whipped up an app to dump card info.
Let's talk about that magnetic stripe on the back of your credit cards (and driver's licenses, and store club cards, and gift cards, and...). The physical specs of those cards are standardized. I got all of my info from an old article in Phrack which I found online. That article has everything you need to know about the data format on the cards. I'll restate some of it here anyway.
The magnetic stripe consists of 3 physically separated "tracks". Track 1 is closest to the bottom of the card, and track 3 is the highest. Square's reader is positioned to read track 2. Track 2 is the most commonly used track, but most credit cards also use track 1. Track 2 includes card numbers and expiration dates. Track 1 includes that plus names. There may be other data too, depending on the particular card. These tracks are specced to be .11 inches wide, so to read track 1 with Square's reader, we just need to reposition the stripe so that track 1 is lined up with the read head. To do that, we just need to raise it by .11 inches. And we can do that by cutting a .11 (or in my case 1/8) inch slice from a card we do not care about, and putting that at the bottom of the reader. This is called a "shim".
So, now we know where and what the data is, let's talk about how it's encoded. Again, this is all from that phrack article. Data in each track is encoded via magnetic domain flipping. Long story short: The series of domain flips encodes a waveform, that waveform is interpreted as binary. A binary 0 in this encoding is some arbitrary frequency. A 1 is twice that frequency.
Since it's a waveform, the magnetic read head of the Square device can send that over the mic channel to your phone just like any other audio.
So, now we've got a bunch of audio on our device. How do we decode it? I based my code on an Android tutorial which shows how to record data and then play it back. In my case, I made sure to save that audio as 16bit PCM encoded. I sampled at 44100hz. On Android (and elsewhere, I suppose) 16bit PCM data means that each sample is a signed 16bit value. Since we only care about the frequency, we only need to care about how much time there is between "zero-crossings". A zero-crossing is when the signal goes from postive to negative or vice-versa. A 0 bit will be represented by the space between 2 crossings, and a 1 will have an extra crossing in approximately the same time period.
Card data in each track starts off with some (variable) number of 0s, to establish the base frequency. What I did was listen for the first sample above a certain "quiet" threshold, then count the number of samples between zero-crossings. That number becomes the base value for a 0. Since these cards are hand-swiped, the actual frequencies will change somewhat from the start of the scan to the end. So, I made a simple method which determines if the number of samples since the last zero-crossing is closer to the base frequency or twice the base frequency (half the base number of samples). It then adjusts the expected base frequency accordingly. This works well, so long as the changes between any two logical bits are fairly small. And they almost certainly will be.
Okay, after some hand-waving, we now have a binary sequence of data, which we want to turn back into ASCII. The most common encoding (and the only one I wrote a handler for) encodes each character as some number of bits, plus one parity bit. In the case of track 2, that's 4 bits for the character, and 1 for parity, making 5 bit groups. The bits are read from least significant to most, with the parity bit last. The parity bit is set to make the number of 1s in the group odd. In my implementation, I just disregard the parity bit, but it would help determine whether the read was good or not. In track 1, it's 6 bits for the character, plus the parity.
The character set of the tracks differ too, but both are subsets of ASCII with some offset. In the case of track 2, which only encodes some symbols and digits, the character set starts at 48, which is the ASCII code for "0". So if we get 0,0,0,0,1 as our character, we turn that into 0, add 48, and get 48. Similarly, 1,0,0,0,0 is 1. 1+48 = 49 = ASCII "1".
For track 1, the character set starts with " " (space) which is ASCII 32. So we add 32 to the decoded numeric value and get our ASCII character. After that, we have the data, so all that remains is hooking up the UI glue.
Unless otherwise specified, all source code posted on this site is licensed under the GPLv2. Contact me for alternate licensing, including corporate-friendly. firstname.lastname@example.org
- Recording off a reel-to-reel with a credit card reader
- Recording off a reel-to-reel with a credit card reader - Hack a Day
- Reel-to-reel played through iPod Touch and Square Reader - YouTube
- evanlong/ReelToReelTouch · GitHub
- Reading credit cards with a tape head - Hack a Day
- Accept credit cards with your iPhone, Android or iPad – Square
- Evan Long
The simplest magnetic stripe reader
Using the software
Reading credit cards with a tape head
- Reading credit cards with a tape head - Hack a Day
- Cosmodro.me: experiments, toys, and widgets. Rhombus: Square skewed
- Accept credit cards with your iPhone, Android or iPad – Square
- Card security code - Wikipedia, the free encyclopedia
- Raw Audio Manipulation in Android - European Developer Blog
- Hackaday Links: April 18, 2012 - Hack a Day
- North Street Labs
- The simplest magnetic stripe reader
- Cosmodro.me: experiments, toys, and widgets. Posts for cosmodrome-admin
Card security code
|This article may contain original research. Please improve it by verifying the claims made and adding references. Statements consisting only of original research may be removed. (April 2011)|
The card security code (CSC), sometimes called Card Verification Data (CVD), Card Verification Value (CVV or CVV2), Card Verification Value Code (CVVC), Card Verification Code (CVC or CVC2), Verification Code (V-Code or V Code), or Card Code Verification (CCV) are different terms for security features for credit or debit card transactions, providing increased protection for the merchants against credit card fraud.
Types of codes
There are several types of security codes:
- The first code, called CVC1 or CVV1, is encoded on the magnetic stripe of track-2 of the card and used for transactions in person. The purpose of the CVC1 or CVV1 is to ensure the data stored on the magnetic stripe of the card is valid and was generated by the issuing bank. This value is submitted as part of transactions and is verified by the issuing bank. A limitation of the CVC1 or CVV1 is that if the entire magnetic stripe is copied, rather than generated, the card can be duplicated. See the Skimming section for more details.
- The second code, and the most cited, is CVV2 or CVC2. This CSC (also known as a CCID or Credit Card ID) is often asked for by merchants for them to secure card not present transactions occurring over the Internet, by mail, fax or over the phone. In some countries in Western Europe, card processors require the merchant to provide this code when the cardholder is not present in person.
- Contactless card and chip cards may supply their own codes generated electronically, such as iCVV or Dynamic CVV.
These codes should not be confused with the standard card account number appearing in embossed or printed digits. (The standard card number undergoes a separate validation algorithm called the Luhn algorithm which serves to determine whether a given card's number is appropriate.)
These codes should also not be confused with a card's PIN or passwords associated with MasterCard SecureCode or Verified by Visa. These codes are not printed or embedded in the card but are manually entered at the time of transaction.
Location of code
The CSC (the second type of code noted above) is a three- or four-digit value printed on the card or signature strip, but not encoded on the magnetic stripe.
- MasterCard, Visa, Diners Club, Discover, and JCB credit and debit cards have a three-digit card security code. The code is not embossed like the card number, and is always the final group of numbers printed on the back signature panel of the card. New North American MasterCard and Visa cards feature the code in a separate panel to the right of the signature strip. This has been done to prevent overwriting of the numbers by signing the card. The codes have different names:
- "CVC2" (card validation code) MasterCard,
- "CVV2" (card verification value) Visa,
- "CID" (card identification number) Discover.
- American Express cards have a four-digit code printed on the front side of the card above the number. It is printed flat, not embossed like the card number. This code is called:
- "CID" or "unique card code"
Merchants who require the CVV2 for "card not present" transactions are forbidden by Visa from storing the CVV2 once the individual transaction is authorized and completed. This way, if a database of transactions is compromised, the CVV2 is not included, and the stolen card numbers are less useful. Virtual terminals and payment gateways do not store the CVV2 code, therefore employees and customer service representatives with access to these web-based payment interfaces who otherwise have access to complete card numbers, expiration dates, and other information still lack the CVV2 code.
The Payment Card Industry Data Security Standard (PCI DSS) also prohibits the storage of CSC (and other sensitive authorisation data) post transaction authorisation. This applies globally to anyone who stores, processes or transmits card holder data. Since the CSC is not contained on the magnetic stripe of the card, it is not typically included in the transaction when the card is used face to face at a merchant. However, some merchants in North America, such as Sears and Staples, require the code. For American Express cards, this has been an invariable practice (for "card not present" transactions) in European Union (EU) states like Ireland and the United Kingdom since the start of 2005. This provides a level of protection to the bank/cardholder, in that a fraudulent merchant or employee cannot simply capture the magnetic stripe details of a card and use them later for "card not present" purchases over the phone, mail order or Internet. To do this, a merchant or its employee would also have to note the CVV2 visually and record it, which is more likely to arouse the cardholder's suspicion.
Supplying the CSC code in a transaction is intended to verify that the customer has the card in their possession. Knowledge of the code proves that the customer has seen the card, or has seen a record made by somebody who saw the card.
- The use of the CSC cannot protect against phishing scams, where the cardholder is tricked into entering the CSC among other card details via a fraudulent website. The growth in phishing has reduced the real-world effectiveness of the CSC as an anti-fraud device. There is now also a scam where a phisher has already obtained the card account number (perhaps by hacking a merchant database or from a poorly designed receipt) and gives this information to the victims (lulling them into a false sense of security) before asking for the CSC (which is all that the phisher needs).
- Since the CSC may not be stored by the merchant for any length of time (after the original transaction in which the CSC was quoted and then authorized and completed), a merchant who needs to regularly bill a card for a regular subscription would not be able to provide the code after the initial transaction. Payment gateways, however, have responded by adding "periodic bill" features as part of the authorization process.
- Some card issuers do not yet use the CSC - although MasterCard started in 1997 and Visa in the USA had them issued by 2001. However, transactions without CSC are likely to be subjected to higher card processing cost to the merchants, and fraudulent transactions without CSC are more likely to be resolved in favour of the cardholder.
- It is not mandatory for a merchant to require the security code for making a transaction, hence the card is still prone to fraud even if only its number is known to phishers.
Generation of card security codes
CVC1, CVV1, CVC2 and CVV2 values are generated when the card is issued. The values are calculated by encrypting the bank card number (also known as the primary account number or PAN), expiration date and service code with encryption keys (often called Card Verification Key or CVK) known only to the issuing bank, and decimalising the result.
- "Authorize.Net - Developer Frequently Asked Questions:". Retrieved 29 March 2009.
- "Card Security Features" (PDF). Visa.
- "Rules for Visa Merchants" (doc). p. 1.
- "Official Source of PCI DSS Data Security Standards Documents and Payment Card Compliance Guidelines". Pcisecuritystandards.org. Retrieved 2011-12-25.
- "Urban Legends Reference Pages: Visa Fraud Investigation Scam". Snopes.com. Retrieved 2011-12-25.
- "z/OS Integrated Cryptographic Service Facility Application Programmer’s Guide". IBM. March 2002. p. 209.
- "z/OS Integrated Cryptographic Service Facility Application Programmer’s Guide". IBM. March 2002. p. 258.
- CVVNumber.com - Credit Card Security Information for Cardholders (Electronic Transactions Association)