Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Mifare Classic Tool (MCT) - An Android NFC-App for reading, writing, analyzing, etc. Mifare Classic RFID-Tags.
Features are:
* Read MIFARE Classic tags
* Save, edit and share the tag data you read
* Write to MIFARE Classic tags (block-wise)
* Clone MIFARE Classic tags
(Write dump of a tag to another tag; write 'dump-wise')
* Key management based on dictionary-attack
(Write the keys you know in a file (dictionary).
MCT will try to authenticate with these
keys against all sectors and read as much as possible.
See chapter [Getting Started](#getting-started).)
* Format a tag back to the factory/delivery state
* Write the manufacturer block of special MIFARE Classic tags
* Use external NFC readers like ACR 122U
(See the [Help & Info section](https://publications.icaria.de/mct/help-and-info/#external_nfc)
for more information.)
* Create, edit, save and share key files (dictionaries)
* Decode & Encode MIFARE Classic Value Blocks
* Decode & Encode MIFARE Classic Access Conditions
* Compare dumps (Diff Tool)
* Display generic tag information
* Display the tag data as highlighted hex
* Display the tag data as 7-Bit US-ASCII
* Display the MIFARE Classic Access Conditions as a table
* Display MIFARE Classic Value Blocks as integer
* Calcualate the BCC
* Quick UID clone feature
* Import/export to common file types
* In-App (offline) help and information
* It's free software (open source). ;)
(The feature list might be out of date. Check the readme and changelog on Github.
Some general information:
This tool provides several features to interact with (and only with)
Mifare Classic RFID-Tags. It is designed for users who are at least a
bit familiar with the Mifare Classic technology. You also need an understanding
of the hexadecimal number system, because all data input and output is in hexadecimal.
Some important thing are:
* The features this tool provides are really basic. There are no such fancy
things like saving an URL to a RFID-Tag with a nice looking graphical
user interface. If you want so save things on a tag, you have to input the raw
hexadecimal data.
* This App can not crack/hack any Mifare Classic keys. If you want to
read/write a RFID-Tag, you first need keys for this specific tag.
* There will be no "brute-force" attack possibility in this application.
It is way to slow due to the protocol.
* The first block of the first sector of an original Mifare Classic tag is read-only i.e. not writable.
But there are special Mifare Classic tags that support writing to the manufacturer block with a
simple write command. This App is able to write to such tags and can therefore create fully correct clones.
However, some special tags require a special command sequence to put them into the state where writing
to the manufacturer block is possible. These tags will not work.
Remember this when you are shopping for special tags!
* This app will work only on NFC enabled phones with a NXP NFC controller. Controllers of other
manufacturers (like Broadcom) have no Mifare Classic support. Please see:
https://github.com/ikarus23/MifareClassicTool/issues/1
* MifareClassicTool on Google Play
* MifareClassicTool (Donate Version) on Google Play
* MifareClassicTool on F-Droid
* Download MifareClassicTool (APK file)
* Screenshots (outdated, check Google Play)
* Project Page on github (source code, more information like "Getting Started", etc.)
* Additional stuff (Documentation, etc.)
* Donate with PayPal
Last edited by ikarus (2020-09-01 19:33:43)
Offline
Looks good ikarus! Open source too. Two thumbs up
This tool provides several features to interact with (and only with) Mifare Classic RFID-Tags
Why not EV1, DESFire...? I understand that time would be better spent on refining the application but why limit yourself to Mifare Classic only?
Offline
@ 0xFFFF
Looks good ikarus! Open source too. Two thumbs up
Thx!
Why not EV1, DESFire...? I understand that time would be better spent on refining the application but why limit yourself to Mifare Classic only?
Yeah you are right. Until now I'm not familiar enough with these techniques. But maybe I will be someday and then I implemet this stuff too
Unfortunately the code base is not that generic at this time. So there will be a lot of rewriting...
Kind regards
Ikarus
Offline
Great good job!
Offline
Cool!
Offline
Hi there.
App works great, but i have a question.
Why it is not possible to write a copy of tag to another not factory formatted tag?
I dont want to write data to each block and sector separately, but done it quickly just by choosing a clone tag dump file and overwriting data from other tag. I've got keys A and B to the tags.
Maybe there is a diferent app doing such things?
Offline
@katakini
Hi, you are absolutely right. Writing full dumps using known keys is right on top of my personal ToDo-list
But I can't say how long it will take. I'm a little bit busy right now...
Kind regards
Ikarus
Last edited by ikarus (2013-02-18 20:39:34)
Offline
Thx so much for replying and your great job:-)
Looking forward for your updates:-)
Would like to help but I know nothing about making apps:/
Offline
Nice job
Offline
Thx for positive feedback!
The new version (1.1.0) is out now!
(See: original post, updated)
As katakini requested the new version can now write a dump to any Mifare Classic Tag for
which you know the keys. Of course you need the keys with write privileges for all sectors of the dump.
If the dump consists of e.g. 5 sectors you only need the keys for these 5 sectors. If you don't know
the keys for all the sectors, the App will try to write as much as possible.
After selecting the dump and the key files the App will check everything for you!
If there are issues like 'block is read-only', 'key with write access not known', etc., you will
get a report (screenshot) before writing!
I hope this works for everybody. If not, please say so!
Due to a lack of some hardware (a Mifare Classic 4k tag),
I was not able to test this feature in every single detail.
Kind regards
ikarus
Offline
...And another release (version 1.1.1) with some minor bug fixes.
Kind regards
ikarus
Offline
Good Job!!!!
It did not work on the Nexus 4 (4.2.2).
"No Mifare Support"
"There is no Mifare support on your device.You need Mifare support in order to run this APP".
???
Offline
Thanks a lot!! Good job!!!!
Offline
It did not work on the Nexus 4 (4.2.2).
As far as i know the Nexus 4 has no mifare classic support! Sorry.
Please take a look at this: https://github.com/ikarus23/MifareClassicTool/issues/1
Kind regards
ikarus
Offline
As far as i know the Nexus 4 has no mifare classic support! Sorry.
Thank you very much.
Offline
I used a app called "NFC Taginfo" to detect my card.
It can show me the UID and tag type "Mafire Classic 1K/Mifare Plus 2K SL1".
How to explain it?
Offline
nexus 4 has nfc
the problem is the way the internal scard directory is loaded.
they have change the route to the internal scard.
Offline
I used a app called "NFC Taginfo" to detect my card.
It can show me the UID and tag type "Mafire Classic 1K/Mifare Plus 2K SL1".How to explain it?
There is a YouTube video explaining "everything".
the problem is the way the internal scard directory is loaded.
There is nothing about the way the internal scard directory is loaded in the video
or on the websites I saw. It seems to be just a hardware problem...
Or am I wrong?
Kind regards
ikarus
Offline
You werw right.
I have tried with a nexus4. And this happend.
But it's strange because android sdk has the same api or they have made a new api for this drivers?
Android have changed something in the sdk?
Offline
Mifare Classic is a proprietary protocol from NXP. Most phones today use an NXP chip for NFC, which can also read Mifare Classic.
Nexus 4, Nexus 10 and probably also HTC one use a Broadcom chip instead, which only supports the standardized protocols and not the proprietary Mifare Classic.
Offline
New release (version 1.1.2)
(See: original post, updated)
Kind regards
ikarus
Offline
Hello,
Please tell me why Samsung Galaxy Mini 2 (ST-6500) say to me "No Mifare Support"? Is it hardware or software issue?
Another application like Mifare Doctor Professional works but in very inconvenient manner (strange GUI etc)
Many of application even from NXP (Mifare producer) works wihout problem
Maybe it's nfc check routine (hardware supported but your software deny access? maybe newer chip revision or something - i don't know
Anyway thanks for great app and some info about my above questions
PS. If ST-6500 (SGM2) realy have unsupported piece of nfc/mifare hardware please tell me which device (phone or detailed nfc chipset) is fully compatible with MCT
Many thanks
Michal, Poland
Offline
Hi,
on some devices the "No Mifare Classic Support" dialog is a false positive!
In your case it most likely is. I'm working on a solution to fix this problem.
Please read the comments on this: https://github.com/ikarus23/MifareClassicTool/issues/3
Kind regards
ikarus
PS: The "Galaxy Nexus", the "Nexus S" and the "Nexus 7" work fine with MCT as far as I know.
Offline
The "Galaxy Nexus", the "Nexus S" and the "Nexus 7" work fine with MCT as far as I know.
The Galaxy S3 work fine with MCT.By the way,I like your app very much.The UI is very cool!
Offline
New release (version 1.2.0)
(See: original post, updated)
Added a new feature to display generic tag information (screenshot)
The false positive "No Mifare Classic support" messages on some devices is now fixed too.
Kind regards
ikarus
Offline
Hi ikarus and thank you really much for your software !
Looking at your great programming skills can I ask you to add a more specific correlation between manufacturers and ATQA/SAK anticollision answers following this list:
NXP MIFARE Mini 00 04 09
MIFARE Classic 1K 00 04 08
MIFARE Classic 4K 00 02 18
MIFARE Ultralight 00 44 00
MIFARE DESFire 03 44 20 06 75 77 81 02 80
MIFARE DESFire EV1 03 44 20 06 75 77 81 02 80
JCOP31 03 04 28 38 77 b1 4a 43 4f 50 33 31
JCOP31 v2.4.1 00 48 20 78 77 b1 02 4a 43 4f 50 76 32 34 31
JCOP41 v2.2 00 48 20 38 33 b1 4a 43 4f 50 34 31 56 32 32
JCOP41 v2.3.1 00 04 28 38 33 b1 4a 43 4f 50 34 31 56 32 33 31
Infineon MIFARE Classic 1K 00 04 88
Gemplus MPCOS 00 02 98
Innovision R&T Jewel 0C 00
Nokia MIFARE Classic 4k - emulated (6212 Classic) 00 02 38 4 bytes
MIFARE Classic 4k - emulated (6131 NFC) 00 08 38
you can find further (better!) information on this page.
In particular, if you decide to add this "feature", you should write "manufacturer info can be wrong if more than one target are in the field" (read the above page to know why).
Thank you again and GREAT JOB MAN !
EDIT: SAK must be 1byte (hex) so, in you picture, 136(Dec) should be 88(Hex) so ATQA+SAK = 00 04 88 = Infineon MIFARE Classic 1k
Last edited by asper (2013-04-08 18:30:44)
Offline
Thanks asper!
I will implement this feature as soon as possible (maybe tomorow ).
EDIT: SAK must be 1byte (hex) so, in you picture, 136(Dec) should be 88(Hex) so ATQA+SAK = 00 04 88 = Infineon MIFARE Classic 1k
You are absolutely right. It makes no sense to display the SAK as dec. I will fix that too.
"manufacturer info can be wrong if more than one target are in the field"
Yeah, "bad" things happen on collision. E.g. Android can't tell if the discovered tag supports Mifare Classic
(due to the corrupted ATQA, I think). Therefore, if you place 2 MF Classic tags in your reader field,
the App will display a false positive message saying "No Mifare Classic Support"....
Kind regard
ikarus
Offline
I can only thank you again for you efforts in making such a good application !
I have further information I would like to share and maybe implement in your software (ex. other manufacturer specific codes) but, if you agree, I prefere to explain you them before; do you have a contact (mail/network/irc) ?
Last edited by asper (2013-04-08 20:45:18)
Offline
I also want to say big THANKS to You, ikarus
1.2.0 works perfectly on my Samsung Galaxy Mini 2 (S6500)
Can you add in future possibility to write specific sector from dump? Ex. i have full dump but i want to "clone" only sector 4,12 and 15 (rest are skipped even when it have some data)?
Anyway - great job!
Regards
Michal
Offline
And how about support for writing "RAW" dump (generated from other software like libnfc - 4096 bytes dumps)?
"Converting" existing tags dumps from "RAW" to MCT format isn't very big problem, but this will be nice & useful feature
Michal
Offline
Hi,
Thanks for the nice feature requests.
Can you add in future possibility to write specific sector from dump? Ex. i have full dump but i want to "clone" only sector 4,12 and 15 (rest are skipped even when it have some data)?
Sounds interesting. I will put that on my TODO list
And how about support for writing "RAW" dump (generated from other software like libnfc - 4096 bytes dumps)?
I would prefer the approach to write two convert scripts. One to convert MCT-dump to RAW and another to
convert RAW to MCT-dump. There is already a [] to add them.
If this is ok for you, I will put that on my TODO list too.
Kind regards
ikaurs
Last edited by ikarus (2013-04-12 12:33:38)
Offline
@asper
do you have a contact (mail/network/irc) ?
Just use the git author email from "git log"
Offline
Hi,
Thanks for the nice feature requests.
national wrote:Can you add in future possibility to write specific sector from dump? Ex. i have full dump but i want to "clone" only sector 4,12 and 15 (rest are skipped even when it have some data)?
Sounds interesting. I will put that on my TODO list
national wrote:And how about support for writing "RAW" dump (generated from other software like libnfc - 4096 bytes dumps)?
I would prefer the approach to write two convert scripts. One to convert MCT-dump to RAW and another to
convert RAW to MCT-dump. There is already a [] to add them.
If this is ok for you, I will put that on my TODO list too.Kind regards
ikaurs
It's a very good idea to make mentioned "convert" scripts - for me it's ideal because it's onetime job for my purposes (convert near around 100 existing dumps to MCT format)
Another interesting (from my point of view ofcourse ) it's "autoread" function - example - place phone to tag and MCT autoread that tag, using previously selected .keys file and save dump to file (name with numbers - dump_001 or timestamp 2013_04_08_11_50) - of course with on/off switch in options to make autoread on/off
Cosmetical changes - in my SGM2 name of app (MCT - Mifare Classic Tool) enter beyond screen due low resolution of that phone (320x480) - please change (if applicable) to Mifare Classic Tool (without MCT) - and it's fits perfectly
Michal
Offline
Well they are not secrets so I will share.
In this official NXP document (page from 8 to 11) you can find the exact NXP ATQA specification bits and info about more specific NXP tags (there are further SAKs for tag identification) so you will also be able to show much more information about a specific tag (expecially at page 8 and 9) !
Another thing I found out reading quite a few different NXP datasheets (different from mifare ones) is this: last 2 bytes of sector0-block0 identify for sure tag production's week and year and this can be a quite good method to identify counterfait cards (this information is not present in any mifare document) so you can find clones which have random bytes in that position while penultimate byte must be >0 and <52 (max weeks in 1 year - obviously no HEX numbers allowed) and last byte can be from 00 to 13 (2000-2013); I checked many cards (NXP and Gemplus MPCOS) and ONLY mifare clones (ex. chinese cards) did not meet that WW/YY "rule" (they have numbers greater than 52 or 13 or hexadecimal values); if someone wants to verify this theory please you are welcome !
Last edited by asper (2013-04-09 20:35:13)
Offline
@asper
I implemented the list from this page.
I have noticed that some tags have the same ATQA and SAK and the only difference is the ATS.
But in the NXP document they say:
As the ATS of different MIFARE ICs can be customized, it is certainly not advisable to
rely on the ATS to differentiate the IC type. NXP advises to keep the default value of the
ATS to avoid any privacy attack based on the information in ATS.
And that is exactly what I experienced! The MF DESFire card I own produces a "strange" ATS:
ATQA: 03 44 [ok, like on the web page]
SAK: 20 [ok, like on the web page]
ATS: 80 [on the web page it is: 75 77 81 02 80]
So any idea what I should do? Should I only look on ATQA+SAK and ignore the ATS like NXP suggests?
..But detecting the different JCOP versions will then be impossible..
Kind regards
ikarus
P.S.: I can confirm that all my tags have a timestemp in between 0-52 / 00-13
Offline
Maybe it is a customized ATS; are you sure that the "80" is not the last ATS byte and you are missing the others (75 77 81 02) in some way ?
If it is not you can show that sentence: "probably customized ATS" but please check if there is a problem in ATS bytes sequence; unfortunately I do not have mifare DESFire to play with.
JCOPs have different ATQA+SAK so you are able to distiguish between them and mifare; to distiguish between various JCOPs you can check if it is a JCOP reading the ATQA+SAK and from there you analyze the ATS.
P.S.: I can confirm that all my tags have a timestemp in between 0-52 / 00-13
GREAT, as usual GOOD WORK and thanks for the confirmation
Last edited by asper (2013-04-09 20:36:18)
Offline
are you sure that the "80" is not the last ATS byte and you are missing the others (75 77 81 02) in some way ?
Yeah, im pretty sure. For some other cards the App displays ATS with multiple bytes.
JCOPs have differente ATQA+SAK so you are able to distiguish between them and mifare; to distiguish between various
JCOPs you can check if it is a JCOP reading the ATQA+SAK and from there you analyze the ATS.
You are right, it is no problem to distiguish between MIFARE and JCOP. But some JCOP cards can only be distiguished
from other JCOP cards by their ATS. I have one with an ATS that is even not on that website...
But you are right. I will first check ATQA+SAK+ATS. If there is a match, everything is all right.
If not, I will display the match on ATQA+SAK along with the message "probably customized ATS".
Offline
So it is probably a customized ATS; you can check also this file <-- this is a wide list of contact-smartcard ATRs [equivalent to rfid ATS as you probably read] but some of them has a double interface (or triple: ex manget+contatcs+rfid); maybe you can find some useful info with unidentified ATS (ex. try to search for 75 77 81 02 80).
EDIT: if you want to add more info remeber to "decode" the ATQA bits as shown in the NXP Application Note document (page 8 and 9).
Last edited by asper (2013-04-09 20:45:45)
Offline
you can check also this file <-- this is a wide list of contact-smartcard ATRs [equivalent to rfid ATS as you probably read]
Hey, I remember this file! Stumbled on it while playing with the PCSC daemon.
EDIT: if you want to add more info remeber to "decode" the ATQA bits as shown in the NXP Application Note document (page 8 and 9).
I put this on my TODO list, but it is really pain to do bit operations in java
For the next release I only implemented the tag type identification list from the nfc-tools.org wiki. But in the
"Help and Info" section I added some information about tag type identification including links
to the PCSC file and the NXP document.
Maybe in further versions, when I got more time , I will implement a better tag type identification mechanism based on this two files.
Kind regards
ikarus
Offline
New release (version 1.2.1)
(See: original post, updated)
* Tag info tool can now display the tag type and manufacturer.
* Fixed SAK, dec -> hex (tag info tool).
* Fixed ATQA order, e.g. 4400 -> 0044.
* Fixed crash issue, if tag is not MF Classic.
* Some minor bug fixes.
Kind regards
ikarus
Offline
Superb Work man !
If you have some "ATS" cards please post a "tag info" screenshot
Good choice to put those links !
About ATQA bits do it if you want and if you have time; you are doing this for everybody without asking anything back so I must only say THANKS !!!
Last edited by asper (2013-04-10 15:17:06)
Offline
Superb Work man !
Thank you!
If you have some "ATS" cards please post a "tag info" screenshot
Screenshot of "Tag Info" tool with ATS & tag type info.
(This card does not support MF Classic. This is why there is a error message.)
Offline
as asper said: THANKS ))
this is my very little contribution to Mifare TAG identification:
I have some NFC stickers with 7 byte UID with 1K memory - it's Mifare Plus?
ATQA is like Ultralight 0044 (readed with MCT 1.2.1) but with SAK 08 (not 00 like Ultralight)
Below is retyped info form screen (because i can't upload pictures to forum):
UID:
048F3B72A62780
RF Technology:
ISO/IEC 14443, Type A
ATQA:
0044
SAK:
08
ATS (ATR):
-
Tag Type and Manufacturer:
Unknown
Memory Size:
1024 Byte
Block Size:
16 Byte
Number of Sectors:
16
Michal
Offline
@ikarus: thanks for the screenshot
@national: it is for sure an NXP tag and probably a Mifare Plus CL2 2k (page 9 and 11 of this document);
0044 = Can be Mifare Ultralight, Mifare Plus or P3SR008
08 = Can be Mifare Plus 2k or Mifare Plus CL2 2k
your card has 7bytes UID so only Mifare Plus CL2 2k remains !
EDIT:
@ikarus: if you can add also the remaining "SAKs" that are present in the above document but are missing in the nfc webpage
I think you can remove the (ATR) part in the sentence ATS (ATR) because ATR is used for smart card only.
EDIT2:
CL2 means "Cascade Level 2".
In anticollision time, if the CL1 says that the UID is not complete, the reader sends a CL2 and, if not yet completed, sends a CL3 (4, 7 or 10 bytes UID bytes). Source (page 4).
As you can see A LOTO OF INFO can be extracted form few bytes
Last edited by asper (2013-04-10 16:22:03)
Offline
as asper said: THANKS ))
Thank you too!
I have some NFC stickers with 7 byte UID with 1K memory - it's Mifare Plus?
No, it is Mifare Classic 1k (CL2) with 7Bit UID.
0044 = Can be Mifare Ultralight, Mifare Plus or P3SR008
... or Mifare Classic (depending on COS). And there is no MF Puls with 1K memory!
Also the App will only display the "Mifare Classic Info" (size/blocksize/etc.), if it is a MF Classic tag.
(...Therefore the App should at least display "Mifare Classic" instead of "Unknown" as tag type. I will fix that)
Depending on den COS, some MF Classic 1K cards can have a ATQA saying "0044".
The SAK (08) matches on MF Classic 1K cards with "double" UID (7Bit).
(See NXP's MIFARE Type Identification Procedure; page 9, table 5 and page 11, table 6)
Like I said (regarding the tables from the NXP document):
I put this on my TODO list, but it is really pain to do bit operations in java
[...]
Maybe in further versions, when I got more time , I will implement a better tag type identification mechanism based on this two files.
For now: If you really want to know the MF tag type, you have to look at that NXP document...
Kind regards
ikarus
Last edited by ikarus (2013-04-10 16:32:15)
Offline
You are right, can also be a mifare Classic 7bytes UID but for my actual experience no classic has 0044 anyway I can be wrong
Offline
@asper
I've never seen 0044 on MF Classic cards either. But it must be MF Classic because
there is no MF Plus with 1K memory (see NXP MF Plus prduct page)
and national's tag has 1K memory size.
There are some MF Ultralight tags with 1K but Ultralight never has 08 for SAK.
(...and MCT don't show the "Mifare Classic Info" part (like in the first screenshot), if it is an Ultralight tag.)
Kind regards
ikarus
P.S.:
[Now stoping smartass mode..... Done.]
Offline
You are right, i missed the 1024 Byte value
Offline
I submit an order for generic mifare classic stickers (1K - 0004) but they send to me (as classic mifare UID 4 bytes ATQA: 0004) this "some kind of monster" ) - UID 7 bytes, ATQA: 0044 and SAK 08
I have some pieces and at this moment it's useless for my appliances...
Another "extra" functionality for me (maybe in future versions of great MCT ) is possibility to enter some values in DEC ex. 100 and MCT saves that value in a classic Mifare value block form:
value | inverted value | value | inverted value | adr | inv adr | adr | inv adr
i know it's possible via normal "edit dump" from phone but it needs additional recalculation dec to hex and that hex to inverse and some manual tappings
regards
Michal
Offline
Another "extra" functionality for me (maybe in future versions of great MCT ) is possibility to enter some values in DEC ex. 100 and MCT saves that value in a classic Mifare value block
Take a look at this (second item).
I had the same idea (kind of) some days ago.
So there will be a value block decoder/encoder (dec<->value block) in this App.
(But I think I will add it to the tools menu. You then have to copy the generated value block
and past it in the write tag section (write block-wise). )
Last edited by ikarus (2013-04-10 19:41:15)
Offline