A good week everyone.
I'm working on a project to hack my city's transportation cards. The project boils down to accessing the card, reading the data, changing the balance (which is stored offline on the card) and bypassing the approval code that verifies the integrity of the data.
I'm well advanced in the project but I got stuck in that last part, I have no idea how to get around it. Below I will give more details:
We are talking about Mifare Classic 1k/4k cards. The approval code in question is generated by a SAM module (Secure Access Module) and is stored in the last 8 bytes of the first block of sector 4. It is described in the company's documentation as “Signature of last transaction data (Validator)”.
I tested loading the card into a recharge terminal and analyzing the before and after data. Sector 7 (Recharge value sector) was changed in the corresponding bytes, and sector 4 (Sector containing security information) was changed only in the SAM signature bytes and in the CRC-16bits bytes, referring to the blocks of sector 4.
Pre-charge sectors:
sector 04 / 0x04
00 0C 93 00 82 22 01 18 6D F2 26 20 D8 D1 36 FD | SAM 64bits = 6D F2 26 20 D8 D1 36 FD
00 80 60 00 40 1B 80 00 00 08 A8 E8 18 00 00 00 |
22 A3 9F 22 A0 00 00 00 00 00 00 00 00 00 FA 49 | CRC16bits = FA 49
00 00 00 00 00 00 F7 8F 00 00 00 00 00 00 00 00 |
sector 07 / 0x07
22 55 00 00 C8 44 91 40 8A 55 95 50 86 41 C7 A1 |
54 01 00 00 AB FE FF FF 54 01 00 00 21 DE 21 DE |
54 01 00 00 AB FE FF FF 54 01 00 00 21 DE 21 DE |
00 00 00 00 00 00 90 FF 06 00 00 00 00 00 00 00 |
Post-recharge sectors:
sector 04 / 0x04
00 00 00 00 00 00 00 00 FE 91 AC D1 33 C7 02 B6 | SAM 64bits = FE 91 AC D1 33 C7 02 B6
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
00 00 00 00 00 00 00 00 00 00 00 00 00 00 8B 1C | CRC16bits = 8B 1C
00 00 00 00 00 00 F7 8F 00 00 00 00 00 00 00 00 |
sector 07 / 0x07
22 55 00 00 C8 44 91 40 8A 55 95 50 86 41 C7 A1 |
A8 61 00 00 57 9E FF FF A8 61 00 00 21 DE 21 DE |
A8 61 00 00 57 9E FF FF A8 61 00 00 21 DE 21 DE |
00 00 00 00 00 00 90 FF 06 00 00 00 00 00 00 00 |
The SAM module is safely stored at official charging terminals. The data I showed above is from an unofficial terminal (they are quite common around here, I'm just another person trying to build my own machine). I'm trying to find out how this terminal in question managed to bypass this approval code.
I'm working with the possibility of it being a HalfMD5, as it is an 8-byte output in hexadecimal. However, I carried out several tests by hashing the data that was changed to try to arrive at the signature value and I was unsuccessful.
Initially I thought it was a chosen-prefix collision attack, but as the generated signature is completely new, I deduced that this attack would not be applicable to the situation.
Anyway, I would like a suggestion or help to generate this signature, or at least a guide for what I should study. I have a 24/7 study routine for this project, but for the last 3 weeks I've been stuck on this subscription and haven't been able to progress.
I'm working on a project to hack my city's transportation cards. The project boils down to accessing the card, reading the data, changing the balance (which is stored offline on the card) and bypassing the approval code that verifies the integrity of the data.
I'm well advanced in the project but I got stuck in that last part, I have no idea how to get around it. Below I will give more details:
We are talking about Mifare Classic 1k/4k cards. The approval code in question is generated by a SAM module (Secure Access Module) and is stored in the last 8 bytes of the first block of sector 4. It is described in the company's documentation as “Signature of last transaction data (Validator)”.
I tested loading the card into a recharge terminal and analyzing the before and after data. Sector 7 (Recharge value sector) was changed in the corresponding bytes, and sector 4 (Sector containing security information) was changed only in the SAM signature bytes and in the CRC-16bits bytes, referring to the blocks of sector 4.
Pre-charge sectors:
sector 04 / 0x04
00 0C 93 00 82 22 01 18 6D F2 26 20 D8 D1 36 FD | SAM 64bits = 6D F2 26 20 D8 D1 36 FD
00 80 60 00 40 1B 80 00 00 08 A8 E8 18 00 00 00 |
22 A3 9F 22 A0 00 00 00 00 00 00 00 00 00 FA 49 | CRC16bits = FA 49
00 00 00 00 00 00 F7 8F 00 00 00 00 00 00 00 00 |
sector 07 / 0x07
22 55 00 00 C8 44 91 40 8A 55 95 50 86 41 C7 A1 |
54 01 00 00 AB FE FF FF 54 01 00 00 21 DE 21 DE |
54 01 00 00 AB FE FF FF 54 01 00 00 21 DE 21 DE |
00 00 00 00 00 00 90 FF 06 00 00 00 00 00 00 00 |
Post-recharge sectors:
sector 04 / 0x04
00 00 00 00 00 00 00 00 FE 91 AC D1 33 C7 02 B6 | SAM 64bits = FE 91 AC D1 33 C7 02 B6
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
00 00 00 00 00 00 00 00 00 00 00 00 00 00 8B 1C | CRC16bits = 8B 1C
00 00 00 00 00 00 F7 8F 00 00 00 00 00 00 00 00 |
sector 07 / 0x07
22 55 00 00 C8 44 91 40 8A 55 95 50 86 41 C7 A1 |
A8 61 00 00 57 9E FF FF A8 61 00 00 21 DE 21 DE |
A8 61 00 00 57 9E FF FF A8 61 00 00 21 DE 21 DE |
00 00 00 00 00 00 90 FF 06 00 00 00 00 00 00 00 |
The SAM module is safely stored at official charging terminals. The data I showed above is from an unofficial terminal (they are quite common around here, I'm just another person trying to build my own machine). I'm trying to find out how this terminal in question managed to bypass this approval code.
I'm working with the possibility of it being a HalfMD5, as it is an 8-byte output in hexadecimal. However, I carried out several tests by hashing the data that was changed to try to arrive at the signature value and I was unsuccessful.
Initially I thought it was a chosen-prefix collision attack, but as the generated signature is completely new, I deduced that this attack would not be applicable to the situation.
Anyway, I would like a suggestion or help to generate this signature, or at least a guide for what I should study. I have a 24/7 study routine for this project, but for the last 3 weeks I've been stuck on this subscription and haven't been able to progress.
