iceman1001 / chameleonmini-rebooted

Chameleon Mini revE rebooted - Iceman Fork, the ChameleonMini is a versatile contactless smartcard emulator (NFC/RFID)

ChameleonMini RevE - Rebooted

Linux & OSX CI	Releases

Attribution LICENSE

"Based on the open-source NFC tool ChameleonMini: https://github.com/emsec/ChameleonMini" License

This is firmware for the revised, rebooted version of the ChameleonMini RevE Rebooted which so many of you bought. The chinese manufacturer had its firmware changes to themself which was limiting for all who bought this device. After talks with manufacturer, they also came to the conclusion that it should be open-sourced. I managed to get source from them and agreed to make a public repository on GitHub. Since this firmware isn't in the official ChameleonMini repo, I decided to make a 'iceman fork' of it.

Notice

Let us make this fork awesome to play with. Do please play with it. Get excited and experiment with your enhanced ChameleonMini device!

First Steps

This repo is focused on RevE Rebooted. Start with reading our Wiki.

To upgrade the firmware of your ChameleonMini

For RevG owners, please visit the Getting Started page from the doxygen documentation.

For RevE Rebooted owners, please start with our Getting Started

Supported Cards and Codecs

See here.

GUI

Based on the partial source code release for the GUI, we created a new GUI iceman's ChameleonMini rebootedGUI It is a windows .net based software and it is really nice to work with. Has support for ChameleonMini revE / revG commands, dump management, color templates for dumps, and multilanguage.

Questions

If you have any questions, please start with reading our Wiki.

The RFID hacking community discord server is a great place to discuss Chameleon Mini releated stuff among others discord server

Repository Structure

The code repository contains:

• Drivers: Chameleon drivers for Windows and Linux
• Firmware: The complete firmware including a modified Atmel DFU bootloader and LUFA
• Software: Contains a python tool for an easy configuration (and more) of the ChameleonMini, Note that this is currently under construction

Perpetual glory!

A list of those who contributed to this repo in order to make it work. The community owns you all a deep and sincere thank you.

• @bogiton
• @doegox
• @ceres-c
• @iskuri
• @shinhub / @securechicken
• @McEloff

Donate

If you feel the love, do feel free to become a Iceman patron. For some tiers it comes with rewards https://www.patreon.com/iceman1001

All support is welcome.

chameleonmini-rebooted's Issues

New device not working with Android NFC or card access system

Hi all,

I've got a new ChameleonMini Rebooted running the standard firmware, Chameleon-new-1.0.

Connecting to the device works fine, and it accepts commands without a problem. It also gets powered by readers without issue. However, I can't get my phone to recognise any emulated cards, nor a card reader to register it either.

Has anyone else come across this problem?

Crypto patch

Hi guys, could you push the crypto patch to a branch? My device is totally useless without it

Mifare Emulation Problem

I compiled and flashed latest master. Ultralight modes are working as good.
But when I choose Mifare 1K or 4K mode, does not react at all.
In addition if usb cable is not connected, always 8th led is swiched on.
Do you have a prediction?

Flashing issue

Hi !

I spent my night to try to solve my issue but nothing worked... I wanted to upgrade my fresh Chameleon Rev E Rebooted firmware but I can't upload new files and the device is now stuck on bootloader mode.

First of all, to be able to compile, I had to remove the compilation flag Werror wich is in the makefile (was it on purpose ?). Then when I try to erase my device I have following output :

➜ ~ dfu-programmer atxmega32a4u erase --debug 100
target: atxmega32a4u
chip_id: 0x2fe4
vendor_id: 0x03eb
command: erase
quiet: false
debug: 100
device_type: XMEGA
------ command specific below ------
validate: true

