ChameleonTiny

[CaseyBakey]

Hi there,

I did search everywhere but I don't see any information regarding ChameleonTiny.

1) Where can we find the stock firmware and also new, updated firmwares for it, in a binary form? 2) Is the ChameleonTiny is compatible with the ChameleonMini firmware speaking? 3) Is the good way to compile/update the firmware for the ChameleonTiny: a) clone this repo b) go to the Firmware/Chameleon-Mini folder c) run

make

d) plug the ChameleonTiny while pressing the B button to put it in bootloader mode

e) run

make program

? 4) Are you going to update/fix the ChameleonTiny? I got instable serial connection and also got disconnected while trying to use the "CLONE" or "DUMP_MFU" commands. 5) Do you have a fully detailed and updated list of CLI commands supported by your fork of ChameleonMini of Kaos/Oswald? 6) Do you manage to use the "DUMP_MFU" command? 7) Do you manage to support Mifare DESFire? 8) Could you please some examples (text with different commands) of use (like dumping a full Mifare Ultralight or Mifare Classic)? 9) Is the ChameleonTiny compatible with other ChameleonMini fork (or original) firmware? It seems the other repos are more active?

Thank you by advance for your answer!

[maltekrupa]

Hi, I started to play around with the Mini and Tiny today and will try to answer some of your questions.

Where can we find the stock firmware and also new, updated firmwares for it, in a binary form?

Stock from emsec repo: https://github.com/emsec/ChameleonMini/tree/master/Firmware/Chameleon-Mini/Latest Proxgrind firmware: https://github.com/RfidResearchGroup/ChameleonMini/tree/proxgrind/Firmware/Chameleon-Mini/Latest

Is the ChameleonTiny is compatible with the ChameleonMini firmware speaking?

It appears so to me, yes.

Is the ChameleonTiny compatible with other ChameleonMini fork (or original) firmware? It seems the other repos are more active?

Currently, I don't think so. I tested the original firmware and it workes on the terminal, but the buttons do not work correctly on both the Mini and the Tiny.

My fault. The emsec firmware seems to work fine. The buttons just work different, because the original Chameleon Mini has only two LEDs.

Is the good way to compile/update the firmware for the ChameleonTiny

The official documentation worked for me on both the Mini and the Tiny.

Are you going to update/fix the ChameleonTiny? I got instable serial connection and also got disconnected while trying to use the "CLONE" or "DUMP_MFU" commands.

CLONE does not work for me on the Proxgrind firmware either, see https://github.com/RfidResearchGroup/ChameleonMini/issues/7. I haven't tested the DUMP_MFU yet, because I do not own a MFU card.

I'm currently running the emsec firmware (https://github.com/emsec/ChameleonMini/commit/b58ab584716cc3183eed4f8f078027d064ba3a30) on both the Mini and the Tiny because it is working on the terminal.

Do you have a fully detailed and updated list of CLI commands supported by your fork of ChameleonMini of Kaos/Oswald?

I was looking for the same thing and only found this picture so far:

[CaseyBakey]

Thanks for you answer! Yes, it appears that, since all these devices are clones, they're firmware compatible. The ChameleonTiny is just a "tiny" ChameleonMini.

However, how are you using yours with the emsec firmware since the button aren't mapped the same?

And do you know how to make a full dump of a Mifare Classic 1K card (for example) with the ChameleonTiny (and not just the UUID). And how to emulate the full card also?

Even if my first tries around me seem to indicate that only UUID are checked on these cards, I think there may be cases where other sectors/blocks are needed/read?

Right now, I'm back to Proxgrind official firmware, to be able to switch slots with the buttons.

[maltekrupa]

However, how are you using yours with the emsec firmware since the button aren't mapped the same?

Using the original firmware is basically the same, but only two LEDs will be used. On default, LED1 is always on and LED2 flashes when you change slots/SETTINGs. One flash = first slot; two flashes = second slot and so on.

Check the button configuration (LBUTTON, RBUTTON). One of them cycles through the settings, one of them does something else (RECALL_MEM 🤷‍♂️). Note: The original firmware can only cycle through the settings in one direction.

The other difference: On the original firmware, all slots start with a CONFIG of NONE which does not allow you to select them with the buttons. So it might appear that the CYCLE_SETTINGS button does nothing, but this will change, as soon as you configured more slots. This was changed in the RRG firmware where all slots are by default a MF_CLASSIC_1K, so you can cycle through them after flashing the firmware (compare w/ emsec firmware).

And do you know how to make a full dump of a Mifare Classic 1K card (for example) with the ChameleonTiny (and not just the UUID). And how to emulate the full card also?

Not really. My first guess would be the CLONE command. Not sure if it works for the full card, because I only have cards that only set the UID and I haven't spent too much time with it yet.

Can you describe what you did to dump the card?

[r1ddl3rz]

Try to flash latest on my tiny: avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9746 (probably x128a4u) avrdude: NOTE: "application" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "Chameleon-Mini.hex" avrdude: writing application (123898 bytes):

Writing | ################################################## | 100% 2.46s

avrdude: 123898 bytes of application written avrdude: verifying application memory against Chameleon-Mini.hex: avrdude: load data application data from input file Chameleon-Mini.hex: avrdude: input file Chameleon-Mini.hex contains 123898 bytes avrdude: reading on-chip application data:

Reading | ############################################### | 94% 0.75savrdude: Error: DFU_UPLOAD failed: error sending control message: Broken pipe avrdude: Error: DFU status STALL avrdude: Error: Failed to read 0x0100 bytes at 0x1E400 avrdude: Error: DFU_DNLOAD failed: error sending control message: Broken pipe avrdude: Error: Failed to set memory page 0x0000 avr_read(): error reading address 0x0eb6 read operation not supported for memory "application" avrdude: failed to read all of application memory, rc=-2

avrdude done. Thank you.

How to get it working?

[r1ddl3rz]

solved it - needed several attempts until it worked. Get the latest RRG flashed

[dkraft]

I've seen this on lots of avr devices. Cables Cables Cables. Also, different hosts. I'm guessing it's capacitance and timing and temperature drift and environmental rf noise.

[r1ddl3rz]

@dkraft thank you very much. Tested another cable and it worked much better.

[CaseyBakey]

@temal- I didn't dump a card yet. I only cloned UID on Mifare Classic 1K/4K and that was enough to fool the reader to grant me access ;)

But I'll try to take a look at dumping a full card soon.

[Akisame-AI]

I would be very interested in emulating more than just the UID since good places don't use it for access control. I have one card that uses sector 1 as the access code in place of the UID with a non-standard key. Another adds some extra data to sector 0 to check against. I also own a few hotel keys that have the check in/out date stored in hex in sector 3 and 6. You need to simulate those in order to use them. Edit: You can emulate a dump you made of a card (mdf, eml (added december 2018), mct or json format). In principle you can create a dump with Mifare classic tool or the Chameleon and send that to your chameleon