[BUG] MF_DETECTION memory management issue (mfkey32 attack failed, no keys found)

[uspilot]

Environment

Item	Your information
Harware	ChameleonMini-rebooted RevE
Firmware	ChameleonMini-rebooted v1.3 (Iceman: 844caed)
GUI	ChameleonMini GUI - v1.2.0.19 - Iceman Edition
Slot number	1
Slot configuration	MF_DETECTION"
Dump source	N/A
Reader	Elevator access control, model unknown
Flashing environment	HEX/EEP file from repository
Flashing method	USB / flash.bat
Flash memory space	N/A
Makefile configuration	N/A

Bug description

MF_DETECTION function is not working.

Expected function and references

Obtain MF keys

Bug

After using ChameleonMini with MF_DETECTION settings in slot on reader, no keys found with mfkey32 function.

Tried to use same device on the same reader with original Firmware/GUI -> everything is working. Some previous release of Iceman Firmware/GUI also was working in the same configuration of Chameleon/Reader

--> VERSION?
101:OK WITH TEXT
ChameleonMini-rebooted v1.3 (Iceman: 844caed)

--> SETTING?
101:OK WITH TEXT
NO.1

--> CONFIG?
101:OK WITH TEXT
MF_DETECTION

--> DETECTION?

6E 6D 6C 6B 6A 69 68 67 FB F5 F4 E8 F8 FA BF D6 90 8C 90 84 8D EF C4 CD C4 CB C5 96 8D 96 9B 84 D2 D3 D6 D0 9C B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 83 7B 31 30 30 3A 4F 4B 0D 0A 00 00 00 00 00 00 00 00

[+] Success, found Chameleon Mini device on 'COM4' with Firmware RevE rebooted installed
[Tag slot 1]
mfkey32 attack failed, no keys found
[Tag slot 2]
mfkey32 attack failed, no keys found

Steps to Reproduce

1. Set slot 0 mode to MF_DETECTION
2. Apply ChameleonMini on reader
3. Use mfkey32 function to get keys

   Resolution paths

   Ideas

   I don't know if this bug is from Firmware of GUI. Needs some more tests with previous release of Firmware/GUI.

[securechicken]

@uspilot As far as I understand from @iceman1001 , it is not supposed to work any time (i.e. mfkey32/64 might not always find a valid key for some collected data).

There have been some bugs reported on "MF_DETECTION" before, and I never tried it by myself, but can already say from a quick look at the code that the implementation is for long buggy, as it reads/writes at arbitrary out-of-bound spaces in memory. For instance in "Detection.c" application:

AppMemoryWrite(data_save, (turn_flaga * MEM_BYTES_PER_BLOCK) + 4096, MEM_BYTES_PER_BLOCK);

The "MF_DETECTION" is declared with a 1024 bytes memory space, but writes to "+ 4096" address... Latest memory rewrite may have "brutally" fixed this, as it prevents any read/write out of application memory space bounds.

Please go with further narrowing this issue (which part on GUI, which part on firmware, is this always failing or sometimes failing), in order to help someone fix this. If someone like @iceman1001 or @bogiton knows more about how it is supposed to work code-wise, please do not hesitate to brief it here in order to ease any attempt at fixing/rewriting this app.

[iceman1001]

Since you fixed the memory allocations, I suggest you reserve some 1kb memory for MF_DETECTION not near the normal 8x4Kb memory slots. Or the logging functions (if still any). The GUI just wants that array of bytes (a.k.a nonces from Mifare Authentications), to feed into the mfkey32 key recovery. This is a pure fw problem :)

[securechicken]

@iceman1001 there are not "normal 8x4kb memory slots". There used to be "at most" 4Kb + 7 x 1Kb, depending on what you set on 1st slot. Now they are 8 x nKb, where n is taken from configuration declaration structure, and is up to (ALL AVAILABLE FLASH MEMORY / 8). Which is somewhere around 64Kb available per slot at least with smallest memories. MF_DETECTION is already declaring 1Kb, but is reading/Writing some places that are definitely not in its space. Before it worked, sometimes (according to previous issues - but never had it to work in my cases), because it overwritten other's slots memory, making other issues appears. Now the memory libs prevent that (i.e. MF_DETECTION messing with memory in most of use cases, except if used in 2nd slot with 1st one set as MF 4K and all others closed).

