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.
so nothing more to say except: it's great
Offline
I've downloaded the source and running it on my phone using eclipse. However, when running it this way, the application cannot detect any NFC cards. When I install from apk, it works fine.
Am I configuring something wrongly?
... hmmm, I don't know. If I do it this way everything is working fine.
If I done something wrong and you stumble on it, please say so!
Offline
Hi
[...]
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 place to add them.
If this is ok for you, I will put that on my TODO list too.
The MCT dump -> RAW dump script is done.
Usage: ./mct-dump2raw.sh example-dump-file.txt > hexdump.raw
Check out the source from Github and try it, if you want.
Kind regards
ikarus
Offline
The RAW dump to MCT dump script is now done too.
Usage: ./raw-dump2mct-dump.sh example-dump-file.raw > mct-dump
Offline
Is there any particular phone model which works better with this application or require less phone "customisation" for running all functions of this application? I have chance to get new phone from mobile operator with new contract.
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
But it should work on nearly all Android NFC phones/tablets.
The only exception I know of is the Nexus 4 (and 10) due to their NFC chips (see this).
I hope I could help.
Kind regards
ikarus
Offline
New release! (version 1.3.0)
(See: original post, updated)
* Added new tool: Decode & Encode Mifare Classic Value Blocks (screenshot).
* Added script to convert MCT dumps to RAW dumps.
* Added script to convert RAW dumps to MCT dumps.
* Display the UID length (and the CL) in tag info tool.
* Use proguard to shrink APK files.
* Fixed: Do not create language-dependent dump files using strings.xml
* Some bug fixes.
* Some code cleanup.
I hope you enjoy it!
Kind regards
ikarus
Offline
Hi Ikarus, and thank you for this new version ! Can you explain what kind of encoding/decoding it performs ?
Offline
Hi Ikarus, and thank you for this new version ! Can you explain what kind of encoding/decoding it performs ?
It can decode a MF value block to an integer and the address value.
Encoding is just the other way around (int + addr to value block).
Value block are special formated blocks which represent a 4 byte signed integer.
(see chapter 8.6.2.1 of the NXP Mifare Classic Datasheet).
The new tool is (more or less) a implementation of nationals request
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
Kind regards
ikarus
Offline
Thank you man, I totally removed that chapter in the datasheet....
I noticed an error in the datasheet (verified by your screenshot); here they are both:
As you can see the decimal value 1234567 converted to hexadecimal is 0012D687 and not 0012D684 as stated in the official datasheet... did you noticed that ? So your encoding is correct while the datasheet one is not... right ?
Offline
...did you noticed that ? So your encoding is correct while the datasheet one is not... right ?
Yeah, I noticed that too...
The text ist right (1234567d = 0012D687h), but in the table they made a mistake.
(This examle is new. Old versions of the datasheet do not have it. So maybe they will fix it in futher versions.)
I guess nobody is perfect
Last edited by ikarus (2013-04-23 19:01:58)
Offline
I guess nobody is perfect
Of course ! But everybody can improve
[sorry for the OT]
Offline
Ikarus, will it be possible to build a visual interface to send raw ISO14443A commands using your software or building another very small app ? It is a really missing feature (mainly in PC software) in my opinion.
Offline
Ikarus, will it be possible to build a visual interface to send raw ISO14443A commands using your software [...]
Hey that sounds like really cool idea! And it should not be that hard to implement.
There already is a method for this in the API.
Is it possible to change the UID of Magic Chinese Cards with raw ISO14443A commands? And if yes, is the command sequence known?
If so, maybe I could try to implement a feature to change the UID of cards like these.
Kind regards
ikarus
Offline
Hello Ikarus
I have one small question about some interesting feature in MCT (very useful for me and maybe for others)
Is possible to make feature like some "dictionary" for known tag content?
Example
After reading full (16 sectors) tag or some different range of sectors content - it is compared with prepared "known" data from file
1. Read tag
2. MCT compare readed content (be more specific some bytes strings) with some file (ex. string 00AABB in sector 9 block 2)
3. If data from file is known to MCT (match) MCT display own tag name (also defined in file with compared string) ex. Super Duper Mifare Tag
Thanks for reply
Regards
Offline
Yes commands for chinese cards are known ikarus; if you will be able to send the raw commands can you also see if iso14443b and iso15693 raw commands can be used under android? I am not sure of that and I will need some sorce code also for them in a near future.
Anyway thank you for appreciateing the idea
Offline
Mifare standard "raw" commands are the following:
and they are explained in details inside this official Mifare4k datasheet from page 22 to page 27 (table above is taken from page 16).
About Magic Chinese Card block0 writing, those should be the commands to send:
50 00 57 CD (halt command+2bytes CRC) and no answer from the TAG
40 (TAG answer ACK = 0A)
43 (TAG answer ACK = 0A)
from now on you can send read-write commands without authenticating
For example:
A0 00 + 2bytes CRC (to write block0: standard mifare command) <-- TAG answer ACK = 0A
16bytes-manufacturer block+2bytes CRC (data to be written in block0) <-- TAG answer ACK = 0A
now you have written block0
and
30 00+2bytes CRC (to read block0: standard mifare command)
now you read block0
In practice you must send halt, then 40 (7bits), then 43 (full 8bits) and the card enter in a special state in which you can do things without authenticating.
If the above sequence is incorrect please correct it and if there are other "secret" commands (valid only for Magic Chinese Cards), for example command byte 41 (I read it in the sources but I am not able to understand how/when to send it) please describe them here to add support inside the great ikarus app (maybe merlok can help?) ! Thank you !!
This is a sniffed writing sequence (taken from this other thread):
ETU :rssi: who bytes
---------+----+----+-----------
+ 0: 0: TAG 04 00
+ 1647: : 93 70 44 66 70 3c 6e 72 f2
+ 65: 0: TAG 88 be 59
+ 189650: : 52
+ 4752: : 52
+ 64: 0: TAG 04 00
+ 1646: : 93 70 44 66 70 3c 6e 72 f2
+ 66: 0: TAG 88 be 59
+ 73474: : 50 00 57 cd
+ 57150: : 40
+ 81: 0: TAG 0a!
+ 15717: : 43
+ 66: 0: TAG 0a!
+ 20061: : a0 00 5f b1
+ 65: 0: TAG 0a!
+ 2071: : 44 66 70 3c 6e 88 04 00 47 c1 1d 58 a1 00 24 05 c2 40
+ 2656: 0: TAG 0a!
Threads for Magic Chinese Card support:
http://www.proxmark.org/forum/viewtopic … 5678#p5678
http://proxmark.org/forum/viewtopic.php?id=896
Google Code changed pages with Magic Chinese Card support:
https://code.google.com/p/proxmark3/source/detail?r=588
https://code.google.com/p/proxmark3/source/detail?r=589
EDIT:
This is the old code part of mifarecmd.c r589 in which is described command 41 that now is no more present:
// card commands
uint8_t wupC1[] = { 0x40 };
uint8_t wupC2[] = { 0x43 };
uint8_t wipeC[] = { 0x41 };
so I suppose it is not needed for Magic Chinese Card specific operations.
Note that 40 and 43 are "@C" in ASCII... maybe a hint to "China" ? ^_^
EDIT2:
I would like to thanks everyone that was involved in reversing the Magic cards !!!
EDIT3:
To exit that particular special mode ("do operations without authenticating") I think that an halt command should do the trick; am I right ?
Last edited by asper (2013-09-22 17:58:00)
Offline
@national
Interesting idea but I think it is a little bit too special, sorry.
I'm thinking about some generic feature to compare 2 dumps like a unix/linux diff.
Maybe this can help you to compare unknown dumps to dumps of known tags.
@asper
Great job! Thank you really much for this nice summary on Mifare Classic and Magic Chinese commands.
I will implement the "send raw command"-feature in the next version.
Hopefully the App will then be able to write the manufacturer block of Magic Chinese cards. If so,
I want to implement a "change manufacturer block"-feature that do these commands automatically.
This way it is more user-friendly.
Kind regards
ikarus
Last edited by ikarus (2013-04-28 11:54:52)
Offline
It will be absolutely more friendly but a "raw command window" will be also appreciated a lot for non-mifare cards )! Thank you man!
If implementing that feature you learn that android is also able to send iso14443b and iso15693 raw commands please tell me
Offline
A question (mainly for roel-master ^_^), maybe silly but...
- the cypto1 algo is known
- appearently we can send raw commands to tags
... so, will we be able to add support for mifare card to non-NXP NFC devices (es. some Nexus or Galaxy S4 that uses a Broadcom chip) using raw commands and a software-implemented crypto1 algo ? Or is Android OS too slow for that and we must use an hardware to emulate it ?
EDIT: in this thread roel seems to say it is possible !
Quoting directly:
Roel:
...you can use the NFC controller to take care of the authentication for you or do it yourself. When you want to let the chip do the crypto, you only have to supply the key (e.g. transport key = ffffffffffff = 12xf) and use the nfc_initiator_mifare_cmd() command.
For sending the frames manually you need the nfc_initiator_transceive_bits() functions to do the crypto yourself. You can implement the cipher yourself, or use a library like crapto1.
At page12 of this document we can find a kind of explanation of tag<->reader chiphering communication and here the algo description in details (page7).
EDIT2: auto-answer to my previous question:
raw data to ISO14443B tags
raw data for ISO-Dep 14443-4
raw data to ISO15693
raw data to Felica/JIS 6319-4/ISO18092
Last edited by asper (2013-04-30 09:18:43)
Offline
NFC-War will support write Chinese Magic Card!We test it works!!
Offline
We test it works!!
Thats good news! Then I will implement it too. Just to be a step further in building a
Mifare Classic "Swiss Army Knife" App
Kind regards
Ikarus
Offline
Oookay. That is frustrating!
I implemented a beta/testing version of the send ISO 14443A commands tool.
But nearly every command throws an exception!
First Issue:
Android automatically adds a CRC to every command. If I get this right, it is impossible to send say a
"Anticollision CL1"-command like 9320h (no CRC) to a tag.
Second Issue:
Android automatically checks and removes the CRC of every incoming tag answer. If the CRC
is incorrect a "Transceive failed" exception is thrown. This was not even mentioned in the Android documentation!
Problem: Some commands (e.g. the MF authentication, chapter 11.1 of the datasheet) don't have a CRC!
(see: http://stackoverflow.com/questions/1246 … entication
Third Issue:
Android throws a "Tag Lost Exception" on commands like 26h or 52h. I don't know why...
I tested every command I know. I tried to reproduce snooped conversations like these
+ 6671: : 26
+ 63: 0: TAG 04 00
+ 612: : 93 20
+ 66: 0: TAG 53 2b 19 af ce
+ 876: : 93 70 53 2b 19 af ce ba e4
+ 66: 0: TAG 08 b6 dd
+ 13726: : 50 00 57 cd
but everything failed. All I get the tag to say is 04h...
Maybe some of you guys can help me out. Or maybe this feature is not reasonable to implement due to Android...
However a testing version can be downloaded here.
If you are able to do something useful with this feature please say so!
@RadioWar:
You said it worked. How? Can you help me out? Maybe share your knowledge?
Kind regards
ikarus
Offline
Have a look at this (very interesting); I think the only solution is to have a modified libnfc-nxp and this library must be the same version of the Android platform it is used otherwise you need to instalkl the correct rom version (correspondant to the original/modified libnfc-nxp version used); if the same version is used and the phone is rooted the files /system/lib/libnfc.so, /system/lib/libnfc jni.so and /system/app/Nfc.apk can be directly substituted.
Now the problem are: are you able to modify the library ? Will you add a "rooted-only" function to your app ?
EDIT: maybe this source can help, in particular this file.
Last edited by asper (2013-05-08 14:05:47)
Offline
As always: Thanks for the great help, aper!
This bachelor’s thesis is indeed very interesting!. Looks like it is possible to send raw ISO 14443A commands
after all... but not the easy way .
I think I will shift this feature down on my priority list. Sure, for the long shoot I really want this in the MCT-App,
but for now I think it is best to care about the more basic/non-root/easy-to-use/easy-to-implement features to make some progress.
I also want to add this App to the Google Play Store the next moth or so.
Kind regards
ikarus
Offline
Great to hear from you man !
If you want I can try to help you with the nfclib "hack" but you need to guide me step-by-step ! Do you think that you are eventually able to mod those .so libraries ?
Note that even root-needed functions can be added in a playstore app, you only need a disclaimer in the store and also inside the app ! I hope the cost of that app will be "less" for forum users
Offline
This tool is awesome, I love it!
I miss the possibility to export dump files though, to for example email. It is easier to compare files and edit them on a computer. Or can I copy the dump files from the phone to my computer somehow without rooting my phone?
Offline
This tool is awesome, I love it!
Thanks!
I miss the possibility to export dump files though, to for example email.
That is indeed a good idea. I will write that on my todo list.
Or can I copy the dump files from the phone to my computer somehow without rooting my phone?
Dumps are stored in the MifareClassicTool/dump-files/ directory (on external storage / SD-card).
So no rooting needed here!
(For more information see the In-App "Help and Info" section.)
Kind regards
ikarus
Offline
Cool. Found the files now. Thanks!
Offline
Hey everyone,
I am a bit proud to announce that the MCT is now available on Google Play Store.
Check it out: https://play.google.com/store/apps/deta … lassicTool
Kind regards
ikarus
Offline
New release! (Version 1.3.1: APK-file, Google Play)
(See: original post, updated)
* Share dump files (e.g. via mail or bluetooth).
* Some minor bug fixes.
Kind regards
ikarus
Offline
...And again:
New release! (Version 1.3.2: APK-file, Google Play)
(See: original post, updated)
* Delete dump or key files via the file chooser's menu.
Kind regards
ikarus
Offline
Always getting better! Thank you!!
Offline
Very nice app. Thanks for making it available!!
Small bug (I think): When showing value blocks in a mifare dump, the block number seems to be too low by 1. E.g.
000000c0 6c e4 00 00 00 00 00 00 00 00 01 0e 0d 00 00 01 |l...............|
000000d0 d0 07 00 00 2f f8 ff ff d0 07 00 00 0e f1 0e f1 |..../...........|
000000e0 d0 07 00 00 2f f8 ff ff d0 07 00 00 0d f2 0d f2 |..../...........|
shows as sector 3, block 0 and sector 3, block 1, which to my mind should be block 1 and block 2, respectively.
Offline
@Neuer_User
You are absolutely right!
I will fix this bug within the next version. Thank you for reporting.
... And there is another huge bug that makes the App crash,
if you try to write a 4k dump to a MF 4k tag.
I will fix that too!
Kind regards
ikarus
Offline
New release! (Version 1.3.3: APK-file, Google Play)
(See: original post, updated)
* Fixed crash issue while writing 4k dumps to MF 4k tags.
* Fixed wrong block nr. in value blocks as int view.
Kind regards
ikarus
Offline
* Fixed wrong block nr. in value blocks as int view.
Thanks, can confirm, is working now correctly.
Btw. could you implement read/write to the chinese cards?
Also, it would be very nice if you would save the mapping of each card, so if the same card was used again, there could be the option to reused the last saved mapping of that card.
Thanks
Michael
Offline
Btw. could you implement read/write to the chinese cards?
I have really tried, but failed so far... If you want to know why and what the problem is
you can read from http://www.proxmark.org/forum/viewtopic … 7020#p7020
until http://www.proxmark.org/forum/viewtopic … 7189#p7189.
Also, it would be very nice if you would save the mapping of each card, so if the same card was used again, there could be the option to reused the last saved mapping of that card.
Having the same thoughts here for quite a while. Soon or later I will implement a possibility to
save a key map. Maybe along with a quick steal / quick dump feature.
Something like: choose a key map -> read tag -> immediately dump into file with timestamp -> read next tag -> dump -> and so on...
Kind regards
ikarus
Offline
Something like: choose a key map -> read tag -> immediately dump into file with timestamp -> read next tag -> dump -> and so on...
Kind regards
ikarus
Could be even easier:
Put tag in range, app detects uid, shows some info about card and offers menu: "generate key map", "read card" and "write card". If no key mapping exists for the card, it will only offer the first point.
"generate key mapping" will ask for the key sets (as it does today), and after successful generation, it would save the map with a reference to the uid.
Offline
@Neuer_User
I don't think it is a good idea to connect UID and key map logical. It is quite common that
several cards share the same key map (and 4 byte Unique IDs aren't really unique).
I think always letting the user decide if he/she wants to "generate new key map" or to "use saved key map" for reading/writing is the best way.
(I'm not sure if it is really important to automate this process with some kind of UID<->KeyMap reference management system.)
Something like: choose a key map -> read tag -> immediately dump into file with timestamp -> read next tag -> dump -> and so on...
This was only my concept for the "quick steal" feature (and has almost nothing to do with the key map concept).
Sorry if I was not clear enough about this part. What I want in future is just another mode (apart of the one that already exists) to read
and dump tags fast. So you can dump tag data in "drive by" speed.
Kind regards
ikarus
Offline
What I want in future is just another mode (apart of the one that already exists) to read
and dump tags fast. So you can dump tag data in "drive by" speed.
Ahh, I see. Well, for dumping cards fast, that is probably a nice function.
In my case I rather have a number of cards that are used for several of my clients. All of them do have unique UIDs (even if they are only 4 byte). It would really be nice to just put the tag in range and then dump the content without manually choosing the right key map.
Here is a comprimise:
When a tag is in range, the app automatically chooses a key map if there is one matching the UID.
Then it displays the menu with the following entries:
- generate key map
- choose key map
- read card(s)
- write card(s)
So, for my use case, I would only need to click on read or write (if a key map for the UID exists) and that's it.
If a new card is used, one can simply choose a key map and then read/write.
I guess that could also be used for "batch reading", if a default key map is set or just the last used one will be used for the next card.
Anyway, looking forward to whatever it will look like in your future implementation. And thanks again for the app!
Cheers
Michael
Offline
Oookay. That is frustrating!
...............
but everything failed. All I get the tag to say is 04h...
I missed that sentence... 04 means "NAK" (Not ACKknowledged = not allowed), if it was 05 = "Transmission Error". The right answer is 0A = ACK (Acknowledged).
Offline
@Neuer_User:
Hmm your use case is some kind of special. I'm not sure if it is the right thing for this App.
My goal was to create a "Swiss army knife" tool for MF Classic and not a tool to dumping tags as
quick and as possible with as less as possible effort. There are other features that are more important - at least to me.
And with the feature to use saved key maps (hopefully will come soon), the effort to dump a known tag is not that much.
...Or maybe I'm just to lazy to implement the UID<->KeyMap linking system and new menu structure
And of course: This project is open source! Feel free to implement this feature if you really need it.
@aper:
Thanks. I thought it is some kind of NAK, but I wasn't 100% sure. I must have missed it on the datasheet.
Kind regards
ikarus
Offline
New release! (Version 1.4.0: APK-file, Google Play)
(See: original post, updated)
* Format tags back to factory/delivery state.
* Writing the UID (manufacturer block) of *special*
MF Classic tags is now possible (thanks to alfs).
* Improved key mapping speed (thanks to alfs).
* Share key files (e.g. via mail or bluetooth).
* Changed key file editor functions layout from buttons to menu.
* Fixed some minor bugs.
* Cleaned up some code.
Important notice on "special" Mifare Classic tags:
There are special MF Classic tags that support writing to the manufacturer
block with a simple write command (e.g. these ones should work).
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!
Kind regards
ikarus
Offline
Just tested the new version with "special" changeable UID card (which requires special commands) and in fact it doesn't work. Unfortunately I do not have the "other" special card so I cannot test with them; anyway good to know that there are 2 kind of "special card" out there !!
To sum up:
- 1 kind of tag (the oldest ones), also known as "backdoored" ones, that means they need some special commands (backdoor) to be sent before you will be able to freely write any block;
- a second kind of tag (newer) in which you can send normal mifare commands to freely write any block (probably with or without authenticating at all as I suppose, can you confirm?).
Thanks. I thought it is some kind of NAK, but I wasn't 100% sure. I must have missed it on the datasheet.
If I well remember it is in an Official Application Note pdf, not in the normal card datasheet.
Last edited by asper (2013-06-01 15:40:10)
Offline
- 1 kind of tag (the oldest ones), also known as "backdoored" ones, that means they need some special commands (backdoor) to be sent before you will be able to freely write any block;
- a second kind of tag (newer) in which you can send normal mifare commands to freely write any block (probably with or without authenticating at all as I suppose, can you confirm?).
Exactly!
I think you need to be authenticated in order change the manufacturer block.
The special MF Classic tags just handles the first sector like every other sector, I think.
I don't own such a tag (yet) to check that. But I know that changing this block with the MCT App
works, because "alfs" checked it (see: this).
Offline
New release! (Version 1.4.1: APK-file, Google Play)
(See: original post, updated)
Version 1.4.1:
* Fixed "No valid key found" issue.
(This issue appeared on some devices with custom ROM.)
Kind regards
ikarus
Offline
Bad news for us Ikarus: it seems not to be possible to send raw commands even with NFC modified sources because the communication is totally controlled by the NFC chip; to have a real NFC-modem function (send raw commands) we should modify the NFC-chip firmware that is not possible because most of them (at least NXP ones) are "signed" and cannot be freely modified.
In few words: NFC-chips that are inside mobiles are not "NFC-modems" like PM3, they control the communication protocol with an hardware-based firmware and they cannot be modified (at least until now).
Offline
The most commonly NFC chip used is the PN544.
The PN544 supports 'Virtual Card mode'. So you can emulate cards at least.
On rooted phones you can sign your own packages.
Offline
Any way to find the key's sectors? Your app can read the data for sector cero using a default key, but can't read the other sectors, which are the importants, because of the lack of key, so must be some kind of dictionaries for brute force or any kind of algorithm coming from the info in sector cero
Offline