Proxmark developers 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.

#51 2018-03-17 21:08:27

iceman
Administrator
Registered: 2013-04-25
Posts: 5,008
Website

Re: Greek transportation system -Mifare Ultralight

+1


冰人

modhex(hkhehghthbhudcfcdchkigiehgduiehg)

Offline

#52 2018-03-20 20:06:14

alpha
Contributor
Registered: 2018-01-28
Posts: 9

Re: Greek transportation system -Mifare Ultralight

smile Ordered the component (15$) which will allow me to use battery on my pm3. Until then will try to find a decent Y otg cable as Bonito advised me and see if that works temporary

Offline

#53 2018-04-03 13:50:33

bogito
Contributor
Registered: 2017-10-18
Posts: 39

Re: Greek transportation system -Mifare Ultralight

Just a little update on this.
Chameleon didn't work as expected on the real reader, probably due to timing differences.
Setting a ticket to a previous state (after having acquired its pwd) byte-by-byte also didn't work on a real reader, which means that it either checks online the status of the presented ticket (very doubtful) or that it stores each time the current values of the counters in the user data area of the ticket.
To clarify, what I did was this: I had a dump of a ticket (without pwd/pack) first time I got it with 1 route loaded in it. I used the ticket normally and then I sniffed the reload of it in order to obtain the pwd. I had then a dump of the whole ticket (since the auth was successful). Having the two dumps, I wrote on the ticket the entire data of the first dump (before its first validation). I presented it to the real reader and it failed. That means that the only different thing on the ticket was the value of the counters (initially they had the value of 1 and now it was incremented to 2).
Next step is to finally try the simulation of a ticket with the PM3, setting the correct counters this time.
Also, I tried to find out how/where the dates are stored on the ticket, using a tool called Dcode (http://www.digital-detective.net/digital-forensic-software/free-tools/), but no luck either.
Figuring out the data mapping in general would be a great help, if anyone can contribute.

Offline

#54 2018-05-20 15:31:49

ultraev1
Contributor
Registered: 2018-01-03
Posts: 2

Re: Greek transportation system -Mifare Ultralight

+1
Thanks for the update Bogito! Keep us posted!

I am also interested in figuring out the date in the card. Here is what I have so far:

Example for a card with id (F804C90C02464E84)
Obtained on 01/01/2018 15:51

When empty

Initial	10902167 461d0000 
Zeros	00000000 
Hash 1	03876d45 8936a125 e71b70b8 01fafacb 
Data 1	00000000 00000000 00000000 
Time 1	00000000 
Zeros	00000000 
Data 2	00000000 00000000 
Zeros	00000000 
Time 2	00000000 
Zeros	00000000 
Hash 2	64fd0ec2 0b7c9d80 40fd6c0d b7c21f5a 
Hash 3	bb47a327 a0446dac ebac2343 1168b005 
Hash 4	bb47a327 a0446dac ebac2343 1168b005 
Const	1b04008c 
Time 3	2042fcc5 
Last	01a14601

After being used

Initial	10902167 461d0000 
Zeros	00000000 
Hash 1	00d774e5 5d4e90eb 560bb7a2 d012ae9b 
Data 1	10a04b50 00000001 03eb0429 
Time 1	20453422 
Zeros	00000000 
Data 2	00989955 00090000 
Zeros	00000000 
Time 2	60428efb 
Zeros	00000000 
Hash 2	5b390f91 8b169b22 63e833c1 f4baf212 
Hash 3	bb47a327 a0446dac ebac2343 1168b005 
Hash 4	00d774e5 5d4e90eb 560bb7a2 d012ae9b 
Data 3	1b04008c 
Time 3	2042fcc5
Last	01a14601 

Time 1 is the time last validated
Time 2 is the previous time validated. It takes the constant value (60428efb) when validated only once.
Time 3 is the time of purchase
Here is how to read the times, e.g. 2018-1-1 15:51

0x 2042fcc5 = 0b 001000 0001  00001 01111 110011 000101
                 Y    8 M  1  D   1 h  15 m   51

The last 6 bits could be seconds or they might indicate the station where the transaction happened.

The hashes are probably hashes of the counters. For single ride tickets they start out as Hash3=Hash4 and change to Hash1=Hash4 when used.

The last 4 bytes seem to indicate the type of the card. Here -- 01a1 (46) 01 -- 46 means single ride ticket while the rest seem to be constant.

I am not sure what the data fields keep for different card types but judging from the encoding of times the info is probably not byte aligned. Data 3 seems to be constant for single ride tickets.


I want to help out with the data mapping process and inverting the pwd and pack. Let me know if you have more info. I am guessing by now you must have many more (uid, pwd, pack) triples. If we collect about 30-50 such samples, I can possibly invert the pwd algorithm if it is based on linear hashing similar to what other transportation systems use, i.e. if

pwd(00 00 00 00 00 00 01) xor pwd(00 00 00 00 00 00 02) = pwd(00 00 00 00 00 00 00) xor pwd(00 00 00 00 00 00 03)

In that case, we don't need single bit uids as iceman suggested. All we need is many linearly independent samples. Of course, single bit uids could be very helpful if other types of algorithms are used.

Offline

#55 2018-05-29 13:26:16

bogito
Contributor
Registered: 2017-10-18
Posts: 39

Re: Greek transportation system -Mifare Ultralight

Amazing find, ultraev1! Very good job, congrats! Up until now, I thought that they were storing encrypted data, as described here https://www.nxp.com/docs/en/application … N11340.pdf. I am very happy that you proved me wrong about that. All this time I was searching for the 2018 as a part of the date, but they use just the 8... *sigh*
Regarding the last 6 bits of the time fields, I can confirm that they are representing the seconds (I purchased two tickets, one after the other and the seconds passed matched that value).
Most likely, they also store the station of validation or purchase somewhere. I tried searching for the "Device ID" they print in the receipt of the purchase, but no luck.
Since I always get a single ride ticket, I get the constant value of 01a14601 for the last bytes. If 46 is the single ride then the 01 could be the count of this type. I will purchase another type to see if it changes (and to what). Can someone else verify this?
Unfortunately, I only got a few more (4-5) triples, since I wasn't in Athens for the last couple months, but hopefully I will get more during the summer. Especially if you believe that you can help with the pwd inversion.

Offline

#56 2018-08-23 08:00:27

dmitri21
Contributor
Registered: 2018-08-22
Posts: 2

Re: Greek transportation system -Mifare Ultralight

Hello guys, is there any progres to the project?

There is an official android app which can reload tickets to the card. https://play.google.com/store/apps/details?id=com.lgcns.greece&hl=el

I am wondering if it could be useful to read the code of this app. we can download the apk from sites like apkpure etc.

Offline

#57 2018-08-23 22:42:02

bogito
Contributor
Registered: 2017-10-18
Posts: 39

Re: Greek transportation system -Mifare Ultralight

Hello dmitri21.
The app you mentioned is indeed the official app for the public transportation of Greece, but it only works with the personalized cards, the Desfire EV1 ones (described here: http://proxmark.org/forum/viewtopic.php?id=5286). So maybe we should move this discussion there.
To answer your thought, I already tried to decompile the apk of the app, but it is heavily obfuscated and the decompilation is not that good. There are some interesting strings/URLs there though, but nothing very clear (like keys or passwords).
The next step would be the sniffing of the communication between the app and their servers to understand the workflow, but since the app only works on NFC-capable phones (and I don't have currently one), I cannot try that out.
If you are interested I could share the decompiled source for further investigation or you could just load it up in JADX or JD-GUI and check it out.

Offline

#58 2018-12-02 17:54:25

bogito
Contributor
Registered: 2017-10-18
Posts: 39

Re: Greek transportation system -Mifare Ultralight

After a whole year, I managed to get some more pwds. This is the entire list of uid/pwd/pck we got so far.

UID                  | PWD         | PACK
---------------------+-------------+-------
04 23 C2 5A 5F 5C 80 | 7B 1D 06 03 | FD B7
04 2C 63 92 E1 5F 81 | EC 3A 95 8A | B7 22
04 2E A6 C2 D2 4F 81 | 05 75 D7 12 | 8D 73
04 38 29 92 6D 5B 81 | 1A C8 CC 02 | 13 A3
04 5E F1 CA D2 4F 80 | 59 AB EF F8 | 6F 55
04 71 D5 DA 1F 5C 81 | 9A 77 B4 C9 | 73 A9
04 7D D5 DA 1F 5C 81 | 27 6B 7F 67 | 73 46
04 76 82 32 46 4E 81 | 3C EF 1A 25 | 21 EE
04 77 82 32 46 4E 81 | 55 31 93 EF | A2 22
04 89 82 32 46 4E 81 | 83 D5 39 2F | 4C 2C
04 7F 09 EA B9 5D 84 | C1 3B 30 4B | 49 48
04 83 8F 2A 46 4E 80 | 96 13 0C EA | ?? ??
04 83 CF CA D2 4F 80 | 91 CE 53 3C | 86 97
04 86 CF 7A B6 5D 80 | E7 C4 12 3D | 68 6B
04 92 24 0A 46 4E 84 | 5B 19 90 48 | 5D 73
04 9E 91 0A 22 4E 80 | FE 67 01 22 | 3F 77
04 A4 91 0A 22 4E 80 | 55 B7 3B C6 | F5 21
04 AA B7 A2 21 4E 80 | 8C F7 F3 72 | F7 13
04 B5 46 E2 21 4E 84 | BA 5B 2A FD | 6D CB
04 D1 31 E2 82 58 84 | 94 16 C0 95 | 62 15
04 E5 18 E2 C4 5B 84 | 97 A0 F3 3C | DE 9A
04 EC 40 3A C5 5B 84 | C5 C3 BB 04 | A7 F0
04 EF 40 CA A9 52 80 | 69 64 2E C7 | 2A 09

There are some pairs that differ only in a single byte/bit which may help in figuring out the algo.
I will keep up collecting more during the winter.

Offline

Board footer

Powered by FluxBB