How to CREATE DUMP + DOWNLOAD it through TeraTera + how to UPLOAD it

[pavol82]

Hi everyone, please here on this website + in manual unfortunately I cannot find any solution regard "How to CREATE DUMP + DOWNLOAD it through TeraTera + how to UPLOAD it"

Please, can someone help us how to do it just through TeraTera or some another software through windows?

1) CONFIG=ISO14443A_READER 2) IDENTIFY 3) DUMP_MFU 4) CONFIG=MF_ULTRALIGHT 5) DOWNLOAD then my file is empty and UID is 0000000

Thank you very much everyone for assistance.

[maxieds]

The last time I checked progress on this much requested feature had not been completed (though many users have asked me about adding it in the Chameleon Mini Live Debugger application). I believe there is currently a working CLONE command which will clone the UID for the card/tag only. Some older Mifare (Classic or Ultralight?) cards may have weaknesses in them which will allow you to snarf the whole contents of the tag bit-by-bit, but in general this is not possible, again to my working knowledge.

On Android there's the NXP TagInfo app which is able to print quite a bit about the tag data with the exception of the encrypted and/or locked fields where you would need a key or password to get at this data. Basically, my suggestion is to read the binary data from the tag systematically using a sequence of directory listing, file listing, etc. APDU communications, then get the data which you can obtain, and then work on feeding this to a blank slot with the correct CONFIG=<TAG-TYPE> setting (if it's available in the current firmware). Perhaps a sequence of SEND or SEND_RAW commands to the blank slot would effectively write data into the blank slot? Someone else should weigh in here though.

In short, no there's not in general a good way to accomplish this task at the current time except for possibly in some rare and very special cases. Sorry to break the news.

[ceres-c]

If we're talking about mifare ultralight (non-EV1) it shouldn't be that hard to write an application to dump data and save it to an empty setting... I don't have the time to look into this due to other ongoing researches, but I am pretty sure you could do it yourself @pavol82. Both reader and emulation codec are ready, so you could build on that basis.

[maxieds]

@ceres-c @pavol82 Some of the implementations of the dump image formats for the various configuration types are going to depend on the internal format of the card contents (and hence the dump images) to run correctly. What I think this means is that you are going to first need to completely dump (again, the unencrypted portions on an EV1 tag) the contents via a sequence of APDU commands. I believe this can be accomplished with the SEND and SEND_RAW commands. Then you are either going to need to find another mechanism for re-translating this read data with the Chameleon to the blank slot with more send commands, OR possibly if you know the internal tag format like NXP does, write an external C utility which will create a raw dump image that can be loaded with XModem and UPLOAD. Does this sound right?

