Trimet hop fastpass - Githubissues

cfk4lif3 commented 7 years ago

<scan>
    <version>4.23</version>
    <date>2017-08-05 22:39:53</date>
    <title>NXP Semiconductors MIFARE DESFire EV1 tag</title>
    <uid nxp="true">04:2E:7B:1A:14:4D:80</uid>
    <hasndef>false</hasndef>
    <section>
        <subsection title="IC manufacturer">
            <block type="text">
    <content>NXP Semiconductors</content>
</block>
        </subsection>
        <subsection title="IC type">
            <block type="text">
    <content>MIFARE DESFire EV1</content>
</block>
        </subsection>
        <subsection title="DESFire Applications">
            <block type="text">
    <content>Multi-modal transit #0
‣ null<hexoutput> (0xF210E0)</hexoutput></content>
</block>
        </subsection>
    </section>
    <section>
        <subsection title="No NDEF data storage populated">
            <block type="text">
    <content></content>
</block>
        </subsection>
    </section>
    <section>
        <subsection title="Memory information">
            <block type="text">
    <content>Size: 256 bytes
Available: 128 bytes</content>
</block>
        </subsection>
        <subsection title="IC detailed information">
            <block type="text">
    <content>Capacitance: 17 pF</content>
</block>
        </subsection>
        <subsection title="Version information">
            <block type="text">
    <content>Vendor ID: NXP<hexoutput> (0x04)</hexoutput>
Hardware info:
‣ Type/subtype: 0x01/0x01
‣ Version: 1.0
‣ Storage size: 256 bytes<hexoutput> (0x10)</hexoutput>
‣ Protocol: ISO/IEC 14443-2 and -3<hexoutput> (0x05)</hexoutput>
Software info:
‣ Type/subtype: 0x01/0x01
‣ Version: 1.5
‣ Storage size: 256 bytes<hexoutput> (0x10)</hexoutput>
‣ Protocol: ISO/IEC 14443-3 and -4<hexoutput> (0x05)</hexoutput>
Batch no: 0xBA65185590
Production date: week 48, 2015<hexoutput> (0x4815)</hexoutput></content>
</block>
        </subsection>
    </section>
    <section>
        <subsection title="Technologies supported">
            <block type="text">
    <content>ISO/IEC 7816-4 compatible
Native DESFire APDU framing
ISO/IEC 14443-4 (Type A) compatible
ISO/IEC 14443-3 (Type A) compatible
ISO/IEC 14443-2 (Type A) compatible</content>
</block>
        </subsection>
        <subsection title="Android technology information">
            <block type="text">
    <content>Tag description:
‣ TAG: Tech [android.nfc.tech.IsoDep, android.nfc.tech.NfcA, android.nfc.tech.NdefFormatable]
‣ Maximum transceive length: 65279 bytes
‣ Default maximum transceive time-out: 618 ms
‣ Extended length APDUs supported
‣ Maximum transceive length: 253 bytes
‣ Default maximum transceive time-out: 618 ms
<hexoutput>MIFARE Classic support present in Android</hexoutput></content>
</block>
        </subsection>
        <subsection title="Detailed protocol information">
            <block type="text">
    <content>ID: 04:2E:7B:1A:14:4D:80
ATQA: 0x4403
SAK: 0x20
ATS: 0x06757781028000
‣ Max. accepted frame size: 64 bytes (FSCI: 5)
‣ Supported receive rates:
    • 106, 212, 424, 848 kbit/s (DR: 1, 2, 4, 8)
‣ Supported send rates:
    • 106, 212, 424, 848 kbit/s (DS: 1, 2, 4, 8)
‣ Different send and receive rates supported
‣ SFGT: 604.1 µs  (SFGI: 1)
‣ FWT: 77.33 ms  (FWI: 8)
‣ NAD not supported
‣ CID supported
‣ Historical bytes: 0x80 |·|</content>
</block>
        </subsection>
        <subsection title="Memory content">
            <block type="text">
    <content>PICC level (Application ID 0x000000)
‣ PICC key configuration:<hexoutput> (0x0F01)</hexoutput>
  • AES key
  • PICC key changeable
  • PICC key required for:
    ◦ directory list access: no
    ◦ create/delete applications: no
  • Configuration changeable
  • PICC key version: 13</content>
</block>
<block type="text">
    <content>
