MCT and Sony Z3

[ikarus23]

moscowneversleeping said:

Hi. New version don't works with some type of Classic Tags. SONY Z3. Android 5.0.2. I see debug information today, and write here crashing logs.

[ikarus23]

Hi. Another user told me that the Sony Z3 does not support Mifare Classic. Are you sure it worked before? Have you verified this by downgrading MCT to e.g. 2.0.1?.

[ikarus23]

Ok, there are other users reporting issues with using Sony's Z3 in combination with Mifare Classic tags.

First, Samsung's Galaxy S5 returns arrays with a length different from 16 bytes to a readBlock() (e.g. 6412ec60d7e9f47facc793a06c606d5ffbb8cf93) call, then HTC's One m7/m8 devices deliver broken Tag objects to the app and now Sony's Z3 has Mifare Classic issues too?! Hmpf. Why do all manufacturers tamper with the NFC stack these days...

[bildin]

@ikarus23 finally, issue with HTC is not in broken Tag. But NfcA.get(Tag) tries to get Extras from index of MifareClassic when it is enumerated in Techlist. Applying idea of that patch to this issue, if it is realy so as mentioned in issue on stackoverflow linked above, it is possible to check if MifareClassic is enumerated in Techlist, then change SAK in Extras if is needed. But it may cause some troubles with identifying memory size, I think. Manufacturers are improoving stack, as they think. Russian proverb tells "best" is the enemy of "good". Other engineers say "Don't touch while it works" :)

[ikarus23]

Regarding the issue: Yeah, I thought so too. But I don't like to implement a patch every time a vendor changes the Android code. But I guess I have no choice if I want to have happy users... Anyway, lets try to find out first whether the stackoverflow issue applies to this or not.

Off-Topic: Oh, so it's not the Tag object that is broken, it is the NfcA.get() method! (or is it the "unsorted" Techlist list withing the Tag object?)

[moscowneversleeping]

Now im debugging MCT 2.0.4 on Sony z3, Android 5.0.2 See my logs here https://db.tt/xRXfg596 I thing that most important part is

06-06 20:08:09.031 1643-2355/? D/NfcAdaptation﹕ NfcAdaptation::HalDeviceContextDataCallback: len=4 06-06 20:08:09.031 1643-2334/? I/BrcmNfcNfa﹕ NFC received rsp gid:1 06-06 20:08:09.031 1643-2334/? I/BrcmNfcNfa﹕ nfa_dm_disc_discovery_cback (): event:0x4003 06-06 20:08:09.031 1643-2334/? I/BrcmNfcNfa﹕ nfa_dm_disc_sm_execute (): state: W4_HOST_SELECT (3), event: SELECT_RSP(4) disc_flags: 0x9 06-06 20:08:09.031 1643-2334/? I/BrcmNfcNfa﹕ nfa_dm_disc_sm_execute (): new state: W4_HOST_SELECT (3), disc_flags: 0x9 06-06 20:08:09.033 7531-7531/? E/AndroidRuntime﹕ FATAL EXCEPTION: main Process: de.syss.MifareClassicTool, PID: 7531 java.lang.IllegalStateException: Could not execute method of the activity

[ikarus23]

I can see there a "BrcmNfcNfa" which refers to Broadcom, a NFC chip manufacturer. This is most likely the proof that the Z3 uses a NFC controller by Broadcom. Unfortunately Broadcom chips have no Mifare Classic support. Please read: https://github.com/ikarus23/MifareClassicTool/issues/1. As far as I can see there is nothing I can do about it, sorry.

[moscowneversleeping]

But MCT can read and write some Classic tags on Z3 whith 5.0.2

[ikarus23]

Ok, this is weird... Can you use the Tag Info tool of MCT to get the SAK value?

[moscowneversleeping]

oh shit, I just tried to read the difficult tag and once again she read! but the next time the application again fell. Each time MCT showed tags UID But MCT can't show "Display Tag Info" - failed TagInfo Failed TOO,

But NFC Tools 3.8.1 Free Version about "wakdev" work correctly every one. And i can show you all informatoin. (see photo) Now I tested MCT 2.0.4 on Sony Z1 compact Android 5.0.2 whith this tags, and all wokrs! I can do all other test (may be build MCT from source and debug in real time..)

