[BUG] Active slot out of limit -> ChameleonMini is locked

[uspilot]

I have device not working after use it in MF_DETECTION mode.

After changing slots several time with button, I got ChameleonMini not working, cannot change slot anymore nor connect to ChameleonMini-GUI. The only way to get it back is to flash it again.

I had this issue twice with the same result, but cannot catch exact condition for that and can't reproduce this intentionally.

--> SPI_FLASHINFO
101:OK WITH TEXT
Manufacturer ID: 1f
Family code: 1
Density code: 4
MLC Code: 0
Product version: 0
Flash memory size: 4Mbits (512KBytes)

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

--> CONFIG
101:OK WITH TEXT
CLOSED,MF_ULTRALIGHT,MF_ULTRALIGHT_EV1_80B,MF_ULTRALIGHT_EV1_164B,MF_CLASSIC_1K,MF_CLASSIC_4K,MF_DETECTION

Here is some logs from GUI:

System.ArgumentOutOfRangeException: Value StartIndex cannot be less than zero.
Parameter name: startIndex
   in System.String.Substring(Int32 startIndex, Int32 length)
   in ChameleonMiniGUI.frm_main.SaveActiveSlot()
   in ChameleonMiniGUI.frm_main.RefreshSlot(Int32 slotIndex)
   in ChameleonMiniGUI.frm_main.RefreshAllSlots()
   in ChameleonMiniGUI.frm_main.DeviceConnected()
   in ChameleonMiniGUI.frm_main.frm_main_Load(Object sender, EventArgs e)
   in System.Windows.Forms.Form.OnLoad(EventArgs e)
   in System.Windows.Forms.Form.OnCreateControl()
   in System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   in System.Windows.Forms.Control.CreateControl()
   in System.Windows.Forms.Control.WmShowWindow(Message& m)
   in System.Windows.Forms.Control.WndProc(Message& m)
   in System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   in System.Windows.Forms.Form.WmShowWindow(Message& m)
   in System.Windows.Forms.Form.WndProc(Message& m)
   in System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   in System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   in System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

[securechicken]

Thanks for the report. We would welcome any more logs, comments, and or details on same issue to try to narrow it to something we can reproduce. Did never have such an issue. Which GUI do you use?

[uspilot]

Chameleon Mini GUI v1.2.0.19 Iceman Edition

But it seems like the problem is with Firmware, because it’s not possible to anything with device even using buttons.

I will try to reproduce it, but I’ve no idea right now how to do that

[iceman1001]

something about the active slot selection (ie the green border thingy) that seems to have gone nuts,.

[uspilot]

I've got some new inform,ation about this issue. First of all, this issue is exactly with firmware and GUI crash is just in consequence of primary fault in ChameleonMini firmware. ChameleonMini still working in fact but with some exceptions.

1. GUI crashes due to in SaveActiveSlot() function because there's no response from ChameleonMini device. I'll do a PR for that today later, it's not a big deal:

       // return false if empty answer or set default value (ex. 0)
       if (actSetting.Length <= 0) return false;// or actSetting = "NO.0";

2. The reason for no response is that there's some issue with COM port after trying to change active slot. I got my ChameleonMini device in strange mode again, recompile GUI with some changes and have some logs from it. I have one slot (slot 0 now, but each time it could be different) that has something wrong inside it.I can do everything woth any other slots except this one. Ones I try to set this slot as active I have my device disconnected (but if fact I have it in device list in Windows and device info show that it's working). I still have COM port, but cannot conect to it. I have to disconnect ChameleonMini from USB and reconnect it again to be able to communicate with them.

[***] COM4 - USB\VID_03EB&PID_2044\437533136353FFFF60FF9000E000
[=] Connecting to LUFA CDC-ACM Virtual Serial Port (COM4) at COM4
[+] Success, found Chameleon Mini device on 'COM4' with Firmware RevE rebooted installed

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

--> SETTING=0

[!] Присоединенное к системе устройство не работает.

[!] Операция ввода/вывода была прервана из-за завершения потока команд или по запросу приложения.

[***] COM4 - USB\VID_03EB&PID_2044\437533136353FFFF60FF9000E000
[=] Connecting to LUFA CDC-ACM Virtual Serial Port (COM4) at COM4
[!] Failed COM4
[***] COM1 - ACPI\PNP0501\1
[=] Connecting to Последовательный порт (COM1) at COM1
Didn't find a Chameleon on 'COM1'
[***] COM4 - USB\VID_03EB&PID_2044\437533136353FFFF60FF9000E000
[=] Connecting to LUFA CDC-ACM Virtual Serial Port (COM4) at COM4
[!] Failed COM4
Didn't find any Chameleon Mini device connected

--> SETTING=1
1
--> SETTING=2
1
--> SETTING=3
1
--> SETTING=4
1
--> SETTING=5
1
--> SETTING=6
00:OK