As MF_DETECTION (and code part of it which lays in Commands.c) does for now (and before that as well) mess with memory at most of its memory operations, based on a MifareClassic.c code copy, it seems to be deserving a bit more attention than that... A temporary fix would probably be giving MF_DETECTION 5120 bytes of memory (or setting it to "0", to get all available space). An acceptable more stable fix would be to rewrite MF_DETECTION, starting by fixing all addresses and offsets.

[iceman1001]

go go go :) And I so looking forward to when you start looking into the RRG/Iceman proxmark repo :)

[securechicken]

@uspilot please clone that branch (git clone --single-branch --branch <branchname> <remote-repo>) and try now, as I cannot test things like MF_DETECTION by myself.

[uspilot]

MF_DETECTION works now, but there's some issue with memory allocation.

I set UID for slots 00000001 ... 00000008 before applying Chameleon to reader. After reader UID changed to: Slot 1: 603C1A80 Slot 2: 603C1A80 Slot 3: 6014502D Slot 4-8:603C1A80

Dump from Slot 1:

--> DOWNLOAD
110:WAITING FOR XMODEM

60 3c 1a 80 8e b9 c9 f0 c3 84 95 86 61 01 1d 6b 
60 14 50 2d b0 81 8a 4b 9d 00 82 df 83 e4 d1 42 
60 3c 1a 80 94 15 0f 05 cb d3 ed d0 64 f2 0d 7f 
60 14 50 2d 68 31 f4 ae 4a cd 64 ea 7a 22 76 7e 
60 3c 1a 80 a6 8b 85 60 21 e2 76 1d 2a 6c 1b 04 
60 14 50 2d 40 36 93 17 a1 f6 ec 42 b8 2d 95 23 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

--> SETTING?
101:OK WITH TEXT
NO.0

--> VERSION?
101:OK WITH TEXT
ChameleonMini-rebooted v1.3 (Iceman: 8225086)

[+] Success, found Chameleon Mini device on 'COM4' with Firmware RevE rebooted installed
[Tag slot 1]
[S5 / B20] KeyA [1c0cb79ee465]
[S15 / B60] KeyA [1844e84306b1]
[Tag slot 2]
[S5 / B20] KeyA [1c0cb79ee465]
[S15 / B60] KeyA [1844e84306b1]
[Tag slot 3]
[S5 / B20] KeyA [883efdf93a3b]
[S15 / B60] KeyA [8c6aa224c92f]
[Tag slot 4]
[S5 / B20] KeyA [1c0cb79ee465]
[S15 / B60] KeyA [1844e84306b1]
[Tag slot 5]
[S5 / B20] KeyA [1c0cb79ee465]
[S15 / B60] KeyA [1844e84306b1]
[Tag slot 6]
[S5 / B20] KeyA [1c0cb79ee465]
[S15 / B60] KeyA [1844e84306b1]
[Tag slot 7]
[S5 / B20] KeyA [1c0cb79ee465]
[S15 / B60] KeyA [1844e84306b1]
[Tag slot 8]
[S5 / B20] KeyA [1c0cb79ee465]
[S15 / B60] KeyA [1844e84306b1]

[uspilot]

The same dump I had before when I got my ChameleonMini stuck on one slot in issue #128

It really looks like a memory allocation problem

[securechicken]

Thanks testing this @upsilot. I fixed some out-of-bounds offsets in MF_DETECTION, but there still might be some to be fixed. I am not familiar with "MF_DETECTION" codebase, and it is not an easy one to validate. Plus the GUI that correctly handles UID and slots setting/resetting is still not published so there might be some glitches from there as well. And finally, we can always consider there is a particular situation with your device as well.