i'm sorry about Russian on photo :)

[moscowneversleeping]

Soon I will write test results MCT on Sony Z3 with early 4.4.2 Android

[bildin]

@moscowneversleeping did you tried to read this card on another device? what kind of card is it? try to get info with https://play.google.com/store/apps/details?id=com.nxp.taginfolite

there is some important information in your log:

... 06-06 20:08:07.536 1643-2334/? D/BrcmNfcJni﹕ NfcTag::discoverTechnologies (discovery): enter: rf disc. id=2; protocol=128, mNumTechList=2 06-06 20:08:07.536 1643-2334/? D/BrcmNfcJni﹕ NfcTag::discoverTechnologies (discovery): index=0; tech=3; handle=1; nfc type=4 06-06 20:08:07.536 1643-2334/? D/BrcmNfcJni﹕ NfcTag::discoverTechnologies (discovery): index=1; tech=1; handle=1; nfc type=4 06-06 20:08:07.536 1643-2334/? D/BrcmNfcJni﹕ NfcTag::discoverTechnologies (discovery): index=2; tech=8; handle=2; nfc type=128 06-06 20:08:07.536 1643-2334/? D/BrcmNfcJni﹕ NfcTag::discoverTechnologies (discovery): index=3; tech=1; handle=0; nfc type=0 06-06 20:08:07.536 1643-2334/? D/BrcmNfcJni﹕ NfcTag::discoverTechnologies (discovery); mNumDiscTechList=4 06-06 20:08:07.536 1643-2334/? D/BrcmNfcJni﹕ NfcTag::discoverTechnologies (discovery): exit ... 06-06 20:08:07.544 1643-2334/? I/BrcmNfcNfa﹕ RW_SetActivatedTagType protocol:4, technology:0, SAK:32 ...

Mifare Classic is enumerated in TechList (tech=8) and uses protocol (nfc type = 128), but tag is activated wth protocol 4 coresponding to IsoDep (tech=3)

May be your card is Mifare Plus switched to another security level?

[ikarus23]

The screenshot of NFC Tools is showing a SAK of 0x20 (also present in the logs; 0x20 = 32). According to NXP's guidelines on identifying Mifare tags (Page 11), this a Mifare Plus ore Mifare DESFire tag.

[moscowneversleeping]

I'm using a MIFARE Classic emulated Look I find my problem http://stackoverflow.com/questions/30238152/tag-incorrectly-enumerated-as-mifare-classic-sak-32

Can you build test version? where MCT dont see on SAK and application will be use direct commands for reading. (As you do for write zero block may be)

[moscowneversleeping]

To day I installed Android 4.4.4 instead 5.0.2 on my Sony Z3 and run MCT

But yesterday I really was able to read the MIFARE Classic emulated Tag once (On Sony Z3). I know that this is possible, because Tag is reading on other phones (Sony Z1 and Nexus S, etc i'm testad it).

More information about Tags

And of course I can read(write) this Tags with ACR 122u (use default SDK) or with Proxmark3, load keys and read as Mifare classic tags.

[ikarus23]

Regarding the stackoverflow issue: I know this issue, I posted it right at the top of this issue ;)

Regarding the testing version: No, I can't build a version like this. On Android it is not possible to do real Mifare Classic commands. (Thats why only some of the UID changeable tags work).

Regarding the screenshot: MCT looks at the TechList of a tag. If there is no Mifare Classic it means that Android is not able to talk the Mifare Classic protocol with this tag. (And as you can see in the other screenshot with the "Tech" tab: There is no Mifare Classic.) This could have two reasons. Either your device does not support Mifare Classic or your tag is no Mifare Classic tag. MCT tries to find out this reason by parsing several information. This includes the SAK. Because the SAK is 0x20 (which is according to this guide not a Mifare Classic tag) MCT is showing you the message "Not a Mifare Classic Tag".

Regarding a fix: I think this is a issue of the tag. A emulated Mifare Classic tag should not use a SAK thats reserved for Mifare Plus or Mifare DesFire.

[moscowneversleeping]

Then I must modify the MifareClassic.java for correct display TechList information. Can you recommend something else? And you have any idea why once turned to consider the tag using MCT (read all sections with different keys)?

