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

[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

Edit: the atxmega doesn't have a user page. It seems it is a hardware issue. The 3rd Bit is stuck converting the binary so it adds 4. 0x0A = 00001010. The 3rd Bit is stuck so it turns into 00001110 which is 0x0E

[Akisame-AI]

I am using Iceman's chameleon mini gui version 1.3.0.3 to upload my dumps. I checked if v1.2.2.1 still works to exclude a bug in the GUI and it does still work. 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 blocks get 0x04 at the 2 and 3rd hex value as well as at the same relative position in the second half of the block (10th and 11th hex value). It does this for all cards.

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 and eeprom should be completely overwritten during flashing and the non-volatile storage should get overwritten when I am uploading a new dump.

[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

The same happens with MF4K cards as well as ultralight cards, classic mini, etc etc. basically all card types. They all get 0x04 added to the 2nd, 3rd, 10th and 11th hex value if they end in 0,1,2,3,8,9,A or B

[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

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?

[Akisame-AI]

Okay, there is no user page.... It seems I may have a hardware issue. if you convert the hex values that change and the hex values that don't change you'll see that the bits that change are the ones that have the 3rd Bit off and the ones that don't change have the 3rd bit on.....

[Akisame-AI]

I messaged the manufacturer. They replied with this:

Btw, I ask our engineers about the problem you have.

3% of the units will have this problem due to MRAM. If you place the tiny near magnets, the MRAM will be affected.

Ignore the return parcel. We will just send a new one.

Sorry and thank you for your understanding.

-Dennis