I made a ChameleonMini by myself.
Here is my step to download the firmware:

1. connect the board to PC
2. use avr isp mkii to download the bootloader(RevE-atxmega32a4u_104_modified.hex)
   

I can see a device named ATxmega32A4U

3.after that, I dowload the firmware/eeprom Chameleon-Mini.hex/Chameleon-Mini.elf with avr isp mkii,and I got this:"Unknown device"(at that time, one led turns on), and I also use the FLIP to download the firmware/eeprom, I got the same result.

I want to know what happened.

Tanks :)

I can download the frimware which is provided by the AVR studio6

and I got this

It seemed like working well...

I believe it is best to add various build byproducts to .gitignore to avoid accidentally committing those. It is at least the contents of the Bin directory plus various build tools outputs like map or assembly listing files.

For official firmware releases, you can do it directly on github: https://help.github.com/articles/creating-releases/

Today we've "Driver" subdirectory in the repo

GettingStarted.txt:

• "Drivers" subdir mentioned 3x

README.md:

• Driver : The Chameleon driver for Windows

I suggest renaming the subdirectory "Driver" into "Drivers" as we've now bits for Win & Lin, and to fix README.md accordingly.
You may also consider serving 98-ChameleonMini.rules with rawgit as it's already done for the Windows drivers in GettingStarted

I made a ChameleonMini by your PCB design, and it works well, after I increased the UID, I want downlaod the changed dump file to find the differences between the file and origin file.

But after I sent "DOWNLOAD" command, and select File -> Transfer -> XMODEM -> Receive, it can't be done, always.

I changed the software to SecureCRT, doesn't work.

Hi,

I got my Rev.G today,when DFU firmware updated done.
the windows can't found the device and virtual com port.
an USB cannot recognize message show quickly when device plug in,and LED keeping on green.

then try use my MKII reprogram the bootloader and still no help.
the FUSE setting list by:

0x00
0xFF
0xFE
0xFF

that looks difference of the old Rev.E setting's.
so just confirm the fuse setting is right?

Best Regards and Thanks!

What is purpose of this part? Can it be safely removed? Why is that even there?

Hi

It seems that AT45DB081D-SSU is not manufactured anymore: http://export.farnell.com/adesto-technologies/at45db081d-ssu/ic-dataflash-8mbit-serial-8soic/dp/1455038

Would this work as a direct replacement? http://download.siliconexpert.com/pdfs/2014/5/4/13/28/7/641/adesto_/manual/9ds-45db081e_028.pdf

This: http://www.adestotech.com/pcn/dfreplacement.pdf - seems to suggest that it might, but if I compare the two here: http://export.farnell.com/webapp/wcs/stores/servlet/CompareProductsDisplay?catalogId=15001&langId=71&storeId=10152&catentryId=64576771,67382491&pageType=PLP

I see that the newer chip doesn't have a Serial interface, only SPI and that the memory type is Serial flash and not Flash.

Thanks

Hi! I was trying to test the DOWNLOAD command and my cameleon waits for an XMODEM file transfer to start. I was using screen and "^a:exec !! lrx file" but it said that headers were garbled, then I tried minicom and presses ESC-Z and then R for receive and the XModem and a filename. It didn't seem to work.
Also I don't understand the documentation here very well, does that command send the whole memory that's been read from a card into a file? Can that same be done _on_card* and be stored internally? How? I'd like to clone a whole card.

Hi, I tried MF_ULTRALIGHT against a hotel door but it was highly unreliable.
The problem is that the emulation doesn't handle the STATE_HALT properly.
It should wake up only when receiving a WUPA and not when receiving a REQA otherwise the reader is discovering the same card over and over.

I tested it with an ugly patch, works better. I may provide a proper patch when having a bit more time...

Another tracking item for more card types to be emulated. It seems Plus cards slowly replace Classics just like the vendor wants it, so it would be nice to have this supported too.

Add identify command tom chamtool.py.

Hi folks,
Is there a tutorial or a link that anyone would be kind enough to share that explains how to set up the development environment for the firmware on a Windows based system? I have quite a lot of embedded C experience, so that's not a problem, I have never developed for an Atmel device before, so i am keen to learn. Also I have quite a lot of experience writing applications that use cards (in the transport industry), so that's not a problem. I am keen to learn about the low level driving of cards now...