[ikarus23]

As I said. The real fix (from an Android perspective) would be to change the SAK of the tag. A dirty fix (which I will not implement) would be to patch the TechList of the tag to make Android think that this tag is able of talking Mifare Classic.

[ikarus23]

Oh, that is weird. In the screenshot you've taken from NFC Tools, there is a Mifare Classic in the TechList. Did you do this screenshot with a different device? Or a different tag? Or was it just the newer Android version?

[moscowneversleeping]

No. It's my Sony Z3, but Android 4.4.4 (then i install to day). I can Install 5.0.2 and look Tagingo NXP.

If nothing happens, I'll be grateful to you if you tell me a place in the source code to patch the TechList of the tag to make Android think that this tag is able of talking Mifare Classic.

More information about tag

proxmark3> hf 14a reader ATQA : 00 02 UID : cf 6e 2a 0e SAK : 38 [1] TYPE : Nokia 6212 or 6131 MIFARE CLASSIC 4K ATS : 0e 78 80 70 02 4a 43 4f 50 32 34 32 52 32 8d 1b

• TL : length is 14 bytes
• T0 : TA1 is present, TB1 is present, TC1 is present, FSCI is 8 (FSC = 256)
• TA1 : different divisors are NOT supported, DR: [], DS: []
• TB1 : SFGI = 0 (SFGT = (not needed) 0/fc), FWI = 7 (FWT = 524288/fc)
• TC1 : NAD is NOT supported, CID is supported
• HB : 4a 43 4f 50 32 34 32 52 32 Answers to chinese magic backdoor commands: NO