Application ID 0xF210E0
‣ Key configuration:<hexoutput> (0x0B82)</hexoutput>
  • 2 AES keys
  • Master key changeable
  • Master key required for:
    ◦ directory list access: no
    ◦ create/delete files: yes
  • Configuration changeable
  • Master key required for changing a key
  • Key versions:
    ◦ Master key: 13
    ◦ Key #1: 13</content>
</block>
<block type="text">
    <content>‣ 2 files present</content>
</block>
<block type="text">
    <content>
  • File ID 0x00: Standard data, 96 bytes
    ◦ Communication: plain
    ◦ Read key: free access<hexoutput> (0x0E)</hexoutput>
    ◦ Write key: blocked<hexoutput> (0x0F)</hexoutput>
    ◦ Read/Write key: blocked<hexoutput> (0x0F)</hexoutput>
    ◦ Change key: master key<hexoutput> (0x00)</hexoutput></content>
</block>
<block type="text">
    <content>    ◦ Contents:
</content>
</block>
<block type="DesFire">
    <address addrwidth="4">0</address>
    <data>01 54 52 49 31 01 00 0D 10 00 00 00 00 00 3D 3A</data>
</block>
<block type="DesFire">
    <address addrwidth="4">16</address>
    <data>00 00 00 00 00 00 00 00 00 00 00 0D 30 34 02 18</data>
</block>
<block type="DesFire">
    <address addrwidth="4">32</address>
    <data>3B 55 8A B4 6F BF 8F 5B 70 ED 9B 47 F2 14 80 0B</data>
</block>
<block type="DesFire">
    <address addrwidth="4">48</address>
    <data>FB 31 40 F9 E0 5C 2E 9B 02 18 47 BA C7 7B 0C EE</data>
</block>
<block type="DesFire">
    <address addrwidth="4">64</address>
    <data>D3 E8 AD AE FB 69 60 97 81 F4 47 CD 90 FF 34 A9</data>
</block>
<block type="DesFire">
    <address addrwidth="4">80</address>
    <data>FF 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00</data>
</block>
<block type="text">
    <content>
  • File ID 0x01: Backup data, 48 bytes
    ◦ Communication: encrypted
    ◦ Read key: free access<hexoutput> (0x0E)</hexoutput>
    ◦ Write key: blocked<hexoutput> (0x0F)</hexoutput>
    ◦ Read/Write key: key #1
    ◦ Change key: master key<hexoutput> (0x00)</hexoutput></content>
</block>
<block type="text">
    <content>    ◦ (No access)</content>
</block>
        </subsection>
    </section>
</scan>

supersat commented 6 years ago

File ID 0 appears to have some ASN.1-encoded data, which is probably an (EC)DSA signature of some sort. After skipping 0x1C bytes and dumping the bytes into openssl's asn1parse:

    0:d=0  hl=2 l=  52 cons: SEQUENCE
    2:d=1  hl=2 l=  24 prim: INTEGER           :3B558AB46FBF8F5B70ED9B47F214800BFB3140F9E05C2E9B
   28:d=1  hl=2 l=  24 prim: INTEGER           :47BAC77B0CEED3E8ADAEFB69609781F447CD90FF34A9FF72
   54:d=0  hl=2 l=   0 prim: EOC

phcoder commented 6 years ago

Can you supply the annotations for this dump or (preferably) another dump with annotations? Like current balance and serial number printed on card

phcoder commented 6 years ago

TLDR: only serial number and issue date is stored on those cards, no balance or trips.

I got my hands on one of those.

In first 0x1c bytes only the 4 bytes at offset 0xc differ and they correspond to MFG serial number printed on the bottom of the card.
File 1 contains a const 0x0101 and issue timestamp. Otherwise it's full of zeros.
The DER blob is also there. Note: it may contain encrypted data with ElGamal rather than a signature but I doubt it since it would mean that the encrypted data is uner 25 bytes and has no signature which is against best practices except if it's some kind of authentication key but this usecase seems also unlikely. Presumably it's signature of firsct 0x1c bytes

So it doesn't look like balance is stored on the card. The main serial number may be derivable from MFG number. if it's not the main serial number is unavailable.

phcoder commented 6 years ago

PR: https://github.com/micolous/metrodroid/pull/196 . But as I said: almost no info is stored on the card

codebutler / farebot

Trimet hop fastpass #147