I have cygwin installed on my machine, and I downloaded the Atmel Studio v7.0. When I run make in the Firmware directory, the first error is "avr-size: command not found". I guess there may be either a package missing from cygwin or the PATH is wrong. C:\cygwin64\bin is in the path variable...

Any suggestions more than welcome.

Thank you
Neil

Hi guys, I was wondering weather the ChameleonMini supporting ISO15693 currently? Cause now I'm trying to emulate the TI Tag-it HF-I Plus Inlay, and I made ChameleonMini by my own once, the ChameleonMini wiki says it can emulate ISO15693. But I didn't find the correct instructions and manual to change ChameleonMini to ISO15693 mode. Besides, I read the ChameleonMini source code, it only contains ISO14443 protocol.

So here is the question, can ChameleonMini emulate ISO15693 card now? If not, do you guys plan to add the function as you described in your wiki? And I really love your awesome job.

Best Regards!

An Ultralight dump is only 64b but chamtool.py requires at least 128b for the XMODEM packets.
When using another xmodem tool such as minicom, they pad the 64b to 128b and send it successfully.
chamtool.py should do the same to allow sending Ultralight dumps easily.

"Any chance of getting a guide on how to write codecs and applications? Reading the fine code might delay things quite a bit."

I received my ChameleonMini today. Great!

I checked the Getting Started to learn I had to upgrade the firmware. I downloaded the files and hit the first bump. It needed libusb0.dll. After getting and installing that, I continued.

Pressing the RBUTTON when connecting the device to the PC does not show anything on the device. Is that correct? I expected some indication the device is in bootloader mode.
Connecting the device to the computer without pressing a button shows one green LED.

The second solution, using the test firmware, implies the computer should be able to detect the device. I don't seem to be able to find the device in Device Manager.

Currently, only 106k is supported. Unfortunately, to properly emulate newer cards it would be required to support 212k and 424k at the very least; this would allow for proper emulation of DESFire (the first model). Until we have that, we would either have a different ATS stating we only support 106k OR the ATS would lie a bit in order to mimic the original card and risk the reader setting comm rate higher than 106k.

How much work would it take to implement the higher data rates? From my very limited experience with codecs in Chameleon, I would writing a new one for each speed setting?

Hello,
perfect project !

Can you say about time to update to Rev. F or G ?

Best wishes
Mitek

I connect by board in DFU mode (no lights on) to my mac having installed avrdude with brew and get the following:

