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.
So, correct me if I get the terminology wrong but shouldn’t “clone” mean that also the UID is copied over the blank?
Just copying the content of the blocks would be a dump.
BTW @vniux those cards aren’t the same type as the Iclass, not even the same size.
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.
you’re getting a successful dump with --ki 0 as well as as wrbl…which means you’re credential is using that key!
–ki 0
in your post about
hf ioclas wrbl -b blah blah blah…
you siad it was unsuccessful…but never said why or how you determined that? the post didn’t show a rdbl comman showing diff values?
what makes you think it didn’t work?
what does
hf ic rdb l -b 7 --ki 0 give you?
AND now that I think about it…why are you writing THAT value to block 7??? I’ve never seen THAT used THERE???
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?