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.
I ran into a unknown tag from Infineon the other day in Istanbul, Turkey.
After a minor bugfix in the magic-test, this is what we have.
Since infineon uses uid[1] to specify between models, the high nibble (0x7) UID[1] == 7F, is not known today.
someone ran into this model before?!!?
TAGINFO :
pm3 --> hf 14a re
UID : 05 7F 51 6B 65 54 E9
ATQA : 00 44
SAK : 00 [2]
TYPE : INFINEON my-dÖ move lean (SLE 66R01L)
MANUFACTURER : Infineon Technologies AG Germany
proprietary non iso14443-4 card found, RATS not supported
Answers to chinese magic backdoor commands: NO
pm3 --> hf mfu in
--- Tag Information ---------
-------------------------------------------------------------
TYPE : INFINEON my-dÖ move lean (SLE 66R01L)
UID : 05 7F 51 6B 65 54 E9
UID[0] : 05, Infineon Technologies AG Germany
BCC0 : A3, Ok
BCC1 : B3, Ok
Internal : 15, not default
Lock : 00 C0 - 1100000000000000
OneTimePad : 03 00 00 00 - 00000000000000000000000000000011
Since the tag is unknown, the dump command defaults to 16...
DUMP:
pm3 --> hf mfu dump
TYPE : Unknown 000000
Reading tag memory...
Block# | Data |lck| Ascii
---------------------------------
00/0x00 | 05 7F 51 A3 | |
01/0x01 | 6B 65 54 E9 | |
02/0x02 | B3 15 00 C0 | |
03/0x03 | 03 00 00 00 | 0 | ♥
04/0x04 | 02 00 00 03 | 0 | ☻
05/0x05 | 03 0F 03 07 | 0 | ♥☼♥
06/0x06 | 95 59 58 B4 | 0 | òYX┤
07/0x07 | 7D 57 BE 92 | 0 | }W¥Æ
08/0x08 | 30 30 30 35 | 0 | 0005
09/0x09 | 2D 4E 53 54 | 0 | -NST
10/0x0A | 02 F5 1D 11 | 0 | ☻§↔◄
11/0x0B | 24 02 EC 80 | 0 | $☻ýÇ
12/0x0C | 00 00 00 00 | 0 |
13/0x0D | 00 00 00 00 | 0 |
14/0x0E | 11 05 00 00 | 1 | ◄♣
15/0x0F | 60 97 34 22 | 1 | `ù4"
---------------------------------
Written on tag:
--------------------------------------
1105 0000 6097 3422
P151405452 - 057f516B6554E9
Where the last number is the UID.
Last edited by iceman (2015-06-01 16:31:27)
Offline
It is known: SLE 66R01L (my-d move lean); UID1 info (from Infineon datasheets):
It is also described in this list.
New info to update your commands
Last edited by asper (2015-05-31 22:25:23)
Offline
some good info here
it appears the lean is just 16 pages.
Offline
I saw your addons Marshmellow, great!
Now we only need to add the NFC part of it for that my_d tag...
Didn't seem like the my_d tags supported version|authentication
Last edited by iceman (2015-06-01 09:58:43)
Offline
What NFC part? for the my_d_move_nfc vs my_d_move? i think that is just an initialization difference.
Offline
i don't see any mention of version, but there are 8 byte keys and password modes mentioned for some of the tags: SLE 66RxxS especially.
Haven't found the actual command set yet for the auth though.
Offline
dunno, I haven't read any datasheets yet, however I was refering to the "hf mfu info" command needs to print ndef_cc for this new tag since it is ndef_Cc compliant
Offline
it will. all tags will now.
Offline
good.
Any ideas on the data dump? Doesn't look encrypted.
its a 3 times pass, 10 turkish lira (0x0A) ,
the onetimepad could be used, since I stamped it twice of the three times allowed.
Offline
Need more examples and surrounding info.
Offline
Lets see if there is some people visiting Istanbul in this forum then.
Offline
To bad that in 4 years, none answered (considering the huge touristic attraction of Istanbul).
I hope i can start back the conversation with my dump if you are still interested.
this is a used 1-pass (Birgeç)
proxmark3> hf mfu dump
TYPE : INFINEON my-d move lean (SLE 66R01L)
Reading tag memory...
Block# | Data |lck| Ascii
---------+-------------+---+------
0/0x00 | 05 73 10 ee | |
1/0x01 | 82 fa 54 e9 | |
2/0x02 | c5 15 00 c0 | |
3/0x03 | 01 00 00 00 | 0 | ....
4/0x04 | 02 00 00 03 | 0 | ....
5/0x05 | 01 12 06 14 | 0 | ....
6/0x06 | f7 29 87 ee | 0 | .)..
7/0x07 | e3 ab 57 43 | 0 | ..WC
8/0x08 | 4b 44 45 2d | 0 | KDE-
9/0x09 | 59 4b 44 00 | 0 | YKD.
10/0x0A | 01 31 05 0c | 0 | .1..
11/0x0B | 3a 01 65 77 | 0 | :.ew
12/0x0C | 02 66 26 00 | 0 | .f&.
13/0x0D | 4b bf 5c 67 | 0 | K.\g
14/0x0E | 11 50 00 01 | 1 | .P..
15/0x0F | 31 08 29 34 | 1 | 1.)4
---------------------------------
this is another but i don't know what kind and how much used.
proxmark3> hf mfu dump
TYPE : INFINEON my-d move lean (SLE 66R01L)
Reading tag memory...
Block# | Data |lck| Ascii
---------+-------------+---+------
0/0x00 | 05 7f b1 43 | |
1/0x01 | 13 ca 54 e9 | |
2/0x02 | 64 15 00 c0 | |
3/0x03 | 01 00 00 00 | 0 | ....
4/0x04 | 02 00 00 03 | 0 | ....
5/0x05 | 01 12 06 14 | 0 | ....
6/0x06 | 52 ef a8 24 | 0 | R..$
7/0x07 | 12 28 4f 49 | 0 | .(OI
8/0x08 | 4b 44 45 2d | 0 | KDE-
9/0x09 | 59 4b 44 00 | 0 | YKD.
10/0x0A | 01 31 05 0c | 0 | .1..
11/0x0B | 3a 01 1e 62 | 0 | :..b
12/0x0C | 02 66 26 00 | 0 | .f&.
13/0x0D | fc 15 8b ab | 0 | ....
14/0x0E | 11 57 00 01 | 1 | .W..
15/0x0F | 31 08 29 33 | 1 | 1.)3
---------------------------------
Offline
I think I have some istanbul tickets aswell layin' around
Offline
I think I have some istanbul tickets aswell layin' around
I have these cards, is there anything I can do for you?
Offline
Not really, you would need to do as in this thread http://www.proxmark.org/forum/viewtopic.php?id=5126
gather specific pairs of data. UID/ PWD.
Offline
Seeing people's dumps and comparing with my findings, I think I have some kind of understanding of Istanbul Xtime pass tickets.
These are my dumps:
2Pass ticket / 2x Used
Block# | Data |lck| Ascii
---------+-------------+---+------
0/0x00 | 05 71 5B A7 | | .q[.
1/0x01 | 4A FA 54 E9 | | J.T.
2/0x02 | 0D 15 00 C0 | | ....
3/0x03 | 03 00 00 00 | 0 | ....
4/0x04 | 02 00 00 05 | 0 | ....
5/0x05 | 02 12 06 16 | 0 | ....
6/0x06 | D3 91 E5 96 | 0 | ....
7/0x07 | 4E 4B 59 7A | 0 | NKYz
8/0x08 | 5F 5F 43 2D | 0 | __C-
9/0x09 | 31 38 36 39 | 0 | 1869
10/0x0A | 02 43 C7 23 | 0 | .C.#
11/0x0B | 00 00 E5 AC | 0 | ....
12/0x0C | 03 0F 29 00 | 0 | ..).
13/0x0D | B4 81 6C 64 | 0 | ..ld
14/0x0E | 11 56 00 01 | 1 | .V..
15/0x0F | 00 00 57 88 | 1 | ..W.
---------------------------------
1 Pass ticket / Not used
Block# | Data |lck| Ascii
---------+-------------+---+------
0/0x00 | 05 74 F3 0A | | .t..
1/0x01 | 3C 5B 54 E9 | | <[T.
2/0x02 | DA 15 00 C0 | | ....
3/0x03 | 00 00 00 00 | 0 | ....
4/0x04 | 02 00 00 03 | 0 | ....
5/0x05 | 01 12 06 14 | 0 | ....
6/0x06 | F0 D0 78 4D | 0 | ..xM
7/0x07 | C0 A0 29 B8 | 0 | ..).
8/0x08 | 00 00 00 00 | 0 | ....
9/0x09 | 00 00 00 00 | 0 | ....
10/0x0A | 00 00 00 00 | 0 | ....
11/0x0B | 00 00 00 00 | 0 | ....
12/0x0C | 03 10 29 00 | 0 | ..).
13/0x0D | 62 82 E2 FE | 0 | b...
14/0x0E | 10 95 00 01 | 1 | ....
15/0x0F | 00 00 88 24 | 1 | ...$
---------------------------------
Another 1 Pass ticket / 1 Used
Block# | Data |lck| Ascii
---------+-------------+---+------
0/0x00 | 05 72 A1 5E | | .r.^
1/0x01 | 2E FA 54 E9 | | ..T.
2/0x02 | 69 15 00 C0 | | i...
3/0x03 | 01 00 00 00 | 0 | ....
4/0x04 | 02 00 00 01 | 0 | ....
5/0x05 | 01 12 06 12 | 0 | ....
6/0x06 | E6 12 EE 1B | 0 | ....
7/0x07 | DA EB 72 3B | 0 | ..r;
8/0x08 | 55 5A 31 2D | 0 | UZ1-
9/0x09 | 55 5A 31 00 | 0 | UZ1.
10/0x0A | 01 97 CD 23 | 0 | ...#
11/0x0B | 00 00 14 26 | 0 | ...&
12/0x0C | 03 10 29 00 | 0 | ..).
13/0x0D | 8B EB C0 C3 | 0 | ....
14/0x0E | 10 98 00 01 | 1 | ....
15/0x0F | 00 00 99 57 | 1 | ...W
---------------------------------
- Comparing with 3Pass/2Pass/1Pass you can see Block 5's first byte is changing according to how many times you can use it.
- Block 8 to Block B contains information about Station that you used the ticket. I saw those strings on Bus's information screen. Also inside of normal Istanbulkart. ( can be read with the help of proxy android app, my research on normal ticket )
- Other than Block 3 and Block8-A, no block is changing after transaction.
- Block 5 contains date information but I'm not sure. 0x12 = 20 (in 2020) 0x6 , 6th is month. They are holding this because tickets can be used only within 60 days after you purchase it.
- Locking bytes always set to same block 14 and 15. These blocks cannot be changed.
- OTP section is set after using the ticket. Since iceman's 2/3 pass ticket is also set 03 as OTP, (same as my 2/2 ticket's OTP) I think 03 means 2 times used. 01 means 1 time used.
I'm not done researching it but one of my theory is block 14 and 15 can be mac of card's data. Since there are different type of pass tickets, reader need to know which type (1x/2x/3x) of card its communicating. If it takes type from block 5, It can be changed and machine can be fooled ? If block 14 and 15 is kind of mac they can block this behaviour..
Also as far as I understand in MY D lean SLE 66R01L there is no authentication. Can't we just simulate the card ?
Next day update:
- I incremented the block5[0], but machine gave `invalid card` error which means there is a check for it. Maybe section 6-7 ?
- In second attempt I tried to lock OTP section by writing to Lock section So machine cant write to OTP section (usage count) Machine gave weird error but doors didn't open
Last edited by eybisi (2020-06-18 12:56:53)
Offline