MacBook-Pro-3:Chameleon-Mini` Keytree20$ sudo avrdude -c flip2 -p ATXMega128A4U -B 60 -P usb -U application:w:Chameleon-Mini.hex:i -U eeprom:w:Chameleon-Mini.eep:i

avrdude: Error: No matching USB device found
avrdude: AVR device initialized and ready to accept instructions

Reading |                                                    | 0% 0.00savrdude: error reading signature data for part "ATxmega128A4U", rc=-1
avrdude: error reading signature data, rc=-1

avrdude done.  Thank you.

Not Sure how to resolve.

i have made a ChameleonMini, successfully installed firmware, and have access to console configuration.

When trying to emulate a card, I found cannot scan it with a reader (phone or ACR121). Maybe it is due to the RF antenna filtering, and specially the C2 value.

Can you advise a way to diagnose this issue ? and a explanation of C2 value over antenna spec ?

Thanks

After the boot, the following error, how to solve?（Repeatedly restarted）

===================================
You can also use the following commands:

• Type "showlog" to show the factory test log
• Type "reset" to re-run the self test (you need to power cycle the Chameleon)

Generating Test Report from SRAM:
Test Report for Chameleon-Mini

• FW version: 0.5
• Test Buttons: FAILED (Took 16584ms) Time exceeded without input on Left Button, time exceeded without input on Right Button.
• Test Reader: FAILED (Took 529ms) Could not perform a whole ISO14443A select protocol and finally receive a SAK without errors. Used threshold range: 50 - 4095.
• Test FRAM: PASSED (Took 149ms) Wrote 32768 pseudorandom bytes to FRAM. Successfully read the same bytes from FRAM.
• Test Fuses: PASSED (Took 1ms) Read the following fuse bytes (the values in brackets have the form <reference value;mask>). 1: 00(00;FF) - 2: BE(BE;63) - 4: F3(F3;1F) - 5: ED(ED;3F).
• Test Signature: PASSED (Took 0ms) Read the Device ID 1E9746, expected 1E9746.
• Test USB Enum: PASSED (Took 137ms) USB Device State is ADDRESSED.
• Test VCC: PASSED (Took 106ms) Measured a VCC of 3330 mV.
• Test Antenna: PASSED (Took 107ms) Measured the following RSSI values: 12632 mV, 12503 mV, 12468 mV, 12562 mV, 12457 mV.
• Total Testing Time: 17614ms
  Your Chameleon will emulate a card with the UID 3D03F2C9.
  Sorry. Some test(s) have FAILED, please unplug chameleon, fix errors and re-test.
  Welcome to your ChameleonMini! This is test firmware version 0.5.

Sorry. Some test(s) have FAILED, please unplug chameleon, fix errors and re-test.

Type "upgrade" to jump to the bootloader and install new firmware as described on https://github.com/emsec/chameleonmini

Any help? I am using latest Kali and the sources you proposed here on github...

python3 chamtool.py -p /dev/ttyACM0 -i

Traceback (most recent call last): File "chamtool.py", line 205, in <module> main() File "chamtool.py", line 168, in main if (chameleon.connect(args.port)): File "/usr/local/src/pentest-rfid/ChameleonMini/Software/Chameleon/Device.py", line 96, in connect result = self.getCmdSuggestions(self.COMMAND_CONFIG) File "/usr/local/src/pentest-rfid/ChameleonMini/Software/Chameleon/Device.py", line 168, in getCmdSuggestions result = self.getSetCmd(cmd, self.SUGGEST_CHAR) File "/usr/local/src/pentest-rfid/ChameleonMini/Software/Chameleon/Device.py", line 165, in getSetCmd return self.writeCmd("{}{}{}".format(cmd, self.SET_CHAR, arg)) File "/usr/local/src/pentest-rfid/ChameleonMini/Software/Chameleon/Device.py", line 134, in writeCmd statusCode, statusText = status.split(":") ValueError: not enough values to unpack (expected 2, got 1)

However, socat - /dev/ttyACM0,crnl works. Are patches around or am i using it wrong, there`s not really much help inside...

Following Upgrade the leds are deactivated, furthermore they are unable to be set. Steps followed as well as version information is listed bellow.

Steps:
Connect to Chameleon using Minicom
version? - Returns version info bellow
ledgreen? - Returns state of None
ledgreen=powered - Returns 100 OK
store - Returns 100 OK
ledgreen? - Returns None
Disconnect from Chameleon and reconnect yields same result

OS : Ubuntu 16.04
MiniCom Version : 2.7

Version:
ChameleonMini RevG 161024 using LUFA 151115 compiled with AVR-GCC 4.9.2. Based on the open-source NFC tool ChameleonMini. https://github.com/emsec/ChameleonMini commit 2005f46

My chamtool.py keep failing as issue#16.
File "/multimedia/git/ChameleonMini/Software/Chameleon/Device.py", line 134, in writeCmd
statusCode, statusText = status.split(":")
ValueError: need more than 1 value to unpack

Therefore, I've update firmware to ChameleonMini
But chamtool.py didn't react to -p comport(Mine was COM3)

System:Win 10 64-bit, Python ver 3.5

One more question,
My dump_mfu always showed timeout when dumping my classic 1K card by using Teraterm
Reading works find for me, though.

Any suggestion?

Hello,

I've finally gotten the ChameleonMini to work under Linux / VMWare. I'm now trying to emulate a Mifare 4K card but I'm having trouble uploading the data.

I flashed the Chameleon with the latest github firmware, created a card in slot 0 with CONFIG=MF_CLASSIC_4K and gave it a UID.

When I download the memory using minicom, I get a file which is 8k in size, but the dump I created of the original card using mfoc -O card.mfoc is only 4k. When I upload these 4k via xmodem then the resulting mfoc -O clone.mfoc is not identical with the original dump, it seems the data after 0x400 is missing.

