If the fob you’re copying from is using the standard key, all you should need to do is have the existing fob on the hf antenna and then run:
hf iclass rdbl -b 7 --ki 0
Then take the valid fob off the proxmark and put the writable fob/card on and run:
hf iclass wrbl -b 7 -d XXXXXXXXXXXXXXXX --ki 0
Replace the Xs with the 8 bytes (16 hex symbols) that the proxmark3 output when you ran the rdbl command.
That should be it (assuming they’re not using non-standard ‘high security’ keys or something else going on).
Here is a list (incomplete and made very quickly) of posts that contain useful iClass information. I suggest you read each carefully as the next steps for standard and more involved iClass cloning have been covered elsewhere:
I understand there is a steep learning curve with some of this but you just blatantly ignored my suggestion to carefully read other posts so you could help yourself…I even gave you some of the most useful posts to get you started.
I’m not your mother, it’s not my job to spoon feed you.
TL;DR - You’ve got the wrong kind of blanks.
Please learn to search the forum rather than asking questions that have already been answered.
There’s your issue. You need a blank PicoPass 2k card in order to properly clone. T5577 is an LF card. Generally the gold standard for blank 2k cards is RedTeamTools, but they are currently out of stock. I’m on their notification list for when it’s back in stock. They’ve been out of stock for a while, I might make a post when they are FINALLY back. In the meantime, eBay is your best (albeit overpriced) option.
These will probably do the trick, but no guarantees:
Generally speaking yes… clone means ID and memory blocks… however… the functional meaning is to simply enable the target chip to function like the source chip with the intended application… and in this case, the iClass legacy system ignores the UID completely and only cares about the content of a few memory blocks… therefore cloning a source iClass chip to another target chip just requires copying those memory blocks, ignoring the UID.
so block 7 should not be THAT value…unless the proverbial stars have aligned. THAT value belongs to another name that you are aware of. That value will be xor’d with you CSN from block 1 in order to authenticate you credential. then the other data blocks (or in this case, block 7 alone) will be checked against the database to approve or deny the check. Does that make sense?