[BUG] Chameleon mini not recognized as valid by a real reader

[evazzoler]

Environment

Item	Your information
Harware	Chameleon mini RevE Rebooted by Lab401
Firmware	Latest compiled (iceman 1.3) as suggested in the wiki since I'm affected by bug #173
GUI	The glorious ChameleonMini-rebootedGUI v.1.2.1.7
Slot number	1-8
Slot configuration	Classic MF 1k
Dump source	PM3 Classic / PM3 Easy / PM3 RDV4
Reader	2 different reader by 2 different manufacturers "on the field"
Flashing environment	Linux Ubuntu / Windows 10
Flashing method	USB
Flash memory space	N/A
Makefile configuration	N/A

Bug description

I tried all the possible combinations between dumps/readers/OS used for flashing
Chameleon seems to work properly:

• I can read it and write it with PM3
• I can dump it with PM3 and diff it with the dump of the original card and they are identical

When I put it in front of the real reader, it refuses the "card". The "original card" works perfectly.
I tried this on two different systems running different hardware (they are different vendors).

I don't know if it is relevant, but I can't get a valid key with mf_detection setting the same (valid) UID. Size of all slots are fixet to 1024 and I can't change them.

Expected function and references

I suppose it is recognized as a real "card" and the reader use it as it would be "real".

Bug

I don't figure out what is the casue of this.

[leegarrett]

How are you comparing the dumps? At least the last flashable version of the firmware has a bug where it truncates the UID to 4 byte.

[evazzoler]

I compare the dump of the original tag with the dump of the chameleon. Both made with a proxmark3. They are identical.
If I read the chameleon with the PM3 issued as reader, the reply is the same of the original tag, same UID.

[iceman1001]

Seems like last release of the firmware made the chameleon unstable.
I have removed that offending release, but nevertheless this indicates that the currect source code isn't stable either. @grspy

[securechicken]

At least the last flashable version of the firmware has a bug where it truncates the UID to 4 byte.

@leegarrett could you describe this issue please?

[securechicken]

@evazzoler could you please try emulating your dump again with last release, and with another firmware release from this repo, ideally untagged-20a751f659efdcf8ef79

Unfortunately the hardware and its Mifare implementation introduce some timings that will not fit with some readers, so it will not work with some of them, in any case. You have to try against other types of readers to see if it is the case for your specific issue.

[Akisame-AI]

I'm having a similar issue with my RevE Chameleon mini emulating a mifare classic 1k dump (tried untagged-baf383b57e2f8177d332 as well as untagged-20a751f659efdcf8ef79). it works with MCT and the proxmark3 but I haven't been able to get it to work with the readers in my apartment building.

• MCT works. Tag 1 light flashes and the dump is identical. Same with the proxmark3
• The apartment readers give no response when faced with the chameleon. The chameleon's tag 1 light does not flash.
• The apartment readers give no response when faced with a magic card gen2 (from lab401) (same as the chameleon).
• The apartment readers work with direct write magic cards (lab401).
• The readers give a Red signal when faced with a non-magic card.
• The readers do work with a magic tag gen2 OTW from lab401
• I have tested turning READONLY mode on as well. The dump I am using is made with MCT.

It is my understanding that magic commands are disabled but it appears that the reader detects that something is off.
Does anyone have any clue?

I should receive my revG chameleon (tiny) in 2-3 weeks so I can try again at that time with the newer release.

ps. The readers only the UID for access control which is stupid and I have informed management about the issue. After inquiring with me they are implementing a system that uses a non-standard key in sector 1 to have an additional passcode but this system is currently only running on 2 readers. Still not very safe but at least it should stop the average person from using their smartphone to copy my card
The readers do a standard check for a magic card by sending 0x40 and 0x43.

[iceman1001]

Try latest fw?

Anyway, closing because on no activity