So Squareup.com gives you credit card merchant services on your phone... but the reader can read any magnetic stripe... when you swipe things like drivers licences or gift cards you can read data into the square program and show the last for digits of an id or something, but what else is on there? Thats where all you internet people come in... i need some engineers who are smarter than me to give me some guidance on how to decode the signal the card reader produces. Ive found some of what I think I need here on "A Day in the Life of a Flux Reversal" using a free spectrum analyzer app im able to see positive and negative waves as I swipe the card that seem to be alot like the flux lines the guy talks about...
But I thought my life would be much easier with data so I got a bunch of old cards and swiped them a few times each, recording the output from the square dongle so i can have some samples to decode with some known data
- Texas-Trust-Mastercard-5105-9400-0109-1438.mp3
In order to view this object you need Flash Player 9+ support!
- JCPenny-Gift-Card-6006492001928534134.mp3
In order to view this object you need Flash Player 9+ support!
- HEB-Gift-Card-6006-49668-81060-07754.mp3
In order to view this object you need Flash Player 9+ support!
- Dave-Busters-94937573.mp3
In order to view this object you need Flash Player 9+ support!
- Carnival-Sign-Sail-05411183.mp3
In order to view this object you need Flash Player 9+ support!
- AMC-Gift-Card-6006491324135697820.mp3
In order to view this object you need Flash Player 9+ support!
So if anybody wants to help me build an open source app to decode the data off other cards with the square reader drop me a line im @cartercole
Also: based on what ive seen from this instructable called "Magnetic stripe card spoofer" with just a little tinkering you could play back these recordings into an electromagnet and drive the reader to spoof the data you recorded. I know.. like super cool spy toys :) I now take this time to remind you that neither CarterCole.com or Carter Cole condone illegal activity and all information shared here is for curious who are people without malicious intent ( do you think that disclaimer protects me? )
Decompiling their .apk reveals some interesting things. Reviewing some of the information in their exposed repository also reveals some interesting things. From the brief look I had at it, they're recording audio of the mag swipe (no surprise there) and the file is sent to their servers for analysis. Constant track markers in the card (a question mark, a semi-colon, etc.) set the starting and ending calculation points. Because a card can swipe at different speeds, the frequencies in the audio capture can be higher or lower. So the markers are located to determine their frequency and compare the rest of the frequencies against them. Since there's one at the beginning and end of a Track2, if the frequencies aren't within the same relative range per swipe, the server will reject the swipe and require it to be done again. So inconsistent speed during the swipe would cause a failure in card data recognition.
ReplyDeleteOnce a card is identified on the server, the partial data (last four digits, name, etc.) are returned to the handheld device for confirmation and use. My guess is that a transaction ID is also sent with that data so that when it is completed, the device is just responding with an amount, ID, and basic data (signature, time, etc.) but no complete card number. This would ensure PCI security compliance. FYI: The code I reviewed showed Track1 and Track2, so yes, it's pretty useful for almost all cards out there. Track3 is not very commonly used.
I saw in the code that the audio file from the card swipe is immediately tossed, so the application has no lasting memory of the event or data. You may be able to deconstruct the data frequencies to actual numbers/letters/symbols, but given the variations of speed in swiping, and the variety of cards available to swipe, you've got your work cut out for you to duplicate what they've done. The physical card swiper is about as simple as designs go. But the backend work to interpret it...that's got some good heads designing that. Even obtaining their mobile platform source code would not reveal the translation process they're using to result a card number. They did it right: server side (cloud) for the important stuff, dumbed down front-end for everything unimportant. I haven't taken the time to run Shark on the device to identify protocols/data/destinations, but attempting to identify and track their servers is probably not the smartest idea.
Decompiling their .apk reveals some interesting things. Reviewing some of the information in their exposed repository also reveals some interesting things. From the brief look I had at it, they're recording audio of the mag swipe (no surprise there) and the file is sent to their servers for analysis. Constant track markers in the card (a question mark, a semi-colon, etc.) set the starting and ending calculation points. Because a card can swipe at different speeds, the frequencies in the audio capture can be higher or lower. So the markers are located to determine their frequency and compare the rest of the frequencies against them. Since there's one at the beginning and end of a Track2, if the frequencies aren't within the same relative range per swipe, the server will reject the swipe and require it to be done again. So inconsistent speed during the swipe would cause a failure in card data recognition.
ReplyDeleteOnce a card is identified on the server, the partial data (last four digits, name, etc.) are returned to the handheld device for confirmation and use. My guess is that a transaction ID is also sent with that data so that when it is completed, the device is just responding with an amount, ID, and basic data (signature, time, etc.) but no complete card number. This would ensure PCI security compliance. FYI: The code I reviewed showed Track1 and Track2, so yes, it's pretty useful for almost all cards out there. Track3 is not very commonly used.
I saw in the code that the audio file from the card swipe is immediately tossed, so the application has no lasting memory of the event or data. You may be able to deconstruct the data frequencies to actual numbers/letters/symbols, but given the variations of speed in swiping, and the variety of cards available to swipe, you've got your work cut out for you to duplicate what they've done. The physical card swiper is about as simple as designs go. But the backend work to interpret it...that's got some good heads designing that. They put the important work on a server - disconnected from prying eyes, and left a dumbed down front-end in our hands. They did it right. I haven't taken the time to run Shark on the device to identify protocols/data/destinations, but I wouldn't recommend you do that either. Chasing that idea is bound to take one in the path of oncoming traffic.
@mruvsc thanks for the info! the more i look into decoding the signal from the square device, the more difficult it seems, and it makes sense that they'd be sending this off to beefier servers for decoding.
ReplyDeletethanks again for the research.
Hi Carter, please contact me, I'd like to discuss this. Have been having some similar conversations. David. dpingram[at]gmail.com.
ReplyDeleteCheers
David
Interesting stuff here. Any new updates?
ReplyDeleteHey Carter, check out:
ReplyDeletehttp://www.informationweek.com/news/security/vulnerabilities/231300283
They talk about using it with software from:
http://www.makstripe.com
Perhaps they could assist with things or the software may help get a bite on it. I'd love to hear if any progress is made.
Isn't it dangerous for you to publish the sounds of your credit cards like this? Suppose I started up Square on my phone, and when it asks me to swipe a card, I will feed it your sound recording and your card would get charged, no?
ReplyDeleteInteresting stuff here. Any new updates?
ReplyDeleteI want to know how to use it in order to make my own app that uses this reader in a game.
ReplyDelete