1) In order to narrow this down, could you please follow next steps:

I set UID for slots 00000001 ... 00000008 before applying Chameleon to reader.After reader UID changed to:

Could you detail what configurations slots were set to? If this is on another config that "MF_DETECTION", another issue will have to be opened.

2) In order to get sure your memory is clean (as what you have in your device might be due to previous firmwares writing out of bounds), please follow these steps (with the 'tempfix_detection' branch from my repo, or with latest firmware from this repo with PR #152 manually applied) and report results here:

• 2A) in Makefile, please uncomment following 2 lines, make new firmware, flash it to your device:

  #SETTINGS    += -DCONFIG_DEBUG_MEMORYTEST_COMMAND
  #SETTINGS    += -DCONFIG_DEBUG_MEMORYINFO_COMMAND

• 2B) run MEMORYINFO from a preferably terminal-only (e.g. minicom -D </dev/tty...>) connection to your device, and reports results here
• 2C) run MEMORYTEST from a preferably terminal-only (e.g. minicom -D </dev/tty...>) connection to your device, and reports results here
• 2D) run CLEARALL from a preferably terminal-only (e.g. minicom -D </dev/tty...>) connection to your device, then go back to your test use cases with MF_DETECTION, and reports if something changes.

If you find that UID and memory read strangeness persist after previous steps, regardless of what you will report for them, please try to check you have the same results with a GUI and with a terminal-only setup. Always start your test scenario with a "CLEARALL" (from a terminal-only command-line preferarbly. This will also work with GUI terminal, but while the latest rebootedGUI fixes are not published, this might hang out/reset your GUI - do not worry, and just close/open it again).

The reason of all this is because we want to rule out previous memories states and/or previous firmwares out-of-bound writing to be cause of these bugs. "CLEARALL" is a new command that I introduced that, even while GUI is not synced with recent changes, will totally and fully reset all persistent storage memories. As so, we will be sure your memory content clean of any bit from previous buggy applications memory management.

Thanks for your tests.

[uspilot]

1. All slots were set to MF_DETECTION mode with UID 00000001 ... 00000008

2. 2A) Once I compile with SETTINGS += -DCONFIG_DEBUG_MEMORYTEST_COMMAND, I have a warning during flashing (it seems to be another bug?)

