Bystroushaak's blog / English section / Hardware / I used to be a phone card cracker / A path to the phone card emulator

A path to the phone card emulator

Declaration

This article is something like a mind game, something like chess without a chessboard. This game proposes individual actions and counteractions, attacks and defense, the discussion discusses what would happen if ..

If anyone decides to commit a crime on the basis of this article, it is only their decision and the author of this article definitely refuses to have anything to do with it. In other words; The author does not take any responsibility for the way in which readers may deal with the information contained in the article. If you, as a potential reader, disagree with this, plan to break the law or suspect that you would not be able to keep the information acquired in a theoretical way, I, as the author, do not give you permission to read the article any further. Otherwise, you may proceed.

Introduction

I wrote this text to organize my thoughts and at the same time summarize freely available information on phone card security on the Internet in a short article. The article further presents theoretical possibilities how to break the security, while (unfortunately ;) not giving a guide, but only information that should stimulate further discussion and thus move this thought game to the next round.

Maybe someone will think why even try, when today basically everyone has their own mobile phone, or can call via VoIP? I don't have a general answer to this question, but I can say that it's quite fun to try to get into a technology about which not much is known and which, moreover, remains uncracked for years (at least I don't know that anyone managed to emulate modern cards).

Phone card

As everyone probably knows, a phone card is a device that allows you to make calls, send SMS and emails from a so-called pay phone. Each card has information about the number of units stored in it in some way. If we insert the card into the machine, the card is validated first using the so-called challenge/response protocol. If the check is done correctly, the machine allows you to make calls (send emails, SMS, etc..) as long as there is a sufficient number of some kind of credit on the card. If the card verification is not done correctly, or there are no units on the card, the machine makes a high whistling sound and a prompt to remove the card appears on the display.

If you have read the previous paragraph carefully, you may have wondered how the units are stored on the card and whether it would be possible to add them again after the call. Unfortunately, with modern cards, something like this would not be possible.

In times long past, the units on the card were represented by (EE)PROM memory, which the automaton decremented by 1 after each reading. As is probably obvious to everyone, there were soon people who found out how to write on EEPROM and started to recharge their cards, or from EEPROM memory created emulators of PROM cards. Phone companies responded by adding a microprocessor to the simple memory, which allowed only to read the units. To make it impossible to emulate the card easily, a mechanism was added to verify if the card was genuine. This mechanism is called challenge/response and will be discussed in the next part of the article.

If someone is interested in the hardware details of the card, they can be found here; http://gsho.thur.de/gsho/phonecard/bin/phonecards_204.txt, or in ISO standards.

Description of the challenge/response protocol

The pay phone will ask for the content of the card after it has been inserted

The pay phone applies a hash function, into which 48b random number enters along with the card's contents

A pay phone sends a card the same random number (challenge)

The phone card uses the same hash function to calculate the response and send it to the phone

If both numbers match, the card is recognised as valid

A somewhat different description can be found here;

It follows from the above procedure that the only thing preventing the building of the card emulator is knowledge of the hash algorithm. Unfortunately, the algorithm is not easy to find, so I see only one possibility to find it using the methods below.

Possibilites of cracking the c/r

MITM sniffer

One of the easier options is to build a device to intercept the communication between the card and the machine. After collecting a certain number of records of the communication, it should then be enough to build a bruteforce cracker (discussed below) and try to break the algorithm.

Advantages

Disadvantages

Inspiration

Reverse engineering of the phone

This would involve stealing the machine and dissecting and examining it, searching for data in the memory, detecting protections and ultimately the possibility of MITM interception between the card and the machine at home.

Advantages

Disadvantages

Reverse engineering of the card

Fake phone

Basically, build a device that will act as the pay phone. If it sends random numbers to the card, the hash results of the function can be stored on the computer for later bruteforce, eliminating the need to build a MITM sniffer.

Advantages

Disadvantages

Attack on card hardware

Advantages

Disadvantages

Obtaining an algorithm from collected data

Certain sources indicate that the algorithm is based on the hardware functions of the processor, using the 48b sliding register, XOR and NXOR. The processor also contains three 9b, 6b and 5b counters with unknown function. Furthermore, there is a not inconsiderable probability that the algorithm resembles a CRC calculation.

The article on hw.cz mentions that to get one bit of hash it is necessary to send the card 160x CLK pulse. This implies that the algorithm runs sequentially for each bit and is theoretically made up of max. 160 instructions.

It follows from the above that the algorithm should look something like this:

Possibilities for algorithm reconstruction

I think that there are only two possible techniques:

Since the first choice is somewhat out of the realm of the ordinary geek, I think a brute-force attack will have to do.

Bruteforce cracker

A brute force attack should be greatly simplified because we know the input, the output, the approximate number of instructions, plus we know which operations the hash generation algorithm is probably using and which are not. All that remains is to write a program that attempts to reveal in what order the operations are applied, revealing the algorithm and allowing the emulator to be built.

Cracker, in my opinion, should look something like this:

Description of the cracker

It might be a good idea to build genetic algorithms into the cracker, but since I don't know much about them, I don't know how much their implementation would be appropriate in this case.

Conclusion

Finally, I would like to point out that this article is not perfect, I am not perfect, I am not even an expert on microprocessors or card security and therefore there is a relatively good probability that the article contains errors or inaccuracies. It is possible that some of the methods and options I have described are meaningless, or not working.

This article was not intended and is not intended to serve as a guide, but to stimulate a discussion abouthe the described methods. If anyone comes up with a comment or a substantive criticism, I'll be glad if he mentions it in the discussion on the article, or sends it to me in another way.

Sources

Become a Patron