Search My Blog

Saturday, June 16, 2012

Recording off a reel-to-reel with a credit card reader

I found some interesting info on Recording off an Analog reel-to-reel Tape Deck, with a credit card reader on, Hack a Day. I followed the links through and found even more info on how to use Analog Tape Heads to Read Card Stripes. I especially like the use of the simple Tape Head Setup to Digitize Old Analog Tapes. Of course you could just use your Old Analog Tape Deck. Plugged into your Sound Card and use Audacity or which ever App you Prefer, to Record Digitize Your Old Tapes. But, if your old Analog Decks are worn out and the Tape Speed is lagging and making a wobbling sound on your recordings. Or if your Tape Head is Dead. Or if you have an iPod, which I don't. Then this method would be great for you. But, really, most any Analog Sound Card should work with this method. So, you might be interested in doing some Re-Engineering on that Old Worn Out Analog Tape Deck;)

Check out what I found...

Don

iPod Meets Reel by Evan Long

About

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.

Result

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!

Materials

Modifications

Rhombus: Square skewed (How to use the Square dongle that you can plug in to your phone's mic jack)

|

2011 March 25

First, the disappointing part: I'm not going to post my full code or apk here. I am going to describe what I had to do to build it. Update: I have put up the app and the RhombusLib android library

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. steve@cosmodro.me

Go there...
http://cosmodro.me/blog/2011/mar/25/rhombus-square-iskewedi/

Foreword

The main aim in all the designs you will find in these pages is to keep them as simple as possible while working. When I first made a magnetic stripe reader I hadn't a sound card by that time so I had to design a simple amplifier to rise the weak signal of the magnetic head up to a level usable by a computer. Nowadays sound cards are common even in laptops so the amplifier is no longer needed, you just have to connect the magnetic head directly to the microphone input of the sound card (impedances of both devices are usually similar). Of course you will still need the mechanic device to swipe the card, which can be the one I describe in my reader page. If you want to read magnetic stripe cards using a computer without sound card you can still use my original reader.

Setup

As I said above if you have a computer with a sound card with microphone input (all cards I know have such input) you only need a magnetic head to read magnetic stripe cards. The head has to be chosen such that the size of the track matches that of the magnetic stripe. I found that the size of the track of a normal mono audio cassette player is a little bit smaller than required but it works well. Using a stereo audio head is not recommended but it will likely work if you use just one of the two tracks. I use a 1.5 meter long twisted pair thin cable to connect the mono audio head to the microphone socket using a mono jack connector. If one of the pins of the magnetic head is connected to its case you should connect this pin to ground, which is the side of the jack closer to the cable (rear part). Now you only need some mechanical device to swipe the card, see my first reader page for a particular design.

Some sound cards have a stereo socket for the mic input, providing around +5v DC current in the middle connector (jack's ring), although I've seen at least one card with the +5v output in the outer connector (jack's tip), see here for details. If you use a mono jack connector (tip and ring shorted together) then this DC current is applied to the magnetic head and it might be enough to erase magnetic stripes (it happened to me with one sound card, I erased accidentally a couple of magnetic stripes while trying to read them), so you might consider adding a capacitor (around 200 nF should be fine) in series with the head to avoid this DC current. Of course you can use a stereo jack and leave the ring (or the tip) open, but anyway it's a good practice to measure the voltage before connecting the magnetic head to be sure there will be no DC current when you connect the head.

To read data using my software you will need Linux running in your computer with the sound card configured to be used. You will also need a C compiler, the sox utility, a mixer (aumix, kmix, gmix, xmixer, asmixer, ...) and the C shell, don't worry, all these utilities are included in any Linux distribution. The software I wrote consists of a shell script (don't forget to activate the execution permission, the download will remove it) and a C program which you will have to compile (see source for instructions). Of course you can develop your own program to read data using Windows (sox is available for that platform), for example, but please don't ask me to do it. If you do not have and do not want to install Linux (you don't know what you are missing ;-) you still have the choice to run Linux on CD and use my programs, see my page running Linux without installing it. Actually I have a prepared 700 MB Knoppix ISO image which has the source codes and the compiled binaries. See the mentioned page for instructions.

Using the software

Read More...
http://www.gae.ucm.es/~padilla/extrawork/soundtrack.html

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

From Wikipedia, the free encyclopedia (Redirected from Card Verification Value)

 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 is located on the back of MasterCard, Visa and Discover credit or debit cards and is typically a separate group of 3 digits to the right of the signature strip.
On American Express cards, the Card security code is a printed, not embossed, group of four digits on the front towards the right.

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)[1] are different terms for security features for credit or debit card transactions, providing increased protection for the merchants against credit card fraud.

Contents

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.[2] 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"

Security benefits

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.[3] 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.[4] 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.

Limitations

  • 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).[5]
  • Since the CSC may not be stored by the merchant for any length of time[3] (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.[6][7]

See also

References

  1. ^ "Authorize.Net - Developer Frequently Asked Questions:". Retrieved 29 March 2009.
  2. ^ "Card Security Features" (PDF). Visa.
  3. ^ a b "Rules for Visa Merchants" (doc). p. 1.
  4. ^ "Official Source of PCI DSS Data Security Standards Documents and Payment Card Compliance Guidelines". Pcisecuritystandards.org. Retrieved 2011-12-25.
  5. ^ "Urban Legends Reference Pages: Visa Fraud Investigation Scam". Snopes.com. Retrieved 2011-12-25.
  6. ^ "z/OS Integrated Cryptographic Service Facility Application Programmer’s Guide". IBM. March 2002. p. 209.
  7. ^ "z/OS Integrated Cryptographic Service Facility Application Programmer’s Guide". IBM. March 2002. p. 258.

External links

[hide]

Major cards

Regional and specialty cards

Defunct cards

Accounts

Interest

Payment

Interchange fee

Technology

Security/crime


Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)