flash.bat should be fixed to accept command-line parameters for BOOT_LOADER_EXE (it's easy to fix), but what means Bootloader and code overlap? Could usage of --suppress-bootloader-mem lead to brick of device or nothing happens?

z:\ChameleonMini-rebooted\Software\Flashing-Windows>flash --suppress-bootloader-mem

.---------------------------------------------------.
|                                                   |
|   ChameleonMini RevE Rebooted flasher utility     |
|                  Iceman fork                      |
|                                                   |
`---------------------------------------------------'

Creating the EEPROM binary...
Write done!

Creating the Flash binary...
Write done!

Flashing the files onto the "ChameleonMini RevE Rebooted"...
old_driver_bootloader
Erasing flash...  Success
Checking memory from 0x0 to 0x6FFF...  Empty.
0%                            100%  Programming 0x40 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
0%                            100%  Reading 0x400 bytes...
Bootloader and code overlap.
Use --suppress-bootloader-mem to ignore

2B)

SPI Flash:
- Bytes Per Setting: 65536
- MDID Bytes: 1F240000
- Memory size: 4 Mbits (512 KBytes)
EEPROM:
- Bytes Per Setting: 128
- Memory size: 1024 Bytes

2C) Unable to do due 2A warning 2D) Done.

UID change still exist:

--> DOWNLOAD
110:WAITING FOR XMODEM

60 3c 1a 80 a1 16 d2 da 02 76 61 cd 6d b3 47 df 
60 14 50 2d 76 79 89 6c d6 2b ce 50 00 43 86 34 
60 3c 1a 80 29 19 8b 26 fe 13 a2 ba 36 fb c7 7a 
60 14 50 2d 57 b5 8c 50 31 68 b9 d5 50 32 53 90 
60 3c 1a 80 94 ff 67 1d 8b d4 17 88 8e df 9d 8a 
60 14 50 2d 1f eb dc bd db aa 9f 29 b6 55 81 52 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

It looks like AppMemoryWrite write detection data into slot dump starting from Block0 overwriting UID information set for this slot.

--> UID?
101:OK WITH TEXT
603C1A80

[securechicken]

@uspilot confirmed, some offsets are still to be fixed, and my dirty fix was not enough. For now, every use of MF_DETECTION overwrites Block0. I will fix this.

As for warning you have, it's "dfu-programmer" code (which BOOT_LOADER_etc. is based on) that warns of firmware sections overlaps. This may mean you are running out of memory (or may mean nothing, who knows...). This should not prevent you to use "MEMORYTEST".

[securechicken]

@uspilot please test with branch/PR update with new commit. Still did not work for me, but now it should not overwrite UID.

[uspilot]

It still overwrite UID, but with 0xFF data Moreover for Slot1 it changes mode to MF_CLASSIC_4K It seems like memory allocation problem again.

--> VERSION?
101:OK WITH TEXT
ChameleonMini-rebooted v1.3 (Iceman: f74036b)

--> UID?
101:OK WITH TEXT
FFFFFFFF

MEMORYTEST doesn't make any output in terminal. Is it correct?

[securechicken]

It still overwrite UID, but with 0xFF data

CLEARALL will reset all your memory, which is setting it to "0xFF" all along for a flash chip. So will MEMORYTEST at the end of its tests.

Moreover for Slot1 it changes mode to MF_CLASSIC_4K

What now ???! Did not see that happen, ever. What do you have activated in your Makefile as -DDEFAULT_CONFIGURATION=? Did you use DETECTION= command format at some point? How often/when do you use CLEARALL or MEMORYTEST command?

MEMORYTEST doesn't make any output in terminal. Is it correct?

It is supposed to return a 101 code with a text displaying FINE if it succeed. It will display a hexstring otherwise, that I will be happy to check out. Use it on a terminal only connection to ChameleonMini to get sure GUI is not interfering with timeouts (this has been recently patched, and is now published in rebootedGUI, so you might want to update GUI as well). The command will also delete all memory at the end to ensure test consistency in next run, so if you run MEMORYTEST (or CLEARALL) often, this will clear all slots config and memory content each time.

Please try to keep consistent in your testcase (running the same(s) steps, always, and precisely listing them), keep to terminal-only interaction for now, and use MF_DETECTION only to get sure we sort this out first.

• compile branch and flash as you want, preferably with MEMORYTEST enabled,
• use a terminal-only connection to ChameleonMini,
• run MEMORYTEST (to get output, and see if there is a memory management issue beyond MF_DETECTION application),
• run CLEARALL (this shouldn't be needed after MEMORYTEST, but just to get sure in case previous step failed),
• set some slots as MF_DETECTION with buttons as you want (UID will be 0xFFF... by default, you can change it, as well as ATQA and SAK), and disconnect from terminal,
• use ChameleonMini "MF_DETECTION" slots to apply on readers, where you known there are supposed to be results,
• connect back, with terminal-only, and check what you have with slot memory download and/or DETECTION?. Check if UID changed from your initial setting, and if slots config changed,
• lastly (this is important), disconnect from terminal, and connect to rebootedGUI (preferably updated version as of today), to run "mfkey32" on the appropriate slots.

[uspilot]

Compiled with MEMORYTEST enabled SETTINGS += -DDEFAULT_CONFIGURATION=CONFIG_MF_DETECTION

I used terminal minicom 2.7.1 to connect ChameleonMini

1. VERSION?

   101:OK WITH TEXT
   ChameleonMini-rebooted v1.3 (Iceman: f74036b)

2. MEMORYTEST

   101:OK WITH TEXT
   FINE

3. CLEARALL

   100:OK

4. `UID=00000001'

   100:OK

5. UID?

   101:OK WITH TEXT
   00000001

   UID don't change after use of MF_DETECTION on reader but mf32key function doesn't work

   [Tag slot 1]
   mfkey32 attack failed, no keys found

   
   --> DOWNLOAD
   110:WAITING FOR XMODEM

00 00 00 01 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

--> DETECTION 201:INVALID COMMAND USAGE

--> DETECTION?

6E 6D 6C 6B 6A 69 68 67 66 65 64 63 62 61 60 5F 5E 5D 5C 5B 5A 59 58 57 56 55 54 53 52 51 50 4F 4E 4D 4C 4B 4A 49 48 47 46 45 44 43 42 41 40 3F 3E 3D 3C 3B 3A 39 38 37 36 35 34 33 32 31 30 2F 2E 2D 2C 2B 2A 29 28 27 26 25 24 23 22 21 20 1F 1E 1D 1C 1B 1A 19 18 17 16 15 14 13 12 11 10 0F 0E 0D 0C 0B 0A 09 08 07 06 05 04 03 02 01 00 FF FE FD FC FB FA F9 F8 F7 F6 F5 F4 F3 F2 F1 F0 EF EE ED EC EB EA E9 E8 E7 E6 E5 E4 E3 E2 E1 E0 DF DE DD DC DB DA D9 D8 D7 D6 D5 D4 D3 D2 D1 D0 CF CE CD CC CB CA C9 C8 C7 C6 C5 C4 C3 C2 C1 C0 BF BE BD BC BB BA B9 B8 B7 B6 B5 B4 B3 B2 B1 B0 AF AE AD AC AB AA A9 A8 A7 FD 01 31 30 30 3A 4F 4B 0D 0A 00 00 00 00 00 00 00 00

Also ChameleonMini with MF_DETECTION slot doesn't respond on PM3 requests:

[usb] pm3 --> hf search [=] Checking for known tags...

[] Searching for Topaz tag...[=] 04 00
[/] Searching for iClass / PicoPass tag...[=] You can cancel this operation by pressing the pm3 button

[-] No known/supp

[usb] pm3 --> hf 14a reader [!] iso14443a card select failed

[securechicken]

Thanks @uspilot . Yes, same results here - I now can generate tests case from my side as well.

So I guess parts of results you were having before (either good or not) are due to old memory not being cleared: after my first fix attempts, offsets were finally fixed on MF_DETECTION, but memory was most probably never written, because of WUPA/REQA-Select phase rarely reaching the authoring state, where MF_DETECTION is supposed to store results in memory. Hence the "[!] iso14443a card select failed" with pm3. I am on it, but this is not an easy one to me.

[uspilot]

In fact, after first fix I did CLEARALL and tried MF_DETECTION with real reader and with PM3.

mf32keys correctly recognized keys after hf mf rdbl command from PM3.

By the way, is there some limitations to store only 2 nonces, it looks like there’s enough memory to keep more AUTH requests

[iceman1001]

Since it seems like this little tidbit of information got lost.. MF_DETECTION fakes just enough of the anticollission of a Mifare Classic 1K card that the reader tries to authentice. Its not a genuine simulation of a 1K card.

If reader wants a 4K card before authenticate, mf_detection will fail.

So to me, and what I tried to change some year ago, is that MF_DETECTION shouldn't exist as a mode. The command should still be there for downloading the collected data needed for mfkey. It can easily be added to 1k/4k/4b/7B classic parts. Where it just saves the nonces..

So testing MF_DETECTION to a reader / pm3 and don't get full recognition and saying its an error, means that you don't understand what the command is doing.

[securechicken]

@iceman1001 exactly what I thought as well: this is a specialization/feature of MifareClassic app, that has to be rewritten as so (for code size's sake as well...). I am actually working on this. But I think it should still exist as a separate configuration, cause detecting needs to change the full regular Mifare simulation in order to maximize the chances of getting more nonces exchanges, and has to write into memory with a logic that is not at all compliant with a regular Mifare Classic application. Otherwise, not setting a dedicated configuration, I think this would imply missing opportunities to get nonces, and taking memory space/writing things in memory for many occasions where we do not actually need to (and as so affecting performances).

But meanwhile, MF_DETECTION is not functional, and it seems quite difficult to find good conditions to make it work actually. Which means besides memory corruptions that existed, the current MF_DETECTION may be suffering from not doing enough of Mifare Classic correct WUPA/REQA/HALT/Select kungfu to interact with most readers, anyway.

I'll probably publish a dirty "I do not need to understand anything" fix today or tomorrow (let the original code, with just a memory extension in associated config to prevent memory overwrites), to confirm "original" MF_DETECTION is working, and get working tests conditions (or find other issues). I am still working on an clean integration to MifareClassic application meanwhile.

[iceman1001]

you mean writing an offset of 4096 to get outside of the 4k slot and into the reserv space. Didn't you add 5kb for each slot now?

I would just add a write of those nonces in the normal 1k/4k modes, remove mf_detection as a mode, keep the command to download the nonces. I wouldn't try to fix MF_DETECTION to get full anticollsion etc.

[securechicken]

@iceman1001 nope, did not do this dirty "5k" fix yet, and opted to manually fix offsets in order to get them right... but still did not manage to get MF_DETECTION "work" for me or @uspilot so...

[securechicken]

@uspilot you can try my 'dirt fix_detection' branch, or PR #156 .

[uspilot]

@shinhub Tried, memory increased to 5k, MF_DETECTION mode respond to requests from reader and PM3, some nonces are widen from 4096 offset, but mfkey32 doesn't decode it.

[securechicken]

@uspilot thanks. Well then I do not understand cause apart from this memory size change, I kept the code strictly identical as original.... Need more tests, or any help : )

[uspilot]

@shinhub will try to do more tests

[uspilot]

@shinhub @iceman1001 did another test with another reader as well as PM3. I can confirm that this mfkey is works now.

[Tag slot 1]
[S1 / B6] KeyA [112233445566]
[S2 / B10] KeyB [1122334455ee]
[S5 / B23] KeyA [112233445588]
[S13 / B55] KeyB [1122334455cc]

VERSION?
101:OK WITH TEXT
ChameleonMini-rebooted v1.3 (Iceman: 3cdba8c)

[securechicken]

@uspilot cool! At least it works on "some cases", which is I guess considered "non regression" : )

