search

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.72k stars 391 forks source link

Can't write to UID #300

Closed X-Ryl669 closed 3 years ago

X-Ryl669 commented 3 years ago

Done this:

version?
101:OK WITH TEXT
ChameleonMini RevG 210603 using LUFA 151115 compiled with AVR-GCC 11.1.0. Based on the open-source NFC tool ChameleonMini. https://github.com/emsec/ChameleonMini commit 41fa243
setting?
101:OK WITH TEXT
1
config
201:INVALID COMMAND USAGE
config?
101:OK WITH TEXT
NONE
uid?
101:OK WITH TEXT
NO UID.
config=?
101:OK WITH TEXT
NONE,MF_ULTRALIGHT,MF_ULTRALIGHT_EV1_80B,MF_ULTRALIGHT_EV1_164B,MF_ULTRALIGHT_C,MF_CLASSIC_MINI_4B,MF_CLASSIC_1K,MF_CLASSIC_1K_7B,ISO14443A_SNIFF,ISO14443A_READER,ISO15693_SNIFF,TITAGITSTANDARD,TITAGITPLUS,EM4233
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
clear
100:OK
store
100:OK
uid?
101:OK WITH TEXT
72F47648387034
uid=01020304050607
100:OK
uid?
101:OK WITH TEXT
72F47648387034

UID never update and it's fixed to a wrong value.

When programming the device with avrdude, the verification is ok for both flash and eeprom, yet, I can't get the flash to program from the application itself. I've tried to also build the firmware with disabled DMA (in Memory.c, commented #define UseDMA) but no change whatsoever.

Programming with avrdude works, since if I change the number of codec in the Makefile, it appears in the config=? query

Also, the device is not in readonly mode (readonly? returns 0)

Any idea ?

X-Ryl669 commented 3 years ago

Also, I get exactly the same value for any setting:

setting=1
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=2
100:OK
uid?
101:OK WITH TEXT
NO UID.
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=3
100:OK
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=4
100:OK
uid?
101:OK WITH TEXT
NO UID.
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=5
100:OK
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=6
100:OK
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=7
100:OK
uid?
101:OK WITH TEXT
NO UID.
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=8
100:OK
uid?
101:OK WITH TEXT
NO UID.
config=MF_CLASSIC_1K_7B
100:OK
uid?
101:OK WITH TEXT
72F47648387034
setting=9
202:INVALID PARAMETER
ceres-c commented 3 years ago

Totally wild guess and most likely won't help, but have you tried disabling some configs at compile time? It's very unlikely this is related, but still...

X-Ryl669 commented 3 years ago

So far, I've gave up with the "flash" storage and patched the code to use EEPROM instead. I don't know if I have a version with MRAM (not FRAM) and since I recently started to store my keys with a magnet on them...

I only needed to emulate a TiTag +. I've fixed everything and both the original tag and the emulation returns the same thing now (UID + Memory content) when scanned with NXP TagInfo (and NFC Tool), but the original reader rejects the chameleon.

Up to last week, it worked flawlessly with firmware from august 2020, but it suddenly failed (the original reader started to emit error tones) and I've tried to update the firmware to a more recent version. If I remember correctly, when I've initially programmed it (in august or september), I had to reverse the UID byte order in order to work and the chameleon wasn't correctly detected by my phone but what perfectly detected by the reader.

Now, while I can't see any difference with my Android's NFC scan tools, the original reader does not even bip when the chameleon is presented, like if the emulation wasn't working. The field led is blinking. I don't have to revert the UID anymore.

I'm 99% sure the tag memory content is not required (in my case), only the UID, yet it does not work.

Is there some work done on the TiTag standard (or plus) version that could have reduced the compatibility ?

I'm afraid the system is damaged somehow (and it's too expensive to buy another one just to try).

david-oswald commented 3 years ago

Did you ever get this fixed? It sounds like an FRAM issue, because the current config should be buffered in FRAM afaik.

Also, which version of the Chameleon are you using? Just the normal KAOS RevG?

X-Ryl669 commented 3 years ago

Honestly, I've wasted too much time on this. So to sum up, I used the EEPROM instead of the MRAM (really, it's a MRAM I have, and I'm 99% sure it's dead) to store the TagPlus UID I needed (and the content of the tag, which happened to be all zero). With my android phone, when I'm detecting the tag, it's a 1:1 of the other (genuine) tag in both NXP TagInfo and NFC Tool, yet, the chameleon tiny does not work with the original reader.