--> SETTING=6
1
--> SETTING=7
1
--> SETTING=7
1
--> SETTING=7
00:OK

--> SETTING=0

I also found out that Slot 1 has strange dump (it was cleared initially). This is the first several blocks:

--> setting=1
1
--> DOWNLOAD
110:WAITING FOR XMODEM

60 14 50 2d 09 6d 48 d0 27 d1 ed bb 3e a6 5c f5 
60 3c 1a 80 1e 48 1b 2d 6c 71 66 66 2a 70 f1 42 
60 14 50 2d 4f af 71 71 dd 70 ed 0a 3a 80 ef 90 
60 3c 1a 80 d1 3a be 03 9c 4c 37 63 4e 8f 37 d2 
60 14 50 2d f0 21 e9 b1 ee 95 eb d3 d2 eb d5 ee 
60 3c 1a 80 b7 8c cb d8 ab eb 02 86 12 d3 af ab 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

I noticed this issue before. After using MF_DETECT on several slots I've got UID changed on 4 of 8 slots. I didn't check dump those time, but UID seemed to be the same like in this dump.

[iceman1001]

Are you on the latest source code from this repo? compiled / flashed when this happens?

[uspilot]

Now I have: ChameleonMini-rebooted v1.3 (Iceman: 7420671)

First time it happened with one of previous firmware

[iceman1001]

ok, so now you have latest, and this is happening on it? Just to be clear.

[uspilot]

Exactly. I set all slots to MF_DETECT, button to change slot and just pressed buttons several time, separately and together with different interval.

I can’t say exact algorithm of pressing to get this fault.

Now I keep device in this condition to do some other actions with it if required.

[iceman1001]

you press button on the device while in GUI?

[uspilot]

No, in standalone mode. I got this with and without reader, so it doesn’t depend on reader’s signal.

Now one slot is blocked and cannot be selected from GUI or from device by button.

[iceman1001]

Standalone mode?
But how are you getting the serial textoutput if you are not connected with the computer?

[uspilot]

After getting this issue I connected ChameleonMini to modified version of GUI that allow me to connect device use SERIAL mode and all other functions.

[iceman1001]

Hard to help someone who is inconsistent in the bug report with documenting down the exact behavior to trigger the bug.

[uspilot]

It very hard to describe the bag when it’s not possible to catch the condition which cause that bug

[iceman1001]

Well, the GUI got a fix. Until someone else triggers this bug, I am afraid there is not much we can do

[bogiton]

For some reason, I also got my Chameleon to stop responding after using the latest firmware. At first I thought that the battery has gone bad. But even after replacing it the device was not powering up, so I had to reflash it. It is definitely not (only) a GUI bug since it happened to me without using the GUI.

[iceman1001]

OK, bug confirmed but unidentified.

[securechicken]

@bogiton, @iceman1001 , @uspilot did catch a one like this as well. At some point with no clear reason, and several times, the ChameleonMini got stuck on one particular slot and I cannot switch slot or connect it to GUI or serial term anymore. I however am still able to have the slot (MF classic simulation) read by a reader... meaning the application and memory are still working. I am thinking of a loop somewhere (buttons ? LEDs ? even application - but seems to appear on different ones so probably not), but cannot see where as I cannot even reproduce bug in a deterministic fashion.

[iceman1001]

With @shinhub latest pr's (excellent work!) lets see if this kinds of bugs still appear

[securechicken]

@iceman1001 well thanks, but would not close this while not confirmed, as I am sure it happens sometimes. I have seen that quite a really few times, and once with my memory rework as well. I think I might have fixed it with last commit, by completing the "CLEAR" command actions, but not sure.

I am now thinking the bug might be due to conflicting BUTTON actions, leaving slot stuck, or to a slot that cannot move to a recently "CLOSED" config that in fact has been changed to a non-CLOSED one since (this would be due to an out of sync situation between configurations in PROGMEM and RAM).

[securechicken]

@uspilot , @bogiton : is this still happening? It does not for me, and only appeared 2 or 3 times in a year anyway...

[uspilot]

Didn't tried hard testing for this bug last time, but probably this bug is connected with memory allocation issue from #151 ?

[securechicken]

@uspilot not. Slots switching, config, buttons and LEDs have absolutely nothing to do with "MF_DETECTION" application memory management. Memory chips where associated "bytes" are stored are even separate ones.

So is this still happening? What are the required steps to reproduce?

[securechicken]

I suspect there might have been a conflicting state between GUI and firmware both setting BUTTONs with their own logic, before GUI was fixed, while I was implementing consistent reset for slots in firmware but set both default buttons actions to "CLOSED". This might have resulted in all buttons set to CLOSED for an active slot, but with GUI showing otherwise, and as so... well the slot was stuck when pressing any button then. The GUI is now fixed and sets/shows correct BUTTON config, while the firmware does not set both defaults as "CLOSED", so this should never happen again, even with older GUI.