I submitted another branch/PR #157 , which is a rewritten version that also fix memory issues with MF_DETECTION, aimed at consuming less memory, and being more integrated with MifareClassic application code. It would be great if you could test the exact same case and say if you get results!

[uspilot]

@shinhub ok. will try it today. btw, do we really need to encode detection data during sending them from device to computer and then decode ? it takes extra memory and makes some difficulties if we want to save more nonces (for example 50 pair or more)

[securechicken]

Yeah agree, and was wondering about that as well... I think this is to ensure the GUI is compatible with original firmware, which probably does this "encryption" thing in any case. But there might be another reason I do not know of. A way to get rid of that would be to not encrypt, but prefix our saved data with a "detection data format info" canary (in BLOCK0, where "Manufacturer Data" is supposed to be, for instance), and then the GUI would check for this canary to know if it has to decrypt. Let say our canary would be 4-bytes, and set to "DE7EC710" for instance : )

[iceman1001]

One of those strange decision DXL did when he added all this. Good thing was CRC, then encryption layer is most likely to stop competition, ie other software to work with it. Original firmware uses this encryption. GUI needs to deal with encrypted nonces or if we decide to remove it, decrypted nonces. I looked at the code, it didn't take much space. so to keep things easy, I left it. I suggest leaving it like it is. Get it to work first, then afterwards we can consider if someone is willing to change GUI and FW to support both cases.

