Slashdot Mirror
Unlocking The Power Of the Magstripe
Acidus writes "While researching for an embedded systems project (a magstripe enabled Coke machine), I was shocked by the lack of magstripe information: Programs/code that would run on a modern OS were all but nonexistant, articles that were 6-10 years old, etc. Further research proved hard, because I had become google's authoritative source. So Stripe Snoop was born, and is now at 1.5 . Stripe Snoop is a suite of research tools that captures, modifies, validates, generates, analyzes, and shares magstripe data, with an ever-growing database of card formats. Decoding everything from driver's licenses to banking cards, its features can analyze non-standard cards, such as NYC's Metrocard."
There was also an interesting article in this summer 2600 magazine about magstrips. Some information and code were supplied...
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
Here's the real link to the article:
Linky.
It would be cool if it didn't suck.
http://www.yak.net/acidus/magstripe/coke.html
liqbase
I can imagine some card company out there will try and put a stop to this, purely to save their own skins for putting out fairly weak systems.
:)
Could be a useful tool though, I'd love to save car parking charges (place where I park sometimes uses magnetic cards)
When I was in college they had bar code scanners for the parking gates. That was easy enough to duplicate. But, right when I was leaving they switched to mag stripes. Now it's easy for a new generation to figure them out and make working cards.
Evolution or ID?
Hey all...
I have worked with developing Linux-based solutions with products from MagTek (manufacturer of hundreds of devices like stripe and card/check readers) and I have to point out that you may not find much information on the subject because the programming for such is so simplistic that a manual is not really needed. I am curious if other products from other providers work in a similar fashion.
MagTek devices will decode the stripes for you. The data contained within is sent to the computer in serialized format, so once the string of characters is received, you simply have to break the data into whatever pieces you need by looking for sentinal characters in ISO-defined positions. A dozen lines of code at most will handle this under most common programming languages.
When I was approached by my former employer to create a product with Linux and MagTek devices, (in mid-2000) I found absolutely no documentation on the devices whatsoever on the Net other than sales literature. The customer support personel did send me several pages of specs and such via FedEx Overnight, and when I received them, I saw that most of their then-current product line operated in a similar manner.
If possible, connect your reader device to some sort of I/O port and watch the data that is sent to the port with a terminal program (serial I/O in this case, similar methods used for parallel and USB-style interfaces...) Perform enough tests, and you should be able to get a more than adequate idea on how to parse the data sent.
In case you are really curious, go look at the older (now defunct?) Serial I/O HowTo at linux.org (or one of the mirrors). There are more than enough examples within to show you how to handle any type of serial-based interfacing project.
Hope this helps...
Brian
I't not like a federal offense or anything is it?
I have always been told to take the mag stripe keys from hotels I stay in and cut them up. I wonder what kind of personal info they actually do store on those cards.
Evolution or ID?
i was going post as AC but i dont want people not taking this seriously. i have had to research this technology deeply for legitimate and non legitimate applications for different clients. the reason there is little info or programs or source code -- as mentioned in an issue of 2600.
it is because that there is alot of poor win32 closed source software out there costing $1000 upwards!
all pooorly written in VB and the like by programmers whose pooor coding is more than obvious once a button is pressed or a menu selected.
ramcwin , rencode 2000 being obvious candidates.
it seems this is one of those few areas in software applications where even on the vast breadth of the internet a conspiracy of supression of knowledge . non open code. [not that the code is worth anything to learn from] in order to force the sale of ridiclous 1000 dollar licences for extremely poor code. my project i s free open source mag stripe oswftare compatible with as many reders and writesr as possible including portable code and libraries to embed in dumb terminals for people wanting to make thin open source terminal clients for EPOS systems.
i hate poor elite pricey specialised software.
for instance in a few months a large electronics chain has moved over to linux for their epos. i will make sure their "custom" software does not violate the gpl. [i just applied for a job !!]
Some newer card printers will actually write the magstripe as they print the card. The problem is that they're not too informative as to how you get the magstripe data into the printer to encode.
Usually this is achieved by a setting within the printer driver which defines which stripe (of the three) to write to and how to get the data out of the printing data. The sequence is usually marked out with start and stop character sequences (on Javelin printers these are usually "${n" and "}$" for start and stop, where n is the track number.)
This saves people the trouble of printing the cards and then writing them seperately.
Does anyone know how much data you can store on a typical strip?
When I was at school, in the physics lab, we had a jar of very fine iron powder that was used to demonstrate ferromagnetic liquids properties. We used to pour a little on the backside of a credit card, lightly shake the credit card to spread it around, and we could see the patterns left by the magnetic record on the stripes (which, incidently, weren't located where the visible black stripes were).
I imagine you could do the same with any magnetic card and a little fine iron sawdust that you could make yourself with a grinder.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Maybe you were mildly suprised?
Support the First Amendment. Read at -1
Having worked on retail apps, working with magstripes is a pretty trivial thing. Most magstripe readers are either RS-232 or keyboard wedge, and it's quite easy to tell where you have to look for the data you're interested in by just looking at what comes up when you swipe the kind of card you are interested in.
The biggest problem was dealing with keyboard wedge scanners - if your app expects some kind of event, or possibly a dedicated communication channel (like a serial port) you have to muck around with keyboard hooks to make it work.
Oolite: Elite-like game. For Mac, Linux and Windows
This project would open up to many more people if a more simplistic way of interfacing to the card reader was introduced. How 'bout via the soundcard?
I was poking around the links provided on the site, and found this: The simplest magnetic stripe reader. He wrote software to analyze the audio generated by the card when passed over the read head. This means that any old cassette player has a chance at being used to hack magstripes! Any comments on how accurate this method is, versus the F2F decoder chips?
I just got the idea of setting up a computer running Strip Snoop in a public place. Put a single board computer inside, a cheap LDC and card reader outside.
:-)
It should be made to look offical and be housed in an hard-to-destroy case. It would be bolted down on the sidewalk in the middle of the night, near an ATM or in a shopping center.
Have a big sign that says "what is REALLY on your magnetic cards?".
If you are an art student you could pull off doing something like that and get credit for doing instalation art.
Acidus was recently on episode 56 of Binary Revolution Radio (http://radio.binrev.com/) where we discussed his 2600 article and went into detail about his stripesnoop project. If anyone is interested in learning about the tech behind it or hearing about the thought processes that went into it, they should check it out.
--- The revolution will be digitized! - http://www.binrev.com/ ---
I just visited Singapore and those guys are like ten years into the future compared to us. Everything, and I mean everything, takes debit or credit cards.
From soda machines to subway ticket machines, etc.
It's strange that it's almost only credit cards that's used in the US. The only ones who gain from that is Visa and Mastercard. Debit cards without any fees is the future.
While researching for an embedded systems project (a magstripe enabled Coke machine)
In other words you wanted to get a Coke the other day and didn't have any spare change, right? :)
Couldn't access the site through the computer at work, it was blocked by the Internet filter, something about "Criminal skills". Only application that seemed to have anything to do with the Internet in the taskbar was a Symantec anti-virus/internet shield app. Now why is it a "criminal skill" to know about magcard readers?
Quality, performance, value; you get only two, and you don't always get to pick.
Anyone has been able to pick up a card reader cheaply for years, most office supply places sell them and that monster-battle toy had one. Or if you cant find one in a skip you could probably make something crude from an old tape-recorder (i guess?). Infact you can pick up an old ATM too! Most people wouldnt have a clue what to do with them, even if you get to the point where you can see the bits/bytes on a computer you still have to have some basic engineering knowledge and instinct to figure out each system or know who to ask. The problem is a quick fix is never quick, most systems will be proprietry code that was written years ago and editing even the slightest thing would require a whole lot of work and money. Hopefully most systems were designed well - its not like its hard, just make sure you understand the premise that anything on a strip is like anything written in pencil on the front of the card: it can be seen and changed by anyone.
This comment does not represent the views or opinions of the user.
I always wondered that. I've examined the doors closely and haven't seen any way for them to power the locks or communicate with them. I presume communication would be necessary to invalidate the access previously granted to lost or compromised cards.
I've just assumed that the power is delivered via hinges and wires buried in the door (which would mean custom doors or some sophisticated drilling to retrofit). I suppose you could have induction powering and communication of the reader via the door jam (simplifying installs).
Actually, many access control card schemes incorporate an "issue code" as part of the data on the card. Once a card with a "later" issue code in a sequence is used, the lock recognizes that "earlier" issue codes are no longer valid. No communication back to a server is needed, although any other offline locks to which a given card has access of course won't be updated until the new card is used in them. The sequence of available numbers for issues codes is simpply made large enough to make it impractical/improbable for someone to manage to cycle through the entire series just to cause an older card to become valid again.
And, on the subject of communications - some locks are fully "online" (and the communications and power cables are very unobtrusive), and others are offline (and communications may be done either manually on a periodic schedule, uploading the data from a reader via a PDA and then to a server, or wirelessly through an RF transmitter). In either case for offline locks, power can be supplied by a 'pack' of several rechargeable or replaceable AA batteries. If the hardware/processor/etc., in the door is optimized enough for power consumption, a single set of 4 AAs can last several months, making the maintenance sufficiently cheap.
I've just assumed that the power is delivered via hinges and wires buried in the door (which would mean custom doors or some sophisticated drilling to retrofit).
That retrofitting expense is why some facilities choose the wireless or offline versions.
Once a card with a "later" issue code in a sequence is used, the lock recognizes that "earlier" issue codes are no longer valid.
Presumably they don't honor newer issue codes UNLESS the "open" code also matches. If they did honor newer issue codes even if the open code was wrong, I could just DoS room locks when I checked in by swiping my card in everyone's lock..
From the site's FAQ:
Q: Why is keyboard based reader support so primitive?
A: Keyboard based readers, while cheap and easy to interface, have several problems. First off, The reader simply decodes each track that is present, from 1 to 3, appending each track to the next. No dividing characters are used, so it very difficult to detrimine where the decode for 1 track ends and the next begins. Not being able to reliably seperate the track data means we can't analyze it using our card database. For now, Keyboard based readers work best with cards that only have 1 track.
The keyboard-based reader I have, has dip-switches on it so you can put start and end markers around each track, and select which track you want. Sounds like the guy hasn't done much research on available card readers (or available card writers).
Also, the mag card format is an ISO standard so it isn't as if there is any mysterious behaviour going on here (apart from the non-standard card he mentioned).
Finally, in case anyone was under the wrong impression, having a mag card writer doesn't mean you can break anyone's bank account (bank cards don't contain security information). The worst you could do would be to copy someone else's card for a building security system, then rob it and try and blame the other guy (somehow I don't think this would be too successful).
I do a lot of kiosk and interactive exhibit work that utilizes magnetic stripe readers for a variety of purposes, from Fujitsu and NCR ATM machines, to POS systems from Symbol and @POS, to serial readers from MagTech to off the shelf keyboard wedge readers from ID Tech, and I never managed to run across Acidus' site when doing research. His app StripeSnoop looks fairly interesting as a tool. I wanted to point out that there is in fact a TON of information out there available from vendors and standards organizations from credit card track formatting, to ISO specs to you name it, they are all online. Its been said before, but you just need to spend a few minutes with google or talking to your hardware or software vendor and you can find what you need, you just need to dig around a bit. As an example, I recently spoke on the topic of Kiosks and Interactive exhibits at FlashForward 2004 in NY and along with some other things, I demonstrated an application for capturing track data from a keyboard wedge based card reader, and used the freely available specs from AAMVA (American Association of Motor Vehicle Administrators) http://www.aamva.org and their specs available here to decode drivers license information that conforms to their standard of encoding. I have used this in a couple of recent applications. I'm about to post up a version that decodes the most useful bits of credit card info (name, card number, expiration) that would be useful for integrating into POS systems, kiosks, etc. The source files (everything is done in Macromedia Flash Mx 2004 - yes not a lot of Flash fans on slashdot - but this is another example of how to use Flash for REAL applications) and more information can be found here: http://www.impossibilities.com/blog/entry_blog-155 .php - everything is released under Creative Commons Attribution-NonCommercial-ShareAlike 2.0 License - so have at it and start experimenting. It should be fairly simply to add in support for just about any type of track data you want to work with, at least data types that are compatible with keyboard wedge devices - its really just string manipulation and all you need to know are the rules for decoding the data. I use ID Tech's Omni Reader - a USB device that supports all three tracks and barcodes (including infrared barcodes) in one simple USB keyboard wedge device.
In the example I put together, youll also find an application for using off the shelf bar code scanners like Symbols - that also hook up via a keyboard wedge interface - to look up UPC info from the free UPC Internet Database. Enjoy! -Rob
Yes, I've been to Europe a few times over the last several years and was interested to see those portable credit card terminals that they bring to your table at restaurants. We have nothing of the like in the U.S. (unless you're talking some really large, fancy place that has developed its own wireless handsets for waitstaff).
... ready for it? ... telephone system.
... fancy, smart-chipped credit cards never really take off when the banks try them, because who wants a credit card that you can't count on at most restaurants etc.?
The way it was once explained to me is that it has everything to do with the
In the United States, local telephone calls are essentially free. There are local points-of-presence for all the major credit card validation services, so restaurants can use a standard business phone line to call out to validate an infinite number of credit card transactions at a flat rate for phone service. Because of this, credit card infrastructure in the U.S. has been built up around automatic verification of all credit card transactions. Our credit cards don't come with smart chips or the like, because there's simply no real reason for them. The perception by industry is that it's much easier to just call up and verify your credit directly with the bank than to rely on some "unproven" technology like a smart chip.
And so, given no smart chips, there are no "advanced" authentication schemes like the ones you mention. There are a couple of cards that have rolled out devices like you describe that you can use at home for Internet transactions, but I've never heard of a place of business that supports them. And so, it's a chicken-and-egg problem
It's much easier to launch an entire new credit card product (like Discover, which is still not accepted in Europe but was rolled out in the U.S. maybe 10 years ago) than it is to add a smart chip to Visa cards, because the new card can ostensibly use the same magnetic stripe readers with just a firmware upgrade or something.
The other thing is, I think the cost for the credit card companies to insure themselves against fraud is a lot less than it is to implement new technology. Right now, if somebody steals your credit card in the U.S., walks into a store and purchases something with it, the merchant is going to be the one who comes up liable, nine times out of ten. The merchat will get back neither the merchandise nor the funds from the fraudulent transaction, and the credit card company goes on about its business. So where's the incentive for the credit card industry to reform its security?
Breakfast served all day!