As you can see Proxmark write then SAK : 38 [1] but Android or MCT write SAK: 20 (((

[moscowneversleeping]

More interesting sniffing information when MCT detectable Tag solve the information about it, and showing the message "Not a Mifare Classic Tag". https://cloud.githubusercontent.com/assets/2129699/8023350/ac7aa33a-0d11-11e5-8910-ead5b1b801a9.jpg

results of proxmark3> hf 14a snoop for Sony Z3 Android 4.4.4 with MCT 2.0.4 https://db.tt/F9SLqeYS

---

Now I again updated my Sony Z3 to Android 5.0.2 What news: when i try read tag using TagInfo by NXP "Unfortunately, TagInfo has stopped"

when i want see Tag info in MCT "Unfortunately, MCT has stopped"

results of proxmark3> hf 14a snoop for Sony Z3 Android 5.0.2 with MCT 2.0.4 https://db.tt/moroUCu6

And last, Mifare docor work and show

But NFC Tools 3.8.1 by "wakdev" show

[bildin]

@moscowneversleeping it is strange thing in TechList NfcA occures twice. Let me guess that first (which is also returned by Tag object) contains SAK = 0x20, while second contains 0x18. It may caused by dual mode of this card. So I can try to compile test app for dumping and editing TechList tomorrow. Please contact me.

[moscowneversleeping]

@bildin it would be perfect. As i can contact you? my mail moscowvet@gmail.com

[ikarus23]

Regarding the screenshots from this post: As you can see, the Mifare doctor app failed to read this tag. So does MCT, but it crashes from this failed read attempt. This is a thing I should definitively fix. NFC tool does not show any error because it has not tried to read the tag yet. All the information you can see in the screenshot are handed over to the app by Android. The app doesn't need to read anything to display those information.

[bildin]

@ikarus23 my assumption has been prooved... Techlist contains: 0:IsoDep with histbytes in Extra 1:NfcA with SAK = 0x20 2:NfcA with SAK = 0x18 (at another card with same issue 0x08) 3:MifareClassic with the same Extra as at index 2 (earlier Android had been put null here, so therefor in previous issue HTC reads Extras from this index) 4:NdefFormatible with null in Extra.

I did OR both SAKs and put new Extra to the first occurance of NfcA. It works fine, but it makes me crazy to follow all of these variations.

[moscowneversleeping]

@bildin Thanks for the help @ikarus23 Can you make a changes to the main app code to read/write all available Mifare Classic tags in TehList? This trend will continue in Android 5.* and it will be work with all new phones Sony (Z3 +, Z4 etc)

[ikarus23]

Thanks again, @bildin, for bringing light into the into the dark corners of strange Android Mifare Classic issues! I'm not sure if I got you right on how to fix this. You added a new Extra to the NfcA at index 1? And removed the old one?) With a SAK of 0x20 | 0x18?

Do you think there is a more general approach to fix these issues? Maybe manipulating the list to only contain one MifareClassic and one NfcA entry? If there are only those two, will the MifareClassic.get(tag) method work all the time?

@moscowneversleeping Lets try to find a general way to fix the TechList Extras that hopefully will work for all devices with issues (e.g. the Sony Z3 and the HTC One). I would relay like to implement something like this and not just another fix for another device.

[moscowneversleeping]

@ikarus23 Thanks. For my part, you can always count on quick tests of your application and any other help that I can provide.

[bildin]

@ikarus23 I think more general Tag's cleanup will be something like this (in case of multi NfcA and preserving functionality with other technologies)

    private Tag cleanupTag(Tag oTag) {
        if (oTag == null)
            return null;

        String[] sTechList = oTag.getTechList();

        Parcel oParcel = Parcel.obtain();
        oTag.writeToParcel(oParcel, 0);
        oParcel.setDataPosition(0);

        int len = oParcel.readInt();
        byte[] id = null;
        if (len >= 0) {
            id = new byte[len];
            oParcel.readByteArray(id);
        }
        int[] oTechList = new int[oParcel.readInt()];
        oParcel.readIntArray(oTechList);
        Bundle[] oTechExtras = oParcel.createTypedArray(Bundle.CREATOR);
        int serviceHandle = oParcel.readInt();
        int isMock = oParcel.readInt();
        IBinder tagService;
        if (isMock == 0) {
            tagService = oParcel.readStrongBinder();
        } else {
            tagService = null;
        }
        oParcel.recycle();

        int nfca_idx = -1;
        int mc_idx = -1;
        short oSak = 0;
        short nSak = 0;

        for (int idx = 0; idx < sTechList.length; idx++) {
            if (sTechList[idx].equals(NfcA.class.getName())) {
                if (nfca_idx == -1) {
                    nfca_idx = idx;
                    if (oTechExtras[idx] != null
                            && oTechExtras[idx].containsKey("sak")) {
                        oSak = oTechExtras[idx].getShort("sak");
                        nSak = oSak;
                    }
                } else {
                    if (oTechExtras[idx] != null
                            && oTechExtras[idx].containsKey("sak")) {
                        nSak = (short) (nSak | oTechExtras[idx].getShort("sak"));
                    }
                }
            } else if (sTechList[idx].equals(MifareClassic.class.getName())) {
                mc_idx = idx;
            }
        }

        boolean modified = false;

        if (oSak != nSak) {
            oTechExtras[nfca_idx].putShort("sak", nSak);
            modified = true;
        }

        if (nfca_idx != -1 && mc_idx != -1 && oTechExtras[mc_idx] == null) {
            oTechExtras[mc_idx] = oTechExtras[nfca_idx];
            modified = true;
        }

        if (!modified) {
            return oTag;
        }

        Parcel nParcel = Parcel.obtain();
        nParcel.writeInt(id.length);
        nParcel.writeByteArray(id);
        nParcel.writeInt(oTechList.length);
        nParcel.writeIntArray(oTechList);
        nParcel.writeTypedArray(oTechExtras, 0);
        nParcel.writeInt(serviceHandle);
        nParcel.writeInt(isMock);
        if (isMock == 0) {
            nParcel.writeStrongBinder(tagService);
        }
        nParcel.setDataPosition(0);

        Tag nTag = Tag.CREATOR.createFromParcel(nParcel);

        nParcel.recycle();

        return nTag;
    }

[moscowneversleeping]

@ikarus23 Do you have any news about this issue ?

[ikarus23]

Sorry moscowneversleeping, I'm really short on spare time right now. I will try to look into this deeper soon. However, I compiled a testing version of MCT. This version implements the patch of bildin (just copy&paste). Please try it.

[moscowneversleeping]

Yes, this patch work good! Thanks 27 июня 2015 г. 1:01 пользователь "ikarus" notifications@github.com написал:

Sorry moscowneversleeping, I'm really short on spare time right now. I will try to look into this deeper soon. However, I compiled a testing version of MCT http://tests.icaria.de/MifareClassicTool-2.0.4-testing.apk. This version implements the patch of bildin (just copy&paste). Please try it.

— Reply to this email directly or view it on GitHub https://github.com/ikarus23/MifareClassicTool/issues/64#issuecomment-115902855 .

[ikarus23]

@moscowneversleeping: Great! Thanks for testing. @bildin: If I got the patch right it will fix the Sony Z3 issue and the HTC One issue, right?

[bildin]

@ikarus23, yes, You've got right. Notice, Sony Z3 issue doesn't call exception, so this modification of patch is manipulating with tech list forcefully for all devices to avoid occurrence of these issues on devices with need, but is harmless for devices with no need.

[ikarus23]

@bildin Thanks for making this clear. And thanks again for another patch ;)

[ikarus23]

@bildin Just another short question: Is there a reason you ored the SAK values of the NfcA? Or did you just tested it with 52 as SAK and it worked? Do you think it will work for 24 or 32 as SAK too? Do you think it will work all the time if there only is one NfcA?

[bildin]

@ikarus23 based on http://www.nxp.com/documents/application_note/AN10833.pdf pages 10-12:

3.2.1 Coding of SAK for MIFARE Implementation In case of MIFARE Implementation, final SAK shall be set according to ISO14443-3 and MIFARE SAKs. In case of multi-MIFARE implementation all supported SAKs can be ORed to generate a SAK to be presented.

bit 4 responds to Mifare Classic (1K as default) bit 1 - mini 0.3K bit 5 - 4K bit 6 - ISO1443-4 (in case of @moscowneversleeping)

so, as we tested with @moscowneversleeping 0x20 | 0x08 = 0x28 and 0x20 | 0x18 = 0x38 work well.

In case of only one NfcA oSak == nSak and patch doesn't touch SAK in extra.

I' m not sure what did you mean with SAK 52? It is mistype of 56, isn't it?

[ikarus23]

@bildin Thanks for clearing that up! And of course I meant 56, not 52 :)

[jlanza]

@bildin I have checked the code you provided in our application and the tag is detected and SAK is the correct one. But the problem is that when we try to read the memory from the MIFARE card we got an exception that the tag is lost. Any idea?

[ikarus23]

I have created another testing version of MCT with a slightly modified version of bildin's patch (just code structure). Could somebody please test if this still works for a Sony Z3?

EDIT: Updated link

[moscowneversleeping]

@ikarus23 Sure! One minute;)