Another solution is, we can release this as v1.4 that would be easy for the GUI to work with. all fw below v1.4 is to be considered to send encrypted nonces.

More enhancements, which would be useful, We can make the nonces memory part to be able to collect authentication tries for all sectors. The more pairs we collect the better changes of recovery.

However the normal process for a reader is to do anticollision, then authenticate a block, read block/s, write blocks (update) , and read again to verify. If first read fails, reader usually don't continue and goes back to detect card on field / anticollision phase.

So the amount of authentication tries we can collect is usually limited because of this.

I suspect that to make it more useful, is to upload found keys to correct slot, and sector trailer from GUI. And that is discussion for GUI repo. The chameleon mini device cant do much in this case.

[uspilot]

Encryption is not a big deal for 6 pair of nonces (in fact now it used just 3 pairs for key A and 3 pairs for key B, then it overwrite them).

12 nonces is limited by buffer used for encryption, CRC calculation and sending data to computer.

We have enough memory in each slot to store much more nonces (I did 50 pairs without separating into key A/B).

It possible to use the same slot (with offset, if we need raw data from reader) to store encrypted data, but this will require some changes in encryption function. CRC calculation function can also be replaced to work with stream data, not with whole buffer.

The main question is: does it really required to encrypt data or not?

For GUI it not a big deal to adapt it to work with “both” kind of nonces. We have 11 bytes in block 0 (which is not used now) to keep some extra info about transferring data.

