0x04 is being added to 2nd, 3rd, 10th and 11th hex value if they end in 1,2,3,8,9,0,A or B

[Akisame-AI]

Edit: made this post into a summary of the current findings 0x04 is being added to every 2nd, 3rd, 10th and 11th hex value if they end in 1,2,3,8,9,0,A,B. I tested this by uploading a dump via iceman's chameleon mini gui version 1.3.0.3 and then instantly downloading it again and comparing it to the original uploaded dump. Writing to the tag directly with MFC tools has the same issue. The bug seems to persist across firmwares and I think it is being caused by some values in the Non volatile that are not being erased when it is being flashed. I have tried to clear memory by opening every setting and sending clear, logclear, config=NONE. The problem persists

My current hypothesis is that something in my user page is corrupted. I would need a user page from someone with a working chameleon tiny (dfu-programmer read --user > user.hex) so I can compare yours with mine and reflash it

[ceres-c]

First off: which application are you using? Are you trying to emulate a Mifare Classic? No similar bugs were ever reported. What do you mean by "is unable to emulate block 0"? Which device are you using to read the tag emulated by the Chameleon? Isn't it possible that the Chameleon is not recognized by your system because you changed the key?

[Akisame-AI]

Aah, sorry. I should have included all of the extra info but I was dumb, frustrated and tired. I am using Iceman's chameleon mini gui version 1.3.0.3 to upload my dumps. I'll check if v1.2.2.1 still works to exclude a bug in the GUI. I am trying to emulate a mifare classic 1K card. The card was successfully dumped using a PM3 with a hardnested attack and has been verified by writing to a direct write mf1k card.

I was using the februari prebuild firmware from the proxgrind branch but I was experiencing some timing issues so I decided to upgrade to the latest prebuild version (22 june 2020). Since then no matter which version I flash I get the same issue.

• all 000 blocks get 0x40 at the 2 and 3rd hex value as well as at the same relative position in the second half of the 000 block (10th and 11th hex value). It does this for all dumps.

• If sector 0 has the default key of FFFFFFFFFFFF sector 0 will work just fine when reading the chameleon tiny. However I am trying to emulate a card that has A0A1A2A3A4A5 as the key for sector 0. When I try to read it with mifare classic tools it shows that it couldn't find a key for sector 0. Some B-keys are changed as mifare classic tools shows them to be ------------ meaning it couldn't find the key in the keyfile.

I'll use my PM3 from work in the afternoon to check the keys to verify this.

My guess at the moment is that when I flash a new firmware something of the old code remains but this seems very weird to me because the NAND should be completely overwritten during flashing and the non-volatile storage should get overwritten when I am uploading a new dump.

[Akisame-AI]

I tested it with a few older versions of the Iceman gui repo. The bug persists

[Akisame-AI]

uploading the dump and then directly downloading it from the chameleon tiny reveals the same issue. the keys of sector 0 have 0x04 added to it (hence why the original key didn't work). the 0x04 is added everywhere except when the lower bit approaches C. So 1B becomes 1F but 1C stays 1C. If this happens the second 0x04 also doesn't appear. This works for either of the 2 0x04's.

I made a file to scan which values change.

It seems values ending in a 1,2,3,8,9,0,A or B are increased by 4. the high bit of the hex value is ignored by this bug

[Akisame-AI]

Writing directly to the tag itself using mifare classic tools yields the same issue. I wrote 00000000000000000000000000000000 to sector 15 block 0 and it yielded: 00040400000000000004040000000000 Replacing the 3rd and the 10th hex to an ending number that does not have this issue worked perfectly fine

[Akisame-AI]

The same happens with MF4K cards as well as ultralight cards, classic mini, etc etc. basically all card types

[Akisame-AI]

I dumped the flash and checked the configuration right after flashing. In the flash dump I can see that the 0x0404 error is not present. If I read it with MFC tools the 0x0404 does show up. the configuration in flash is correct. The error MUST be in the user page then

[Akisame-AI]

When I dump the flash card 1 looks like this:

:10000000BC59FC0F160804000138E31F63B2971DAA
:1000100000000000000000000000000000000000E0
:1000200000000000000000000000000000000000D0
:10003000FFFFFFFFFFFFFF078069FFFFFFFFFFFFDD
:1000400000000000000000000000000000000000B0
:1000500000000000000000000000000000000000A0
:100060000000000000000000000000000000000090
:10007000FFFFFFFFFFFFFF078069FFFFFFFFFFFF9D
:100080000000000000000000000000000000000070
:100090000000000000000000000000000000000060
:1000A0000000000000000000000000000000000050
:1000B000FFFFFFFFFFFFFF078069FFFFFFFFFFFF5D
:1000C0000000000000000000000000000000000030
:1000D0000000000000000000000000000000000020
:1000E0000000000000000000000000000000000010

However when I read it with MFC Tools the 0x0404 shows up again..... and it doesn't match what is available in flash

BC59FC0F16080400013CE71F63B2971D
00040400000000000004040000000000

However reading the user page presents some....issues

[Akisame-AI]

I've done a check of the flash, eeprom, bin before and after adding a card and they match. That means ONLY the user page remains as a source for the issue.....but I can't read it...... Is there anyone with more experience with DFU programmer that can tell me how I can read the user page?

[timokasper]

I notice you are having problems with your "chameleon tiny". This sounds to me like a bug in the hardware of this device as it has never appeared in the last 4 years since the birth of ChameleonMini RevG. Meanwhile there exist various replica and variants of ChameleonMini RevG, please understand that we cannot give support for them as we cannot work out for each variant, what the manufacturer did wrong. This github project is the official github project for ChameleonMini RevG. Please contact the manufacturer or your device directly or maybe they have a separate github or forum or other ways of support... Note also that the hardware of Chameleon Tiny / Proxgrind Chameleon ist NOT open source, in contrast to the original ChameleonMini RevG. It would be contradictive to give support and fix bugs of commercial products / commercial replica in the original open-source project, right? If I may give some advice, get a RevG and be happy, like thousands of other ChameleonMini RevG users.

[ceres-c]

Well, according to the XMEGA datasheet (page 23)... there is no User Memory in the XMEGA 128. This could be the reason DFU prog can't dump the memory

[Akisame-AI]

aah crap.... I think you are right.... Converting the hex to binary you can see that the 3rd Bit is stuck in the on position.

[ceres-c]

It's possible that something's wrong with the FRAM installed on your Chameleon Tiny. The XMEGA progmem works fine (which explains why dumping the firmware returns a perfect copy of the original), but the FRAM where dumps/logs are stored has strange issues.

[Akisame-AI]

Do you have any suggestions for clearing it? I already cleared the dump/log space via serial commands. I already contacted the supplier to claim my warranty but if I can fix it that's always preferable.

[ceres-c]

You have to check the datasheet for your specific FRAM, but there should be a "clear all" command or something like that. To isse it either you remove the chip from the board and use something like the buspirate or modify the Chameleon firmware to do it for you (have a look at the SPI.s file)

[Akisame-AI]

Thanks. I'll have a look. I think it might be easier to fill the FRAM with logs and then clear it. LOGCLEAR should clear the FRAM but I'll look in the code for a bit

[Akisame-AI]

I overwrote the FRAM with 0xFF and cleared it again. The problem remains.

[david-oswald]

Dear @Akisame-AI, can you confirm which Chameleon hardware version you are using? This project is only for the original RevG, so if your Chameleon is another version (e.g. proxgrind or so) pls contact them re this issue, sounds like a hardware issue to me.

[Akisame-AI]

I am indeed using the proxgrind version and we have since confirmed that it is a hardware issue. I shall close the thread.