Why does the download command receive 8k of data for a 4k card? And how do I need to modify the 4k dump from mfoc to upload into the Chameleon memory?

Looking at possible values for log entries, I see those application related are purely for MIFARE Classic. Would it be possible to restructure the log entry codes so that applications could define their app-specific codes instead?

I am a bit confused as to what would be the best approach to use logging in the DESFire application I am writing.

Hi, When i try to execute the upgrade i get the following message:

zgv@ZGV-MacBookPro:~/Desktop/upgrade$ sudo avrdude -c flip2 -p ATXMega128A4U -B 60 -P usb -U application:w:Chameleon-Mini.hex:i -U eeprom:w:Chameleon-Mini.eep:i

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 (131072 bytes):

Writing | # | 2% 0.05savrdude: Error: DFU_DNLOAD failed: error sending control message: Broken pipe
avrdude: Error: Failed to set memory page 0x0000
avrdude: Error: DFU_DNLOAD failed: error sending control message: Broken pipe
avrdude: Error: Failed to set memory unit 0x00 (Flash)
**failed;
avrdude: Error: DFU_DNLOAD failed: error sending control message: Broken pipe
avrdude: Error: Failed to set memory unit 0x00 (Flash)
*__failed;
avrdude: Error: DFU_DNLOAD failed: error sending control message: Broken pipe
avrdude: Error: Failed to set memory unit 0x00 (Flash)
*__failed;
avrdude: Error: DFU_DNLOAD failed: error sending control message: Broken pipe
avrdude: Error: Failed to set memory unit 0x00 (Flash)
*__failed;
avrdude: Error: DFU_DNLOAD failed: error sending control message: Broken pipe
avrdude: Error: Failed to set memory unit 0x00 (Flash)
*__failed;
avrdude: Error: DFU_DNLOAD failed: error sending control message: Broken pipe
avrdude: Error: Failed to set memory unit 0x00 (Flash)
*__failed;
avrdude: Error: DFU_DNLOAD failed: error sending control message: Broken pipe
avrdude: Error: Failed to write 0x0001 bytes at 0x0007
*__failed;
avrdude: Error: DFU_DNLOAD failed: error sending control message: Broken pipe
avrdude: Error: Failed to write 0x0001 bytes at 0x001E
*__failed;
avrdude: Error: DFU_DNLOAD failed: error sending control message: Broken pipe
avrdude: Error: Failed to write 0x0001 bytes at 0x003E
**failed;
^C
zgv@ZGV-MacBookPro:~/Desktop/upgrade$

Dose any one have an idea why?

A few simple examples or step by step instructions would be wonderful:

1. How to read and existing card and dump the data to a file (READER)?
2. How to take a dump and upload it to a virtual card 1-8?
3. How to clone a card from READER to directly to a virtual card?
4. How to set random UID without using buttons?

[...]

What is the exact value of the C4 capacitor?
In the BOM, it is written, "N. M.", which is a term I don't understand.

Thanks.

If anyone has use for this:
bronken.de/chameleonminigui

Its not finished but since SW0002 it contains almost all commands currently available. Up/Downloading of Files are already on my "to do" list.

I didnt know where to publish. Its no a real issue but not a pull request either, but should be somewhere around this github project because of its nature.
If this is not wanted here, any admin can feel free to delete this post.

Been playing around with my Chameleon and it's really cool, it's identified all of my NFC cards and it's pretty interesting!

I can't however figure out how to read the contents of the card or how to clone it. I understand the DUMP_MFU is only for the Ultralight cards so with the only cards I've got being MIFARE Classic 4K and MIFARE DESFire EV1 will I have to wait for new code to read from these cards?

Hope this isn't a silly question, I'm new to this NFC stuff :)

I got a board fabbed built out a chameleon mini and am wondering about the crystal configuration as I didn't source a xtal. Is it possible to run the chameleon on the internal oscillator only?

From my understanding the local oscillator can supply a sufficient 12mhz clock for the usb.. however, I configured the board to run on the internal but the v-usb never initializes properly.. Any ideas or pointers in the right direction?

