[BUG] Chamaleon stop working after some slot data manipulation

[BreakSecurity]

Environment

Item	Your information
Harware	RevE Rebooted
Firmware	ChameleonMini-rebooted v1.3 (Iceman: f463cd6)
GUI	https://github.com/iceman1001/ChameleonMini-rebootedGUI (last version)
Slot number	Every slots
Slot configuration	MF_ULTRALIGHT_EV1_80B
Dump source	Regular dump done with proxmark 3 RDV4.0 hf mfu dump
Reader	Nexus 5 phone
Flashing environment	Windows 10
Flashing method	flash.bat
Flash memory space	80
Makefile configuration	N/A

Bug description

Expected function and references

After dump upload if I try to change sector 0x09 to all zeros Chamaleon freeze after some reads of the modified slot. No led light and the only possible solution is to reflash. Page 0x09 is locked but chamaleon let you wrote on it anyway.

Steps to Reproduce

1.1 Select any slot
1.2. Click on 'Upload Dump'
1.3. Select the attached dump (json listed below)
2.1. Modify the 0x09 page with all zeros
2.2 Try to read the card a bounch of time.
2.3  Enjoy your dead Chamaleon

Resolution paths

Ideas

Possible Implementation

Something to do with lock bytes maybe... https://github.com/iceman1001/ChameleonMini-rebooted/blob/d044bb42241720f21e59690b012056fd4140109a/Firmware/ChameleonMini/Application/MifareUltralight.c#L200

Json:

{
  "Created": "proxmark3",
  "FileType": "mfu",
  "Card": {
    "UID": "04481AD2A05E85",
    "Version": "0004030101000B03",
    "TBO_0": "0000",
    "TBO_1": "00",
    "Signature": "B44E1D9A80C825E1F7AE32506848DC6C10CE7F5DFA835158D52B1A0B7C4ED470",
    "Counter0": "000000",
    "Tearing0": "BD",
    "Counter1": "000000",
    "Tearing1": "BD",
    "Counter2": "000000",
    "Tearing2": "BD"
  },
  "blocks": {
    "0": "04481ADE",
    "1": "D2A05E85",
    "2": "A948F203",
    "3": "7FFFFFFE",
    "4": "01030000",
    "5": "0101012E",
    "6": "76B7A400",
    "7": "00AE10A8",
    "8": "13015C46",
    "9": "84AABA40",
    "10": "00000000",
    "11": "00000000",
    "12": "00000000",
    "13": "00000000",
    "14": "00000000",
    "15": "00020000",
    "16": "000000FF",
    "17": "00050000",
    "18": "00000000",
    "19": "00000000"
  }
}

[securechicken]

Hi there, I am not sure how you did "2.1. Modify the 0x09 page with all zeros"? Could you explain this please?

[BreakSecurity]

I loaded the JSON dump, read the emulated tag through the app UltraManager Pro on a Nexus 5 phone, and write all zeros to page 09 (that is locked by bytes in page 02). The write is successful because if I read the tag again I see all zeros on page 09. After some readout of the emulated tag, the led stop working and the chameleon is dead. I was able to solve only by flashing again.

[securechicken]

So there are two things as I see it: 1) you are surprised to see that locked pages can be zeroed, 2) you manage to trigger a chameleon hangout when you read ULTRALIGHT_EV1_80B dumps.

1) This may be wanted in fact. Do not know anything about Ultralight, but maybe @McEloff can help, as he patched Ultralight code precisely so we can zero locked pages in #142 (see this diff).

2) This will have to be narrowed down. There is a memory management issue with Ultralight as it is now, because it tries to write data out of bound (to store a "password", but this should not break the whole Chameleon. Can you try again to trigger this bug, and help us finding out how it is triggered (does that also happens with other configs, other Ultralight dumps, is this on any reading sequence or on specific reading contexts, etc.) ?

[McEloff]

Hi! Commit #142 fixes only manipulations with pages 2 and 3 of Ultralight. Lock-bits (page 2) and OTP-bits (page 3) cannot be resets to zero if was sets previously. For example, if page 3 = 0x0007 and you try to write to page 3 value of 0x0008, result will be as "logical bitwise OR" = 0x000F. For lock-bits (page 2) so on. My commit not fixes write access to pages locked by lock-bits in page 2.

[securechicken]

Closed due to lack of feedback.