Emulation issue

[Peterthegreat]

Hi again, I am running the latest official firmware of the Chameleon but in the log there is no "ar" nonce (tried it multiple times, I got the same result). The tag that should go to the reader is a standard mifare classic 1k iso14443A.

*** Note that this is a different reader than the one in issue #121

Here is a partial log (the rest is the same, just repeating with other values):

One more thing to add: this is the log from an automated recharging machine.

When using other readers from the same system there is nothing on the Chameleon's log, and for them it looks like the chameleon is not present at all. The odd thing is that there is RX communication but no field present (I had set the led config for RX comm and field detect)

[Peterthegreat]

Update: Tried the firmware on the same reader as in issue #121 for a sanity check. There is still no ar nonce, so I will try an older firmware and post the result

[geo-rg]

Hi @Peterthegreat what happens there, is that the reader may not understand the Chameleon properly. At 12429, the Chameleon receives the authenticate command for sector 4, it answers with the nonce nt, but then the reader suddenly sends a HLTA command, which is interpreted by the Chameleon as the readers answer and therefor the log says APP AUTH FAILED.

[Peterthegreat]

Ok, so the latest version of the Chameleon is the problem. I am now running version "RevG 170626" (which I believe is form the old MF_Patch branch) and the reader from post #121 works again. I will try again the reader that gave errors next weekend, but I am pretty sure there is a problem with the final version.

[Peterthegreat]

Update: Just tried the system(2 readers) that gave errors. The problem is still there, and it manifests the same way (as I mentioned in my first post). Are there any other builds that I could try?

Thank you

[geo-rg]

So you are using commit 05fa61c and it works, but the current head does not work, correct?

The diff says that the only relevant differences are:

1. the auto-alignment has been added, which should improve the emulation,
2. attaching the encrypted parity bits, without these the emulation should not work properly for a reader who checks them,
3. a new init function for MFC 1k 7B

Do you use MFC 1k 7B? If not, we can rule out this as error source. The parity bits cannot be the problem. Could you please compile the current firmware without the auto-alignment and then test this again? Therefor you have to comment out this line and then recompile.

[Peterthegreat]

I don't know which commit i am using, only the software version. Is there a way to check? I am emulating a MFC 1k 4B. I am now recompiling the current firmware without the auto-alignment and I will test it later.

If this doesn't work, I will try different commits and post the results.

[Peterthegreat]

Update: I believe the problem is somewhere else. Even without the auto-alignment, the log is the same like the one in my first post. I noticed that after the log memory is full, emulation works. (tested twice, goes to around 2200 lines) Maybe adding the encrypted parity bits made the processing a bit slower and therefore the emulation errors?

The REVG version number is actually the date in YYMMDD format? If so, some of the versions dose not match the commits dates. I will post the ones that worked for me.

[geo-rg]

What you call the version number is actually only the compilation date. Sorry, this is a little bit confusing, I know. The important part is the commit ID, which can be found at the very end of the version? response. Thus, we don't know exactly, which versions you have used.

You could also test with the current firmware and just set the logmode to off, then we would know whether the logmode is the problem.

[Peterthegreat]

@geo-rg Emulation works fine with logmode turned off (latest firmware). I did not had time to test other commits, maybe I will try some of them this weekend.

[geo-rg]

OK, thanks for this information, I will see what I can find out about this.

[geo-rg]

I am really not able to reproduce the problem. Could you please try the following firmware (with enabled logmode): Chameleon-Mini-test20170919.zip

It is the current firmware but I disabled the feature that writes the log from SRAM to FRAM. This is the most probable cause I can think of for your problem.

[Peterthegreat]

I was out of my country until yesterday. I will gladly test the firmware.

I think I can get the commit ID for the firmware that works for me, so that will help you find the bug.

[geo-rg]

No hurries and thanks for your help!

[Peterthegreat]

Here is the log with the test-firmware. No more halting, but It looks like it's still not fast enough (?).

The commit ID for the working firmware is 35dcd0e. I will start testing firmwares from that point.

You are the one who is helping me :). So thank you! Taking part on this project is awesome! (even if I suck at programming and can mostly just do some testing)

[geo-rg]

OK, the commit ID is from the version? command, right? Can you upload the firmware which is working?

The thing is: the commit ID means only that your branch was at this point at the time this firmware was compiled. So it is also possible that there are changes in it.

[Peterthegreat]

The commit ID is not from the "version?" command. Actually, my friend made a branch, but the ONLY change is limiting some of the output of the log. It worked perfectly fine even before those changes.

[geo-rg]

OK, but can you upload the firmware (hex and eep)? Then I can compare it and find out more.

[Peterthegreat]

If I can find it in my computer, sure. But since it's compiled from a branch, there is no commit ID in the version? command.

[geo-rg]

No problem, I just want to compare the files to the generated files of the commits to see what exactly is in this firmware. Commit 35dcd0e uses the old Crypto1 implementation, but has no differences in the log mode to the current firmware. But the very next commit on that branch uses the new Crypto1 implementation and it is at least theoretically possible that actually this one is used. So I first want to check this.

[Peterthegreat]

I was about to mention that. The new Crypto1 was actually used..

Chameleon-Mini-limited-log.zip ("RevG 170626")

[Peterthegreat]

Since I cannot be 100% certain about the files above (until I will test them again today), can you please also look into these files? (it may be the same firmware) Chameleon-Mini-2.zip

[geo-rg]

OK, there are differences between both of the firmwares you have uploaded and then there are big differences between the firmwares and the actual commit 35dcd0e. It seems like this approach won't help much. A suggestion: simply go to your local copy of this repository and run

1. git checkout e8d6c80
2. make Then flash the Chameleon, turn on logmode and test the whole thing. This would help very much since I cannot reproduce your problem here.

[Peterthegreat]

I am so sorry, I mentioned 35dcd0e because it was the only common commit ID between the master branch and my local branch (didn't realized that 8025d18 it's an actual merge). I hope that the extra information did not complicated the situation any further.

The main idea is that the last commit from my local repository works for me, without any errors (with logmode=memory ). So the last commit, or even the one without limited logging (8025d18) are the ones that are working

Thank you for your time

[Peterthegreat]

Soo... bumping this old issue with some new information. The older post are somewhat irrelevant at this point as it's really hard to understand the problem from them. RECAP:

Issue: Incorrect emulation Mifare 1K 4b when using "logmode=memory" (output log is similar to the last picture -- I can provide more logs if necessary ). I have to wait for the memory to fill up by the log messages, and then ( when the logmode automatically goes to "OFF" ) the emulation works.

Good news: Everything works fine in commit 82ce8f0 (ONLY this commit works) Bad news: The next commit has multiple changes (mostly in the Crypto1 files) that where not caught by github.

Tried to compile the latest code with the Crypto1 from 82ce8f0, but the results are the same.

[Peterthegreat]

Ok, so the latest version now works! :+1: commit 8ffa1aad959408bd07fe48f62b48597d5d23373c I missed a lot of the development update. Did you implemented something from MFClassic_patch branch? Or maybe it was a problem on how logmode operated (now that it was updated to work both ways).

Thank you for all the help and time to solve this issue Glad I can close this issue and to see that people are still working on this!