emsec / ChameleonMini

The ChameleonMini is a versatile contactless smartcard emulator compliant to NFC. The ChameleonMini was developed by https://kasper-oswald.de. The device is available at https://shop.kasper.it. For further information see the Getting Started Page https://rawgit.com/emsec/ChameleonMini/master/Doc/Doxygen/html/_page__getting_started.html or the Wiki tab above.
Other
1.74k stars 392 forks source link

Effectively programming emulated MIFARE tags on the Chameleon with ISO APDU #179

Open maxieds opened 6 years ago

maxieds commented 6 years ago

Hello. I have been tinkering with some USB code to control the Chameleon Mini boards (both revisions), and am interested in building up a non-trivial tag that is being emulated by the Chameleon Mini boards. By this I mean, that I want to be able to make directories, store files, key protect special files, etc., and all of that fun special jazz that can be done with your typical NFC tag by means of (usually) ISO APDU commands. Right now the only particularly easy tag properties to configure are UID-related.

I plugged my Chameleon RevG board into my favorite Linux, and issued the following command: $ lsusb -v 16d0:04b2

As a response I got back some interesting details like

Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               5
Device Status:     0x0000
  (Bus Powered)

In my android app (Chameleon Mini Live Debugger) I have always chosen to communicate with the Chameleon devices over serial USB (UART specification if you look up the USB libs for communication on Android. What I'm wondering is if all this extra output at the end of the above command could let me communicate in a different mode with the Chameleon? The end goal of this is again to talk to, say, a MIFARE_1K tag that the Chameleon board is currently emulating using standard APDU-formatted messages.

I would really, really be appreciative of anyone who can shed some light on this approach!! :)

geo-rg commented 6 years ago

Hi @maxieds I never tried to communicate with the Chameleon in other ways than it is implemented currently. Personally, I only see little benefit from using APDUs. However, it would need major changes in the Firmware and if you really want to do this (we appreciate every contribution!) you should have a look at the functions in Terminal/Terminal.c and Terminal/CommandLine.c.