The second option is why I have considered incorporating such a feature into the Chameleon Mini Live Debugger Android application I have written. Though this seems to be no small task and I really do not have time to start trying right now :(

[ceres-c]

I believe it'd be easier to create a specific application devoted do dump-and-emulate behaviour. Doing so you could wait for a tag in field, then identify it and if it's the right kind of tag (mf ultralight, in this case) send the appropriate commands as a reader to get all the data. This data from the tag will be written to memory (that should start off empty) in a format that fits how mf-ultralight emulation application wants it to be. It's just a matter of reading the correct header file when developing this novel dumper application. Then the application switches the chameleon to emulation mode (changes the codec) and enables the correct emulation application (mf ultralight, again).

I'd do it this way, at least.

[pavol82]

If i buy proxmark3 can I through them easily sort this issues with decryption + download that final DUMP + then implement it into chameleon?

Or exist another easiest solution? Honestly I need just clone NFC tags but these NFC tags has UID and I dont know how to emulate these UID... I can use copy hand electronic tool but they will copy on another NFC tag where UID will be different and this is problem (I am not expert but what I can see it is like this).

Unfortunately I need to emulate NFC tag and I am just getting stuck that I cant either dump.

Regard Chameleon Debuger, can I ask how can I do it easily? Or email me it?

[ceres-c]

@pavol82 which tag do you have exactly? Use NXP TagInfo app and let us know what you're trying to emulate. Probably the solution is way easier than we thought before, if I understood correctly.

[maxieds]

@ceres-c Actually implementing this read and dump command in the Chameleon firmware would be a complete solution to this often asked feature request on these issue pages about finishing the implementation for the CLONE command. Again, currently CLONE only clones the UID of the tag its reading into the current slot. This would be a very nice and useful feature for a PR, no? Is anyone actually up to the challenges involved here?

Note that it might be easier to actually start with a single or a couple of easy configurations for which the APDU command set needed to parse the contents of the tag is ostensibly smaller. For example, start with getting a working CLONE implementation for MF_CLASSIC_1K, then the Ultralight tags, and so on. I would have to assume that this is a sane, if not the most reasonable approach, to finishing CLONE. Tags like the DesFire EV1 are necessarily going to be more complicated to read with nuanced tag substructures and possibilities than older standards (see this implementation and its docs for reference on the tag format).

[pavol82]

NXP TagInfo from store (NFC TagInfo by NXP) is impossible download it, its seems gooble blocked it [http://www.ocity.net/tmp/aa.jpg]

[ceres-c]

@maxieds I'm actually thinking about doing this for NTAG cards. I'm working on those with @gcammisa and, once emulation is done we could be writing that auto cloner. Of course, in that case, it'd be made for NTAGs and it should be ported to other tags, but we'll try to write code as easy as possible to port.

@pavol82 Download the NXP app from ApkPure (no geo lockings there) and dump the data with that app. You should be able to emulate it if it's a mifare ultralight. NTAG support is still missing but, as I said before, I'm working on it with a friend of mine and should be ready sooner or later.

[maxieds]

@ceres-c Yeah, that's what I just suggested in my edited comment above. Start with implementing CLONE in full detail on small easy cases first, and then gradually build up to be able to clone more tags as more people contribute PR's for their favorite tags in application.

@pavol82 What country are you in? I have an active install in the US.

[pavol82]

http://www.ocity.net/tmp/tag.txt

Thank you guys for assistance, please If i will buy proxmark it is possible dump it easy and then same dump implement into chameleon?

I am UK at the moment

[maxieds]

@ceres-c Let me know if you need any tips or help with the firmware hacking. I've been working on development with it on a fairly stock Linux distribution and have run into oh so much growing pains with avr-gcc and avr-libc. In some instances it's easiest to just install the AVR toolchain from source so you know what libraries the avr-* binutils commands are linking against. One problem I ran into at least...

[maxieds]

@ceres-c The reason I offer is that this is very much a feature I'd like to see improved, but I really don't have time to launch into trying to solve it myself right now. Anything I can help with in getting this feature more off the ground than it currently is sounds good to me.

[maxieds]

Are the NTAG variants going to extend the generic ISO14443A reader configuration? The only active non-generic configurations I see here is for the Mifare classic and ultralight tags. I believe these are different from the NTAG specs based on my experience with raw NFC in Android. If this is the case, it might be easiest (though less interesting in your applications) to start again with the MF Classic configuration CLONE implementation just to get a rough structure to build on in place for other contributors to submit PR's for their favorite tags in practice.

[ceres-c]

@pavol82 No need for a Proxmark, you already have the data you need. See those hex bytes in the lower end of the file you posted here? That's memory content. You can't yet know if it's full memory or if it's protected and then read as 00 since you're not authenticated. You better read NTAG 21X datasheet to understand what I'm talking about. Also, at the moment you can't emulate the data (even if that is a complete dump) because NTAG 21X is still not supported by the chameleon. As I wrote before I am working on it with a friend of mine. You could start to work on your implementation or hope all goes well for us and we deliver soon :-)

@maxieds I've got a good degree of thinkering with the chameleon. I had to fix a bug with iso15 codec (that damn interrupt) and wrote an iso15 application from scratch. Yep, sometimes this thing is... Peculiar, but believe me, nothing like the Proxmark. That is a whole new level of codebase nastiness. ;-) Thanks for the help, though, I might ask you to take a look at my iso15 branch and maybe think about adding support in your app for titagit and em4233 :-)

We'll see how NTAG emulation goes. If that does not take too much time we could actually implement cloning, but I can't guarantee given that we're very busy with other projects in this field with higher priority, at the moment

[maxieds]

@ceres-c Glad to help any time with the iso15 branch. I'm more responsive over my gmail usually though.

I'd be happy to take a look at adding more specific tag support in my app. The only thing I worry about is supporting non-standard builds of the firmware (~171 forks of this repo so far, including at least one of my own to count). Have you submitted PR's for the tags to the original firmware sources (or will you)?

[pavol82]

@ceres-c Thank you really much for explanation. Please can I download real raw dump from this app? I can use this app for future dumps but i dont see any save or export. Thanks for help how to dump file at least in some way.

[ceres-c]

@maxieds Yes, my code has been merged into @bosb PR: https://github.com/emsec/ChameleonMini/pull/182 Still it hasn't been yet merged in master due to unknown reasons. The mantainers look busy at the moment. We'll wait for the merge :-)

@pavol82 You can't get a binary dump, but you can copy-paste that hex data into an hex editor if you wish. Or, if you need to perform many dumps, you could write a python script to perform a regex and write the output in binary to file, as I did

[geo-rg]

@pavol82 You may want to read this.

@ceres-c As you guessed correctly, we are super busy. However, we really hope that we can merge your great work within the next three weeks.

[ceres-c]

@geo-rg Thanks, I'll update you on the other matter soon. We're working on some stuff