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.
If you can send seven bit shortcommands with your tool, then you might add some simple checks to see if a tag responses to the chinese magic commands ie detect s50 gen1 cards.
Offline
Unfrtunately It is not possible to send 7bits commands (nfc chip firmware forced limitation) if so even devices not compatible with mifare will be compatible.
Offline
That's a bummer.
Offline
Hi ikarus,
I did some tests on Huawei X4 and found the same issue 1. But I don't know whether Huawei X4 uses the same NFC chip as OnePlus One's NXP nsd404x or not.
Then I turned back to my One and found the root cause of this issue. MCT (or nsd404x) can read data of sectors with keyA/B of "FFFFFFFFFFFF" using the key "000000000000"!
1. If a key file contains both "FFFFFFFFFFFF" and "000000000000", the issue will arise randomly. But I haven't start to read the code of MCT so I don't know what's your procedure of mapping a key. I guess it's because MCT read the data using "FFFFFFFFFFFF" and "000000000000" randomly and both of them were succeeded. There's no difference after I seperated the two keys to two files and chose both of them to read a card.
2. The issue does not exist any more after I deleted "000000000000" from the key file, or just do not choose the key file which contains "000000000000".
3. I use a key file contains just one key - "000000000000" to read cards. It can really read the data of sectors using "FFFFFFFFFFFF" for keyA/B WITH NO ERROR!
4. All sectors use FF078069 for access controls.
For issue 2, I don't know whether the mis-read dumps causing by issue 1 affects it or not. I don't have any cards using "000000000000" for keys to make a real dump. But I wrote a modified dump which contains "000000000000" sectors with a key file containing only "000000000000", it shows "No keys found (or dead sector)" again for "00000000000" sectors.
So, why all-0 key can read all-F sectors but not read its own all-0 sectors?
Could you please do the same tests on your devices?
Many thanks!
Sorry for my poor English.
Offline
Hi ikarus,
I did some tests on Huawei X4 and found the same issue 1. But I don't know whether Huawei X4 uses the same NFC chip as OnePlus One's NXP nsd404x or not.
Then I turned back to my One and found the root cause of this issue. MCT (or nsd404x) can read data of sectors with keyA/B of "FFFFFFFFFFFF" using the key "000000000000"!
1. If a key file contains both "FFFFFFFFFFFF" and "000000000000", the issue will arise randomly. But I haven't start to read the code of MCT so I don't know what's your procedure of mapping a key. I guess it's because MCT read the data using "FFFFFFFFFFFF" and "000000000000" randomly and both of them were succeeded. There's no difference after I seperated the two keys to two files and chose both of them to read a card.
2. The issue does not exist any more after I deleted "000000000000" from the key file, or just do not choose the key file which contains "000000000000".
3. I use a key file contains just one key - "000000000000" to read cards. It can really read the data of sectors using "FFFFFFFFFFFF" for keyA/B WITH NO ERROR!
4. All sectors use FF078069 for access controls.
For issue 2, I don't know whether the mis-read dumps causing by issue 1 affects it or not. I don't have any cards using "000000000000" for keys to make a real dump. But I wrote a modified dump which contains "000000000000" sectors with a key file containing only "000000000000", it shows "No keys found (or dead sector)" again for "00000000000" sectors.
So, why all-0 key can read all-F sectors but not read its own all-0 sectors?
Could you please do the same tests on your devices?Many thanks!
Sorry for my poor English.
For issue 2, I don't know whether the mis-read dumps causing by issue 1 affects it or not. I don't have any cards using "000000000000" for keys to make a real dump. But I wrote a modified dump which contains "000000000000" sectors with a key file containing only "000000000000", it shows "No keys found (or dead sector)" again for "00000000000" sectors.
I mean it shows "No keys found (or dead sector)" again for "00000000000" sectors when reading it after writing.
Offline
ikarus,
I never succeeded to use the "writting to manufacturee block" feature. I'm using a UID writable card that made in China. Actually all bits of this card can be written like no access control. I often use it to clone M1 cards using ACR122u and below app.
But when I try to write sector 0 of any dump to it, it just fails with this.
Offline
@stickymarm: Unfortunately, the type of the card can't be determined from the block 0 data. Could you read the card with the app that I linked? It's free, doesn't require strange permissions and takes only a minute.
Does anyone actually has a direct writable card and is willing to share the type of the IC (or a cheap source)?
Thanks
624639160@qq.com
Daniel li
Fudan S50 1K
received summer 2013 and working just fine
Offline
New release! (Version 1.8.3: APK-file, Google Play (Donate Version), F-Droid)
(See: original post, updated)
* Bugfix: Show the "unsaved changes" dialog only if the user
edited a dump and not just looked at it. Thanks to "systemcrash".
Happy new year!
ikarus
Offline
Happy new year!
Offline
great job ikarus...working well on my phone...Do u know any idea of implementing bruteforce in future?..I know its very slow but maybe u can give an option like bruteforce only last two keys "11 22 33 44 55 XX" or custom option for bruteforce.
Thanks.
Offline
@result
I really can't reproduce the behavior you got there. I can read factory formatted tags (key A/B FFFFFFFFFFFF)
only with key FFFFFFFFFFFF and not with 000000000000. Is there something wrong with your tag?
Have you tried to read it with 000000000000 with your ACR122? Also there should not be "random" behavior
within the MCT key mapping process. I should be reproducible.
Regarding your attempt to write the manufacturer block: Are you sure you got the right type of tag?
Remember: 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.
@kevin84
Thanks!
In the readme it states "There will be no "brute-force" attack capability in this application. It is way too slow due to the protocol.",
but I never thought of partial bruteforcing.. Is this really useful? How often is it the case you know parts of the key? Isn't it easier to
just buy an ACR122u for about $50 and crack the keys?
Offline
Hi Ikarus,
the card that made the reader "crazy" is probably Legic or desfire. Any suggestion about reader/software.
So far all apk i have are reading only the UID
Offline
https://play.google.com/store/apps/details?id=com.legic.nfc.p2p.p2p_example
https://play.google.com/store/apps/details?id=com.skjolberg.mifare.desfiretool
Offline
https://play.google.com/store/apps/details?id=com.legic.nfc.p2p.p2p_example
https://play.google.com/store/apps/details?id=com.skjolberg.mifare.desfiretool
thank you
any soft for RDR-80582AKU ?
Offline
Ask the reseller.
Offline
http://proxmark.org/forum/viewtopic.php?id=2238 ikarus, can you have a look to the bottom of this thread about SAK? It seems that MCT shows it in decimal and not in hex:
Last edited by asper (2015-01-12 22:03:21)
Offline
Hmm... It should be HEX.
...unless my byte2HexString method is broken.
But until now I never had any issues/complaints.
Offline
Thanks for looking. SAK is reported in hex in every paper. Maybe he is using an old MCT version... unfortunately i don't have cards wit SAK >= A anymore to test.
Last edited by asper (2015-01-13 01:16:08)
Offline
The SAK was always hexadecimal in MCT.
...But you may have discovered another bug! MCT always displays a one byte long SAK value.
As I just found out, the SAK is two byte long for tags with a 7 byte UID!
The issue will be fixed within the next release!
Offline
Well, not exactly 2 bytes: you receive a 1st SAK and if it has a specific bit set to 1 (bit3 start counting from 0) it asks for the next part of the UID and after this the reader receive another SAK, if also this shows there is a 3rd part of UID (triple size uid) another sequence will start and you will receive the last SAK. Here is an example with a double size UID.
So you can have 3 SAK bytes, one after each 9x 20 -> 9x 70 sequence, but not all at the same time.
93 20 --> 93 70 --> SAK-bit3 = 1 --> --> 95 20 --> 95 70 --> SAK-bit3 = 1 --> --> 97 20 --> 97 70 --> SAK bit3 = 0 --> END
93 70 = Select of cascade level1
95 70 = Select of cascade level2
97 70 = Select of cascade level3
Last edited by asper (2015-01-13 21:48:57)
Offline
Android returns the SAK"in one peace" (after the whole anti collision and card selection process).
Therefor it can have more than one byte. Although, really interesting is that it can have two bytes at max.
I'm not sure why. Maybe Android cant handle CL3 tag?! Are there any CL3 tags out in the field?
(I never saw one.)
Offline
Never saw one me too.
Offline
Hi, at first congratulations for the app, it works properly on lg g3.
Please can you help me, I own an u-key like this http://www.nurissa.ch/uploads/content/clae_u-key.jpg and which I use in the vending machine and I want to change the credit value.
Now can I do this with your app? If yes how I can interpretate the values?
This is the code
Thank you very much
[== Undefined ==]
+Sector: 0
FE41BF3A3A8804004885149145200111
D2000000000000000000000000000000
00000000000000000938093809380938
A0A1A2A3A4A561E789C1B0B1B2B3B4B5
+Sector: 1
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
A0A1A2A3A4A578778869B0B1B2B3B4B5
+Sector: 2
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
A0A1A2A3A4A578778869B0B1B2B3B4B5
+Sector: 3
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
A0A1A2A3A4A578778869B0B1B2B3B4B5
+Sector: 4
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
A0A1A2A3A4A578778869B0B1B2B3B4B5
+Sector: 5
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
A0A1A2A3A4A578778869B0B1B2B3B4B5
+Sector: 6
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
A0A1A2A3A4A578778869B0B1B2B3B4B5
+Sector: 7
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
A0A1A2A3A4A578778869B0B1B2B3B4B5
+Sector: 8
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
A0A1A2A3A4A578778869B0B1B2B3B4B5
+Sector: 9
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
A0A1A2A3A4A578778869B0B1B2B3B4B5
+Sector: 10
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
A0A1A2A3A4A578778869B0B1B2B3B4B5
+Sector: 11
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
A0A1A2A3A4A578778869B0B1B2B3B4B5
+Sector: 12
8807F8820004A50A0000270001019B19
--------------------------------
--------------------------------
A0A1A2A3A4A51E11EE5A------------
+Sector: 13
--------------------------------
--------------------------------
--------------------------------
A0A1A2A3A4A50F00FF5A------------
+Sector: 14
--------------------------------
--------------------------------
--------------------------------
A0A1A2A3A4A50F00FFF5------------
+Sector: 15
--------------------------------
--------------------------------
00005E2000F3ED00000000004D494300
A0A1A2A3A4A54B44BB5A------------
Offline
No answers to fraud questions. You are not welcome in this forum.
Offline
Ok, I'm so sorry. I didn 't read the forum rules, I will do it right now
Offline
So talking in general, how can I interpretate the values shown in the app? I read in the info of the app that are in the Hex format but it don't seems like that...maybe the key used by the program aren t right so the result isn't readable?
Thanks in advance
Offline
hi stefano. write me a mail to explain you how the program function
lada21011 at yahoo com
Offline
New release! (Version 2.0.0: APK-file, Google Play (Donate Version), F-Droid)
(See: original post, updated)
* New Feature: Increment/Decrement Value Blocks.
* New Logo. Thanks to Beneke Traub (http://www.beneketraub.com/).
* MCT can be used in "offline" mode on devices with no NFC
* Fixed the monospace font issue of the diff tool for Android 5.0+..
* Fixed representation of SAK and ATS in the tag info tool.
* Major (cosmetic) code cleanup & typo fixes.
* Some minor bug fixes.
* Samsung Galaxy S5 900P, Huawei G620S and Xiaomi MI 3 are not supported.
Why version 2.0.0? No particular reason. It just felt right. There have been much improvements
and new features since 1.0.0. With the new logo, a new feature and a lot of fixes I thought the time
was right to move to 2.0.0.
To all Samsung Galaxy S5 and HTC One (m7/m8) users that upgraded to Android 5.x:
I'm sorry, MCT does not to work on this devices right now. Unfortunately, it seams that
this is an issue of the Android builds provided by Samsung/HTC. There is nothing I can do about it.
Please see: https://github.com/ikarus23/MifareClassicTool/issues/53 and
https://github.com/ikarus23/MifareClassicTool/issues/52.
Have a nice day!
ikarus
Last edited by ikarus (2015-04-26 13:57:09)
Offline
Hi lolio,
I'm sorry, but you are right. These changes can not be undone.
Regarding the warning notice. I'm not sure where to place it and what exactly its content should be.
Adding a hint that you can't change the Access Conditions once you removed the permission to change them sounds kind
of ridiculous... And already is the dialog before writing to a sector trailer
You're about to write to a sector trailer. Writing incorrect data may cause irreparable damage to the tag.
and the dialog at the first usage of MCT
This application is dedicated to users who have at least basic familiarity with the
Mifare Classic technology. Its features are basic and at a low level. Therefore nearly all data input and output will be hexadecimal.
It is also important that you understand what you are doing, e.g. if you write data to a tag. Writing the wrong data to certain
blocks may cause irreparable damage to the tag.
Maybe a warning message within the AC encoder tool is the right choice. I will consider it.
Thanks for your feedback! Have fun using MCT and exploring Mifare Classic!
Offline
Hello, does it work on LG G3?
Offline
@Lukkasss
The LG G3 should work. At least this site state it has a "NXP PN547 NFC chip".
But I can't guarantee for anything. I don't own a LG G3.
Edit: This user tested it and it works, even with Android 5
@phaza
Sorry I don't understand your problem. You can use the menu button in the editor to
convert hex to ASCII, if this is of any help to you...
Last edited by ikarus (2015-03-24 21:09:27)
Offline
@Lukkasss
The LG G3 should work. At least state it has a "NXP PN547 NFC chip".
But I can't guarantee for anything. I don't own a LG G3.
Edit: This user tested it and it works, even with Android 5@phaza
Sorry I don't understand your problem. You can use the menu button in the editor to
convert hex to ASCII, if this is of any help to you...
Thanks for the answer ikarus.
I'm going to buy a G3 next month and I'll play with your app. I'll need some help in the future so your answers here are incredible amazing.
Thanks for providing this for us.
Have a nice day.
Offline
New release! (Version 2.0.1: APK-file, Google Play (Donate Version), F-Droid)
(See: original post, updated)
* Fixed bug causing to show dashes on Samsung Galaxy S5 devices.
Thanks to "andake".
* Samsung's Galaxy Ace 4 is not supported
Finally... thanks to andake one of the ugly bugs could be fixed. MCT should now work again on Samsung's Galaxy S5.
The error: The readBlock() method of the Android API should always return 16 bytes.
On Galaxy S5 devices it sometimes returns more or less than 16 bytes.
The fix (workaround): If less than 16 bytes --> error, if more than 16 bytes --> ignore tailing bytes.
Have a nice day!
ikarus
Last edited by ikarus (2015-03-31 23:21:40)
Offline
how i can change the list of key ?
Offline
how i can change the list of key ?
You mean add another key file? or edit existing key files?
1. Create new key file:
Edit/Add Key File => Context menu (3 dots) => Create New File
2. Edit key file:
Edit/Add Key File => Select a file => Edit or add keys
Was that really so hard?
Offline
hhhh no is so esay ....thinks
now i need to save all of tag memoiry in STRING OR another type to display afficher chaque information dans leur text view
Offline
hhhh no is so esay ....thinks
now i need to save all of tag memoiry in STRING OR another type to each display information in their text view
Offline
Sorry, but I really don't get what you are saying...
Offline
I want to put all the tag data in a single chain
Offline
Just open the dump file with your favorite editor. It's a simple text file.
Offline
je suis un développeur ,je veux modifier l'interface de l'application pour afficher plusieurs infomations chaque dans leur textview
Offline
I'm a developer, I want to change the application interface to display multiple infomation each in their textview
Offline
If you want to modify the application, feel free to check out the
source code at github and alter it in the way you want.
Offline
New release! (Version 2.0.2: APK-file, Google Play (Donate Version), F-Droid)
(See: original post, updated)
* It's now possible to save the mapping range as default.
* Improved Mifare Classic support check. Thanks to Kirill Elagin.
* Sony Xperia Z3 (SOL26) is not supported.
Have a nice day!
ikarus
Last edited by ikarus (2015-04-26 13:56:44)
Offline
New release! (Version 2.0.3: APK-file, Google Play (Donate Version), F-Droid)
(See: original post, updated)
* Fixed crash issue for HTC One (m7/m8) with Android 5.x.
Thanks to "bildin" and many others for helping to find
a workaround for this. The real issue is still there and
has to be fixed by HTC.
* It's now possible to create a key file from the currently
viewed dump using the Editor.
* Added more well known keys to the extended key file.
(Remove the old and restart MCT to get the new key file.)
* Samsung's Galaxy A3 and Galaxy Alpha are not supported.
* Added scripts to convert .eml to MCT dump files (and vice versa).
(Python script, not part of the Android app.)
* Added scripts to convert .eml to .mfd files (and vice versa).
(Python script, not part of the Android app.)
* Some minor code improvements.
Again, I want to thank all of the people who helped to find a workaround
for the HCT One (m7/m8) issue! You guys are great!
For anyone interested in what the issue is and how it was fixed
have a look at the github issue.
Have a nice day!
ikarus
Offline
New release! (Version 2.0.4: APK-file, Google Play (Donate Version), F-Droid)
(See: original post, updated)
* Bugfix: Don't save dumps as key files.
Thanks to Oliver H. for reporting this.
Have a nice day!
ikarus
Offline
Hi Strideynet, you are not the only one. Some time ago I wrote something about this:
Just another short notice:
A lot of people asked me (in the forum and via email) where to buy the block 0
writable tags that work with MCT. A friend of mine found a reliable source:Mifare Classic 1k
Mifare Classic 4k
Mifare Classic 1k (7 byte UID)This company also sells the tags via ebay.
I'm sure that is not the only good source to buy them.
And I'm pretty sure there are cheaper ones, but least these tags work!Have a nice day!
ikarus
About two month ago I bought one of these tags (Mifare Classic 1k). It works perfectly fine.
EDIT/UPDATE: The ebay shop of this source is down (hopefully only temporarily).
Last edited by ikarus (2015-09-07 21:14:37)
Offline
Hi ikarus,
I want to re-open an old post (http://www.proxmark.org/forum/viewtopic.php?pid=7175#p7175) because I have an interesting news.
Today I was able to send my first raw command to a MifareClassic 1k tag using NXP chip inside an Android phone.
Command sent was the AUTH_A (used to start authentication) on sector #0. And finally I got back 4 bytes nounce from tag!!
To get this result I needed to:
1) call BasicTagTechnology.transceive(msg, raw) with raw=false. This way no CRC is computed in request
and no validation of CRC is performed in the response.
(see com_android_nfc_NativeNfcTag_doTransceive() function in Android-Nfc-master/nxp/jni/com_android_nfc_NativeNfcTag.cpp)
2) build message in a proper way:
[0x00, 0x00, 0x60, 0x00, 0xf5, 0x7b]
|---| |---| |---| |---| |----------|
| | | | |
| | | | +- little endian order of CRC([0x60,0x00])=0x7bf5
| | | +- block #0 (or any other block)
| | +- AuthA command
| +- ignored for raw messages (can be any byte)
+- means Mifare raw message
NB: First 2 bytes are the header and not part of raw message sent.
(see phNfc_eMifareCmdList_t enum definition in libnfc-nxp-master/inc/phNfcTypes.h)
Now, the bad news is that I'm not able to invoke BasicTagTechnology.transceive(msg, raw) directly
since it has package scope. The only public method I can use is NfcA.transceive(msg) that calls
BasicTagTechnology.transceive(msg, raw) with raw=true. This is not what I need.
At present the only way I can test my code is executing NfcA.transceive(msg) method in debug mode
and during runtime execution change 'raw' value (via a breakpoint) from true to false.
Works but not very comfortable
Anyway I think this is an important test because it shows that raw ISO-14443A messages can be sent without
modifing NXP chipset firmware or else. Probably a patch in the Android NfcA class would be needed to get
full control of NfcA.transceive() method.
Offline
Good test tontol1 but even solving that problem there is another one to make it "full raw compatible": the ability to send 7bits commands insted of 8bits. 26 (or 52) is a 7bits command that is part of the mifare standard command set managed by the NXP chip. If you want, for example, "talk" with a magic 1st gen mifare card you must send another 7bits command [it is 40] that is not coded inside NXP chip so even with your method it will be not possible to achieve a full raw.
It is something like SRIX4K support: they are not supported by Android because they are not full ISO14443B and have specific commands not supported by the chipset (at least this is what came out by tests) but maybe with your method this one can be solved because those specific commands (SRIX) are 8bits [the command is exactly 0600 = INITIATE]. Let us know if you find a way (also for ISO14443B commnds) !
Last edited by asper (2015-09-27 10:00:51)
Offline
More tests show me some limitations of my method for sending raw ISO14443 messages:
1) not able to send 7-bits commands (as asper said);
2) no control over parity bits sent (not clear if computed by Android or Chipset).
So it is not a "full raw" ISO14443 method.
Probably it can still be useful for doing cryptanalysis of underneath crypto algorithms, since AUTH commands are byte oriented. I'm going that direction, now.
Offline