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
- Low cost
- Should be relatively easy
Disadvantages
- Long time needed to collect the information
- Every time a card is inserted, an authentication is performed
- After the unit is subtracted (~1 minute) the authentication takes place
- After the card is taken out, the machine needs about 5-10s to restart
- Need to connect memory to the collection device (laptop?)
- The need for an operator to pull and paste the card
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
- Speed of MITM
- MITM will be accelerated if there is the possibility to conduct eavesdropping undisturbed e.g. all night long
- Possibility to find an easier way to retrieve data
- There may be a chip in the phone that performs the data hashing - by examining it, the algorithm might be detected
- If I export the chip to my own board, I won't have to wait for the reset of the machine - this only affects when getting data using the MITM attack
- Possibility to use an encryption chip in an emulator
- Some Russian sites suggest that the encryption chip and memory can be used as an emulator
Disadvantages
- The need to steal the phone machine
- It can be hard
- You can be reported by random witnesses
- A stolen phone machine gets noticed, you can't hide it at home
- Possibility of injury during theft (230V in the machine)
- Ultimately, it may be useless
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
- Very Low Cost
- High rate of response retrieval (several per second, I reckon)
- Subtlety
Disadvantages
- Essentially, none
Attack on card hardware
-
Active
- This involves dissolving off the chip's cover layer and exploring its structure
- In this process, it is possible to read (P)ROM memories directly
- It is possible to interfere with the operation of the card, or eavesdrop on the various parts of the chip
-
Passive
- Essentially, it's an effort to examine the structure of the card using e.g. X-rays, or a terahertz camera, or some similar non-invasive device
- Assuming the program is in the (P)ROM, it should be easy to read it
- Unfortunately, the X-ray microscope doesn't seem to be used much (use an electron microscope instead?)
- Instead of a microscope, wouldn't a very sensitive film be enough?
Advantages
- Getting the algorithm as it is stored on the card
- Possibility of manipulating the chip, getting some interesting images :)
Disadvantages
- Need for access to advanced laboratory
- Need to obtain necessary toxic substances, or X-ray machine
- Knowledge of working with violently toxic substances
- Need for experience with similar work
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:
- Mathematical analysis
- It takes a cryptoanalyst with a deep knowledge of mathematics to make it happen.
- Downside; capable cryptoanalysts are a bit hard to come by.
- Bruteforce
- Since the microchip has very little power, I daresay the algorithm won't be very long because even the memory size for the program will be relatively small.
- The algorithm needs 160 CLK pulses to calculate one of the 16b hashes, which means the program should contain a max. 160 instructions.
- However, it has to be taken into account that some operations may need multiple CLK pulses for one result, so ultimately it may be less.
- On the other hand, some operations (such as incrementing a counter) can occur at the same time as other instructions, so there will actually be more primitive operations than 160. This fact will have to be taken into account when designing the cracker.
- An attack requires a mediocre programmer and a lot of power, which shouldn't be such a problem these days, especially if parallelism is used.
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
- Load the captured card contents, the random number and the resulting hash.
- The permutator generates a sequence of instructions to send to the interpreter.
- The interpreter gradually executes instructions, stores the captured card contents and a random number in registers or memory.
- The size of the output from the interpreter is measured - if it does not equal 16b, it proceeds directly to the next iteration.
- If the hash has passed the size test, it is compared to the recorded hash. If the hashes are the same, the current instruction sequence is stored in a log and the next recorded hash, card content and random number are loaded. Same instruction sequence is applied.
- If the hash passes even now, we can repeat the previous step, or write the instructions into a file and declare that the algorithm has been broken.
- If it fails to compare with the recorded hash, we send a signal to the permutator to generate a new sequence and the process is repeated.
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 about 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.
