I see a lot of videos showing withdrawals from ATMs with cloned EMV cards like code 201 so
how can be possible when a card uses DDA (dynamic keys) another question is cloned card just for magstripe because it is unencrypted or even EMV chip
It is a question that does not really belong to SO and due to the nature of what you are asking about, you may not receive a detailed answer. I will still try.
First of all, ATMs are online-only devices that do not need any form of Offline Data Authentication so DDA has little to do with them normally (there are exceptions from this rule, as usual).
There are still dynamic keys that are meant to provide security, nevertheless. A standard symmetric-key algorithm is used to generate online cryptogram and it is validated by the issuer. Symmetric keys are individual to each specific card and are not easily extracted (of course, nothing can be ever treated as 100% secure, but it would require a complex hardware attack to extract keys from a single card).
I assume your question about Service code 2xx, 5xx or 6xx is mostly revolving around magstripe data with no chip data available. In some situations (i.e. when card is mute) a fallback to magstripe transaction may happen. Normally, unattended devices should have this option blocked and decline such attempts but I would not bet there are no such devices around the world. You also need to consider that there are still devices that are not EMV-capable.
When it comes to magstripe data, they can be easily modified (for instance changing the service code) although such modification should be detectable. Same goes for using EMV track equivalent data on magstripe. In both cases, issuer is capable of detecting modification of the data or using it on different interface through the use of CVC/CVV which is encoded on a track and is created to cryptographically protect integrity of the track data. However, this requires to have proper implementation on the issuer side to detect and decline such attempts where cryptographic data from CVV or cryptogram are incorrect.
I am a software developer so I have quite a lot of reading to do on hardware. My questions is this :
My goal is to create an RFID tag that has dynamic data. So I plan to use a microcontroller to be the processor and input data to an RFID module. I have did some research on RFID in general, is it actually possible to change RFID/NFC tag values via wiring instead of and RFID writer?
I really hope someone could give me some guidiance on this.
There are commercial ICs available from different manufacturers - e.g. NXP's NTAG I2C or ST's ST25 Dynamic NFC Tags.
You can connect them to your µController and share data to a phone. Most conveniently in the form of an NDEF message, as this can be read by iPhones as well.
Also the other direction (phone to µC) works, e.g. for configuration or firmware upload purposes (restricted to Android).
Commercial rfid tags generally have a manufacturer assigned ID (similar to a MAC address. Additionally, programmable tags have a raw memory that you can directly write bytes into sections.
When you read one with a reader, you'll get back this ID and the byte contents of the section you ask for.
A more typical use would be using the id to access a dataset stored somewhere else. Storing data locally isn't impossible though, you can also get write once types, each memory section can't be overwritten. The accrual memory capacity tends to be extremely small, like long url only.
I have one stupid question. I have mifare classic tags (1k). I want to hide content of this card (any data stored there). How to do it?
What about ndef records?
MFC (MiFare Classic) got reverse engineered completely, so storage should be considered read-write, and clear text, copiable/clonable, etc.
If you can afford encryption of the payload before putting it on the card, you may be able to make data confidential, but not "hide" it: third parties will be able to tell card is not blank, but will not be able to tell what is actually stored.
NDEF wont help you there.
MIFARE Classic allows to store data in sectors, which can be access protected. So authentication with the sector key needs to be done before any read operation (if configured that way).
"Generic" apps like NFC TagInfo usually try out "well-known" keys, before declaring a sector content "unknown". They don't try to hack the keys.
You can also use more advanced products, like MIFARE Plus or MIFARE DESFire, which both use AES cryptography for authentication and data encryption.
I bought a bunch of NTAG213 cards and have an ACR122U reader writer. I want to password protect each card with the same password, write a unique ID to each card, and use that ID to compare against a database in order to get an approval or declined response. I've studied the documentation and learned how the cards work via various tool, but my biggest question is, how do I actually send commands to the cards to read and write stuff in the system I'm thinking about creating? Is there a specific scripting tool or software I should be using to read and write or build upon?
Speaking about unique IDs, I've been told that each card has an ID, and that the pages that store the IDs can never be overwritten right? So is it safe to assume that if I bought one million NTAG213 cards, I'd never have to worry about a duplicate ID? If that is the case, is it possible for me to instead just write a program that reads the ID from each card and use that instead of writing an ID to each card? How can I get a program I'm writing to read that ID?
Sorry about bothering you guys with what may be a total beginner question, but I'm totally clueless and really want to learn. I'd really appreciate any help that I can get.
You should get in the habit of asking individual/specific questions on this site, it's not really a forum.
With that said...
How do I actually send commands to the cards to read and write stuff in the system I'm thinking about creating? Is there a specific scripting tool or software I should be using to read and write or build upon?
This is a "bad" question in that it's too broad for Stack Overflow. There are hundreds of tools available. Literally google "programming NFC" or something similar.
Speaking about unique IDs, I've been told that each card has an ID, and that the pages that store the IDs can never be overwritten right? So is it safe to assume that if I bought one million NTAG213 cards, I'd never have to worry about a duplicate ID?
This is a good question.
The ID can never be overwritten on most tags. Definitely not on the NTAG213.
Yes your reasoning is correct, but because the UIDs are not a standardised GUID/UID (e.g. Universally unique identifier - Wikipedia) and the IDs are set by manufacturers (and therefore are open to spoofing and perfectly legal situations where a manufacturer can produce 1 million tags with the same UID), there is no 100% guarantee, it is just statistically very unlikely and a practical assumption that you can make in most cases.
If that is the case, is it possible for me to instead just write a program that reads the ID from each card and use that instead of writing an ID to each card? How can I get a program I'm writing to read that ID?
Yes that approach is good, but I would consider adding another form of authentication too, because as discussed the tag IDs are not 100% unique. How to do it? It's a bit of a complex question, but if you're writing an Android app, you can simply use the getId() method with the nfc.Tag class Tag | Android Developers API.
As read on topic here How to find the unique serial number of a flash device? and especially here How to get manufacturer serial number of an USB flash drive? I know it is possible to get properties of hardware devices (particularly hard drives and usb drives...) using WMI Win32_PhysicalMedia and Win32_DiskDrive, which I'm getting done successfully.
However, I really want to know about the safety of these informations.
PhysicalMedia property SerialNumber returns the actual serial number of the main hard drive, while using other Win32_LogicalDisk and other calls we can map the drive letter of flash storage to actual Win32_DiskDrive device, and from there read properties like Name, Model, FirmwareRevision, SerialNumber, DeviceID, Manufacturer...
Now, DeviceID is generated by Windows / Pc itself, while SerialNumber should be the one that manufacturer added to the physical flash drive.
Manufacturer in most cases returns "Standard" something, Name is also of no use, while SerialNumber actually gets me a something that looks like unique ID, (I've read that in some cases this is not returned, so PNPDeviceID should be used instead? , Model gives the actual model of the flash drive, and FirmwareRevision just a number that could be used to add safety switch to the licensing, but is not vital.
However, the only one of these that seems / should be actually safe to use is SerialNumber, right?
So, the question here goes: Which level is Win32_DiskDrive actually reading this info from? Is it possible to fake that at all (Ok, letalone the actual lowlevel hacking stuff or driver injection etc...(??)), and if so, how hard it is?
If there's a known way / guide / example, I'd be also happy to read it. (not necessary info looking for here though.)
This is not for intention of bypassing some licensing. I'm making licensing for my SW, and am curious, whether it would be safe enough to use USB drive's SerialNumber property, and lock license against the presence of that USB flash, for which the license was bought for? Basically to use it as kind of a dongle, but not like the dongles actually work (using communication with the actual hardware inside the dongle...)
I know it may not seem as a safe solution, as flash drives dies quite often these days, or get lost etc, but this is just to add an option to my licensing from "Per PC" to "Portable - per USB device".
Thanks for any info!!!
EDIT:
I am completely aware that bypassing these kind of safety switches is very possible. Of course, even Windows itself is not licensed in a way that couldn't be hacked, nor Adobe, ProTools etc, (software that is widely used and costs a lot!).
But that wasn't a real question, and also, that's not the case for me -> the software will not be that expensive and not used by that much people, that I'd be afraid to drag interest in someone who will do extensive programming to make a patch/crack for it. Regular debugger use and workaround is pretty unlikely to be used by regular client who would need the software, ( and also, since it is something to be used in business environment, where stability is vital, I doubt they will really play around that...).
Main point here:
It is possible for sure, but: HOW hard is it to do for a regular person? (I know, the answer is: depending on your code.)
Main question of the post: Is it possible to change the ID on the USB itself, OR to make an app that will fake that data to my app? If it is, I'm sure it might be easier than making a crack/patch, that's why I wanted to know, whether WMI reads explicitly from hardware, or could one make an app that would pass fake data to it?
WMI just returns what the hardware tells it. It's as unique as the hardware. Which ultimately depends on the vendor.
But...
If someone has an administrator account to the computer†, then there are very few things that can be done to keep them from just hooking up the kernel debugger to your program and overriding your checks, or recording the raw USB communication session and replaying it on an unauthorized system. The real dongles do some to mitigate this, by having the hardware generate a response to a particular challenge. The challenge/response changes for each request, so it's not as susceptible to replay attacks, but the debugger tricks still work.
This is the real problem with the serial number approach. Uniqueness is not the primary concern for dongled software. The primary concern is unpredictability.
An illustrative example-
Let's say that I'm a bouncer at an exclusive night club. We're so exclusive that you have to answer a question to get in. You really want to get in, but no one will tell you the answer to the question. One night, you hatch a plan. You hang out in the alley and listen to the conversations that I'm having with the patrons trying to enter the club. It doesn't take you long to realize that I'm asking everyone the exact same question, and you're in. (This is the serial number approach)
After a while, I notice that there are a lot of people coming into the club that I've never seen before, and begin to suspect something. The people we really want to allow in are all given a card with a formula‡ on it. Whenever they come to the door of the club, I give them a number and they apply their formula and tell me the result. Since I also know the formula, I can tell if they are really allowed in. Now, even if you hear the entire challenge and response, without the formula, you aren't getting in. (This is one common approach taken by dongles.)
But what about the debugger? The debugger just made herself the club's owner, fired me, and can come and go as she pleases.
†Or has physical access to the machine and a password reset disk.
‡Stop laughing, this could totally happen. :)
Photo credit: Guillaume Paumier, CC-BY. Found on the Wikimedia Commons 7-Oct-15
Edit to address the question edit:
HOW hard is it to do for a regular person? (I know, the answer is: depending on your code.)
The question is how skilled is the 'regular person'? If you're talking about software/electrical engineers, then this is a trivial task. If you're talking about sales/marketing then it's a challenging task.
Is it possible to change the ID on the USB itself, OR to make an app that will fake that data to my app?
It depends and Yes. Changing the ID on the device itself is possible with some devices, and impossible with others. Software to spoof/man-in-the-middle the USB communication, or to create a virtual USB device is possible.
If it is, I'm sure it might be easier than making a crack/patch, that's why I wanted to know, whether WMI reads explicitly from hardware, or could one make an app that would pass fake data to it?
As I led with above, WMI reads from the hardware. This can be intercepted or bypassed.
Some ways to bypass the check:
Make a virtual USB device
Modify the USB MSD device driver to report the same serial number for all devices.
Build hardware using commercially available cheap host controllers that identifies with the same information as the authorized device. ($10 worth of raw components and a little bit of time.)
Redirect the system calls to/from USB to a compromised library.
Note also that:
Some places have restrictions on USB storage devices, ranging from discouraging their use, to outright bans. This would prevent your software from being used in sensitive computing environments processing private data, like credit cards, PII, trade secrets, classified information, etc. (In the US many governmental agencies have outright bans on USB storage devices, and block the install of any MSD.)
The Mass Storage specification doesn't require serial numbers. They are usually there, but they don't have to be, and many low-cost vendors
A USB PKI token costs a little bit more, but would probably do what you want. Here's an example from Safenet (Disclaimer: I am in no way affiliated with Safenet Inc, and you should evaluate all the possible options from all vendors. I suggested this because it was the first thing that came up through CDW, and the price was ~$30)