Now there are magic ISO15693 cards which can have their UID changed:
This is of no interest to us, as SKIDATA tags are EM4233 and those magic tags are NXP ICODE. I recall that some tickets used to be ICODE, at least in my home resort, but I haven't seen them since long ago. Older tags have been (or are being) phased out.
]]>It is NOT POSSIBLE to modify an UID/Serial for ISO15693 cards/tags (and the above mentioned cards are all ISO15693); no one has ever emulated an ISO15693 tags until now so it will be impossible for you to do what you are trying to do. Also serials are written at the tags factory so even ski resorts have no control on them, they receive them "as is", they can only put the serial in the database and add/remove features to it.
Now there are magic ISO15693 cards which can have their UID changed:
]]>My approach with these tags is like this:
- buy a point card;
- go to the gate and snoop the conversation for a few times;
- send raw commands to the tag based on snooped conversation in order to recharge with points.
I don't have the gear to snoop, but if someone can share some clean conversation I can try to recharge.
The problem is that the raw commands will contain UID or other encryption, and most likely will work on the tag that was snooped!
Any other ideas?
P.S. I have more records in TXT files!
]]>This first reading was made immediately after I charged the tag with 120 points, every entry on the gate take 4 points from the card, and every scan has a time stamp.
Unfortunately I wasn't able to take readings every time, and I was unable to correlate the points with readings.
Here are all the block's values and after you'll get just the time stamp and 3 (2F, 30, 31) blocks that are changing with every pass:
** TagInfo scan (version 4.24.4) 2019-02-10 17:34:20 **
# Memory content:
[00] . 57 08 77 A9 |W␈w.|
[01] . 82 18 60 20 |.␘`␠|
[02] . 00 38 00 00 |␀8␀␀|
[03] . 1C 48 33 00 |␜H3␀|
[04] . 1B 00 00 00 |␛␀␀␀|
[05] . 00 00 00 00 |␀␀␀␀|
......zero.....
[1B] . 00 00 00 00 |␀␀␀␀|
[1C] . 2A 80 53 42 |*.SB|
[1D] . 1F 90 53 42 |␟.SB|
[1E] . 33 00 00 00 |3␀␀␀|
[1F] . 00 00 00 00 |␀␀␀␀|
......zero.....
[29] . 00 00 00 00 |␀␀␀␀|
[2A] . A8 11 FE 02 |.␑.␂|
[2B] . A0 05 1B 01 |.␅␛␁|
[2C] . CC CB D5 7B |...{|
[2D] . 3A EE 62 D5 |:.b.|
[2E] . 40 DF B1 65 |@..e|
[2F] . 00 00 00 00 |␀␀␀␀|
[30] . A4 80 09 0F |..␉␏| ~~~~~ charged with 120 points
[31] . 00 00 78 00 |␀␀x␀|
[32] . 00 00 00 00 |␀␀␀␀|
[33] . 00 00 00 00 |␀␀␀␀|
** TagInfo scan (version 4.24.4) 2019-02-11 13:24:21 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . 42 80 8F 0C |B..␌|
[31] . 00 74 68 00 |␀th␀|
** TagInfo scan (version 4.24.4) 2019-02-11 18:29:19 ** ~~~~~ let's say "X" points
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . A8 80 95 08 |...␈|
[31] . 00 A4 48 00 |␀.H␀|
** TagInfo scan (version 4.24.4) 2019-02-11 18:33:22 ** ~~~~~ now X-4 points
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . B5 80 95 08 |...␈|
[31] . 00 C4 40 00 |␀.@␀|
** TagInfo scan (version 4.24.4) 2019-02-11 18:37:45 ** ~~~~~ now X-8 points
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . 60 80 8D 07 |`..␇|
[31] . 00 C4 40 00 |␀.@␀|
** TagInfo scan (version 4.24.4) 2019-02-12 15:25:02 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . 9C 80 91 06 |...␆|
[31] . 00 84 38 00 |␀.8␀|
** TagInfo scan (version 4.24.4) 2019-02-12 16:16:28 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . A2 80 92 05 |...␅|
[31] . 00 A4 30 00 |␀.0␀|
** TagInfo scan (version 4.24.4) 2019-02-12 16:26:49 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . 9D 80 92 05 |...␅|
[31] . 00 AC 28 00 |␀.(␀|
** TagInfo scan (version 4.24.4) 2019-02-12 16:41:29 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . A3 80 96 04 |...␄|
[31] . 00 AC 28 00 |␀.(␀|
** TagInfo scan (version 4.24.4) 2019-02-12 16:53:26 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . B0 80 96 04 |...␄|
[31] . 00 CC 20 00 |␀.␠␀|
** TagInfo scan (version 4.24.4) 2019-02-12 17:03:42 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . 88 80 93 03 |...␃|
[31] . 00 CC 20 00 |␀.␠␀|
** TagInfo scan (version 4.24.4) 2019-02-13 09:42:47 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . 7B 80 93 03 |{..␃|
[31] . 00 B4 18 00 |␀.␘␀|
** TagInfo scan (version 4.24.4) 2019-02-13 09:50:42 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . 81 80 97 02 |...␂|
[31] . 00 B4 18 00 |␀.␘␀|
** TagInfo scan (version 4.24.4) 2019-02-13 10:29:04 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . D5 80 98 01 |...␁|
[31] . 00 D4 10 00 |␀.␐␀|
** TagInfo scan (version 4.24.4) 2019-02-13 10:52:54 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . D6 80 9C 00 |...␀|
[31] . 00 DC 08 00 |␀.␈␀|
** TagInfo scan (version 4.24.4) 2019-02-13 11:07:27 ** ~~~~~ EMPTY CARD
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . BF 80 1F 00 |..␟␀|
[31] . 00 FC 00 00 |␀.␀␀|
** TagInfo scan (version 4.24.4) 2019-02-13 11:18:07 ** ~~~~~ Recharged with 120 points
[2F] . 00 00 00 00 |␀␀␀␀|
[30] . A4 80 09 0F |..␉␏|
[31] . 00 00 78 00 |␀␀x␀|
** TagInfo scan (version 4.24.4) 2019-02-13 11:28:57 ** ~~~~~ minus 4 points
[2F] . 20 00 00 00 |␠␀␀␀| ~~~~~ now 116 points
[30] . 58 80 8A 0E |X..␎|
[31] . 00 4C 78 00 |␀Lx␀|
** TagInfo scan (version 4.24.4) 2019-02-13 11:37:15 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . 5E 80 8A 0E |^..␎|
[31] . 00 6C 70 00 |␀lp␀|
** TagInfo scan (version 4.24.4) 2019-02-13 11:58:14 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . 3C 80 8B 0D |<..␍|
[31] . 00 6C 70 00 |␀lp␀|
** TagInfo scan (version 4.24.4) 2019-02-13 12:10:41 **
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . 3C 80 8B 0D |<..␍|
[31] . 00 74 68 00 |␀th␀|
Right now i'm interested in ISO 15693 tag, especially in snooping / writing on Skidata cards. I have knowledge only in EM Microelectronic-Marin SA tags.
Until now I'm able to read full info from these cards with 3 separate devices:
- arduino & PN5180 - can be standalone read/write device;
- M24LR-Discovery kit - read/write device with PC;
- Sony Xperia X with "TagInfo" app from NXP - read only device.
Here is an example of a full scan (all scans are made with my smartphone):
** TagInfo scan (version 4.24.4) 2019-02-11 13:24:36 **
Report Type: External
-- IC INFO ------------------------------
# IC manufacturer:
EM Microelectronic-Marin SA
# IC type:
EM4x3x
# Application information:
SKIDATA keycard
* Key number: xx-16147133534526504087-x
* Area: [Unknown area] (2260)
* (Probably)Valid till: 30/07/1989 (FE:02)
-- NDEF ------------------------------
# No NDEF data storage populated:
-- EXTRA ------------------------------
# Memory size:
208 bytes
* 52 blocks, with 4 bytes per block
# IC detailed information:
Supported read commands:
* Single Block Read
* Multiple Block Read
* Get Multiple Block Security Status
* Get System Information
AFI supported
DSFID supported
IC reference value: 0x02
Customer ID: 0x066
-- FULL SCAN ------------------------------
# Technologies supported:
ISO/IEC 15693-3 compatible
ISO/IEC 15693-2 compatible
# Android technology information:
Tag description:
* TAG: Tech [android.nfc.tech.NfcV, android.nfc.tech.NdefFormatable]
* Maximum transceive length: 253 bytes
MIFARE Classic support present in Android
# Detailed protocol information:
ID: E0:16:24:66:02:3F:FC:97
AFI: 0x00
DSFID: 0x02
# Memory content:
[00] . 6D 08 80 20 |m␈.␠|
[01] . 42 18 60 20 |B␘`␠|
[02] . 00 38 00 00 |␀8␀␀|
[03] . 1C 48 33 00 |␜H3␀|
[04] . 1B 00 00 00 |␛␀␀␀|
[05] . 00 00 00 00 |␀␀␀␀|
[06] . 00 00 00 00 |␀␀␀␀|
[07] . 00 00 00 00 |␀␀␀␀|
[08] . 00 00 00 00 |␀␀␀␀|
[09] . 00 00 00 00 |␀␀␀␀|
[0A] . 00 00 00 00 |␀␀␀␀|
[0B] . 00 00 00 00 |␀␀␀␀|
[0C] . 00 00 00 00 |␀␀␀␀|
[0D] . 00 00 00 00 |␀␀␀␀|
[0E] . 00 00 00 00 |␀␀␀␀|
[0F] . 00 00 00 00 |␀␀␀␀|
[10] . 00 00 00 00 |␀␀␀␀|
[11] . 00 00 00 00 |␀␀␀␀|
[12] . 00 00 00 00 |␀␀␀␀|
[13] . 00 00 00 00 |␀␀␀␀|
[14] . 00 00 00 00 |␀␀␀␀|
[15] . 00 00 00 00 |␀␀␀␀|
[16] . 00 00 00 00 |␀␀␀␀|
[17] . 00 00 00 00 |␀␀␀␀|
[18] . 00 00 00 00 |␀␀␀␀|
[19] . 00 00 00 00 |␀␀␀␀|
[1A] . 00 00 00 00 |␀␀␀␀|
[1B] . 00 00 00 00 |␀␀␀␀|
[1C] . 2A 80 53 42 |*.SB|
[1D] . 1F 90 53 42 |␟.SB|
[1E] . 33 00 00 00 |3␀␀␀|
[1F] . 00 80 00 00 |␀.␀␀|
[20] . 00 00 00 00 |␀␀␀␀|
[21] . 1C DE 5E 8D |␜.^.|
[22] . AD 97 F2 92 |....|
[23] . F0 DE 44 6C |..Dl|
[24] . 20 00 00 00 |␠␀␀␀|
[25] . BF 80 1F 00 |..␟␀|
[26] . 00 FC 00 00 |␀.␀␀|
[27] . 00 00 00 00 |␀␀␀␀|
[28] . 00 00 00 00 |␀␀␀␀|
[29] . 00 00 00 00 |␀␀␀␀|
[2A] . A8 11 FE 02 |.␑.␂|
[2B] . A0 05 1B 01 |.␅␛␁|
[2C] . 1C DD 5E 8D |␜.^.|
[2D] . ED 8B F2 92 |....|
[2E] . 40 1B 80 6C |@␛.l|
[2F] . 20 00 00 00 |␠␀␀␀|
[30] . A2 80 91 09 |...␉|
[31] . 00 A4 48 00 |␀.H␀|
[32] . 00 00 00 00 |␀␀␀␀|
[33] . 00 00 00 00 |␀␀␀␀|
x:locked, .:unlocked
--------------------------------------
Writing operation is possible only between 4 and 27 blocks, the rest are somehow locked!
Between 11 and 16 FEB 2019, I am on a small ski resort and I have around 50 almost consecutive readings from 4 different tags (with point on them), and I can tell you that the gates make writing operations on the card and they aren't linked to a server or central data base.
]]>[23] [25] - Select
[13] [23] - Read multiple blocks
[23] [E0] - Unknown (2-way auth)
[03] [E1] - Unknown (2-way auth)
So I guess there is no write operation between turnstile and a card with limited time. But anyway I will continue to sniff in order to obtain inventory command.
]]>03 E1 16 DEBC9A7856341200 8C49E5 0FE2
[flags] [cmd] [EMcode] [unknown] [crc]DEBC9A7856341200 -> DE BC 9A 78 56 34 12 00 -> 00 12 34 56 78 9A BC DE
Yep, today I saw it. Yesterday I was very tired and should have gone to bed instead of writing that post
BTW, other interesting thing is that EM4233 card responds only 3 times in a row for E0/E1 commands and than I have to remove it from the field to run this sequence again, like this:
1.
>>> 23E01669B19903662416E00
<<< 009EDD379EA46057
>>> 03E116DEBC9A7856341200B7F4B5
<<< 010F [error]2.
>>> 23E01669B19903662416E00
<<< [some other hash]
>>> 03E116DEBC9A7856341200B7F4B5
<<< 010F [error]3.
>>> 23E01669B19903662416E00
<<< [some other hash]
>>> 03E116DEBC9A7856341200B7F4B5
<<< 010F [error]4.
>>> 23E01669B19903662416E00
<<< [some other hash]
>>> 03E116DEBC9A7856341200B7F4B5
<<< ... [no responce]Brute force protection))
Well, worst case scenario: the proxmark can reset its field and the tag is power flushed
]]>Also, where did you find 00123456789ABCDE?
03 E1 16 DEBC9A7856341200 8C49E5 0FE2
[flags] [cmd] [EMcode] [unknown] [crc]
DEBC9A7856341200 -> DE BC 9A 78 56 34 12 00 -> 00 12 34 56 78 9A BC DE
BTW, other interesting thing is that EM4233 card responds only 3 times in a row for E0/E1 commands and than I have to remove it from the field to run this sequence again, like this:
1.
>>> 23E01669B19903662416E00
<<< 009EDD379EA46057
>>> 03E116DEBC9A7856341200B7F4B5
<<< 010F [error]
2.
>>> 23E01669B19903662416E00
<<< [some other hash]
>>> 03E116DEBC9A7856341200B7F4B5
<<< 010F [error]
3.
>>> 23E01669B19903662416E00
<<< [some other hash]
>>> 03E116DEBC9A7856341200B7F4B5
<<< 010F [error]
4.
>>> 23E01669B19903662416E00
<<< [some other hash]
>>> 03E116DEBC9A7856341200B7F4B5
<<< ... [no responce]
Brute force protection))
]]>With the information papuaoshi just published here, I'd say this might be Grain128A authentication, even though, 7*8=56 is way too short for any "standard" Grain128A value, may it be the key or the IV. Did they roll their own crazy Grain implementation with less bits?
I do not have the full datasheet, but might have found some good source to reverse engineer information from. Fire me an email if you wish @papuaoshi
]]>The response for E0 is random hash string of 7bytes like C21EAAAF7284C3, B73AACDA41D702, ...
Obviously, UID of that card is 69B19903662416E0 and it looks like 00123456789ABCDE is some kind of password (may be SIM card key#2?). But the rest is unknown for me.
The only datasheet I have is EMDB410 and EM4233SLIC, so could anyone share EM4233 full datasheet with me maybe?
]]>thanks for your reply. but it's will not help me.
I have some information,
In the big station using Skipass in France they have the anti-passback active.
So if you use a same card (clown) in a same turnstil, the second guy can't go on.