search

iceman1001 / ChameleonMini-rebooted

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

Broken for 4k in several ways #22

Closed jackkleeman closed 5 years ago

jackkleeman commented 6 years ago

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.

bogiton commented 6 years ago

Yeah, there are a couple of issues in the MF Classic emulation in the current build. The plan is to get a mostly working build that is close to the stock firmware (and make a release at that point) and afterwards apply the MF Classic patches (coming from the official RevG version) that should solve most problems.

iceman1001 commented 6 years ago

@jackkleeman feel free to help out!

jackkleeman commented 6 years ago

Hi guys, I have managed to brick it now so I will wait for my avrisp and then help out.

iceman1001 commented 6 years ago

Don't count it out yet. Use the solutions mentioned in other thread and you should be able to unbrick it :)

jackkleeman commented 6 years ago

I can't even get it recognised as bootloader now. I could never get it recognised as bootloader on windows as well, so I was flashing using Mac and dfu programmer. I want to be able to develop easily so I need an avrisp anyways

nurzhannn commented 6 years ago

"chameleon-mini" he can sniffing acr122u with "mifare_classic" between them ?

bogiton commented 6 years ago

@jackkleeman there is a program called Zadig (http://zadig.akeo.ie/) which enables you to replace installed drivers very easily. When in bootloader mode (black button pressed etc.) launch Zadig, Options->List all devices, select the Atxmega32a4u from the list and replace its driver with libusb-win32. This may fix your device being recognized by BOOT_LOADER_EXE.

@nurzhannn as far as I recall, the RevE rebooted firmware doesn't have support for reader and sniffing capabilities. RevG device supports it. I guess that we can add it to our firmware some time in the future though.

jackkleeman commented 6 years ago

@bogiton I actually already tried this but I can try again

iceman1001 commented 6 years ago

Hard to tell if the device is in bootloader mode if the drivers are all mixed up.

Regarding sniffing? We have 32kb to play with, that is very little. I don't think sniffing will be inside the major firmware, (the logging functionality) , but in a custom firmware where you can remove other stuff to fit it in.. I have no need for it, since I have proxmark3 for the heavylifting stuff.

@bogiton and I talked about why you would need sniffing, and in the end its because you want to get the unknown key or password used. For Ultralight Ev1 / NTAG its a password in clear you want. For Mifare its the keys..
We have mfkey to get mifare keys out, when enables you to run darkside/nested/hardnested attacks in order to collect all keys. We just need to save the clear text password and a way to extract it for Ultralight/NTAG and that functionality doesn't take much space.
With that you have basically what you would need to extract all data from a tag that you have.

Act as a reader,.. it not quite the purpose of a Mini, but sure, if you want to use it as a reader its doable already with RevG.

I think ISO15693 support ISO14443b and other protocols are more of value for this project. After all bug fixes of course

securechicken commented 5 years ago

I confirm there are still "bad" things happening with 4K (at least, I had not have enough real-case 1K tests to tell for 1K), even after 0b5cc0a commit (McEloff/fix_4k_tags). "Bad" like heavy memory corruption.

EDIT: this seems to be due to the slots overlaps in memory when using 4k #41 .

I can reproduce issue starting at the first firmware I have where you can choose a function for "Button Long" (here). The first stock firmware from GUI "Load Default" does not have the same issue. I noticed it first because various readers did not manage to read a multi-purpose 4K tag dump I have (Chameleon sometimes did not blink at all, or readers did not react or seemed to fail). The same 4K dump however perfectly works when I clone it to a real Chinese or direct write physical tag.

Here is how to check on the issue easily:

You will be able to notice that (somewhere near 1K for me), the 4K dump you download back is totally messed with, compared to your original 4K dump, and notably that parts of the 2nd slot 1K dump are being mixed within the 4K dump you downloaded back (you will be able to spot your 1K-dump easily identifiable bytes patterns, or ASCII readable patterns, within the 4k dump that has been downloaded back from Chameleon).

securechicken commented 5 years ago

@jackkleeman please try with new compiled firmware as of today, a lot have been reworked on Mifare, notably 4k. Try your chance with Wiki rescue kit pages to restore a proper DFU if need be. @iceman1001 could probably be closed as last comment from user is 1 year and half now.