Proxmark3 community
Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Announcement
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Pages: 1
#1 2018-12-09 16:03:42
- schlumpfpirat
- Contributor
- Registered: 2018-03-13
- Posts: 2
Understanding MIFARE Classic Cards
So I've been trying to make some sense of how the PM3 works for some weeks now, but I cannot quite make sense of how functionality is interconnected on sth more complex than Low Frequency cards.
Example:
Way before I ever got my hands on the Proxmark3, I've been fascinated with tinkering with IT protected system and got a Chinese RFID Scanner supporting multiple protocols. I'm sure most of you have seen it before; it's quite straight forward and can SCAN+WRITE a card in a matter of two button presses. Here's a sample output, showing the UID of a MIFARE 1k card. (which I have already copied using this scanner, simply by pressing WRITE)
Proxmark3:
How ever the China Scanner obviously quite limited in its functionality due to its closed and non-updatable firmware. That's why I got the Proxmark3, thinking it would provide more flexibility and potency for more complex cards. But trying to read the exact same card turned out to be somewhat confusing and overly tedious using the Proxmark3, especially as the UID doesn't seem to match. Starting as follows:
NullX:~ 401$ proxmark3 /dev/tty.usbmodem14101
Prox/RFID mark3 RFID instrument
bootrom: /-suspect 2018-08-12 15:49:48
os: /-suspect 2018-08-12 15:50:29
fpga_lf.bit built for 2s30vq100 on 2015/03/06 at 07:38:04
fpga_hf.bit built for 2s30vq100 on 2017/10/27 at 08:30:59
uC: AT91SAM7S512 Rev A
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 512K bytes. Used: 194008 bytes (37). Free: 330280 bytes (63).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
proxmark3> hf search
UID : 6b 52 dX XX
ATQA : 00 04
SAK : 08 [2]
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1
proprietary non iso14443-4 card found, RATS not supported
No chinese magic backdoor command detected
Prng detection: HARDENED (hardnested)
Valid ISO14443A Tag Found - Quiting Search
proxmark3> hf 14a read
UID : 6b 52 dX XX
ATQA : 00 04
SAK : 08 [2]
Field dropped. I'm thinking why does hf 14 read drop the fields and what could I do with this information; why do I not see the same UID as on my China scanner, even when HEX decoding the UID I got from the Proxmark.
So continuing in order to figure out and eventually clone/simulate this card, I proceed with the suggested hardnested attack.
Side note: Wish I could've bought the Proxmark3 Rdv4, but it launched days after I ordered my other one. Bad luck. :(
proxmark3> hf mf hardnested 0 A ffffffffffff 1 A
--target block no: 1, target key type:A, known target key: 0x000000000000 (not set), file action: none, Slow: No, Tests: 0
Using AVX2 SIMD core.
time | #nonces | Activity | expected to brute force
| | | #states | time
------------------------------------------------------------------------------------------------------
0 | 0 | Start using 12 threads and AVX2 SIMD core | |
0 | 0 | Brute force benchmark: 1808 million (2^30.8) keys/s | 140737488355328 | 22h
1 | 0 | Using 235 precalculated bitflip state tables | 140737488355328 | 22h
4 | 112 | Apply bit flip properties | 11542412132352 | 2h
6 | 224 | Apply bit flip properties | 8551861321728 | 79min
7 | 335 | Apply bit flip properties | 8380193177600 | 77min
8 | 447 | Apply bit flip properties | 8378623459328 | 77min
9 | 557 | Apply bit flip properties | 8378623459328 | 77min
10 | 668 | Apply bit flip properties | 8378623459328 | 77min
11 | 780 | Apply bit flip properties | 8378623459328 | 77min
12 | 890 | Apply bit flip properties | 8378623459328 | 77min
13 | 1001 | Apply bit flip properties | 8378623459328 | 77min
14 | 1111 | Apply bit flip properties | 8378623459328 | 77min
15 | 1221 | Apply bit flip properties | 8378623459328 | 77min
16 | 1331 | Apply bit flip properties | 8378623459328 | 77min
17 | 1442 | Apply bit flip properties | 8378623459328 | 77min
20 | 1551 | Apply Sum property. Sum(a0) = 0 | 115630923776 | 64s
20 | 1660 | Apply bit flip properties | 115630923776 | 64s
21 | 1769 | Apply bit flip properties | 114275516416 | 63s
22 | 1879 | Apply bit flip properties | 114275516416 | 63s
23 | 1879 | (1. guess: Sum(a8) = 0) | 114275516416 | 63s
27 | 1879 | Apply Sum(a8) and all bytes bitflip properties | 39565250560 | 22s
96 | 1879 | Brute force phase: 24.77% | 30538059776 | 17s
98 | 1879 | Brute force phase completed. Key found: ffffffffffff | 0 | 0s So cool, I got the same key I specified above using hardnested, so the only other option I can remember to get some actual input is to use some script, because most of the hf commands seem to be somewhat redundant due to their lack of usefulness nowadays anyways.
proxmark3> sc run mfkeys.lua
--- Executing: mfkeys.lua, args ''
This script implements check keys.
It utilises a large list of default keys (currently 92 keys).
If you want to add more, just put them inside mf_default_keys.lua.
Found a NXP MIFARE CLASSIC 1k | Plus 2k tag
Testing block 3, keytype 0, with 85 keys
Testing block 3, keytype 1, with 85 keys
Testing block 7, keytype 0, with 85 keys
Testing block 7, keytype 1, with 85 keys
Testing block 11, keytype 0, with 85 keys
Testing block 11, keytype 1, with 85 keys
Testing block 15, keytype 0, with 85 keys
Testing block 15, keytype 1, with 85 keys
Testing block 19, keytype 0, with 85 keys
Testing block 19, keytype 1, with 85 keys
Testing block 23, keytype 0, with 85 keys
Testing block 23, keytype 1, with 85 keys
Testing block 27, keytype 0, with 85 keys
Testing block 27, keytype 1, with 85 keys
Testing block 27, keytype 1, with 7 keys
Testing block 31, keytype 0, with 85 keys
Testing block 31, keytype 1, with 85 keys
Testing block 35, keytype 0, with 85 keys
Testing block 35, keytype 1, with 85 keys
Testing block 39, keytype 0, with 85 keys
Testing block 39, keytype 1, with 85 keys
Testing block 43, keytype 0, with 85 keys
Testing block 43, keytype 1, with 85 keys
Testing block 47, keytype 0, with 85 keys
Testing block 47, keytype 1, with 85 keys
Testing block 51, keytype 0, with 85 keys
Testing block 51, keytype 1, with 85 keys
Testing block 55, keytype 0, with 85 keys
Testing block 55, keytype 1, with 85 keys
Testing block 59, keytype 0, with 85 keys
Testing block 59, keytype 1, with 85 keys
Testing block 63, keytype 0, with 85 keys
Testing block 63, keytype 1, with 85 keys
________________________________________
|Sector|Block| A | B |
|--------------------------------------|
| 1 | 3 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 2 | 7 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 3 | 11 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 4 | 15 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 5 | 19 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 6 | 23 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 7 | 27 |FFFFFFFFFFFF|A9F953DEXXXX|
| 8 | 31 |FFFFFFFFFFFF|A9F953DEXXXX|
| 9 | 35 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 10 | 39 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 11 | 43 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 12 | 47 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 13 | 51 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 14 | 55 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 15 | 59 |FFFFFFFFFFFF|FFFFFFFFFFFF|
| 16 | 63 |FFFFFFFFFFFF|FFFFFFFFFFFF|
|--------------------------------------|
Do you wish to save the keys to dumpfile? [y/n] ?y
Select a filename to store to (default: dumpkeys.bin )
> gymkeys.bin
-----FinishedAight so I finally get what seems to be a full output of the card, and it seems like Sector 27B and 31B seem to hold the interesting information. So from my understanding I could finally clone/simulate the card, but yet the UID is not the same as displayed on the simple Chinese Scanner. So how are the IDs from the China Scanner (001430XXXX), the UID form the RAW output (6B52DXXX) and the one from the mfkeys (A9F953DEXXXX) in relationship to each other?
I'm probably missing something here, but thinking about automation. The Chinese Scanner can have some number/UID entered which is then used to write back to the card, so something like simulating 100 cards is just a matter of periodically increasing said UID. It's easy to understand and automate due to it's one-dimensional nature that kind of reminds of low frequency cards.
However it's quite unclear how a Brute Force operation like that could work on the Proxmark3 – given the MIFARE structure is known and only the UID changes – due to a) it's two-dimensional nature of handling MIFARE cards (– even tho it's likely the representation of the real world object) and b) lack of programmatically simulating cards. From my understanding all it can do is restore or simulate a card based on previous binary keydumps (as the one seen above) and not have them generated dynamically.
I literally read 15+ articles on its functionality and watched multiple videos, but there still seems to be some discrepancy at how things/features and operations are interconnected. I feel like there are alot of redundant and old features in the Proxmark3 that end up leading to confusion.
Last edited by schlumpfpirat (2018-12-09 16:05:15)
Offline
#2 2018-12-09 18:33:33
- piwi
- Contributor
- Registered: 2013-06-04
- Posts: 704
Re: Understanding MIFARE Classic Cards
Some answers to some questions:
"Field dropped" means that the High Frequency Electromagnetic field had been switched off by the Proxmark. The card is no longer energized.
The Proxmark shows the UID in hexadecimal notation, your Chinese Cloner shows it in decimal notation.
You had asked hardnested to find the key A for block 1 and gave it the key A for block 0. Block 0 and 1 belong to the same sector 0 and therefore have the same key
mfkeys tests a list of well known keys for each sector. All your sectors have Key A = FFFFFFFFFFFF and key B = FFFFFFFFFFFF with the exception of sectors 6 and 7 (note that mfkeys lists the sectors from 1 to 16, while 0 to 15 is the sector numbering defined by NXP documentation). Those sectors have Key B = a9f953def0a3.
Keys and UID are two different things
From the legacy Proxmark III documentation:
The Proxmark III is intended for users that are either competent hardware or software developers (preferably both). Users that do not understand the basic principles behind RFID may have difficulty using the device.
This may no longer be fully true but there is still some truth in it.
Offline
Pages: 1