Also the cap values (22pf) seem a little high if using the 12mhz xtal, (http://www.atmel.com/images/doc8072.pdf recommends ~10pf). I haven't played with the xmega's, I used to be more of a PIC guy so this might be totally irrelevant..
Thanks in advance!

Hello,

I got the ChameleonMini today and tried it on my Notebook which is running Windows 7.

When I connect it via MicroUSB the device manager finds LUFA CDC demo with an exclamation mark. So I downloaded a zip file of the project, went to the driver folder and right-click on the ChameleonDriver.inf file. But all I get is a message that the inf file I selected does not support this method of installation.

EDIT: I now did manage to install the DFU driver manually and upgrade but I still can't install the LUFA CDC Demo driver.

I tried to install the driver for LUFA CDC demo but I get an error that "Windows can't verify the publisher of this driver software."

I looked through the documentation but the getting started guide doesn't seem to mention anything about how to install the drivers to get started.

Hi team,

I've received my RevG chameleon and proceed with the requisite steps before upgrade to new firmware from my Win7 64bit machine.

1. Installed DFU programmer.
2. Installed Chameleon driver and able to see "ChameleonMini Virtual Serial Port [x]" from TeraTerm.
3. Perform self test and everything was passed from TeraTerm.
4. Hit upgrade from TeraTerm, hang from there. Red light from Chameleon was off.
5. Executed ChameleonFirmwareUpgrade.bat and shows error that chip is empty. Required to press any key to continue as there is no bootloader in the chip.

Performed the similar steps on a WinXp 32bit machine also giving the same result and in the same time shows error on line 7 on Chameleon-mini.eep file.

I believed that I have accidentally wiped the bootloader and now required to restore back to original state.

Please help, Thanks

Please add a requirements.txt/requirements.yaml to Software dir containing all python3 requirements. This allows easy install with pip install -r requirements.txt

currently the contents of requirements.txt is
pyserial

Hello. I'm ready to print PCB but little confused.
In repository I found only RevE-2 board but here http://www.mikrocontroller.net/topic/327629 people talk about RevE-3.
The main difference is in antenna size and bottom left corner element.
Can you please explain what version is better to use?

I've been playing around with my Hotel Door (seems to be a Messerschmitt Classic 3 in the mifare version) and after countless hours of wondering what magic cards Messerschmitt is using, because the cards are identifying as MF Ultralight, but the Chameleon can't sniff anything or when emulating a MF Ultralight I didn't even see read requests....

It took me quite a while to notice, that I have to hold the Chameleon in a very specific angle in a very specific distance to get some data with sniffing. In emulation mode I saw some traffic, but in 30 minutes waving the Chameleon in various speeds, angles, directions&distances at the door, I managed to open it only once (so I know it does work... but not reproducible).

I also noticed that when I use my usb dongle (scl3711) I have to be careful with the Chameleon as well. It mustn't be too close, or it would not be recognized. And it happens quite often, that a "nfc-list" lists 2 (identical) tags.

So, as the noob I am... I'm wondering if

• That's an issue "by design"? (Laws of Physics are a b*tch?)
• My device is faulty?
• The readers are stupid?

And if that can be improved somehow? (There's a u-fl-r-smt connector.. can it be used out-of-the-box?)

I would very much like to see Chameleon supporting emulation of DESFire cards. I reckon this was already implemented according to the WISSEC paper, but is not shred with general public. Any plans on putting it on github?

For most of my cards "IDENTIFY" doesn't work, even though I see through logging that there's some "good" information coming in. That works only in reader config, right?

Recently I tried dump my Mifare Classic 4K card, then emulate by ChameleonMini. So i crack this card using Proxmark3 , mfoc and Mifare Diagnostic tool, as the result, i got the dump file as blow:

Now you can see all 40 key A/B is cracked, Then let's verify these keys:

Read data from origin card with keys:

I campared the data with Proxmark3 dump data one byte by one byte, they are excatly the same.

So i use the scripts in Proxmark3 translate the dump .bin file to .mfd file.( Hex workshop turns out they are the same.), then upload the .mfd file into ChameleonMini .

But~! Here came the question, this card can't pass the card reader in my work place.

So i tried read the ChameleonMini using Mifare Diagnostic tool and the same keys:

Delete some pics contain keys

All first 16 sectors is OK:

Delete some pics contain keys

But after these 16 sectors, the data all goes wrong:

Delete some pics contain keys

I'm sure the config is right:

Is the reason the ChameleonMini just emulate Mifare Classic 1K card(cause only the first 16 sectors emulate right)?

Feature Request: add support for HID iClass Prox cards. These appear to use ISO 15693 and/or 14443B.

References:
http://www.openpcd.org/HID_iClass_demystified
http://www.openpcd.org/OpenPICC_SnifferOnly_13.56MHz
http://www.openpcd.org/git-view/iclass-security/tree/iCLASS-RFID-sniffer
https://www.hidglobal.com/sites/default/files/resource_files/iclass-card-ds-en.pdf

Hi guys:
I made a ChameleonMini recently.When I use a card reader like ACR122 or RC522 to read, it performed well.
but when I use a card reader like Mobile phone or access control,it could not pass the second auth.
I Found that When I send NT, it did not respond.I think it was I missed the response time.But the first auth with no problem.
Looking forward to your reply.
dxls

I tried to use my Chameleon as a reader. I configured a slot in Reader mode and try to read in some cards I have. No matter which command I use I will soon ran into an Timeout. Even adjusting the timeout settings makes no difference.

I there something I've overlooked or is my Chameleon broken?

As there is not really other place of discussion and my notes are probably not mature enough for inclusion in the official docs, I'm sharing a few tips here and hoping to gather yours as well!

I'm using a Debian, details may vary with other distros.

Setup

First my /etc/udev/rules.d/98-ChameleonMini.rules to operate and flash the chameleon as regular user and stop being annoyed by pesky ModemManager:

# Rule for ChameleonMini RFID Research tool
ATTRS{product}=="Chameleon-Mini", SUBSYSTEMS=="usb", ATTRS{idVendor}=="16d0", ATTRS{idProduct}=="04b2", GROUP="users", MODE="0666", SYMLINK+="chameleon", ENV{ID_MM_DEVICE_IGNORE}="1"
# DFU mode
SUBSYSTEMS=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2fde", GROUP="users", MODE="0666"

Minicom

As terminal, minicom can do the job, but a few tweaks help a bit, with this file as
/etc/minicom/minirc.chameleon or ~/.minirc.chameleon:

pu port             /dev/chameleon
pu localecho        Yes
pu linewrap         Yes
# disable other transports than xmodem
pu pname1           YUNYY
pu pname2           YUNYY
pu pname4           NDNYY
pu pname5           NDNYY
pu pname7           YUYNN
pu pname8           NDYNN
pu pname9           YUNYN

Then invoke it simply with:

minicom chameleon

xmodem transfers are possibles.

Screen

Usually I like screen as simple terminal but there is no easy way to activate local echo (see this discussion)

Socat

So the alternative to get a simple terminal is to use socat.
A nice add-on is to use its readline support to get history, ctrl-r etc. Unfortunately Debian and Ubuntu versions compiled it without readline support, so if you want to have it you've to recompile the package by yourself (see notes) or use the original sources.
But getting history in your chameleon terminal is so great!

cham

#!/bin/bash
socat READLINE,history=$HOME/.chameleon_history /dev/chameleon,crlf

File transfer: Download

cham-down

#!/bin/bash
# Usage:
# $ cham-down [filename [slot_nr]]
# default is to dump current slot to dump.bin
[ ! -z $2 ] && echo -e  "SETTING=$2\r" >/dev/chameleon && read foo </dev/chameleon
socat SYSTEM:"echo \"DOWNLOAD\r\" ;read foo; rx ${1:-dump.bin}" /dev/chameleon

File transfer: Upload

cham-up

#!/bin/bash
# Usage:
# cham-up [filename [slot_nr]]
# default is to upload dump.bin into current slot
[ -f "${1:-dump.bin}" ] || exit 1
[ ! -z $2 ] && echo -e  "SETTING=$2\r" >/dev/chameleon && read foo </dev/chameleon
echo -e "UPLOAD\r" > /dev/chameleon
socat EXEC:"sx ${1:-dump.bin}" /dev/chameleon

Flashing

Here is my little script to compile, jump to bootloader, flash and jump back to normal mode in one go without having to unplug/plug the chameleon. This requires to install also the package dfu-programmer.

cham-flash

#!/bin/bash
cd  /path/to/ChameleonMini/Firmware/Chameleon-Mini
make || exit 1
# Jump to bootloader mode
echo -e "\rUPGRADE\r" > /dev/chameleon && sleep 1
make program
# Jump to normal mode
dfu-programmer atxmega128a4u start

Doc

I also created a convenient

cham-man

x-www-browser /path/to/ChameleonMini/Doc/Doxygen/html/index.html &

Your turn

Any other tips to share on your side?

Issue #16 (VERSION returning several lines) was solved by simply writing all the info in a single line.
But dump_mfu returns also several lines and probably more commands will do in the future.
So what about adding a new response type for multiline result?
E.g.

102:OK WITH MULTILINE TEXT

that would e.g. terminate on a last line containing only EOT (end of transmission)

Example:

VERSION?
102:OK WITH MULTILINE TEXT
ChameleonMini RevG 161027 using LUFA 151115 compiled with AVR-GCC 4.9.2.
Based on the open-source NFC tool ChameleonMini.
https://github.com/emsec/ChameleonMini commit 70b6cce
EOT

DUMP_MFU
102:OK WITH MULTILINE TEXT
04575B8031BF02800C48000000000000
000000009632F4000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
EOT

I am trying to get the chamtool.py to work. I am new to python
I have installed Pip and Pyserial manually on a win 7 machine.

C:\Chemelon>pip list
pip (8.1.2)
pyserial (3.2.1)
setuptools (20.10.1)

What is the syntax of the argument that chamtool.py wants ? I have tried a number of combinations.
chamtool.py -p com6
chamtool.py - p 'com6' with quotes and without with -p and with out. I will add my learning's as I am sure I can be the only person learning this from scratch. I have it working with Xmodem but I just wanted to use the script.

from pyserial "i have changed the id" in this text.

ser
Serial<id=0x27dcf0, open=True>(port='com6', baudrate=19200, bytesize=8, parity='
N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False)

~> python3 chamtool.py -v -p /dev/ttyACM0 -c ISO14443A_SNIFF
[2016-10-08 20:37:36.060585] Opening serial port /dev/ttyACM0 succeeded
[2016-10-08 20:37:36.064505] Executing <VERSION?>: 101:OK WITH TEXT
[2016-10-08 20:37:36.175404] Executing <CONFIG=?>: 101:OK WITH TEXT
[2016-10-08 20:37:36.182485] Response: NONE,MF_ULTRALIGHT,MF_CLASSIC_1K,MF_CLASSIC_1K_7B,MF_CLASSIC_4K,MF_CLASSIC_4K_7B,ISO14443A_SNIFF,ISO14443A_READER
Traceback (most recent call last):
File "chamtool.py", line 205, in
main()
File "chamtool.py", line 186, in main
result = cmdFuncs[cmd](chameleon, arg)
File "chamtool.py", line 44, in cmdConfig
result = chameleon.cmdConfig(arg)
File "/root/ChameleonMini.git/Software/Chameleon/Device.py", line 230, in cmdConfig
return self.getSetCmd(self.COMMAND_CONFIG, newConfig)
File "/root/ChameleonMini.git/Software/Chameleon/Device.py", line 177, in getSetCmd
return self.writeCmd("{}{}{}".format(cmd, self.SET_CHAR, arg))
File "/root/ChameleonMini.git/Software/Chameleon/Device.py", line 126, in writeCmd
status = self.serial.readline().decode('ascii').rstrip()
UnicodeDecodeError: 'ascii' codec can't decode byte 0x99 in position 3: ordinal not in range(128)

working in minicom --device /dev/ttyACM0 and typing "CONFIG=NONE" I receive:
..+RNONE100:OK
or
..�.NONE100:OK

Working in minicom or via python actual sets the new config correctly. Only the additional characters in the response are messy.

The Chamleon response with four byte addtional values. They change every call to CONFIG=XXX. It does not matter which config is choosen.

chamtool.py can of course skip those additional lines, but I guess it is something in the firmware...