ATM. On the other side of the wire
In connection with the recently touched topic of ATM devices, the desire of the Habr to learn more about them, as well as the number of speculations from such a seemingly technically savvy audience, I decided to write this post. Unlike UserSide , which was mainly engaged in the physical maintenance of ATMs, and it seems to me that it is very far from those who actually write software for managing their host, I will talk about that side. Naturally, to the best of their knowledge, still too modest.
Since this is my first article on Habré, I apologize for, perhaps, excessive confusion.
The first thing I want to point out is everything that was said in the article and almost everything in the comments is true, but the truth is one-sided - it describes particular cases. And although these are special cases, in the manner in which the information is submitted, an unprepared reader may have the impression that this is only the way it was told. And although several opposite descriptions of situations appeared in the comments, no one sounded the main thing - all these are special cases.
One of the members of the forum, referring to his experience, insisted that any account (and in any currency) can be tied to a card in 5 minutes, someone else doubted. It really is. The possibility of this procedure is determined only by the capabilities of the software of the processing system itself, its support from the Internet / mobile bank, the desire of the bank to provide such services to the public and its desire to pay for this additional money to the system developer. In the system, to the development of which I have a relation, the map and the account are two different entities.
The 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 don’t remember at once. The token serves only to access the account. Moreover, as an account can be accessed through several tokens, a token can serve several accounts. For example, in one bank where our system works, during a card transaction you may be asked to indicate a specific account - if there are several of them linked to a card.
')
This feature is called “False PIN” (iPIN). The fact that some bank proposes to do it by default, as the main PIN, recorded on the contrary, serves only the purpose of easier memorization. Judging by the comments, I got the impression that not everyone understands this.
As far as I heard from colleagues, this feature is not very popular, because It has its negative sides (I do not know which ones). The fact is that it is used extremely rarely.
Again, this is not an immutable rule, it is made just for ease of maintenance. In our system, it is made in this way, I suspect that in all the others it is the same:
When inserting such a card, the host, instead of performing a transaction, requests current counters from an ATM (or an ATM application itself can determine such a card and send the counters right away — further applications). Next, there is a physical collection of the terminal with the introduction of new meters into it (this is done manually, but I heard with the edge of my ear that automatic polling of the tapes is also possible ... but it seems to me that now there is rarely any). After the ATM closes, the door presses down a special button called the supervisor button, and the ATM reports to the network at least that the “supervisor mode” sensor state has changed, at the most — its full state, including new counters (or maybe old ones — see in the chapter on applications). If the report contains information only about the sensor, the host itself 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 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, a command for the initial poll of the counters (before transferring the ATM to supervisor mode for collection) can be given from the host. Collection in this case may look like this: collectors arrive at the scene, call the processing center, the operator executes the command through the system, then everything is as in the first scenario.
Here it should be noted that all applications can be divided into 2 types:
The most important thing that distinguishes these schemes of interaction between a host and an ATM is which side stores intermediate data until a full-fledged transaction can form. This can happen, for example, in the case when 2 or more accounts are linked to the card, because The interaction script does not know the number of invoices in advance; it simply makes a transaction request and sends it to the host. The host rejects it with the reason "Need clarification" and sends a list of parameters that need to be clarified. And then there are two options:
When detecting a non-withdrawn card, the behavior is fully configurable - an 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 quite poor, there should be a UPS in the ATM). What to do if an incorrect PIN is entered, a false PIN is entered (if it exists), when the counter of invalid PIN is reset, if the card is captured, the host decides everything. If the host does not instruct the ATM to grab the card, it will not capture it, even if it is fake, stolen and lost at least ten times.
What to do with chip cards, if you could not read the chip, depends on the scenario settings. A narrower range of services may be offered, or it may simply refuse to serve. The same goes for the cards of other banks.
Which issuing algorithm to use and from where the ATM recognizes it - again, it completely depends on the setting. Of course, now, in the era of the mass Internet, it is more profitable for the host to perform all the calculations, and only issue commands to the ATM. However, for example, the Kaliginte object for managing CashDispenser (cash dispenser) also knows how to calculate the payout amount for different algorithms. In our system, we do not use this feature. Again, allowing the user to choose the issuance algorithm, or, as someone said in the comments, even specific denominations of bills completely depend on the bank’s desire to create such a scenario (well, of course, on the software’s capabilities).
The limit of 40 bills really comes from physical limitations - a pack of 40 banknotes is almost a centimeter thick. About the fact that the ATM simply refuses to issue an amount that can not be physically issued at once, with an unintelligible error - the fault of the script developer - that did not provide for a clear message about the reason. Everything is simple with Kalignite, it’s just plain HTML, as I’ve already mentioned above, actually a local site, and for NDC / DDC ATMs the host’s response may contain updated screens, the text on which, again, defines the host ... The Triton protocol is poorer , and he has few error codes, but Tritons in Russia, it seems, are not very common.
On those on which I have been tested, it is worth Windows XP. And I was tested with the Kalignite script, with NDC and DDC ATMs.
Here you go. I hope it was interesting and the chaos in my head diminished. The main idea I wanted to convey is absolutely EVERYTHING. Naturally, somewhere less, somewhere more, but this is more concerned with the deeper nuances than those that are visible at first glance.
Since this is my first article on Habré, I apologize for, perhaps, excessive confusion.
The first thing I want to point out is everything that was said in the article and almost everything in the comments is true, but the truth is one-sided - it describes particular cases. And although these are special cases, in the manner in which the information is submitted, an unprepared reader may have the impression that this is only the way it was told. And although several opposite descriptions of situations appeared in the comments, no one sounded the main thing - all these are special cases.
1. Cards and bills
One of the members of the forum, referring to his experience, insisted that any account (and in any currency) can be tied to a card in 5 minutes, someone else doubted. It really is. The possibility of this procedure is determined only by the capabilities of the software of the processing system itself, its support from the Internet / mobile bank, the desire of the bank to provide such services to the public and its desire to pay for this additional money to the system developer. In the system, to the development of which I have a relation, the map and the account are two different entities.
The 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 don’t remember at once. The token serves only to access the account. Moreover, as an account can be accessed through several tokens, a token can serve several accounts. For example, in one bank where our system works, during a card transaction you may be asked to indicate a specific account - if there are several of them linked to a card.
')
2. PIN is the opposite for fraudsters
This feature is called “False PIN” (iPIN). The fact that some bank proposes to do it by default, as the main PIN, recorded on the contrary, serves only the purpose of easier memorization. Judging by the comments, I got the impression that not everyone understands this.
As far as I heard from colleagues, this feature is not very popular, because It has its negative sides (I do not know which ones). The fact is that it is used extremely rarely.
3. Cards collectors / supervisors
Again, this is not an immutable rule, it is made just for ease of maintenance. In our system, it is made in this way, I suspect that in all the others it is the same:
When inserting such a card, the host, instead of performing a transaction, requests current counters from an ATM (or an ATM application itself can determine such a card and send the counters right away — further applications). Next, there is a physical collection of the terminal with the introduction of new meters into it (this is done manually, but I heard with the edge of my ear that automatic polling of the tapes is also possible ... but it seems to me that now there is rarely any). After the ATM closes, the door presses down a special button called the supervisor button, and the ATM reports to the network at least that the “supervisor mode” sensor state has changed, at the most — its full state, including new counters (or maybe old ones — see in the chapter on applications). If the report contains information only about the sensor, the host itself 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 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, a command for the initial poll of the counters (before transferring the ATM to supervisor mode for collection) can be given from the host. Collection in this case may look like this: collectors arrive at the scene, call the processing center, the operator executes the command through the system, then everything is as in the first scenario.
4. Application on ATM
Here it should be noted that all applications can be divided into 2 types:
- the exchange protocol is strictly defined; on the ATM side, the program running under this protocol is being executed and cannot be expanded. 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 plugin to support communication with a specific host. This is how Kalignite ATMs are set up - by the way, the most flexible ones I have ever worked with. The Kalignite application is a regular .Net application, the screens displayed on the ATM screen are normal HTML pages displayed through the standard .Net component of the browser (which, in turn, is based on the IE kernel, that is, it has all its vulnerabilities. However, component is heavily trimmed). Thanks to this, the development of the visual part of the script can be done by web designers and enjoy all the benefits - for example, jQuery, virtual keyboard and everything your heart desires.
Since the ATM has a code that is written by the system developer himself, the execution of any service functions can be simplified significantly - for example, a collection transaction can be formed on the ATM itself and sent to the host as a normal transaction request (only this will be an administrative transaction).
The most important thing that distinguishes these schemes of interaction between a host and an ATM is which side stores intermediate data until a full-fledged transaction can form. This can happen, for example, in the case when 2 or more accounts are linked to the card, because The interaction script does not know the number of invoices in advance; it simply makes a transaction request and sends it to the host. The host rejects it with the reason "Need clarification" and sends a list of parameters that need to be clarified. And then there are two options:
- the terminal sends only the updated parameters - in this case, the host must somewhere store the information that the ATM sent in the previous request - the stateless ATM, the statefull host - all ATM programs with fixed protocols behave this way (NDC / DDC, Triton and others) because the protocol does not provide a place to store this data;
- the terminal sends all past data plus the specified parameters - a statefull ATM, stateless. This is best done when working with Kalignite, because you still need (preferably) to write your extension to communicate using a convenient host protocol.
5. Withdrawals and invalid IDs
When detecting a non-withdrawn card, the behavior is fully configurable - an 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 quite poor, there should be a UPS in the ATM). What to do if an incorrect PIN is entered, a false PIN is entered (if it exists), when the counter of invalid PIN is reset, if the card is captured, the host decides everything. If the host does not instruct the ATM to grab the card, it will not capture it, even if it is fake, stolen and lost at least ten times.
6. Chip cards
What to do with chip cards, if you could not read the chip, depends on the scenario settings. A narrower range of services may be offered, or it may simply refuse to serve. The same goes for the cards of other banks.
7. Maximum of 40 bills for issuing and issuing algorithm
Which issuing algorithm to use and from where the ATM recognizes it - again, it completely depends on the setting. Of course, now, in the era of the mass Internet, it is more profitable for the host to perform all the calculations, and only issue commands to the ATM. However, for example, the Kaliginte object for managing CashDispenser (cash dispenser) also knows how to calculate the payout amount for different algorithms. In our system, we do not use this feature. Again, allowing the user to choose the issuance algorithm, or, as someone said in the comments, even specific denominations of bills completely depend on the bank’s desire to create such a scenario (well, of course, on the software’s capabilities).
The limit of 40 bills really comes from physical limitations - a pack of 40 banknotes is almost a centimeter thick. About the fact that the ATM simply refuses to issue an amount that can not be physically issued at once, with an unintelligible error - the fault of the script developer - that did not provide for a clear message about the reason. Everything is simple with Kalignite, it’s just plain HTML, as I’ve already mentioned above, actually a local site, and for NDC / DDC ATMs the host’s response may contain updated screens, the text on which, again, defines the host ... The Triton protocol is poorer , and he has few error codes, but Tritons in Russia, it seems, are not very common.
8. Operating system
On those on which I have been tested, it is worth Windows XP. And I was tested with the Kalignite script, with NDC and DDC ATMs.
Here you go. I hope it was interesting and the chaos in my head diminished. The main idea I wanted to convey is absolutely EVERYTHING. Naturally, somewhere less, somewhere more, but this is more concerned with the deeper nuances than those that are visible at first glance.
Source: https://habr.com/ru/post/217337/
All Articles