atmel.c:934: atmel_blank_check( 0x7ffeeb0048b0, 0x00000000, 0x00007FFF )
atmel.c:1041: atmel_select_memory_unit( 0x7ffeeb0048b0, 0 )
atmel.c:1073: Selecting flash memory unit.
Checking memory from 0x0 to 0x7FFF...
atmel.c:1100: atmel_select_page( 0x7ffeeb0048b0, 0 )
atmel.c:1114: Selecting page 0, address 0x0.
atmel.c:867: __atmel_blank_page_check( 0x7ffeeb0048b0, 0x00000000, 0x00007fff )
atmel.c:902: Region is NOT bank.
atmel.c:910: First non-blank address in region is 0x7FF0.
atmel.c:981: Flash NOT blank beginning at 0x7FF0.
Not blank at 0x7FF1.
commands.c:87: erase 0x7FFF bytes.
atmel.c:444: atmel_erase_flash( 0x7ffeeb0048b0, 4 )
Erasing flash... Success
atmel.c:494: CMD_ERASE status: Erase Done.
atmel.c:934: atmel_blank_check( 0x7ffeeb0048b0, 0x00000000, 0x00007FFF )
atmel.c:1041: atmel_select_memory_unit( 0x7ffeeb0048b0, 0 )
atmel.c:1073: Selecting flash memory unit.
Checking memory from 0x0 to 0x7FFF...
atmel.c:1100: atmel_select_page( 0x7ffeeb0048b0, 0 )
atmel.c:1114: Selecting page 0, address 0x0.
atmel.c:867: __atmel_blank_page_check( 0x7ffeeb0048b0, 0x00000000, 0x00007fff )
atmel.c:902: Region is NOT bank.
atmel.c:910: First non-blank address in region is 0x7FF0.
atmel.c:981: Flash NOT blank beginning at 0x7FF0.
Not blank at 0x7FF1.

I read other thread about it but I didn't find any answer. I tried on two macs and one Windows 10 device. dfu-programmer (0.7.2) output is always the same. and with the BOOT_LOADER_EXE I have the message "dfu-old-driver : no device present"

Thanks for your help

7 byte UIDs (?)

Hi

Sorry for being a noob here. Just got my RevE rebooted, because I wanted to do some experiments with Mifare Classic. The specs said something like "Mifare 1K (4-bit and 7-bit UID)" and "Mifare 4K (4-bit and 7-bit UID)". However, either I am stupid or the firmware only allows 4-bit Mifare emulation?

Again, sorry, if this is a stupid question.

Michael

Provide Precompiled Hex/Bin

would it be possible to provide compiled Versions of the Chameleon-Mini.hex/Chameleon-Mini.eep to the releases?
Since at least for me, using OSX, the compiled files seems not to work (even if flashed with windooze)
there are no errors while compiling, so it's kinda hard to figure out the problem (at least for me/ for now)
btw: if I compile the RevG firmware on OSX -> it works (on my RevG)

enhancements to code

It seems I was too eager, thinking it would be easy to get starting and I started to merge things from rev G direct.

This might not have been my best decision...

no device present

Hallo together,
I am a Newbee, I have the follow problem.
I make all I have to do with the getting started page

http://rawgit.com/emsec/ChameleonMini/master/Doc/Doxygen/html/Page_GettingStarted.html

And I get with win10 the Massage

dfu-programmer: no device present.
There was an error with executing this command. Maybe your ChameleonMini is not in bootloader

mode?

what can I do with this?

Maybe a way How to flash a new firmware on the Chameleon on a linux-based OS?

Hi

Maybe this is the way to flash on a linux based system:

1. Install DFU-Programmer (or be sure that the DFU-Programmer installation was successfull)

2. Activate Bootloader-mode on the ChameloenMini by holding down the button while powering on.
   (Black button)

3. Check/Confirm that the device is available
   lsusb

4. Run the Firmware update / Program the device with dfu-programmer (maybe as root)
   dfu-programmer atxmega32a4u erase
dfu-programmer atxmega32a4u flash-eeprom Chameleon-Mini.eep
dfu-programmer atxmega32a4u flash Chameleon-Mini.hex
dfu-programmer atxmega32a4u reset

I can’t test it because I don’t own a Rev. E Rebooted
If someone like to test / double check it won’t be great.

Maybe another way is available with avrdude but I actual have not enough time between Xmas.
Cheers

Chameleon mini Chinese version (Linux)