What's strange is that:

  1. When I received it in 2019, the delivered firmware wasn't supporting ISO15693, so I had to find a (draft) version from this repository pull requests to compile and flash it. After that, I was able to copy the original tag's UID but I had to reverse its order (at the time, the code did not reversed the UID's byte order)
  2. When read with my phone, it was only detected, maybe once every 10 tries, but it worked flawlessly with the original reader.
  3. It worked until last month (so more than a year), where I've lost the ChameleonTiny's tiny screw holding the string, and decided to attach it to my keys (and replaced the screw).
  4. One of my key has an magnet on it, so I guess it's what destructed the MRAM.
  5. Now the code does not use the MRAM anymore, and I've compiled the latest version which is more accepted by my phone: it works 100% of the time with the phone but does not with original reader.

At this point, I'm not able to make progress anymore. I don't have the tools required to understand/sniff the difference between the original tag's answer and the chameleon's answer.

X-Ryl669 commented 3 years ago

BTW, I also had a Chameleon Rev E but never got it to work.

timokasper commented 3 years ago

To me it seems that you have purchased some other products manufactured by a third party ( I read ChameleonTiny etc.) that are not supported in this git. ChameleonMini RevG definitely has an FRAM. This git is only for the original ChameleonMini RevG as invented, open-sourced and manufactured by us (Kasper & Oswald GmbH / KAOS). We are aware of various other profit-oriented / commercialized variants of our ChameleonMini project - unfortunately they are often not even open-source but have some commercial license! on top of our open-source license.... - and since we don't know what these third party manufacturers have been doing to create malfunctioning devices, we cannot help solving the problems with their products. I recommend to contact the manufacturer directly.

X-Ryl669 commented 3 years ago

Right, it's confusing (for us, customers). I had purchased a Rev E (95% sure it was by KAOS) but since I wanted to emulate a TiTag+ and the support wasn't coming, I bought the ChameleonTiny (because the form factor was perfect as a key chain, the original format is too big to be useful). At the time, I did not realize it wasn't the same company producing both product. If I were you, I won't be ashamed to copy their product (the ChameleonTiny is very convenient and practical) since they weren't ashamed to copy yours.

Anyway, I'm not blaming you for the MRAM issue (which, as you said is not your responsibility). I'm not blaming you for the code I wrote either (to use the EEPROM instead of the MRAM). I'm almost sure my code is working since the emulation is read by my phone correctly on both application.

The original issue is probably invalid, but the later issue is, IMHO, still valid: the TiTag+ emulation is not working with the original reader I had, yet the smartphone does not see any issue.

X-Ryl669 commented 3 years ago

Their hardware is open source: https://github.com/RfidResearchGroup/ChameleonMini

timokasper commented 3 years ago

the ChameleonTiny is very convenient and practical so why the above description of malfunctioning? The original RevG doesn't have these problems.

Their hardware is open source: https://github.com/RfidResearchGroup/ChameleonMini aha, this is some clone of our git; it contains the schematics of (our) original RevG 5 years ago or have I missed s.th. ... ?

Also, on some other page you will find in a hidden way, that the license of the Tiny is NOT open source.

X-Ryl669 commented 3 years ago

This seems recent to me. It looks like Altium's schematic and is dated 2019. There's no Gerber or PCB layout.

david-oswald commented 3 years ago

So to clarify the situation is as follows:

So in summary, contrary to the original Chameleon, you cannot really build a Tiny on your own.

X-Ryl669 commented 3 years ago

There are 2 version of the tiny, one with the BLE chip (I think it's called the Tiny Pro) and the other without. I have the latter version. It's not hard to see that the BLE chip is used as a serial link proxy/pass through (AVR_TX and RX are the only pins going from the NRF to the AVR), so even without the firmware, it shouldn't be required to update it to get it to work.

If I understand correctly, there is no software difference between the tiny and the mini, and I've built this repository's firmware and run on the their board without any issue. The pinout is the same for major components, the FRAM part number is also the same, and the AVR seems to be the same too. They have more pins used for leds (they have 8 leds while yours only has 2). They have a USB-C input but they only use the USB's D+D- lines so (the schematic is so simple) I doubt it would make any difference to the behavior.

There is zero guarantee that they actually routed this schematic (and the broken MRAM shouldn't happen with a FRAM, proves that they've probably swapped the flash for a cheaper MRAM version, unlike what's written on the schematic).

All in all, as a consumer, I'd say that both Chameleon (Rev E and Tiny) are hard to grasp (they are not dumb user friendly). Without a minimum knowledge to NFC standards, it's almost impossible to use. The software is powerful but made as a engineer tool, not as a consumer tool.

I guess the main use of these products is to merge all NFC tags we usually wear with us into a single device. As a dumb user, I would have loved if the product was working this way:

  1. Only 2 modes, the first mode being the default (no action from the user)
  2. Mode 1: When energized, the chameleon should start replying with all compatible tags it has saved in memory (no need to select the tag). Playing them in order with the right ATK/AFI should have the reader select the one it's interested into and the emulation could continue, so it'd work without any action from the user.
  3. Mode 2: When trying to learn a new tag, the user would place the chameleon over the tag and press a "learn" button. The tag will detect the tag type, and UID. If existing in its memory, it should delete it and start copying again on that slot or find a free slot if not. If no free slot or copying failed, they the chameleon should light its red (error) led and that's it.

IMHO, a user shouldn't have to know the technology of the tag she's using (Mifare, NTAG, TiTag+, etc...), nor how does it work. Using the Android App should be reserved for power user and even then, the app should be more intuitive than having to enter commands by hand.

david-oswald commented 3 years ago

Regarding the BLE chip, you're mostly right but I think there is some framing going on and also the BLE chip actually appears to control the Xmega power line and sample the antenna field, so it's not fully trivial.

Regarding the modes you outline, of course we'd be happy to see that as a contribution. However, at least for us the Chameleon is not targeted at "dumb" users but rather people who have (some) understanding of RFID technology.