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.
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.
Hello everybody ,I have several dumps of a 5 route ticket of the Greek transportation system which is using mifare ultralight MF0UL2101.
The dumps are from 4 passes (5th is missing )+ a reload + 2 passes after reload. They use 2 one way counters , 2nd for valid transactions and the 3rd for 5 passes reload.
My problem is the MAC (Message Authentication Code) .I think pages 21-32 are encrypted and contain the counter values(??) .Has anyone seen similar implementations ? Is there a standard encryption i should be checking ?
Sniffs :
https://www.dropbox.com/s/lz7f5uoq1whr83m/sniff.zip?dl=0
Thank you !
Last edited by solem89 (2017-11-05 19:45:24)
Offline
So, I was also doing some research on this Ultralight EV1 card. As you said they are using MF0UL21, which means that the total memory of the card is 164 bytes.
Again, as you mentioned, the card updates 2 one-way counters, one for the times used and the other one for the times a reload takes place. As you may know, these counters are not part of the readable memory space, but instead they can be read separately, using the READ_CNT command. When I was dumping the data from my card (using a NFC phone), I noticed that the third byte in address page 12 (dec) seems to represent the remaining trips of the card. And as far as I can see in your dumps the same byte follows that exact logic.
The last two address pages of the card (39 and 40 in dec) contain the password, which is required to write the user memory space. According to the datasheet, those bytes can only be written, not read. I still haven't tried any common passwords (like 00000000 or ffffffff) to see if I can get it to authenticate. I suppose it is worth checking. Of course, if you own a proxmark it would be rather helpful to try and sniff the communication between the card and a vending machine (which btw are these: Sigma ETS70). Here is a nice (related) thread regarding the italian EV1 card: http://proxmark.org/forum/viewtopic.php?id=2445
And a fun fact about that "well-thought" transportation system of Greece: First time I got my 5-trip card I validated it on a bus, displaying correctly on the screen that 4 trips remain. A couple of minutes later I reached a metro station and I checked my card on one of the vending machines and the only information on the card was "4 trips remain", no time of validation, no remaining time, no nothing. I asked a metro guy if I should re-validate the card if I'm gonna enter the metro and he said that since the card says 4 remaining trips, validating it again now would only decrease the remaining trips of my card to 3... even if it was only a few minutes later (each trip is supposed to last 90 minutes). After he gave it some thought, the same guy told me that the reason for this is that the bus hasn't uploaded the data yet to the system and this will probably happen when it gets to its last stop (which btw could be after 90 minutes)...
Offline
Yup, sniff password and pack, and the data mapping...
Once you have you can look to see if you can reset trips, or lock some blocks to enable "perma" free rides... or. or.. well, much to test...
Offline
I noticed that the third byte in address page 12 (dec) seems to represent the remaining trips of the card.
I saw that too , i tried changing the "remaining trips" address but nothing happened. It just got overwritten with the new value.
I still haven't tried any common passwords (like 00000000 or ffffffff) to see if I can get it to authenticate.
Each card has a unique password . No defaults
I also tried to tweak the one way counters (which i believe represent reloads and trips ) but then my card got invalidated. I used it and no output at all. That let me to believe that pages 21-35 are the hashed values of the counters that are checked when you validate your card .(Since the machine checks the counters and those pages )
Once you have you can look to see if you can reset trips, or lock some blocks to enable "perma" free rides... or. or.. well, much to test...
I also tried "lock attack" ,but the system also checks for "unusually" locked fields. It invalidated my card
Offline
Let me get this straight. You mean that you already have the pass of your card and after authenticating with it, you attempted making changes on it? Cause, as far as I can understand, without correct authentication, writing is not possible.
Also, what do you mean "tweak the one way counters"? You can only access the counters with READ_CNT and INCR_CNT commands (not sure about the proxmark equivalent ones). I can't imagine how increasing a counter would help you in this case.
Finally, at least in my card, all lock bytes are set to 0. That means that nothing is write-blocked. According to the memory organization of MF0UL21, there are 5 lock bytes, that can write-disable different memory blocks. Check sections 8.5.2 and 8.5.3 of the datasheet. One thing I would try is to lock the address page 12 (to disable decreasing of that third byte in that page) by setting the L12 bit of lock byte 1 to logic 1. But that comes after a successful write in the card.
To be honest though, if you do own a proxmark, I was hoping for a better analysis on the communication, as iceman mentioned, in order to maybe find a correlation between the pass/pack and uid of the cards. I will re-paste the link in the forum where imho the guys there are doing an excellent analysis regarding the Italian card: http://proxmark.org/forum/viewtopic.php?id=2445. I think we should aim for the same thing here.
Offline
The counters on a Ultralight EV1 tag can not be decreased or reseted. It can only be read or increased.
Nothing related with Pm3 in that matter.
Locked bytes states "locked", authentication states read/write permissions. Kind of strange with two similar protections on a tag,
I get the feeling the "locked" means no reversal possible, while r/w permissions allows for changes..
We would still need a loot of UID/PWD/PACK samples in order to figure out that pwd-gen-algo if there is one.
Offline
Locked bytes states "locked", authentication states read/write permissions. Kind of strange with two similar protections on a tag, I get the feeling the "locked" means no reversal possible, while r/w permissions allows for changes..
Yes, exactly. Once you authenticate, you can write pages 4-35 normally, as many times as you want. But if you lock a page through the locking bytes, the data there stays permanently. That's why I said "that comes after a successful write in the card", since in order to lock the bytes, you still need to be authenticated to set the corresponding locking bits.
Offline
Let me get this straight. You mean that you already have the pass of your card and after authenticating with it, you attempted making changes on it? Cause, as far as I can understand, without correct authentication, writing is not possible.
Yes I have the pass and I made changes on the card
Also, what do you mean "tweak the one way counters"? You can only access the counters with READ_CNT and INCR_CNT commands (not sure about the proxmark equivalent ones). I can't imagine how increasing a counter would help you in this case.
If you see my dumps ,after I reloaded the card counter2 got increased.So i imagined that counter2 holds reloads (5 trips),and counter0 10trips reloads(??).So i tried increasing counter 2 in order to "simulate" a reload . But it got my card invalidated
Finally, at least in my card, all lock bytes are set to 0. That means that nothing is write-blocked. According to the memory organization of MF0UL21, there are 5 lock bytes, that can write-disable different memory blocks. Check sections 8.5.2 and 8.5.3 of the datasheet. One thing I would try is to lock the address page 12 (to disable decreasing of that third byte in that page) by setting the L12 bit of lock byte 1 to logic 1. But that comes after a successful write in the card.
I have read the datasheet many times. Maybe I wasnt clear. Changing any lock byte ,even "irrelevant" pages (with no data),got my card invalidated
To be honest though, if you do own a proxmark, I was hoping for a better analysis on the communication, as iceman mentioned, in order to maybe find a correlation between the pass/pack and uid of the cards. I will re-paste the link in the forum where imho the guys there are doing an excellent analysis regarding the Italian card: http://proxmark.org/forum/viewtopic.php?id=2445. I think we should aim for the same thing here.
I dont own a proxmark but I own another device that gives me only the reader commands(no card responses).I will be posting soon all data gathered (5-6 sniff logs)
Offline
Without more data there is nothing to do.
Offline
You can find more data here
https://www.dropbox.com/s/lz7f5uoq1whr83m/sniff.zip?dl=0
Offline
The traces are bad. Its hard to make out sense from it.
The reader trasmissions look ok, but tag answers seem of.
On several READ commands, you don't get 18bytes answers.
Where there are a write command, and little bit later reader tries to read same block, the data doesn't match up.
There seem to be only UID, with one PWD, but PACK is different ( C124 vs 91A4 )
All of which seems to be coherent with your sniffer not picking up the tag responses correct.
UID | pwd | pack
---------------+----------+-----
04838F2A464E80 | 96130cea | c124
[edit]
you wrote that your device only pics up reader comm, which could explain that the strange bytes in between in the trace,m where the card should respond..
- that makes the PACK useless above..
Offline
you will need a better sniffing device, since the one you are using is kind of useless.
I suggest you buy yourself a proxmark.
Offline
you will need a better sniffing device, since the one you are using is kind of useless.
I suggest you buy yourself a proxmark.
Proxmark is too expensive for my curiocity .But why would i need it ? Since i have the reader commands dont i already know the tag answers from the card content ?
Offline
Good luck! I can not help anymore.
Offline
Why is it expensive when you get a lifetime free rides?
Just get a proxmark3 and a magic ntag21x to mimic everything and try it.
If your curiosity pays off, you will never pay another ride again like how some hackers have done it in their lifetime.
Nice story to tell the media too but don't link it to us.
Offline
Why is it expensive when you get a lifetime free rides?
I am not using public transport at all. And its not like that my current device is not working , it works just fine and I have all necessary information(reader commands and card dumps). I am sharing all gathered data cause I am out of ideas of how to approach this implementation. Maybe someone sees something I am missing ...
Any ideas are welcome
Offline
Ok, since the thread starter is too stubborn, I had to get a proxmark of my own. So I did get my PM3 RDV2.0 last week and since then I'm trying to get familiar with it. As you may have guessed I have a couple of questions but I'm going to focus on the problem at hand.
The hw version command on my PM3 returns the following:
Prox/RFID mark3 RFID instrument
bootrom: /-suspect 2015-11-19 10:08:02
os: /-suspect 2015-11-19 10:08:09
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2015/11/ 2 at 9: 8: 8
uC: AT91SAM7S512 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 512K bytes. Used: 169916 bytes (32%). Free: 354372 bytes (68%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
I haven't tried flashing a more recent firmware, but I will as soon as you advise me towards that in order to achieve what is needed.
Here is the info of my ticket:
proxmark3> hf mfu info
--- Tag Information ---------
-------------------------------------------------------------
TYPE : MIFARE Ultralight EV1 128bytes (MF0UL2101)
UID : 04 aa b7 a2 21 4e 80
UID[0] : 04, NXP Semiconductors Germany
BCC0 : 91, Ok
BCC1 : 4D, Ok
Internal : 48, default
Lock : 00 00 - 0000000000000000
OneTimePad : 00 00 00 00 - 00000000000000000000000000000000
--- Tag Counters
[0] : 00 00 00
- BD tearing Ok
[1] : 05 00 00
- BD tearing Ok
[2] : 01 00 00
- BD tearing Ok
--- Tag Signature
IC signature public key value : 04494e1a386d3d3cfe3dc10e5de68a499b1c202db5b132393e89ed19fe5be8bc61
Elliptic curve parameters : secp128r1
Tag ECC Signature : 01 d1 51 2c d5 42 f8 ed b9 13 ff 8d 55 5f 63 06 eb ac e7 7e 86 3c 45 50 36 b4 6a 86 37 e8 dc 15
--- Tag Version
Raw bytes : 00 04 03 01 01 00 0e 03
Vendor ID : 04, NXP Semiconductors Germany
Product type : 03, Ultralight
Product subtype : 01, 17 pF
Major version : 01
Minor version : 00
Size : 0E, (128 bytes)
Protocol type : 03
--- Tag Configuration
cfg0 [37/0x25] : 00 00 00 04
- page 4 and above need authentication
- strong modulation mode disabled
cfg1 [38/0x26] : 00 05 00 00
- Unlimited password attempts
- user configuration writeable
- write access is protected with password
- 05, Virtual Card Type Identifier is default
PWD [39/0x27] : 00 00 00 00 - (cannot be read)
PACK [40/0x28] : 00 00 - (cannot be read)
RFU [40/0x28] : 00 00 - (cannot be read)
--- Known EV1/NTAG passwords.
password not known
The full (readable) dump of the ticket, with one trip remaining, can be found here: https://www.sendspace.com/file/784l9t
Next step is sniffing the communication between the reader and the ticket. I understand that I have to probably run "hf 14a snoop" before reading the ticket in the reader and then replay the log with "hf 14a list".
My questions are:
1) Do I need to upgrade the firmware for this task?
2) How can I sniff this in stand-alone mode? I have got a battery for the RDV2. Do I need to customize the appmain.c file for that or the following will also work: a) connect proxmark to pc and run the "hf 14a snoop", b) with the battery on, disconnect the proxmark without turning it off and head to the card reader, c) perform a transaction (like card info), d) press the button for the sniffing to stop and then reconnect the proxmark with the pc to list the logged info.
Thank you very much in advance.
P.S. I came across another card for this transportation system which is probably a MIFARE DESFire EV1. I will start another thread to the correct section at some point.
Offline
Guys, I managed to do some snooping, but I'm not so sure about the results.
First, to answer my own questions:
1) I had to upgrade to a more recent firmware for this to work. Especially for the feature where the client can reconnect to the device without restart. Great job iceman, as always!
2) In order for the standalone sniffing to work, I had to add a new very simple standalone mode where it runs the SniffIso14443a() function when I hold down the button for over a sec. Once I was done, I click on the button once to stop. Without turning the pm3 off, on battery the whole time, I reconnected it to the PC on the already open client and run the "hf 14a list" command.
As for the traces, here is one from the first ticket:
Start | End | Src | Data (! denotes parity error) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
7920928 | 7921920 | Rdr |52 | | WUPA
7923188 | 7925556 | Tag |44 00 | |
8253664 | 8254720 | Rdr |26 | | REQA
8255908 | 8258276 | Tag |44 00 | |
8272352 | 8274816 | Rdr |93 20 | | ANTICOLL
8276004 | 8281828 | Tag |88 04 92 24 3a | |
8297312 | 8307840 | Rdr |93 70 88 04 92 24 3a 4e 9d | ok | SELECT_UID
8309028 | 8312548 | Tag |04 da 17 | |
8327648 | 8330112 | Rdr |95 20 | | ANTICOLL-2
8331300 | 8337188 | Tag |0a 46 4e 84 86 | |
8352608 | 8363136 | Rdr |95 70 0a 46 4e 84 86 2b 8c | ok | ANTICOLL-2
8364324 | 8367908 | Tag |00 fe 51 | |
8555936 | 8556992 | Rdr |26 | | REQA
8558196 | 8560564 | Tag |44 00 | |
8574624 | 8577088 | Rdr |93 20 | | ANTICOLL
8578276 | 8584100 | Tag |88 04 92 24 3a | |
8599584 | 8610112 | Rdr |93 70 88 04 92 24 3a 4e 9d | ok | SELECT_UID
8611284 | 8614804 | Tag |04 da 17 | |
8629920 | 8632384 | Rdr |95 20 | | ANTICOLL-2
8633556 | 8639444 | Tag |0a 46 4e 84 86 | |
8654880 | 8665408 | Rdr |95 70 0a 46 4e 84 86 2b 8c | ok | ANTICOLL-2
8666596 | 8670180 | Tag |00 fe 51 | |
8685088 | 8688704 | Rdr |60 f8 32 | ok | EV1 VERSION
8689876 | 8701524 | Tag |00 04 03 01 01 00 0e 03 45 89 | ok |
8725408 | 8730176 | Rdr |39 00 1a 7f | ok | READ CNT(0)
8731364 | 8737188 | Tag |00 00 00 14 a5 | |
8757136 | 8761904 | Rdr |39 01 93 6e | ok | READ CNT(1)
8763108 | 8768932 | Tag |01 00 00 c8 ff | |
8789264 | 8793968 | Rdr |39 02 08 5c | ok | READ CNT(2)
8795236 | 8801060 | Tag |01 00 00 c8 ff | |
10648752 | 10653456 | Rdr |30 04 26 ee | ok | READBLOCK(4)
10654692 | 10675492 | Tag |10 8f 79 67 96 25 00 00 00 00 00 00 28 a8 86 68 | |
| | |14 d8 | ok |
10696496 | 10701264 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
10702452 | 10723252 | Tag |04 92 24 3a 0a 46 4e 84 86 48 00 00 00 00 00 00 | |
| | |fa 27 | ok |
10744240 | 10748944 | Rdr |30 08 4a 24 | ok | READBLOCK(8)
10750196 | 10770996 | Tag |ad 35 7b 24 12 af fa 58 36 42 a2 f9 00 00 00 00 | |
| | |29 47 | ok |
10790048 | 10794816 | Rdr |30 0c 6e 62 | ok | READBLOCK(12)
10796020 | 10816884 | Tag |00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | |
| | |37 49 | ok |
10837408 | 10842112 | Rdr |30 04 26 ee | ok | READBLOCK(4)
10843380 | 10864180 | Tag |10 8f 79 67 96 25 00 00 00 00 00 00 28 a8 86 68 | |
| | |14 d8 | ok |
11329968 | 11334672 | Rdr |30 08 4a 24 | ok | READBLOCK(8)
11335908 | 11356708 | Tag |ad 35 7b 24 12 af fa 58 36 42 a2 f9 00 00 00 00 | |
| | |29 47 | ok |
12401072 | 12405840 | Rdr |30 14 a7 fe | ok | READBLOCK(20)
12407028 | 12427892 | Tag |00 00 00 00 48 9d 2b 61 3b e8 14 23 e5 84 e9 f4 | |
| | |72 0e | ok |
12452144 | 12456912 | Rdr |30 18 cb 34 | ok | READBLOCK(24)
12458100 | 12478964 | Tag |31 39 dd 0d f1 2a a2 06 09 2c b6 a9 9c a5 76 74 | |
| | |75 10 | ok |
13533376 | 13538080 | Rdr |30 1c ef 72 | ok | READBLOCK(28)
13539316 | 13560116 | Tag |eb f7 50 04 f1 2a a2 06 09 2c b6 a9 9c a5 76 74 | |
| | |6c c6 | ok |
14615888 | 14620656 | Rdr |30 20 00 89 | ok | READBLOCK(32)
14621844 | 14642644 | Tag |eb f7 50 04 1b 04 00 8c 1e f3 58 25 01 a1 46 01 | |
| | |bb 39 | ok |
and this is from the second one:
Start | End | Src | Data (! denotes parity error) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
467216592 | 467221360 | Rdr |50 00 57 cd | ok | HALT
467560560 | 467561552 | Rdr |52 | | WUPA
467562804 | 467565172 | Tag |44 00 | |
467893248 | 467894304 | Rdr |26 | | REQA
467895508 | 467897876 | Tag |44 00 | |
467911936 | 467914400 | Rdr |93 20 | | ANTICOLL
467915588 | 467921476 | Tag |88 04 aa b7 91 | |
467936896 | 467947360 | Rdr |93 70 88 04 aa b7 91 ce f5 | ok | SELECT_UID
467948612 | 467952132 | Tag |04 da 17 | |
467967232 | 467969696 | Rdr |95 20 | | ANTICOLL-2
467970884 | 467976708 | Tag |a2 21 4e 80 4d | |
467992192 | 468002656 | Rdr |95 70 a2 21 4e 80 4d b5 ed | ok | ANTICOLL-2
468003908 | 468007492 | Tag |00 fe 51 | |
468195504 | 468196560 | Rdr |26 | | REQA
468197764 | 468200132 | Tag |44 00 | |
468214192 | 468216656 | Rdr |93 20 | | ANTICOLL
468217860 | 468223748 | Tag |88 04 aa b7 91 | |
468239152 | 468249616 | Rdr |93 70 88 04 aa b7 91 ce f5 | ok | SELECT_UID
468250868 | 468254388 | Tag |04 da 17 | |
468269488 | 468271952 | Rdr |95 20 | | ANTICOLL-2
468273140 | 468278964 | Tag |a2 21 4e 80 4d | |
468294448 | 468304912 | Rdr |95 70 a2 21 4e 80 4d b5 ed | ok | ANTICOLL-2
468306164 | 468309748 | Tag |00 fe 51 | |
468324656 | 468328272 | Rdr |60 f8 32 | ok | EV1 VERSION
468329460 | 468341108 | Tag |00 04 03 01 01 00 0e 03 45 89 | ok |
468364592 | 468369360 | Rdr |39 00 1a 7f | ok | READ CNT(0)
468370548 | 468376372 | Tag |00 00 00 14 a5 | |
468397728 | 468402496 | Rdr |39 01 93 6e | ok | READ CNT(1)
468403700 | 468409524 | Tag |05 00 00 a9 9c | |
468431520 | 468436224 | Rdr |39 02 08 5c | ok | READ CNT(2)
468437492 | 468443316 | Tag |01 00 00 c8 ff | |
470308800 | 470313504 | Rdr |30 04 26 ee | ok | READBLOCK(4)
470314756 | 470335556 | Tag |10 8f 4a 65 72 5d 00 00 00 00 00 00 64 f8 ea 2f | |
| | |30 ee | ok |
470357552 | 470362320 | Rdr |30 00 02 a8 | ok | READBLOCK(0)
470363524 | 470384388 | Tag |04 aa b7 91 a2 21 4e 80 4d 48 00 00 00 00 00 00 | |
| | |70 2c | ok |
470405424 | 470410128 | Rdr |30 08 4a 24 | ok | READBLOCK(8)
470411396 | 470432260 | Tag |e5 ef 56 ce db d2 50 ff ae fa ed 4e 12 20 4b 20 | |
| | |2c d5 | ok |
470452528 | 470457296 | Rdr |30 0c 6e 62 | ok | READBLOCK(12)
470458500 | 470479300 | Tag |00 00 01 01 03 ea 04 12 1e ca 08 48 00 00 00 00 | |
| | |13 b2 | ok |
470500400 | 470505104 | Rdr |30 04 26 ee | ok | READBLOCK(4)
470506372 | 470527172 | Tag |10 8f 4a 65 72 5d 00 00 00 00 00 00 64 f8 ea 2f | |
| | |30 ee | ok |
470991536 | 470996240 | Rdr |30 08 4a 24 | ok | READBLOCK(8)
470997508 | 471018372 | Tag |e5 ef 56 ce db d2 50 ff ae fa ed 4e 12 20 4b 20 | |
| | |2c d5 | ok |
472064064 | 472068832 | Rdr |30 14 a7 fe | ok | READBLOCK(20)
472070036 | 472090836 | Tag |00 00 00 00 41 eb bc 72 b7 3b aa 94 72 cb b4 6a | |
| | |27 65 | ok |
472116928 | 472121696 | Rdr |30 18 cb 34 | ok | READBLOCK(24)
472122900 | 472143764 | Tag |e6 33 da 3c 58 de 9b db 41 53 27 9b 9c 95 79 de | |
| | |20 57 | ok |
473194832 | 473199536 | Rdr |30 1c ef 72 | ok | READBLOCK(28)
473200788 | 473221588 | Tag |ec 68 f6 e0 58 de 9b db 41 53 27 9b 9c 95 79 de | |
| | |15 de | ok |
474278624 | 474283392 | Rdr |30 20 00 89 | ok | READBLOCK(32)
474284580 | 474305380 | Tag |ec 68 f6 e0 19 04 02 bc 1e 95 54 0b 01 a1 37 01 | |
| | |e6 eb | ok |
Unfortunately, as far as I can see, I can't get anything useful out of them. That is probably because I didn't perform any actual transaction, but I only viewed the information on them. That way the reader only read the counters (and maybe their hashed values too as solem89 pointed out), which don't require any authentication. Please, feel free to correct me if I am wrong.
Offline
+1 for creating your own standalone mode
+1 for being the first to actually use the "reconnect" function live, in the real world example
Your traces only shows some reading of the three counter, and reading of memory. No authentication with pwd/pack.
If this is the normal reading process for the ticket system, you should be able to simulate a ticket with your pm3.
Just load your dump, and sim.. see what the system does.
I'm guessing you are looking for a way to understand what you want to achive.
1. collect many dumps. Before a reload, and after a reload.
2. collect uid/pwd/pack. If you have to simulate with different uids to do it, fine, this is for solving pwd/pack gen algo.
3. datamapping. with data from point1, you can start trying to figure out what data is stored on your tag.
Since you can simulate with a pm3, you can edit counters back and forth, you can see which fields changes when you do...
time to start playing!
Offline
Thank you iceman! How many +1s do you deserve, man!
I think I'm gonna try some reloading today for the two different tickets, while dumping each state as you suggested.
When I set up a proper reader for testing, I'm gonna definitely try the sim with pm3.
I also bought a magic NTAG21x tag, that I would also like to test it out, but since this system seems to be based on the reading of counters, I have to find a way to set the counters on that card.
Will inform of my findings! Thanks again!
Offline
So, I was also doing some research on this Ultralight EV1 card. As you said they are using MF0UL21, which means that the total memory of the card is 164 bytes.
Again, as you mentioned, the card updates 2 one-way counters, one for the times used and the other one for the times a reload takes place. As you may know, these counters are not part of the readable memory space, but instead they can be read separately, using the READ_CNT command. When I was dumping the data from my card (using a NFC phone), I noticed that the third byte in address page 12 (dec) seems to represent the remaining trips of the card. And as far as I can see in your dumps the same byte follows that exact logic.
The last two address pages of the card (39 and 40 in dec) contain the password, which is required to write the user memory space. According to the datasheet, those bytes can only be written, not read. I still haven't tried any common passwords (like 00000000 or ffffffff) to see if I can get it to authenticate. I suppose it is worth checking. Of course, if you own a proxmark it would be rather helpful to try and sniff the communication between the card and a vending machine (which btw are these: Sigma ETS70). Here is a nice (related) thread regarding the italian EV1 card: http://proxmark.org/forum/viewtopic.php?id=2445
And a fun fact about that "well-thought" transportation system of Greece: First time I got my 5-trip card I validated it on a bus, displaying correctly on the screen that 4 trips remain. A couple of minutes later I reached a metro station and I checked my card on one of the vending machines and the only information on the card was "4 trips remain", no time of validation, no remaining time, no nothing. I asked a metro guy if I should re-validate the card if I'm gonna enter the metro and he said that since the card says 4 remaining trips, validating it again now would only decrease the remaining trips of my card to 3... even if it was only a few minutes later (each trip is supposed to last 90 minutes). After he gave it some thought, the same guy told me that the reason for this is that the bus hasn't uploaded the data yet to the system and this will probably happen when it gets to its last stop (which btw could be after 90 minutes)...
Bogito, which app do you use to read ultralight ev1 with phone?
Offline
I used the "NFC TagInfo by NXP" app (https://play.google.com/store/apps/deta … lite&hl=en) with a borrowed Samsung phone.
Offline
thanks
Offline
Can we bruteforce the PWD, PACK and RFU? What commands do I have to use?
I have the upstream proxmark, do I have to use your fork? (nice job by the way...)
Offline
RFU stands for "Reserved for Future Use" and is set to 00h by default.
You could sniff the communication between the reader and the card with your proxmark to get the PWD for a specific UID.
Iceman fork is a must
Offline
Of course that'd be easier, but I can't do that for various reasons, but I can leave the proxmark bruteforcing for days.
Installing then
Offline
No use at all to bruteforce, when it usually only takes one sniff using
hf 14a sniff
hf 14a list
Offline
Cracking the algorithm would be the way to go.
I started collecting UID/PWD/PACK.
uid | pwd | pack |
---------------------+-------------+-------
04 AA B7 A2 21 4E 80 | 8C F7 F3 72 | F7 13
04 92 24 0A 46 4E 84 | 5B 19 90 48 | 5D 73
04 89 82 32 46 4E 81 | 83 D5 39 2F | 4C 2C
The only correlation I could find is that the 7th digit of the pwd is same as the 6th digit of the uid. Haven't had time to start xoring things around yet.
Your help to solve this is greatly appreciated
Offline
Cracking the algorithm would be the way to go.
I started collecting UID/PWD/PACK.uid | pwd | pack | ---------------------+-------------+------- 04 AA B7 A2 21 4E 80 | 8C F7 F3 72 | F7 13 04 92 24 0A 46 4E 84 | 5B 19 90 48 | 5D 73 04 89 82 32 46 4E 81 | 83 D5 39 2F | 4C 2C
The only correlation I could find is that the 7th digit of the pwd is same as the 6th digit of the uid. Haven't had time to start xoring things around yet.
Your help to solve this is greatly appreciated
Any luck? If you happen to collect more UID/PWD/PACK post them please. I would like to try and help with the whole algorithm thing.
Last edited by Spoiler (2017-12-19 01:03:32)
Offline
Unfortunately no. I did try some XOR combinations between bytes, but nothing came out from that. I think we need advice from the experts (iceman, asper, etc).
I will get 2-3 more UID/PWD/PACK sets until Friday to see if we can figure something out.
As for my observation about the 7th pwd digit, it seems that it isn't correct. If you see the first uid/pwd that solem89 provided, that correlation doesn't seem to be valid.
Offline
you would need to collect a lot of more pwd/packs.
If you simulate against a reader, you can collect a lot of pwds but not pack.
if you sniff card & reader, you collect pwd / pack for that card.
You normally start with collecting a lot of pwds... To get a feel for the algo.
with uid's like below and so forth.
00 00 00 00 00 00 01
00 00 00 00 00 00 02
00 00 00 00 00 00 04
00 00 00 00 00 00 08
00 00 00 00 00 00 10
00 00 00 00 00 00 20
00 00 00 00 00 00 40
00 00 00 00 00 00 80
Go an collect those, and we have something to work with
Offline
I started saving up money. i hope that by february i will be able to afford my own PM3 to start sniffing pwd / pack. Until then i will do my best to work with what data we get from this thread.
Offline
you would need to collect a lot of more pwd/packs.
If you simulate against a reader, you can collect a lot of pwds but not pack.
if you sniff card & reader, you collect pwd / pack for that card.You normally start with collecting a lot of pwds... To get a feel for the algo.
with uid's like below and so forth.00 00 00 00 00 00 01 00 00 00 00 00 00 02 00 00 00 00 00 00 04 00 00 00 00 00 00 08 00 00 00 00 00 00 10 00 00 00 00 00 00 20 00 00 00 00 00 00 40 00 00 00 00 00 00 80
Go an collect those, and we have something to work with
Iceman would it be better if we set the first uid byte to 04h and the 6th byte to 4Eh? eg.: 04 00 00 00 00 4E 01
04 00 00 00 00 4E 02
04 00 00 00 00 4E 01 etc..
I'm asking because they seem to be the same in every uid from these tickets (including some of my own).
Last edited by Spoiler (2017-12-20 19:21:21)
Offline
No.
The way I want it is to show only one bit change (bitflip) per uid... Which is needed to see which effect each individual bit has.
Offline
Has anyone managed to move forward on this?
Offline
Depends on what you mean by "forward".
If you mean the figuring out of the uid-pwd algo, I keep collecting uid/pwd/pack from the tickets I use (I have around 12 now). I haven't tried the bit-shifting uid checking yet, since every failed attempt (at least on a bus) makes a very loud beep. So I am trying to find a specific route at a specific hour with not much people in it to hear those failed tries. On the other hand, if more people could gather uid/pwd/pack sets, we would have more chances to figure out the algo, without getting caught
Apart from that, I have made a perfect clone of a ticket, but, again, I haven't tried it on a real reader.
Offline
with the Chameleon you should be able to collect data...
Offline
Hehe that is the plan, iceman! The portability of the Chameleon makes it perfect for real world testing. We only need to save multiple pwds each time
Offline
That is great bogito! How can I contribute to this pool? if mean do you just hf search and right the info down? using a proxmark 3 v2 so I might be helpful
As for that Chameleon iceman that looks so beautiful. Wish I can get my hands on it at some point
Offline
alpha, it is not that easy, unfortunately.
Check #18 of this thread to see what I did to get on with the sniffing of the pwd.
In summary the steps are:
1) flash a firmware that enables you to sniff in standalone mode (I may share mine eventually)
2) launch the client, disconnect the pm3 from the pc, but leave the client open
3) turn the pm on (with a connected battery) and then press the button for 2+ sec (to enable the standalone mode - and start the sniffing)
4) hold the ticket and the pm together against a reader (probably a reader on a bus is more accessible) to validate it and grab the pwd
5) press the button once to stop the sniffing, return to the open client and reconnect the pm
6) then issue the "hf 14a list" command to show the sniffed data (if everything went well the pwd would be among them)
Yes, I do steps 2-6 each time
Another, not so discreet, option would be to have a phone/laptop/etc always connected to your pm and run the commands live.
Offline
For anyone interested in my iso1443a standalone sniffing: https://github.com/bogiton/proxmark3.
I did some quick changes to the source code in order to fit my needs so I don't consider them as a proper standalone mode and that is why I don't do a PR for it.
As I already mentioned, once you have flashed my changed firmware, you can press the button for over 2 seconds to enable the sniff mode. You can verify it has started by the lit LED. After you have grabbed what you need, you can press the button once to stop. Be sure to stop sniffing before re-attaching the device to the client.
Offline
+1 Bogito on the steps provided. Got some reading to do but apart from that I believe my pm3 is the version that needs to be connected on a computer all the time as (pm3 v2 easy by eleckhouse) .Is this the case as I have described?
Offline
I think that the Proxmark3 Easy also has a connector for an external battery. I got a LiPo 3.7V @ 800mAh for my device (Proxmark 3 RDV2). Otherwise, you can get a Y-type USB cable and plug a power bank in one end. There are many references about that in the forum if you do some search. This is (still) an Ultralight-related thread
Offline
Hoping that someone may wanna try figuring out the algo, here are the uid/pwd/pack I have so far:
UID | pwd | pack
---------------------+-------------+-------
04 83 8F 2A 46 4E 80 | 96 13 0C EA | ?? ??
04 AA B7 A2 21 4E 80 | 8C F7 F3 72 | F7 13
04 92 24 0A 46 4E 84 | 5B 19 90 48 | 5D 73
04 89 82 32 46 4E 81 | 83 D5 39 2F | 4C 2C
04 EF 40 CA A9 52 80 | 69 64 2E C7 | 2A 09
04 A4 91 0A 22 4E 80 | 55 B7 3B C6 | F5 21
04 76 82 32 46 4E 81 | 3C EF 1A 25 | 21 EE
04 9E 91 0A 22 4E 80 | FE 67 01 22 | 3F 77
04 B5 46 E2 21 4E 84 | BA 5B 2A FD | 6D CB
04 2E A6 C2 D2 4F 81 | 05 75 D7 12 | 8D 73
04 83 CF CA D2 4F 80 | 91 CE 53 3C | 86 97
The first one is the one that solem89 provided, but without the pack.
I think I have tried most combinations with reveng, so we can rule out the possibility that either the pwd or the pack is part of a CRC.
I still haven't had the opportunity to try the bit-shift UIDs.
Offline
until you collect the bit-shift incremented UID data, there seem to be little we can do.
Offline
I thought so. I have the chameleon ready for that, with a special increment button action and all, but most buses are too crowded most of the time for me to play with the readers I keep looking for the right opportunity.
Offline
Ok so here is my hw version
Prox/RFID mark3 RFID instrument
bootrom: master/v3.0.1-71-g5c814c3-suspect 2017-08-23 12:16:58
os: master/v3.0.1-71-g5c814c3-suspect 2017-08-23 12:17:02
LF FPGA image built for 2s30vq100 on 2015/03/06 at 07:38:04
HF FPGA image built for 2s30vq100 on 2017/07/13 at 08:44:13
uC: AT91SAM7S256 Rev D
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes. Used: 197233 bytes (75%). Free: 64911 bytes (25%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
And here is the hf mfu info of one of my tickets
--- Tag Information ---------
-------------------------------------------------------------
TYPE : MIFARE Ultralight EV1 128bytes (MF0UL2101)
UID : 04 9f e6 42 95 58 80
UID[0] : 04, NXP Semiconductors Germany
BCC0 : F5, Ok
BCC1 : 0F, Ok
Internal : 48, default
Lock : 08 00 - 0000000000001000
OneTimePad : 1a 39 de 7b - 01111011110111100011100100011010
--- Tag Counters
[0] : 00 00 00
- BD tearing Ok
[1] : 01 00 00
- BD tearing Ok
[2] : 01 00 00
- BD tearing Ok
--- Tag Signature
IC signature public key value : 04494e1a386d3d3cfe3dc10e5de68a499b1c202db5b132393e89ed19fe5be8bc61
Elliptic curve parameters : secp128r1
Tag ECC Signature : ee 91 b7 0f 75 1a 0a 2b f8 0d 49 bc 0f 6b 59 f1 c5 86 70 36 7a 88 9a b0 7d 25 e1 97 3f 00 0a c5
--- Tag Version
Raw bytes : 00 04 03 01 01 00 0e 03
Vendor ID : 04, NXP Semiconductors Germany
Product type : 03, Ultralight
Product subtype : 01, 17 pF
Major version : 01
Minor version : 00
Size : 0E, (128 bytes)
Protocol type : 03
--- Tag Configuration
cfg0 [37/0x25] : 00 00 00 07
- page 7 and above need authentication
- strong modulation mode disabled
cfg1 [38/0x26] : 00 05 00 00
- Unlimited password attempts
- user configuration writeable
- write access is protected with password
- 05, Virtual Card Type Identifier is default
PWD [39/0x27] : 00 00 00 00 - (cannot be read)
PACK [40/0x28] : 00 00 - (cannot be read)
RFU [40/0x28] : 00 00 - (cannot be read)
--- Known EV1/NTAG passwords.
password not known
Last edited by alpha (2018-03-17 14:28:07)
Offline
alpha, it is not that easy, unfortunately.
Check #18 of this thread to see what I did to get on with the sniffing of the pwd.
In summary the steps are:
1) flash a firmware that enables you to sniff in standalone mode (I may share mine eventually)
2) launch the client, disconnect the pm3 from the pc, but leave the client open
3) turn the pm on (with a connected battery) and then press the button for 2+ sec (to enable the standalone mode - and start the sniffing)
4) hold the ticket and the pm together against a reader (probably a reader on a bus is more accessible) to validate it and grab the pwd
5) press the button once to stop the sniffing, return to the open client and reconnect the pm
6) then issue the "hf 14a list" command to show the sniffed data (if everything went well the pwd would be among them)
Yes, I do steps 2-6 each time
Another, not so discreet, option would be to have a phone/laptop/etc always connected to your pm and run the commands live.
Was wondering since I have the pm3 without the battery, that means I have to use an external battery via usb. So what happens when after sniffing the card reader and remove the battery,in order to connect it to the computer? Will the pm3 keep the data?
Offline
at the moment offical pm3 can not be reconnected.
however iceman fork can, if you want to try it out.
Offline
██████╗ ███╗ ███╗ ████╗ ...iceman fork
██╔══██╗████╗ ████║ ══█║
██████╔╝██╔████╔██║ ████╔╝
██╔═══╝ ██║╚██╔╝██║ ══█║ iceman@icesql.net
██║ ██║ ╚═╝ ██║ ████╔╝ https://github.com/iceman1001/proxmark3
╚═╝ ╚═╝ ╚═╝ ╚═══╝ v3.1.0
Keep iceman fork alive with a donation! https://paypal.me/iceman1001/
MONERO: 43mNJLpgBVaTvyZmX9ajcohpvVkaRy1kbZPm8tqAb7itZgfuYecgkRF36rXrKFUkwEGeZedPsASRxgv4HPBHvJwyJdyvQuP
Proxmark3 RFID instrument
[ ARM ]
bootrom: iceman/master/ice_v3.1.0-741-g4c666e38 2018-03-17 12:02:43
os: iceman/master/ice_v3.1.0-741-g4c666e38 2018-03-17 12:02:45
[ FPGA ]
LF image built for 2s30vq100 on 2017/10/25 at 19:50:50
HF image built for 2s30vq100 on 2017/11/10 at 19:24:16
[ Hardware ]
--= uC: AT91SAM7S256 Rev D
--= Embedded Processor: ARM7TDMI
--= Nonvolatile Program Memory Size: 256K bytes, Used: 252605 bytes (96%) Free: 9539 bytes ( 4%)
--= Second Nonvolatile Program Memory Size: None
--= Internal SRAM Size: 64K bytes
--= Architecture Identifier: AT91SAM7Sxx Series
--= Nonvolatile Program Memory Type: Embedded Flash Memory
And done!
Offline