[moscowneversleeping]

@ikarus23 All right!

[moscowneversleeping]

No) I can Read, but i can not see Tag Info App failed when i try see Tag Info

[ikarus23]

Thanks for testing! Were you able to display the Tag Info with the first testing version?

[moscowneversleeping]

failed too (

[ikarus23]

Thanks again. Ok, as far as I remember the Tag Info tool does not patch the tag object. I think this could cause the issue. I will look into this and be back with another testing version as soon as possible (sorry, not today).

[moscowneversleeping]

See you

[ikarus23]

I've created another testing version. Please check if reading, writing, and the Tag Info tool is working.

[jlanza]

@ikarus23 it seems it is working correctly now. Could you please post the diff code? ;)

Edit: NO IT IS NOT WORKING. The card is correctly detected but it is unable to read the memory data.

[ikarus23]

Arrrrrg! But thanks for testing :) Was reading a tag working with one of the previous testing versions?

[jlanza]

Unfortunately no. We got an exception. It is quite strange as the Tag instance seems to be ok. Then we authenticate and it returns true. But if you get into the functions, the authentication fails.

And therefore, afterwards reading is crashing with and IOException indicating the tag was lost.

Hope that helps. We can try to work something out, but we are "as lost as you probably are". It is just the d**n Z3. Do you know which chipset it includes?

On 06/07/2015 19:26, ikarus wrote:

Arrrrrg! But thanks for testing :) Was reading a tag working with one of the previous testing versions?

— Reply to this email directly or view it on GitHub https://github.com/ikarus23/MifareClassicTool/issues/64#issuecomment-118931510.