[iceman1001]

the encryption doesn't add any value more than only software which has the decryption part can run mfkey with the collected decrypted nonces.

[uspilot]

@shinhub Unfortunately I got some problem with flashing of my device.

$ sudo dfu-programmer atxmega32a4u erase --force --debug 50
target: atxmega32a4u
chip_id: 0x2fe4
vendor_id: 0x03eb
command: erase
quiet: false
debug: 50
device_type: XMEGA
------ command specific below ------
validate: true

commands.c:87: erase 0x7FFF bytes.
Erasing flash...  Success
Checking memory from 0x0 to 0x7FFF...  Not blank at 0x1.

It seems that it cannot be rewritten via USB. I don't have AVRmkII with me and will try to recover it in two days.

So I will be able the do another tests after two-three days.

[securechicken]

@uspilot thanks, but we will not be able to consistently test and debug if you use some tuned flashing, source, and/or apps. You should use make dfu-prog only to rely on this flashing tool, and/or make UNLOCKED_F=True dfu-prog if you flashed a custom original Atmel boot loader to your ChameleonMini (or type the exact same set of commands than the ones showed in the Makefile for you situation). The memory validation error can be bypassed (and is, with our Makefile, by default), as with factory boot loader, happens all the time :)

[uspilot]

I didn't change boot loader before and used 'make dfu-prog' ,but was surprised that from some moment make dfu-prog has no error, but in fact nothing is written into device and Chameleon still working with previous firmware. Even erase command didn't clear flash memory. Device is still working . So I added --debug just to check what's happening. I will try to reflash boot loader

[securechicken]

@uspilot I would not change bootloader if you do not absolutely need to, because factory ChameleonMini is not supposed to have its boot loader changed, and the tools we have are supposed to work with it. I did just to check the source code we managed to find compiled and flashed correctly. If you are not sure of how much you may have messed with your device, you may however flash the factory firmware again, to start fresh. Maybe the --force --suppress-validation combo on flashing in Makefile might sometimes unfortunately hide errors.

Anyway, I finished the cleaner implementation of MF_DETECTION (PR #157 ), that is fully integrated within MifareClassic application (no additional code), fix the bug you initially identified, and is not encrypting the result. I also submitted a rebootedGUI patch to allow it working with unencrypted result for DETECTION command. I had good results with them, mainly testing them with an idle Android MCT contact. Mfkey managed to find a default key MCT seems to be using to read S0/B0 when it cannot deal with the tag.

[iceman1001]

Excellent fixes @shinhub , I gave some comment in the GUI PR. Minor thing, after that we can merge :)