Now in the table in the “blk” column I have 0,0,1,1,2,2 etc. basically every entry is duplicated. One of the entries says (fail) Key B the other entry is (ok).
I’m guessing it just retried and wrote it successfully?
But entries 16 through 59 give me an “Auth error” still.
The console suggested to me I should try ‘hf mf dump --ns’ and I did it with the original tag and also with my newly written tag. The data looks the same. Does it mean it actually succeeded?
I don’t think it did because after issuing “hf search” the original tag has an additional category being displayed which is:
— Tag Signature
IC signature public key name: PLACEHOLDER1
IC signature public key value: PLACEHOLDER2
Elliptic curve parameters: PLACEHOLDER3
TAG IC signature: PLACEHOLDER4
Signature verification: successful
After issuing “hf search” on the cloned tag it has the same UID but it doesn’t have this “Tag signature” category. How do I clone that over?
Whenever I do “hf search” on the original tag it shows a SAK: 08 [2]
after doing “hf mf autopwn” on the original tag and opening the dump.json file the SAK says 88.
Also after issuing "hf mf gen3blk -d NUMBER it executes successfully but doesn’t write the NUMBER 1:1. it differs with 1 digit and it’s the 0 instead of an 8. It just ignores the command without throwing an error?
i wouldn’t bother cloning the sig it’s likely not even checked (very common to not check.) and i’m currently fuzzy if gen3s are even capable of sig emulation.
do data diff -a original.bin -b clone.bin substituting original & clone for the correct file names, the differ will tell you if the files have any incosistencies you need to change, if there are you can easily do so with hf mf wrbl
keep it at 08 unless you find the necessity to change it to 88 after testing your clone against the system.
if it rejects your 1:1 clone (sans SAK being different in b0) you’ll need to sniff the comms between emulated card & reader to see what’s going on under the hood.
IF you need to do that, instructions below
hf mf eload -f original.bin
hf mf sim --1k -u UID
present the proxmark (still plugged in) to the reader, it should beep with some acknowledgement positive or negative, press the button to end the sim and then run hf mf list
this will produce the trace decoded in a mifare classic context where we will be able to look at what’s going on.
for easier access, save the trace with trace save -f pickaname and send it here for evaluation
All right I’ll try without the actual sig but do you have any idea about the SAK thing? Why does it show 08 with ‘hf search’ and the .json file says 88?
I think that’s why I can’t write block 0 to the number I want since it just writes it with only 1 mistake (0 instead of 8).
if you were to try it with changing the whole block 0 to something else (still a valid block 0 for a 7b card, do NOT just type random stuff) using gen3blk does it take affect?
Gen3s are tricky, it could be just write prevention on those bits specifically to prevent you writing data that could potentially cause identification issues.
gen3blk should be able to overwrite block0 so i’m curious as to why it isn’t tbh
oh yeah that should be no problem. the proxmark3 easy is a very capable device.
if the scale of your laptop is a problem you can use an android phone with an OTG (on the go) cable connecting your proxmark to your phone using the termux app. there is more info on that on the Proxmark Repo under termux
Yes it definitely does take effect. Everything changed except for 1 byte which is weird since this command is not dependent on any dump and I just want to change that block 0.
Here’s what I mean cause I think it’s not clear haha:
Lets say 1111111111 were a valid block 0 and the default one of the gen3 magic card.
Lets say 1234887890 were the valid block 0 of the original card.
After typing ’ hf mf gen3blk -d 1234887890’ it says that it successfully wrote the block but it wrote 1234087890 instead of 1234887890.
(I know that block 0 is longer and those might not be valid values but this is just for illustration purposes to get my point across what I mean)
So basically it writes everything except for just that one byte. I guess now its more understandable what I mean. Sorry for the confusion.
oh yah then it’s just enforcing security on the SAK to force it to remain as 08.
it shouldn’t be much of an issue unless a block0 check is sent by the reader to validate it but that’s neither here nor there till we know what’s actually happening with the reader.
excited to find out whether or not your clone card works as intended! fingers crossed all goes well!
