Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

hf mf csetuid #35

Closed
iceman1001 opened this issue Dec 26, 2014 · 3 comments
Closed

hf mf csetuid #35

iceman1001 opened this issue Dec 26, 2014 · 3 comments

Comments

@iceman1001
Copy link
Member

For a long while my "hf mf csetuid" has been all but reliable.
With Piwi's changes to iso14443a_select_card, I was told about the critical timings which are now in order.
I also noticed some entries on the forum asking about the magic cards not working.
When I commented out some "spindelays" here, https://github.com/Proxmark/proxmark3/blob/master/armsrc/mifarecmd.c#L906 , I got my "hf mf csetuid" to work without a problem.

I suspect this is the problem with the other magic-chines commands too.

I suggest the patch to comment out row 906 to 909.

Please review and come back with feedback.
@iceman1001
Copy link
Member Author

the second place to comment out is rows 1032-1035.

iceman1001 added a commit to iceman1001/proxmark3 that referenced this issue Dec 26, 2014
@iceman1001
ADD: marshmellows new lf command and DetectClock. (works great!)
1b492a9 
FIX: a suggested patch for "hf mf csetuid" (Proxmark#35)
FIX: fixed a bug in iso14443a_select_card where the len variable wasnt set,  this made desfire/magic cards not work.
@iceman1001
Copy link
Member Author

If someelse than me can verify that with the following patch to this issue "hf mf csetuid" working. It works for me but it would be nice to have it a bit more tested.

If ok, then this issue can be closed.

commit: 3fe4ff4

@iceman1001
Copy link
Member Author

However I noticed something yesterday again.. And read about it on the forum in some thread a year back. http://www.proxmark.org/forum/viewtopic.php?pid=7883#p7883

It is the default behavior of this commad, "hf mf csetuid" which is to change the uid on a magic s50 tag. There is two behaviors which I want to change. Internally the "csetuid" issues a "hf mf csetblk" command with a block 0 with new UID and SAK&ATAQ,

A) When you use the command, it resets not only the uid in Block0, but it also clears the rest of the block0 with zeros. It makes your cloned copy not an exact copy anymore.

B) The bytes[5-6-7] in Block 0 on a magic tag is the ATAQ & SAK. The normal behavior of the command is to set it to "88 00 04" as default SAK & ATAQ... Which also makes your cloned copy not an exact copy anymore.

Suggested solutions.
A) issue a readblock 0, before and copy bytes 8-16 to the new bytearray. This leaves your block0 intact and just changes the UID. I have implemented this solution.

B) make the SAK & ATAQ optional from command line. Which allows for it easy to make the magic card identify itself as different kinds of tags.

Is this of interest for the community? Feedback on this?

@iceman1001 iceman1001 mentioned this issue Feb 10, 2015
Merged
andylovesnz added a commit to andylovesnz/andy_emv that referenced this issue Jun 2, 2021
@andylovesnz
SUGGESTED FIX:
45363a6 
Issue: Proxmark/proxmark3#35
Forum:  http://www.proxmark.org/forum/viewtopic.php?pid=7883#p7883

Where "hf mf csetuid"  empties the rest of the block0 bytes.
This fix loads the old block0 and replaces the uid+sak+ataq bytes only.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@iceman1001