iceman1001 / ChameleonMini-rebooted

Chameleon Mini revE rebooted - Iceman Fork, the ChameleonMini is a versatile contactless smartcard emulator (NFC/RFID)
Other
389 stars 85 forks source link

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

Closed evazzoler closed 3 years ago

evazzoler commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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.

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 commented 3 years ago

Try latest fw?

Anyway, closing because on no activity