greet all friends. my english is bad. why can not I update the firmware.

$ lsusb

Bus 006 Device 004: ID 03eb:2044 Atmel Corp. LUFA CDC Demo Application

$ sudo bash
$ socat - /dev/ttyACM0,crnl
UPGRADEMY
$ lsusb

Bus 006 Device 006: ID 03eb:2fe4 Atmel Corp. ATxmega32A4U DFU bootloader

/dfu-programmer$ sudo dfu-programmer atxmega32a4u erase

Checking memory from 0x0 to 0x7FFF... Not blank at 0x7FF1.
Erasing flash... Success
Checking memory from 0x0 to 0x7FFF... Not blank at 0x7FF1.

/dfu-programmer$ sudo dfu-programmer atxmega32a4u flash --eeprom Chameleon-Mini.eep

Checking memory from 0x0 to 0x3F... Empty.
0% 100% Programming 0x40 bytes...
[ X ERROR
Memory write error, use debug for more info.

dfu-programmer$ sudo dfu-programmer atxmega32a4u flash Chameleon-Mini.hex

Checking memory from 0x0 to 0x5DFF... Empty.
0% 100% Programming 0x5E00 bytes...
[ X ERROR
Memory write error, use debug for more info.

what can these error data mean?
how can they be eliminated?
help me please.

Getting ChameleonMini in DFU Mode

According to the documentation, I should be able to get the ChameleonMini into DFU mode by holding the black button while plugging it in. However, this is not working. I put the Chameleon into Sniffing Mode, and now it's not detected as an USB device anymore, and I need to reflash it somehow. Shorting PC3 and GND also does not work, maybe I'm doing the button press wrong?

draft for release v1.0

I guess current status should be a release, it compiles and works with old GUI.

https://github.com/iceman1001/ChameleonMini-rebooted/releases/tag/untagged-09ff734155892b121c57

Tell me if its ok or not, and what should change if not.

Memory overlap issue (first slot)

It seems that after commit 459d9aa there is memory overlap issue.

First, the code makes no sense:

if ( GlobalSettings.ActiveSetting == 0 )
		FlashAddress = Address + (uint16_t) GlobalSettings.ActiveSetting * MEMORY_SIZE_PER_SETTING_4K;
	else
		FlashAddress = Address + (uint16_t) GlobalSettings.ActiveSetting * MEMORY_SIZE_PER_SETTING_1K;

For the first case GlobalSettings.ActiveSetting is always zero.

Second, if the first slot uses 4K bytes (0..4095), then with this code second slot will clash into 1024..2047, third into 2048..3071 and fourth into 3072..4095, therefore writing to 4K slot 0 will damage/erase slots 1-3, and vice versa.

Logically correct way of determining address if you want first slot to be 4K and others to be 1K is:

if ( GlobalSettings.ActiveSetting == 0 )
		FlashAddress = Address;
	else
		FlashAddress = Address + MEMORY_SIZE_PER_SETTING_4K + ((uint16_t) GlobalSettings.ActiveSetting - 1) * MEMORY_SIZE_PER_SETTING_1K;

What do you think about it?
Same may apply to other functions like MemoryReadBlock, MemoryWriteBlock, MemoryClear.

By the way, what is the size of the SPI memory that we have?
I can't determine it by looking on chip because something is done with top of it (partially removed?)

Edit: I have clocked out 1F 24 00 00 from 0x9F opcode, which means we should have a AT45DB041D 4-Mbit (512 Kbyte!) chip.

Ultralight EV1 emulation problem

I was testing out a cloned UL EV1 tag on a real reader, but it seems that I face the same problem as the guy who implemented this in the first place on the RevG: emsec/ChameleonMini#104 (comment)
I have also enabled temporarily the logging functionality on our device, just to log the different authentication attempts in a single run, but, same as the other guy, nothing got logged, only the BOOT signal of the device (so, yeah, the logging works as it is).

Before the real test, I run through the full communication (which was previously sniffed with PM3) step-by-step with the PM3 and the responses of the Chameleon were a perfect copy of the original ones. Could this be a timing problem? or maybe some clone detection technique? Speaking of clone detection, I came across the following fix but I'm not sure if it could resolve the issue: emsec/ChameleonMini@d630363
I'm open to any idea.

Implementing CLONE function

What would it take to implement the CLONE function as recently added to the RevG version ?
I've started looking at that piece of code to see how/what it takes but maybe someone else is doing that also ?

Getting the RevE Board Back Into Bootloader Mode

I ran the first erase command (which works with the RevG boards) here:

$ sudo dfu-programmer atxmega32a4u erase

This successfully erased the chip, but to the point that there's no longer any trace of the Chameleon program on it. I have read the discussion at #11 (not sure I completely understand all of its implications). I tried to reflash the board with the stock RevE .eep/.hex files using the Win32 tools in the repo, but the problem is that all I have is a 64-bit Windows so these EXE files do not run -- even in compatibility mode. I also modified the Batch script on the RevG site which uses dfu-programmer on Windows to flash this. No dice, no go with the flashing.

When I try to run the dfu-programmer on Linux it says that the XMEGA chip is write protected. Does this mean I can only get my Chameleon back to sane state by using the Win32 flashing utilities in the repo on Windows? In otherwords, is the chip effectively locked without the use of the CreateBin.exe application. How do I proceed with getting the Chameleon back? I hope I didn't permanently brick the damn thing in the first two days I've had it to play with.

Broken for 4k in several ways

Hi I believe this firmware does not account for the different sector sizes, and the higher sector number of the 4k. See for example the code here:
https://github.com/emsec/ChameleonMini/blob/master/Firmware/Chameleon-Mini/Application/MifareClassic.c#L617
Which has different offsets for keys.

Furthermore, the MEM_SECTOR_ADDR_MASK is broken for blocks above 64d; the mask maps these blocks back to sector 0. 0xFC would work, although not for blocks above 128 as these sectors are bigger.

Problem to use/handle the Chameleon mini RevE Rebooted

Hallo Together,
@iceman1001

last Year I get an Chameleon Mini RevE Rebooted from Lab401.com
I had so my Problems with this.
(https://github.com/iceman1001/ChameleonMini-rebooted/issues/9)

Now I want to try it again and hope it will now work.
I use Windows10 and use some GUI`s, the old from last Year with calc/fast calc Bottum, from Iceman, from LAB401and TeraTerm.

Windows DeviceManager: Anschlüsse(COM&LPT)---Serielles USB-Gerät (COM3)

They all say`s that it is connected.
The firmeware is Chameleon-new-1.0

Is this the correct Firmware?

I want to snif a Cardreader ACR122u with the Chameleon, but nothing happens.
I think normaly the Chameleon LED should be blinking shortly, but the LED is on th hole time if I but it on the Cardreader.
I use a battery from Chameleon too.
Before I use it I connected with a PC Windows10 with GUI.
Firmware is Chameleon-new-1.0
Slot1 MF_DETECTION SWITCHCARD APPLY SET ACTIVE

I use this viedeo for Tutorial
https://lab401.com/blogs/academy/chameleon-mini-mifare-cracking-via-the-reader-attack

Are you any Ideas? Whats wrong?

rev E rebooted == RDV2.0?

Hi @iceman1001,
maybe it's a stupid question, but is the rev E rebooted the same as the RDV2.0?

P.S. Thanks for making the firmware available!

The ChameleonMini can't detect the password

When my device uses the detection function, I use Proxmark3 as the card reader. The ChameleonMini can't detect the password under your firmware (the calculation result is empty), but it can be used under other firmware.

DEFAULT_BUTTON_LONG is not defined in Makefile or SETTINGS

DEFAULT_BUTTON_LONG is not defined and causing an error.
Add this in Makefile and it will compile
SETTINGS += DEFAULT_BUTTON_LONG=BUTTON_ACTION_CYCLE_SETTINGS

Chameleon mini Chinese version

Chameleon mini Chinese version will not work with the original firmware because the Chinese version this not original microcontroller atxmega128a4u,replaced by atxmega32a4u

original firmware gets out error:
avrdude: ERROR: address 0x9010 out of range at line

<<< https://github.com/iceman1001/ChameleonMini-rebooted >>> the Chinese gave the distorted firmware,computer does not see Chameleon-mini
need something to fix it in the firmware
someone have a working firmware ?

Mifare Classic Clone + Reader Attack

Good Afternoon,

I just bought a Proxmark3 RDV4 and the Chameleon Mini RevE Rebooted. I'm starting to play with both, but I'm a little stopped in my enthusiasm with very simple things on Chameleon. I don't know if it could be a chameleon hardware issue or simply one thing I did not understood, so I will try to explain my best with what I know !

1st Issue : Cloning a Tag

I have a simple tag for entering my building which is a MIFARE CLASSIC 1K, as show below :

proxmark3> hf search
hf search

 UID : be ** ** **
ATQA : 00 04
 SAK : 08 [2]
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1
proprietary non iso14443-4 card found, RATS not supported
Chinese magic backdoor commands (GEN 1a) detected
Prng detection: WEAK

Valid ISO14443A Tag Found - Quiting Search

Copying that tag on a simple Magic Chinese Card works fine with the bellow commands, and I can enter the building :

hf mf mifare
hf mf nested 1 0 A ************ d   (*** being previous found key)
hf mf dump
hf mf restore 1 (on a BLANK card)
hf mf csetblk 0 xxx...xxx (I set it manually because for unknown reason it cannot be written with restore)

This is working fine, and I would like to reproduce exactly the same behavior with the Chameleon. However, after some days trying and trying, whatever GUI I use, its ends in a big failure :(.

My steps in the GUI are the followings :

1. Connect to the Chameleon (Firmware Chameleon-new-1.0) in the GUI
2. In "Operation" tab, select "Slot 1", and then select MF_CLASSIC_1K
3. I then click on "Upload Dump" and upload the previously created dumpdata.bin with proxmark
4. UID is then replaced by my dump
5. I click on "Apply"

At the contrary of Magic Chinese Card, this is not working at all with the building reader(s). When I approach the Chameleon from the reader, red light of the TAG1 is ON (sometimes fixed, sometimes blinking, can't explain). Readers, on their sides, sometimes pop a red light, or most often nothing, like if nothing was read from Chameleon.

Also, when I try to read the Chameleon back with the Proxmark, I sometimes have some reading errors :

proxmark3> hf mf dump
hf mf dump
|-----------------------------------------|
|------ Reading sector access bits...-----|
|-----------------------------------------|
[...]
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
#db# Cmd Error: card timeout. len: 0
#db# Read block error
#db# READ BLOCK FINISHED
#db# Can't select card
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
|-----------------------------------------|
|----- Dumping all blocks to file... -----|
|-----------------------------------------|
[...]
Successfully read block  2 of sector  7.
#db# READ BLOCK FINISHED
Successfully read block  3 of sector  7.
#db# READ BLOCK FINISHED
Successfully read block  1 of sector  8.
#db# Can't select card
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
Successfully read block  2 of sector  8.
#db# READ BLOCK FINISHED
[...]
Successfully read block  0 of sector 10.
#db# Authentication failed. Card timeout.
#db# Auth error
#db# READ BLOCK FINISHED
#db# READ BLOCK FINISHED
Successfully read block  1 of sector 10.

Am I missing something here ? I must admin that I have no idea of what can I be doing wrong, any help could be appreciated on that subject.

2nd Issue : Reader Attack

I also tried the reader attack presented in that video (https://www.youtube.com/watch?v=1VpXC3-eKhc), configuring the "Slot 2" with MF_DETECTION and inserting a valid card UID.

When I approach from the readers again, same behaviour, sometime fixed red light, sometimes blinking.

I then come back on the GUI and tries a mfkey32 on the "Slot 2", but again, nothings happens and absolutely nothings appear on the screen.

Any idea on that behaviors also ?

I'm a beginner on these subjects, and your help would be really appreciated. I don't have any problems with the Proxmark, but actually I cannot do anything with the Chameleon !

Thanks for your attention and your help !

build failure.

Getting the project to build.

user@ubuntu:~/ChameleonMini-rebooted/Firmware/Chameleon-Mini$ make
Makefile:120: ../LUFA/Build/lufa_core.mk: No such file or directory
Makefile:121: ../LUFA/Build/lufa_sources.mk: No such file or directory
Makefile:122: ../LUFA/Build/lufa_build.mk: No such file or directory
Makefile:123: ../LUFA/Build/lufa_cppcheck.mk: No such file or directory
make: *** No rule to make target '../LUFA/Build/lufa_cppcheck.mk'. Stop.

Noob Walkthrough

Hi,

I'm pretty new to RFID testing, I've picked up a chameleon mini rebooted running Chameleon-new-1.0 firmware from lab401 and while it looks great, I'm struggling to get started on it.

I'm initially just looking to read Mifare Classic tags, but I'm only seeing commands for card emulation or reader attacks in the commands and "standard" chameleon guides obviously don't work for this firmware.

Could anyone help me with the fundamentals of this device? I'll be happy to write a noob walkthrough guide afterwards for the wiki and then blog about it.

Thanks,
RB

RevE Boards Now Supported by ChameleonMiniLiveDebugger App

I finally had a user inquire about RevE board support in the Chameleon Mini Live Debugger Android app which provides a portable user-friendly GUI for the Chameleon boards. In addition to adding the USB vendor and product IDs which are specific to the RevE firmware on this site, I have added support for the button functionality for the RevE boards and specific command variants not found with the RevG boards. The most recent Play Store version (0.4.1-free) of the app has these updates built in. Recent screenshots (I'll include two below) can be found here.

Ultralight PWD logging

Tested successfully to implement the logging of Ul-Ev1 pwds..

more utils

During the short time I have had time to play with a chameleon mini, I noticed an sense of missing utils.

Its like PM3, most stuff is there but you need to know where they are. Not super clear but there.

With Mini its not there. There is a python client, which I still haven't used.
So where is all the dump-utils, you know, where you convert from different sources like MCT, PM3, LibNFC, all have EML, BIN, MFD which is kind of the same but with minor differences.
And which dump formats is supported?! For a device which uses dumps, I see very little usability for endusers.

• dump converters
• dump + key mergers
• dump viewers

Some of these exits for PM3, which we can just copy over, but still..

Which utils are you missing?

Detect 2 tags instead of just one

Does anybody have this issue where when I read my device it always detect 2 tags instead of just one. Is that a feature or something ?

Im asking because I seem to have problem with a certain reader because it detects 2 cards... If I scan it fast enough at a certain angle it ends up working but im betting that the 2 tags thing is bugging the reader a little.

If you wanna test it just load NFC-LIST and see how many tags your device detects...

user manual found

In the files people sent me, I found a user manual.
user manual

Automatic builds of the firmware

Hey @iceman1001,

Is it legally possible to publish binaries of the firmware ?

If it's legally possible and you are OK, I can help with the automation (automatic builds upon GitHub push).

draft for release v1.1

With this draft I open up for discussions about which functionality the next release should have.

Current firmware works with existing GUI. As of this release we are free to deviate from old legacy and bring new/fixs into action!

original idea

• merge MF_DETECTION functionality into MIFARE_CLASSIC_nK , partly to save space and since it really doesn't need its own function.
• MF_CLASSIC 1K should not react to magic command default. It should be an option.
• MF_CLASSIC 1K SAK 0x08 - 0x88 , optional to set SAK , not to be read for Sector0-Block0.
• MF_CLASSIC 1K crypto1 enhancements.
• tag slots, only allow two slots to have 4K support, in order to save memory

What currently is implemented

• firmware naming a new firmware name to better indicate which version
• MF_CLASSIC 1K should not react to magic command default. Compiler-directive
• MF_CLASSIC 1K optional ATQA/SAK. Can be set per slot individually
• MF_CLASSIC 1K crypto1 enhancements.
• tag slots, only allow two slots to have 4K support, in order to save memory

No serial output other then 200 from terminal ?

I'm trying to use terminal access using putty but all i get is the 200:UNKOWN COMMAND response.
I cant even check what firmware currently there is on it because uploading any firmware other then supplied by lab401 doesnt work.
All information i have found sofar is rather incorrect or for the revG version (different mcu)
Ok it does work as it is but when theres no decent way to compile, upload and config any new firmware its saddly of no use actually...

GUI source code

I've asked the manufacturer about getting the source code for the GUI. They said they will look into it.

It is a start.

Proposal of new firmware name: Chameleon-RevE instead of Chameleon-Mini

Both RevG and RevE (our) versions of the Chameleon-Mini carry the same name for the firmware: Chameleon-Mini.
Maybe it is an option to fork of our own name like Chameleon-RevE. I have created locally a new subdirectory under Firmware called Chameleon-RevE and changed all references for the 'old' name. Just in case everyone thinks this is a good idea, its ready for it :-)

anti copy, Mifare Sector0 / block0 should be locked

Now, new reader, fuck the chameleon, with anti-copy tag system.....
Please implement enable / disable fuid uid...for slot..... if is possible, right. ???
Thank you iceman1001.

converting commands

The current CMDMY convention feels out of date and a hinder somewhat with having a unified way for tools that work with Chameleon Mini RevG, or this rebooted version.
There are not real cause for this change of commands more than locking in the rebooted firmware from the offical one. With putting the rebooted software open-software again, the reason falls away.

However, I do feel we should keep all the extras which makes the rebooted so special, like the mfkeys implementation. I can also see we incoorporate the hardnested attack also into the client in the long run.

What you think?

UL Compat write incorrect behaviour

Ultralight compat write cmd expects data to be starting with third byte (idx 2) on second frame.
However, the specification states that data starts with first byte (D0) - possibly a copycat typo from write command.

Maybe should change to Buffer[0]?
Going to do some testing.

Instructions for flashing the avr directly

While doing my experiments, something wrong happened and now my Chameleon is half-bricked.
Behavior:

• If powered on by USB or battery+on button, the 5Th LED stays up red. Does not register at all on USB port.
• If powered on and the black button is pressed, then register on the USB port but fails to deliver a USB device descriptor (so it's not a lack of drivers as with dfu etc.).
• Does lights up quickly if presented near a NFC field.

So I think something has been corrupted inside the bootloader (I don't know how, as I never flashed it directly, it shouldn't be possible).
I would like to try to revive it but after searching a lot on the Internet, I did not find the specific steps and hardware needed for programming the atxmega32a4u directly. I know @iceman1001 does it, so it should be possible.

I found the 4 pins 3.3, CLK, DAT, GND on the board, but I have absolutely no clue on how to use them nor the protocol used. From their location, I "guess" it's PDI ?

Maybe it would be useful to other people too.

MFClassic_patch

When I access a sector on emulator it's working as it should be.
But when I want to access more than one sector, communication typically fails after reading a few sectors.
It's seems like because of too slow response.

Could it be the same problem?
emsec/ChameleonMini#83

Is the MFClassic_patch branch added into master?

eeprom / bootloader too big

Trying to flash current code, I managed to get Bootloader and code overlap.
The eeprom / bin == 44bytes, and below its expects 40bytes. Not to mention that my device is now bricked...

C:\Chameleon RevE Rebooted Software\FlashTools>flash.bat
... (compressed for readability)
Creating the EEPROM binary...
Write done!
Creating the Flash binary...
Write done!

Flashing the files onto the "Chameleon-Mini Rev-E Rebooted"...
old_driver_bootloader
Erasing flash...  Success
Checking memory from 0x0 to 0x6FFF...  Empty.
0%                            100%  Programming 0x40 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x400 bytes...
Bootloader and code overlap.
Use --suppress-bootloader-mem to ignore

If there are no errors above, flashing the firmware to your "Chameleon-Mini Rev-E Rebooted" should be finished now. Enjoy!

flashing problem

Has anyone managed to flash the compiled eep/hex files successfully onto the Chameleon?

If I run the ChameleonFirmwareUpgrade.bat script, while being in bootloader mode, I keep getting the following:

Checking memory from 0x0 to 0x7FFF...  Not blank at 0x1.
Erasing flash...  Success
0%                            100%  Programming 0x20 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x400 bytes...
[ X  ERROR
Memory read error, use debug for more info.
FAIL
Memory did not validate. Did you erase?
There was an error with executing this command. Maybe your ChameleonMini is not in bootloader mode?

If I try to add the --suppress-validation argument to dfu-programmer.exe the process seems to be finishing without errors, but the result is a dead Chameleon. And then, the only way to revive it is by running the supplied "BOOT_LOADER_EXE.exe" which displays the following:

old_driver_bootloader
Erasing flash...  Success
Checking memory from 0x0 to 0x6FFF...  Empty.
0%                            100%  Programming 0x20 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x400 bytes...
0%                            100%  Programming 0x5800 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x7000 bytes...
load_success!

Out of bound for SPI_FLASH_INFOMY

If you look at https://github.com/iceman1001/ChameleonMini-rebooted/blob/master/Firmware/Chameleon-Mini/Terminal/Commands.h#L61, you will see that the max length for a command is 16. But this should be including the final 0.
As len("SPI_FLASH_INFOMY") == 16, when displaying commands or interpreting them there is an out of bound access to the next member of the struct, ExecFunc.
We should either do a +1 inside the struct to accomodate for the final 0:

char Command[MAX_COMMAND_LENGTH + 1]; //for final \0

or change the value of MAX_COMMAND_LENGTH.

However my board is still dead so I can't test&propose a PR right now. This bug is just a reminder that this should be checked in the future.

Functionality of MF_DETECTION

What is the functionality of the MF_DETECTION configuration?

What should be happen if a slot is configured in detection mode?

Thanks a lot.

is there a GUI for android which like the one on PC?

now i use ChameleonMini live debugger, but i think this app is hard to learn to use than windows GUI by iceman. I still did not know how to upload a dump file to my devices. i think iceman GUI for windows is very great, no useless button and very suitable for ChameleonMini-rebooted. ChameleonMini live debugger have so many button but my device is ChameleonMini-rebooted, lots of them is not support, looks very confused.

Installing instructions

Looking at this repo, trying the source code, it comes to me that we need some installation guidelines.

• Setting up a development environment
• compiling
• flashing

On different systems.

Real memory size of SPI chip?

It seems that the memory size of SPI chip is far beyond 32K.

From my testing by getting manufacturer and chip id info it returned 1F 24 00 00 which corresponds to 4-Mbit chip (thats 512 KBytes!)

And from my testing (write-read-check zero address) it actually has 512 KBytes!

I have got my board from lab401, and it seems to be the common RevE-rebooted board:

Unfortunately I do not have other RevE-rebooted boards to test whether chip memory density is consistent across boards, however i discovered that there are no DataFlash chips with memory density lower than 128 KBytes.

Perhaps 32K of memory that manufacturer declared actually is about the atxmega program memory itself? May need some testing with other physical RevE-rebooted boards.

DFU driver (ATxmega32A4U) problems on WIN10 -

When I try to set the device from normal mode to DFU via GUI, a unknown decvice pops up in Device manager.

It I try to update manualy, and I point it to Chameleon Mini Rebooted GUI\ChameleonMini-rebooted-master\Drivers\DFU Driver (include subfolder),
Its starts to install ATxmega32A4U, but it fails saying The system cannont find the file specified..

Its all files needed located in the repo?

problem sniff MF-Detect, OK with Official App, but not with Iceman Fork

Hello,

Just a little message about a little problem I have with sniff (MF_DETECT)
I noticed for my last sniff I didn't have any output with iceman app (mfkey32), while with very old official release app I have the key (full calc)

maybe it's normal, I don't know ? do we have an option for a full mfkey32 maybe ? I didn't find.
Thanks
Shashadow

Graphic Design

Hello can you give me more informations about this project? Im a graphic designer that contributes for opensource projects like yours, so if you need some help to create a logotype or other stuff just say it.

Greetings