Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ChameleonMini card emulator doesn't play nice with MCT #73

Closed
Sam-Hall opened this issue Oct 8, 2015 · 4 comments
Closed

ChameleonMini card emulator doesn't play nice with MCT #73

Sam-Hall opened this issue Oct 8, 2015 · 4 comments

Comments

@Sam-Hall
Copy link

Sam-Hall commented Oct 8, 2015

Not sure what's going on, but when I try to read the ChameleonMini with a large key file, MCT often loses connection. With a minimal key file (containing only 1 key of FFFFFFFFFFFF), it succeeds but seems to only read every second sector.

NFC WAR works fine and reads all the data, so I'm guessing MCT is not patient enough when trying to brute force the ChameleonMini.

@Sam-Hall
Copy link
Author

Sam-Hall commented Oct 8, 2015

I've compared your code with NFC-War looking for clues. I can't see anything obvious other than the fact that NFC-War does everything in a single parse.

Perhaps the problem is the Chameleon expects you to read some data after authenticating, but if your next action is to authenticate a different sector it behaves erratically. If that's the case this seems like a shortcoming of the ChameleonMini considering it's not behaving the exactly the same as a card it's trying to emulate.

One thing worth noting, the NFC-War technique is going to be more efficient compared to the MCT technique of mapping the keys first and then re-authenticating to read the data off each sector.

@ikarus23
Copy link
Owner

Perhaps the problem is the Chameleon expects you to read some data after authenticating, but if your next action is to authenticate a different sector it behaves erratically. If that's the case this seems like a shortcoming of the ChameleonMini considering it's not behaving the exactly the same as a card it's trying to emulate.

This sounds reasonable. Maybe the ChameleonMini needs a firmware update...

One thing worth noting, the NFC-War technique is going to be more efficient compared to the MCT technique of mapping the keys first and then re-authenticating to read the data off each sector.

Yeah, you are totally right. I separated those steps (creating a key map and reading data) when I designed the software. Never thought about performance in this context... I want to rewrite parts of the the mapper and reader code for quite some time now. If it will ever come to this (lack of spare time), I will take this improvement into account :)

Not sure what's going on, but when I try to read the ChameleonMini with a large key file, MCT often loses connection.

I'm not sure if this is of any help, but you can try to activate the "auto reconnect" setting in MCT.

OffTopic:
Do you like the ChameleonMini? Does it work well? How is the provided software?
Where did you purchase it?

@Sam-Hall
Copy link
Author

It's likely something that can be fixed within the ChameleonMini firmware, I've started delving a bit deeper. The device is still pretty experimental, though I must say, aside from this issue I've found it to be very reliable. Might as well close this issue.

Do you like the ChameleonMini? Does it work well? How is the provided software?

I've had mine just under a week, but so far I'm a big fan. If you are working with 4byte UID Mifare Classic/Ultralight cards, it's still a very useful little unit out of the box with the current software version. I didn't do much research, it was a bit of an impulse buy. It has a little serial port terminal to configure it which works quite well. When it arrived it took me about 4 hours to go from knowing nothing to figuring out how to drive it with a python script in order to use it for automated testing incorporate physical reader/writers (after which I noticed that they actually include an example python script in the github project that I could have pulled apart to save me some time Googling). The hardware of the currently available devices don't support card formats with more than 1KB of memory, a limitation of the current MCU. The 7byte UID support seems flaky, it's not currently working with my ACR122 reader I've been using for testing.

I'm amazed how easy it is to work with really. My C skills are pretty infantile, but I was still able to make a few firmware improvements in the few hours I spent playing around with it over the weekend. There is still plenty of room for improvement. The AVR plugin for Eclipse that should make life easier (though I'm still trying to work out how to configure some of the features of the plugin). In theory, you can upgrade the firmware directly from the Eclipse once it's all setup right. The build process is fast, but it takes about 30 seconds for the device to reset with the new firmware which slows down development time (need a series of 30 second youtube videos on standby or something to pass the time).

I'm currently trying to get it to spew detailed logging information to the serial port terminal so I can debug what's going on with the 7byte UID. Once I've got that happening I'll upload my firmware branch.

Where did you purchase it?

Well, you should know the creators Kasper & Oswald sell them. You can contact them via email on their website. I can also recommend Rysc Corp. I don't want to take sides. They are both very responsive and helpful. If you have time to explore the Kasper & Oswald route, you'll be directly supporting future development of the project though.

Also, the Kickstarter for a better model from Kasper & Oswald that wont have the 1KB limitation should be publishing any day now.

@ikarus23
Copy link
Owner

Thanks for ChameleonMini review ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants