Under the hood of ATM software
I read a lot on GT and Habré articles about bank cards, ATMs, and now I decided to contribute. Below I will try to talk about how an ATM works in terms of software.
Any ATM is essentially a computer with connected peripherals, a hardware manager, and a bank application itself that manages the entire economy. All decisions on the issuance of money takes the server. The ATM only collects information from the client and sends it to the server.
The minimum ATM set includes:
In order for manufacturers not to suffer from writing drivers, which are then unnecessary, and software developers did not suffer from a variety of management solutions for this or that piece of hardware, it was decided to unify the whole thing.
')
Thus, the CEN / XFS standard or just XFS appeared , which stands for eXtension For Financial Services.
The standard describes a client-server architecture consisting of a hardware manager and service providers (read the device drivers) that it manages. In the terminology of the standard, a “service provider” is a library that provides a specific set of functions for obtaining information about a device and managing it. This is usually a dynamic library containing a specific set of standard functions (Open, Close, GetInfo, Execute) each of which has a number of device-specific arguments.
All interaction with the equipment occurs through the XFS Manager API. For example, the Command parameter of the Execute function may have a value for the bill dispenser:
WFS_CMD_CDM_DISPENSE (a set of cassette money)
WFS_CMD_CDM_PRESENT (issuing bundles to the client)
For card reader:
WFS_CMD_IDC_RETAIN_CARD (card capture),
WFS_CMD_IDC_READ_TRACK (reading tracks)
There are several implementations of XFS managers (including open source) written in c ++ and, theoretically, service provider libraries written for one manager should also be suitable for everyone else, but in fact sometimes a library written by a specific vendor for a specific XFS manager, only works with this manager.
There is also Java XFS with its own libraries that are not compatible with classical managers.
Banking application - this is what you see on the screen when you approach the device. It is designed to collect data from the user, send this data to the host (server) and perform a response from the host. As in the case of iron (XFS), there are industry protocols ( NDC / DDC ), through which the application communicates with the host, loads the configuration and interprets it.
Any large manufacturer of ATMs (Wincor, NCR, Diebold) has its own implementation of both XFS and banking applications.
However, there is an alternative software on the market that meets all standards and is not tied to a specific vendor.
I will describe an ATM using the example of NDC as the most common protocol in Russia, but slightly less popular DDC has a similar operating principle.
At each time, the ATM is in one of the modes of operation:
In In service mode, the ATM is in one of the states (state), with the number from 001 to 999, and 25 character description string.
The first character of this string is the type of the state (denoted by the letters A..Z as well as a..z and some characters (, '.?)), It defines the totality. The remaining 24 characters are 8 decimal 3-digit numbers, each of which is a specific setting of the state (the screen number for the display, conditions for transition to the state, a list of actions). There can be any number of states of one type.
At the start of the service mode, the ATM automatically starts to execute state 000. Usually this is state A (Card read state). In this slot, an ATM displays a screen with an invitation to insert a card and puts the card reader into receive mode. The state is also responsible for reading the map and branching, depending on the results of this operation.
Below is an example configuration of a typical A state:
000 A001001011008004002001104
000 - state number
A - state type (Card read state)
001 - screen number (Screen number)
001 - the number of the state to which to go in case of successful reading of the card
011 - number of the state to which to go in case of card reading errors
008 - reading condition 1
004 - reading condition 2
002 - reading condition 3
001 - card return condition (immediately after reading or at the end of the operation)
104 - transition status if the card is unknown to the bank
Go through the parameters in more detail:
The type of the state - everything is clear: after determining the type of the state, the application knows how to interpret further parameters.
The screen number is a link to a line with a text description of the screen displayed during the operation of this state.
Not every state has a screen.
The screen can have a number from 000 to 999. Screens that differ by 100 usually reserve for different languages. Thus, screen 010 and screen 210 are most likely multilingual versions of the same screen. I will tell about screens a bit later.
The number of the transition state in case of successful reading of the card is what state the application will start to perform in case the card is recognized and the data is read successfully.
In addition to the States and screens in the ATM, there is another important configuration parameter - the financial institution table. The table of financial institutions contains data on which cards belong to which bank, how to parse the data read from the card tracks, and what to do depending on this data further. For example, if the card is local, you can perform one scenario, if the card is a third-party bank, then you need to ban the scenario branch with mobile payments and balance check.
The number of the transition state in case of problems with reading the card - if the card could not be read on any of the proposed conditions - go to the state specified in this parameter. As a rule, this is the J state (Close state) on which we give the card, show the screen with the offer to pick it up and activate the timer after the expiration of which the card retention mechanism will be launched. State J is also the last state in the case of a successful transaction.
Card reading conditions (3 parameters in a row) are bit masks, denoting the numbers of tracks that need to be read, and interaction with the chip in case of its presence.
For example, Read Chip, Read Track 2 and Track 1, Read Track 1. If at least one of the conditions works, then the other conditions are not met and the card is considered to be read. If none of the conditions is met, the card is considered unread.
Card refund condition - an ATM can return cards immediately after reading, or it can do so at the end after all operations are completed.
The remaining states are arranged in a similar way:
Moving on all these states , the application sooner or later reaches the state of interaction with the host State I (Transaction Request State). On this steve, a request is formed from data collected on past steates and sent to the server. The request is an ATM ID (Logical Unit Number), data from map tracks, data from previous transactions, data from amount buffers, pin block, function key presses (FDK buffer). Data is separated by a separator character. The server application receives the request and analyzes the FDK buffer — it is by the contents of this buffer that the host understands what the ATM wants. Then, depending on the decision, sends the answer which contains:
In a special buffer, the number of bills that need to be issued from each cassette is transferred (if this is a cash withdrawal operation). It is the number of bills, because the ATM does not know the nominal value of the money issued for it is just a piece of paper in cassettes.
Upon completion of the required actions, the application sends a confirmation to the host and proceeds to the specified state. As a rule, this is the J state already known to us. In case of any failure, the application sends a failure message to the host and waits for a new Transaction Reply with the transition to the new state.
The ATM screen is a field of 32x16 cells. The screen can contain both graphical and textual information, which is positioned relative to the cells. Fonts can be double the height.
The screen description is a string with text, interspersed with controlled characters, such as clearing the screen, positioning the cursor, font size. In most modern banks today, the text is used only when entering amounts, and in other cases the screen is just a solid picture. However, there are completely text screens.
An example of a screen displaying a picture from a table of pictures (\ 0c \ 1bP2018 \ 1b \ 5c)
It is on such screens that the state parameters refer.
A collection of state, screen, FIT, timers is called an ATM script. Each script has its own number. After loading the ATM and connecting it to the network, it sends a message to the host in which it reports its ID and configuration number. If the configuration needs to be updated - the host switches the ATM to “Out Of Service” mode and starts loading the necessary parameters of the new configuration. The last parameter is the configuration number. Similarly, the keys are loaded for encrypting the pin block, for the make-up, and the master keys.
Here, if in brief, the ATM is so arranged. I hope someone this information is useful.
What is an ATM?
Any ATM is essentially a computer with connected peripherals, a hardware manager, and a bank application itself that manages the entire economy. All decisions on the issuance of money takes the server. The ATM only collects information from the client and sends it to the server.
ATM iron
The minimum ATM set includes:
- card reader, for reading the client card
- pin-pad, to enter a pin-code and other information such as, for example, payment / withdrawal amount
- the function keys on the sides (4 + 4) are additionally connected to the pin-pad. In some modern ATMs they were replaced with a touchscreen.
- money dispenser
- various sensors, backlight
Who controls the whole zoo?
In order for manufacturers not to suffer from writing drivers, which are then unnecessary, and software developers did not suffer from a variety of management solutions for this or that piece of hardware, it was decided to unify the whole thing.
')
Thus, the CEN / XFS standard or just XFS appeared , which stands for eXtension For Financial Services.
The standard describes a client-server architecture consisting of a hardware manager and service providers (read the device drivers) that it manages. In the terminology of the standard, a “service provider” is a library that provides a specific set of functions for obtaining information about a device and managing it. This is usually a dynamic library containing a specific set of standard functions (Open, Close, GetInfo, Execute) each of which has a number of device-specific arguments.
All interaction with the equipment occurs through the XFS Manager API. For example, the Command parameter of the Execute function may have a value for the bill dispenser:
WFS_CMD_CDM_DISPENSE (a set of cassette money)
WFS_CMD_CDM_PRESENT (issuing bundles to the client)
For card reader:
WFS_CMD_IDC_RETAIN_CARD (card capture),
WFS_CMD_IDC_READ_TRACK (reading tracks)
There are several implementations of XFS managers (including open source) written in c ++ and, theoretically, service provider libraries written for one manager should also be suitable for everyone else, but in fact sometimes a library written by a specific vendor for a specific XFS manager, only works with this manager.
There is also Java XFS with its own libraries that are not compatible with classical managers.
Banking application
Banking application - this is what you see on the screen when you approach the device. It is designed to collect data from the user, send this data to the host (server) and perform a response from the host. As in the case of iron (XFS), there are industry protocols ( NDC / DDC ), through which the application communicates with the host, loads the configuration and interprets it.
Any large manufacturer of ATMs (Wincor, NCR, Diebold) has its own implementation of both XFS and banking applications.
However, there is an alternative software on the market that meets all standards and is not tied to a specific vendor.
I will describe an ATM using the example of NDC as the most common protocol in Russia, but slightly less popular DDC has a similar operating principle.
How does it work
At each time, the ATM is in one of the modes of operation:
- Power Up - Download
- Offline - No connection with the server, connect
- Supervisor - the collector or service engineer works
- Out of service - the ATM does not work, because it is defective, out of money, or just someone at the bank transferred it to this mode.
- In service - the main mode of operation, familiar to all those who have bank cards.
In In service mode, the ATM is in one of the states (state), with the number from 001 to 999, and 25 character description string.
The first character of this string is the type of the state (denoted by the letters A..Z as well as a..z and some characters (, '.?)), It defines the totality. The remaining 24 characters are 8 decimal 3-digit numbers, each of which is a specific setting of the state (the screen number for the display, conditions for transition to the state, a list of actions). There can be any number of states of one type.
In service mode
At the start of the service mode, the ATM automatically starts to execute state 000. Usually this is state A (Card read state). In this slot, an ATM displays a screen with an invitation to insert a card and puts the card reader into receive mode. The state is also responsible for reading the map and branching, depending on the results of this operation.
Below is an example configuration of a typical A state:
000 A001001011008004002001104
000 - state number
A - state type (Card read state)
001 - screen number (Screen number)
001 - the number of the state to which to go in case of successful reading of the card
011 - number of the state to which to go in case of card reading errors
008 - reading condition 1
004 - reading condition 2
002 - reading condition 3
001 - card return condition (immediately after reading or at the end of the operation)
104 - transition status if the card is unknown to the bank
Go through the parameters in more detail:
The type of the state - everything is clear: after determining the type of the state, the application knows how to interpret further parameters.
The screen number is a link to a line with a text description of the screen displayed during the operation of this state.
Not every state has a screen.
The screen can have a number from 000 to 999. Screens that differ by 100 usually reserve for different languages. Thus, screen 010 and screen 210 are most likely multilingual versions of the same screen. I will tell about screens a bit later.
The number of the transition state in case of successful reading of the card is what state the application will start to perform in case the card is recognized and the data is read successfully.
In addition to the States and screens in the ATM, there is another important configuration parameter - the financial institution table. The table of financial institutions contains data on which cards belong to which bank, how to parse the data read from the card tracks, and what to do depending on this data further. For example, if the card is local, you can perform one scenario, if the card is a third-party bank, then you need to ban the scenario branch with mobile payments and balance check.
The number of the transition state in case of problems with reading the card - if the card could not be read on any of the proposed conditions - go to the state specified in this parameter. As a rule, this is the J state (Close state) on which we give the card, show the screen with the offer to pick it up and activate the timer after the expiration of which the card retention mechanism will be launched. State J is also the last state in the case of a successful transaction.
Card reading conditions (3 parameters in a row) are bit masks, denoting the numbers of tracks that need to be read, and interaction with the chip in case of its presence.
For example, Read Chip, Read Track 2 and Track 1, Read Track 1. If at least one of the conditions works, then the other conditions are not met and the card is considered to be read. If none of the conditions is met, the card is considered unread.
Card refund condition - an ATM can return cards immediately after reading, or it can do so at the end after all operations are completed.
The remaining states are arranged in a similar way:
- There are states for reading the amount from the keyboard and placing it in a special internal buffer;
- There are states for reading the pin-code with a pin-pad and then receiving a pin-block in a special buffer;
- There are steits to verify the entered data (for example, if the entered amount is less than the minimum amount, then it is redirected to the state with an error message);
- There are states for selection using the side keys (called FDKs) and placing the keys of these keys (ABCD FGHI) into a special 8-byte buffer;
- There are states for zeroing and preset buffers.
Moving on all these states , the application sooner or later reaches the state of interaction with the host State I (Transaction Request State). On this steve, a request is formed from data collected on past steates and sent to the server. The request is an ATM ID (Logical Unit Number), data from map tracks, data from previous transactions, data from amount buffers, pin block, function key presses (FDK buffer). Data is separated by a separator character. The server application receives the request and analyzes the FDK buffer — it is by the contents of this buffer that the host understands what the ATM wants. Then, depending on the decision, sends the answer which contains:
- ID of the action to be performed;
- the number of the screen to be shown during this action;
- check contents, if the check needs to be printed;
- State to which you need to go on completion of the action.
In a special buffer, the number of bills that need to be issued from each cassette is transferred (if this is a cash withdrawal operation). It is the number of bills, because the ATM does not know the nominal value of the money issued for it is just a piece of paper in cassettes.
Upon completion of the required actions, the application sends a confirmation to the host and proceeds to the specified state. As a rule, this is the J state already known to us. In case of any failure, the application sends a failure message to the host and waits for a new Transaction Reply with the transition to the new state.
Now about the screens
The ATM screen is a field of 32x16 cells. The screen can contain both graphical and textual information, which is positioned relative to the cells. Fonts can be double the height.
The screen description is a string with text, interspersed with controlled characters, such as clearing the screen, positioning the cursor, font size. In most modern banks today, the text is used only when entering amounts, and in other cases the screen is just a solid picture. However, there are completely text screens.
An example of a screen displaying a picture from a table of pictures (\ 0c \ 1bP2018 \ 1b \ 5c)
It is on such screens that the state parameters refer.
A collection of state, screen, FIT, timers is called an ATM script. Each script has its own number. After loading the ATM and connecting it to the network, it sends a message to the host in which it reports its ID and configuration number. If the configuration needs to be updated - the host switches the ATM to “Out Of Service” mode and starts loading the necessary parameters of the new configuration. The last parameter is the configuration number. Similarly, the keys are loaded for encrypting the pin block, for the make-up, and the master keys.
Here, if in brief, the ATM is so arranged. I hope someone this information is useful.
Source: https://habr.com/ru/post/263077/
All Articles