In connection with the recently raised topic of ATM devices, Habr’s desire to learn more about them, as well as the simply overwhelming amount of speculation from such a seemingly technically savvy audience, I decided to write this post. Unlike UserSide, which was mainly involved in the physical maintenance of ATMs, and, as it seems to me, is very far from those who actually write software to manage its host, I will talk about “the other side”. Naturally, to the best of my knowledge, which is still too modest.
Since this is my first article on carding forum, I apologize for perhaps being too confusing.
The first thing I want to note is that everything said in the article and almost everything in the comments is true, but the truth is one-sided - it describes special cases. And although these are special cases, in the manner in which the information is presented, an unprepared reader may get the impression that it only happens as it was told. And although several opposing descriptions of situations appeared in the comments, no one voiced the main thing - all these are special cases.
One of the forum members, citing his own experience, insisted that any account (and in any currency) can be linked to the card in 5 minutes; someone else doubted it. This is true. The possibility of this procedure is determined only by the software capabilities of the processing system itself, its support from the Internet/mobile bank, the bank’s desire to provide such services to the population and its desire to pay additional money to the system developer for this. In the system, the development of which I am involved in, the card and the account are two different entities.
A card in our terminology is a token - just as a token is, for example, a password, a certificate, an identity document and some others, I can’t remember right away. The token is only used to access the account. Moreover, just as an account can be accessed through several tokens, a token can serve several accounts. For example, in one bank where our system operates, during a card transaction you may be asked to indicate a specific account - if several are linked to the card.
This feature is called “False PIN” (iPIN). The fact that some bank offers by default to make it like the main PIN, written in reverse, only serves the purpose of making it easier to remember. Judging by the comments, I get the impression that not everyone understands this.
As far as I heard from colleagues, this feature is not in great demand, because... has its negative sides (I don’t know which ones). The fact is that it is used extremely rarely.
Again, this is not a hard and fast rule, it is simply for ease of maintenance. In our system it is done this way, I suspect that in all others it is the same:
When such a card is inserted, the host, instead of performing a transaction, requests the current counters from the ATM (or the ATM application itself can detect such a card and immediately send the counters on its own - more about applications later ). Next, physical collection of the terminal occurs with the entry of new counters into it (this is done manually, but I heard out of the corner of my ear that automatic entry by polling cassettes is also possible... but it seems to me that this is rarely available now). After closing the ATM, the door presses a special button, called the supervisor button, and the ATM reports to the network at a minimum that the state of the “supervisor mode” sensor has changed, at the maximum - its full state, including new counters (and maybe also old ones - see . in the chapter about applications). If the report contains information only about the sensor, then the host independently requests the counters. At this point, the host can compare the new counters with the old ones and create a collection transaction. Again, I repeat, this is how it works for us, but this does not mean that it works this way everywhere. But since the scheme is very flexible and autonomous, it is probably used in almost any software product of this kind.
Instead of a card, the command for the initial poll of counters (before switching the ATM to supervisor mode for collection) can also be given from the host. Collection in this case may look like this: collectors arrive on site, call the processing center, the operator executes the command through the system, then everything is as in the first scenario.
It should be noted here that all applications can be divided into 2 types:
The most important thing that distinguishes these schemes for interaction between the host and the ATM is which side stores the intermediate data until a full transaction can be formed. This can happen, for example, when 2 or more accounts are linked to the card - because... The interaction script does not know the number of accounts in advance, it simply generates a transaction request and sends it to the host. The host rejects it with the reason “Clarification required” and sends a list of parameters that need to be clarified. And here there are two options:
The behavior when detecting an uncollected card is fully customizable - the ATM can either capture it or leave it in the path. The same applies to issuing a card before/after money, at the beginning/end of work, during a power outage (if the bank is not completely poor, the ATM should have a UPS). What to do if an incorrect PIN code is entered, a false PIN is entered (if any), when the counter of incorrect PINs is reset, whether the card needs to be captured - everything is decided by the host. If the host does not instruct the ATM to capture the card, it will not capture it, even if it is at least ten times counterfeit, stolen and lost.
What to do with chip cards if the chip could not be read depends on the script settings. A narrower range of services may be offered, or they may simply refuse to serve. The same applies to cards from other banks.
Which dispensing algorithm to use and how the ATM knows it - again, completely depends on the setup. Of course, now, in the era of the widespread Internet, it is more profitable for the host to carry out all the calculations himself, and only issue commands to the ATM. However, for example, the Kaliginte object for managing the CashDispenser (cash dispenser) is also able to calculate the issue amount using different algorithms. In our system we do not use this feature. Again, allowing the user to choose the issuing algorithm, or, as someone said in the comments, even specific denominations of banknotes, depends entirely on the bank’s desire to create such a scenario (and on the capabilities of the software, of course).
The limit of 40 banknotes really comes from physical limitations - a pack of 40 banknotes is almost a centimeter thick. About the fact that the ATM will simply refuse to dispense an amount that cannot be physically dispensed at once, with an incomprehensible error - the fault of the script developer - that he did not provide a clear message about the reason. With Kalignite, everything is generally simple, it’s regular HTML, as I said above, actually a local site, and for NDC/DDC ATMs, the host’s response can contain updated screens, the text on which, again, is determined by the host... Triton’s protocol is poorer , and it has few error codes, but Tritons in Russia, it seems, are not very common.
The ones I tested on use Windows XP. And I tested with Kalignite’s script, with NDC and DDC ATMs.
Here you go. I hope it was interesting and the chaos in our heads was reduced. The main idea I wanted to convey is that absolutely EVERYTHING is customizable. Naturally, somewhere less, somewhere more, but this is more about deeper nuances than those visible at first glance.
Since this is my first article on carding forum, I apologize for perhaps being too confusing.
The first thing I want to note is that everything said in the article and almost everything in the comments is true, but the truth is one-sided - it describes special cases. And although these are special cases, in the manner in which the information is presented, an unprepared reader may get the impression that it only happens as it was told. And although several opposing descriptions of situations appeared in the comments, no one voiced the main thing - all these are special cases.
1. Cards and accounts
One of the forum members, citing his own experience, insisted that any account (and in any currency) can be linked to the card in 5 minutes; someone else doubted it. This is true. The possibility of this procedure is determined only by the software capabilities of the processing system itself, its support from the Internet/mobile bank, the bank’s desire to provide such services to the population and its desire to pay additional money to the system developer for this. In the system, the development of which I am involved in, the card and the account are two different entities.
A card in our terminology is a token - just as a token is, for example, a password, a certificate, an identity document and some others, I can’t remember right away. The token is only used to access the account. Moreover, just as an account can be accessed through several tokens, a token can serve several accounts. For example, in one bank where our system operates, during a card transaction you may be asked to indicate a specific account - if several are linked to the card.
2. Reverse PIN for scammers
This feature is called “False PIN” (iPIN). The fact that some bank offers by default to make it like the main PIN, written in reverse, only serves the purpose of making it easier to remember. Judging by the comments, I get the impression that not everyone understands this.
As far as I heard from colleagues, this feature is not in great demand, because... has its negative sides (I don’t know which ones). The fact is that it is used extremely rarely.
3. Cards of collectors/supervisors
Again, this is not a hard and fast rule, it is simply for ease of maintenance. In our system it is done this way, I suspect that in all others it is the same:
When such a card is inserted, the host, instead of performing a transaction, requests the current counters from the ATM (or the ATM application itself can detect such a card and immediately send the counters on its own - more about applications later ). Next, physical collection of the terminal occurs with the entry of new counters into it (this is done manually, but I heard out of the corner of my ear that automatic entry by polling cassettes is also possible... but it seems to me that this is rarely available now). After closing the ATM, the door presses a special button, called the supervisor button, and the ATM reports to the network at a minimum that the state of the “supervisor mode” sensor has changed, at the maximum - its full state, including new counters (and maybe also old ones - see . in the chapter about applications). If the report contains information only about the sensor, then the host independently requests the counters. At this point, the host can compare the new counters with the old ones and create a collection transaction. Again, I repeat, this is how it works for us, but this does not mean that it works this way everywhere. But since the scheme is very flexible and autonomous, it is probably used in almost any software product of this kind.
Instead of a card, the command for the initial poll of counters (before switching the ATM to supervisor mode for collection) can also be given from the host. Collection in this case may look like this: collectors arrive on site, call the processing center, the operator executes the command through the system, then everything is as in the first scenario.
4. ATM application
It should be noted here that all applications can be divided into 2 types:
- The exchange protocol is strictly defined, on the ATM side a program is executed that works according to this protocol and it cannot be expanded in any way. These are, for example, NDC, DDC and Triton.
- The exchange protocol is not only not rigidly fixed, but on the contrary, the application on the ATM is an extensible plug-in to support communication with a specific host. This is how Kalignite ATMs are designed - by the way, they are the most flexible of those I have ever worked with. The Kalignite application is a regular .Net application, the screens shown on the ATM screen are ordinary HTML pages displayed through a standard .Net browser component (which, in turn, is based on the IE core, i.e. has all its vulnerabilities. However, it itself component is greatly reduced). Thanks to this, web designers can develop the visual part of the script and enjoy all the benefits - for example, jQuery, a virtual keyboard and everything else your heart desires.
Since the ATM runs code that is written by the system developer himself, the performance of all service functions can be significantly simplified - for example, a collection transaction can be generated on the ATM itself and sent to the host as a regular transaction request (only this will be an administrative transaction).
The most important thing that distinguishes these schemes for interaction between the host and the ATM is which side stores the intermediate data until a full transaction can be formed. This can happen, for example, when 2 or more accounts are linked to the card - because... The interaction script does not know the number of accounts in advance, it simply generates a transaction request and sends it to the host. The host rejects it with the reason “Clarification required” and sends a list of parameters that need to be clarified. And here there are two options:
- the terminal sends only updated parameters - in this case, the host must store somewhere the information that the ATM sent in the previous request - stateless ATM, statefull host - this is how all ATM programs with a strictly fixed protocol behave (NDC/DDC, Triton and others) , because the protocol does not provide storage space for this data;
- the terminal sends all past data plus updated parameters - statefull ATM, stateless host. It’s better to do this when working with Kalignite, because... you still need (preferably) to write your own extension for interaction using a protocol convenient for the host.
5. Confiscation of cards and incorrect PINs
The behavior when detecting an uncollected card is fully customizable - the ATM can either capture it or leave it in the path. The same applies to issuing a card before/after money, at the beginning/end of work, during a power outage (if the bank is not completely poor, the ATM should have a UPS). What to do if an incorrect PIN code is entered, a false PIN is entered (if any), when the counter of incorrect PINs is reset, whether the card needs to be captured - everything is decided by the host. If the host does not instruct the ATM to capture the card, it will not capture it, even if it is at least ten times counterfeit, stolen and lost.
6. Chip cards
What to do with chip cards if the chip could not be read depends on the script settings. A narrower range of services may be offered, or they may simply refuse to serve. The same applies to cards from other banks.
7. Maximum of 40 banknotes for issuance and issuance algorithm
Which dispensing algorithm to use and how the ATM knows it - again, completely depends on the setup. Of course, now, in the era of the widespread Internet, it is more profitable for the host to carry out all the calculations himself, and only issue commands to the ATM. However, for example, the Kaliginte object for managing the CashDispenser (cash dispenser) is also able to calculate the issue amount using different algorithms. In our system we do not use this feature. Again, allowing the user to choose the issuing algorithm, or, as someone said in the comments, even specific denominations of banknotes, depends entirely on the bank’s desire to create such a scenario (and on the capabilities of the software, of course).
The limit of 40 banknotes really comes from physical limitations - a pack of 40 banknotes is almost a centimeter thick. About the fact that the ATM will simply refuse to dispense an amount that cannot be physically dispensed at once, with an incomprehensible error - the fault of the script developer - that he did not provide a clear message about the reason. With Kalignite, everything is generally simple, it’s regular HTML, as I said above, actually a local site, and for NDC/DDC ATMs, the host’s response can contain updated screens, the text on which, again, is determined by the host... Triton’s protocol is poorer , and it has few error codes, but Tritons in Russia, it seems, are not very common.
8. Operating system
The ones I tested on use Windows XP. And I tested with Kalignite’s script, with NDC and DDC ATMs.
Here you go. I hope it was interesting and the chaos in our heads was reduced. The main idea I wanted to convey is that absolutely EVERYTHING is customizable. Naturally, somewhere less, somewhere more, but this is more about deeper nuances than those visible at first glance.
