Closed spp2000 closed 10 months ago
done :)
Ok @doegox, thanks! now in the CLI I see both the nick and the ID/UID. I have another proposal :D at least for LF. I try to explain:
If I load a saved LF card to a slot, the nick automatically updates with the ID (the nick equals the stored ID).
If, instead, I clone an LF card to a slot, the nick remains the one previously stored in that slot, while the ID is the one just cloned. IMHO there's no need to preserve that nick; the clone function could update the nick too with the ID just cloned, so there will be more consistency.
PS: for HF (Mifare) I have still not understood how to consider a slot that could have an UID different from the one present in the block 0 of that slot and if this "inconsistency" could have a real application
I would avoid putting automatically UIDs in nicknames. Ppl will mix them and think they can change a nickname to change the UID... But we can change/add a nickname when cloning, into something like "cloned", so ppl know where its data comes from. (and there is no problem having several identical nicknames)
But we can change/add a nickname when cloning, into something like "cloned", so ppl know where its data comes from. (and there is no problem having several identical nicknames)
OK, this could be fine too. The important thing imho is to change the previous nick to avoid confusion. Thanks
done :)
In the slot list it appears only the nick of a slot without any info about the corresponding ID/UID. By knowing the ID/UID too, the user should have a better awareness of what's inside a slot (=what Chameleon emulates), expecially after using the "clone UID" function associated with the hardware buttons.