Adding support to the firmware for DESFire emulation?

[maxieds]

I read #31 and #117. It seems like the topic of support for the DESFire tags is at a standstill. If I start working through the code in this repo, is adding the support for DesFire tags still welcome as a pull request?

[geo-rg]

Hi @maxieds DESfire emulation would be nice, so it definitely would be welcome! However, please note that @dev-zzo has a very good start to the emulation in his fork. So you should start there instead of starting from the scratch.

You also have to consider that the app code is vastly different than the chameleon code should look like. The app is written in Java, which is a very dynamic language, but for the Chameleon you will have to write C for embedded devices. For example, this means: you cannot simply malloc around, but you will have to build your own malloc for the FRAM, since the DESfire emulation needs dynamic allocation (just as an example, because I think, @dev-zzo already has a solution for this).

[overlinden]

I would also be very happy if the support for DESFire will be further developed.

[MAVProxyUser]

Anything new here ?

[floppywiggler]

+1 for this

[street-grease-coder]

+1

[maxieds]

I was honestly a little disappointed with the purported fantastic new firmware features in the new proxgrind devices when I tested them. This is a project that has been on my back burner for a while. I think it's time that a semi-standardized version of some of the desfire support in some forked repositories be made easier to consume.

I'm tied up at work until the beginning of May. After that, I will make it a priority to spend a week of my afternoons putting together my attempt at this functionality. Would someone please be kind enough to remind me of this project at the first of the month? (Any of the +1'ers?)

Are there any specific guidelines that I would need to be aware of before submitting a pull request? I have hacked through the firmware enough before to be confident that I can do the Java to low level C translations, but have never been subjected to the rigor of a PR for the proper Chameleon firmware sources before.

On Tue, Apr 7, 2020, 2:21 PM street-grease-coder notifications@github.com wrote:

+1

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/emsec/ChameleonMini/issues/218#issuecomment-610545490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJDROHXNIUPT544ULUNIDLRLNVLHANCNFSM4HEMZ7RA .

[karimodm]

was honestly a little disappointed with the purported fantastic new firmware features in the new proxgrind devices when I tested them

I was checking the firmware for their Chamaleon-Rebooted boards (https://github.com/iceman1001/ChameleonMini-rebooted), but I don't really see how are they improving stuff over the base project in any significant way. I mean GUI is nice and all, but are they developing any firmware stuff related to DESFire @maxieds ?

[floppywiggler]

was honestly a little disappointed with the purported fantastic new firmware features in the new proxgrind devices when I tested them

I was checking the firmware for their Chamaleon-Rebooted boards (https://github.com/iceman1001/ChameleonMini-rebooted), but I don't really see how are they improving stuff over the base project in any significant way. I mean GUI is nice and all, but are they developing any firmware stuff related to DESFire @maxieds ?

I've come to the same conclusion. They are purposefully misleading in their claims here. No custom firmware has been built it would seem, and they rely on iceman code for the gui AFAIK.

As you say, no significant change or contribution.

[street-grease-coder]

@maxieds bump

[maxieds]

@street-grease-coder I have made some promises that I will not release public code to go further towards DESFire support in the firmware until the end of this summer. This is not something I could have foreseen before when I said I would try to get this working. Sorry for the delay.

[bayan9]

@maxieds so how do we get private access for those who have been in this chain without violating your promises?

On Mon, May 25 2020 at 00:57, Maxie D. Schmidt < notifications@github.com > wrote:

@street-grease-coder ( https://github.com/street-grease-coder ) I have made some promises that I will not release public code to go further towards DESFire support in the firmware until the end of this summer. This is not something I could have foreseen before when I said I would try to get this working. Sorry for the delay.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub ( https://github.com/emsec/ChameleonMini/issues/218#issuecomment-633435543 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AFLGOUOEYUWVBAPBH5FAGK3RTIQE3ANCNFSM4HEMZ7RA ).

[maxieds]

@bayan9 Sorry. Not the way that works. Bump me again over this thread towards mid August. You can help me test things then.

[ceres-c]

@maxieds This sounds much like a responsible disclosure timeline. Should we expect some interesting news about DESfire in the coming months? :-)

[maxieds]

@ceres-c I cannot comment either way. I promised some unknown persons that this isn't getting done until after the summer has passed.

I have an oral exam and other things I have to get done for my Ph.D. at school in the meantime. For all you know, my life could have been threatened in a non-standard way by angry math people if I insist on writing code right now.

The project has been started. It will eventually get to testing point. This has already ben a feature request for years up to this point.

[street-grease-coder]

a-bit-early bump

[maxieds]

@street-grease-coder I do officially have some private sources that I am not yet ready to make public. I have the starter code from @dev-zzo's original repo re-integrated and ready to go, new sources for 3DES/AES tested as working, and some other code that I am currently not able to test. I will not make the repo public until I am minimally confident that it would even be worth having users actively testing it while I know it still needs development work.

A couple of things:

This is at no discredit to @dev-zzo for not having this DESFire stack up and working like a champ. In fact, there a number of subtleties that arise in the implementation, not the least of which is that specs are scarce. It's also important to notice that all of the requirements (especially memory space for the crypto structures) really pushes the limits of what the integrated AVR chip on the Chameleon devices can do. It wasn't easy to get all of this nicely cooperating.

My code currently fails (most of the time) in the anti-collision loop with my cheap USB NFC adapter using libnfc. Sometimes it works like a charm, others the reader will not even pick it up. (Sigh) It could be an issue on the Chameleon with calibration? Not sure.

What I'm really thinking is that I'm going to need a more professional reliable tool like a proxmark to make sure I am actually getting through what I think is supposed to hit the Chameleon DESFire configuration. Then fix my f*ing fortress of C code if and only if the reader sending out the bits actually does what it is supposed to. Unfortunately, I have this sneaking suspicion that this detail is something some of you all smiling NFC hardware nerds neglected to tell me when I said I would take this project on...

So with this in mind, can some of you all help me figure out what type of proxmark and/or supporting hardware I will need to obtain to finally test my firmware mod adequately, and get this whole feature request working and on the road? I have seen proxmark kits from $100-320. I really do not know what to buy. Budget is going to be an issue for me right now. Any suggestions?

[lvandenb]

If the problems are in the anti collision loop, this means it is stuck in the 14443A -3 protocol. https://www.nxp.com/docs/en/application-note/AN10834.pdf So a Omnikey reader ( CCID ) wil not even get the ATR ?

[ceres-c]

If you want a cheap, reliable and configurable device you can use the ST M24LR-DISCOVERY dev board: it's basically an STM32 driving a CR95HF NFC front end. Being a dev board the sources for STM firmware are available and (pretty) easily editable, if you ever needed to. It can be used with the demo software or with python via simple HID commands.

Or you can buy a Proxmark for cheap on eBay: 36€ if you apply the PITLONG20 coupon listed on the item's page. Some of my friends use these ones and, after some initial issues with the older bootloader which must be upgraded, they're kinda fine.

--Edit-- By pure chance I stumbled upon this issue on the PM repo https://github.com/Proxmark/proxmark3/issues/916#issuecomment-607260923 in which @pwpiwi complains about RDV3 Easy issues. Given his experience in Proxmark's codebase, I'd like to retract my take about the "acceptable reliability" of the Proxmark3 Easy on eBay. If you want a proxmark go for the proper ones (RDV3 or RDV4)

[maxieds]

@ceres-c @street-grease-coder I am more interested now in just testing the functionality of the DESFire based commands. Unfortunately, and with the historic code from @dev-zzo, this comes at a penalty of having to do the anti collision loop. I will look into your suggestions.

I made my current sources public here: https://github.com/maxieds/ChameleonMiniFirmwareDESFireStack. I am fully open to pull requests if anyone wants to help me figure out what is up with the anti collision loop. I think I can take a good look at the rest of the implementation once that part is handled. As it turns out, I may have some funding available at school to motivate me to spend more time on this.

The sources compile on MacOS and Ubuntu (cannot vouch for Windows). The current binaries are out of date and need to be recompiled.

[ceres-c]

Haven't yet looked at your code and I can't promise I will, since I'm trying to stay away from computers for a while. Though, I'd like to point out that the M24LR board does not force you to perform the anticollision step. You can send raw apdus or frames

[maxieds]

@david-oswald I just had an extraordinarily frustrating experience on the discord channel. It has occurred to me that the proxgrind developer team and iceman's sources are capable of basically ripping the code for the DESFire stack I have written so far off my back, do so without credit, notification or even implicit blessing on my part, and otherwise behave like sharks rather than ethical professionals at work at their craft.

If you all can find it within your heart of hearts to bear with me, I want to make it perfectly clear that once my DESFire code is more functional, and tested within reasonable satisfaction, I would like to help with the merge process to get it into your original emsec firmware sources. This can be delicate as the implementation necessarily pushes the limits of the memory on the integrated AVR chip. All of the modifications I have had to make so far are well within my memory, so if you end up needing me to custom merge my approximate "fork", or snapshot of your sources with a more recent snapshot at that time, then I will be happy to do so.

[maxieds]

Also, on a semi-unrelated note, I have some firmware mods that I wrote to support AES encrypted XModem uploads housed here. It does some custom, and from my experience very hard to get fine tuned just right, work integrating a C++ crypto library into the C sources for the stock firmware. The one really fantastic thing that the C compiler lets you do is support the indexed enumerations like in this file. OTOH, C++ is really better for lots of things like crypto library wrappers.

The relevant examples in the source code are here, among a few other places if you want to dig around the sources:

• ChameleonCrypto.h
• AESCipherType.h
• AESCrypto.h

This is just a FYI for firmware hackers making their own custom mods. Enjoy the free code. 🍻🍻🍻

[maxieds]

@lvandenb Can you elaborate a little more to help me figure out how to get through the anti collision loop? When I was testing the stock Chameleon MifareClassic and MFU configurations also wouldn't work with the target USB stick I initially bought for testing. Is this possibly something that could be a problem with the codec-related code in the firmware (not supporting the latest, greatest ISO-4 standard)? For example, I remember reading something like there being a parity setting to add support for the newer ISO standard in the libnfc docs. This would be something that gets appended by the codec mod/demod code, correct, not from within the DESFire emulation part of the code? Any help here is much appreciated.

FYI, I'm still working with the same Identive SCM SCL3711 USB stick that is compatible with libnfc right now.

[Akisame-AI]

You really misunderstood a lot right there....We wouldn't take your code without asking. I was referring to Yes, with respect to the under documented BLE support, this is also a problem for users on laptop or desktop machines. I also really do not appreciate the lecture about my motivations when at the heart of it the Proxgrind people are playing games with a very spiteful anticompetitive spirit. This is appaling to me on multiple levels, not the least of which is that their devices are very closely based, and mimic, open source hardware designs and firmware. Again, NOT COOL!

Sorry for the misunderstanding. Also....having a minimum level of respect for others may help you in your future life.

Edit: the full conversation from the point it went downhill. If you want the full complete discussion just comment and I'll edit this post.

iceman1001Today at 2:13 PM
There are things to be upset about for the choice of using a packer,  a closed source android app,  in order to make money.  It would be nice if everything in life was free but in the end even developers must pay rent and eat,  so I even if I promote open source,  I understand why RRG closed sourced it. Trusting Chinese developed apps seems to be a hard thing in the US right now.  Trust don't come easy.
There was a mentioning of the mini BLE was detected even if you put them in the kitchen. The BLE used with the chameleon mini should reach quite far, like 30m.  One of those brand state-of-the-art nordic chips.  Like @linuxgemini  says,  I really can't find anything that is validated with proof or evidence in the accusations you have made.

Besides stating the obvious, another thing to consider is that you are making a competing Chameleon android app.   Now, I don't think promoting ones app by throwing shit on the manufacture app is a good way.  Usually I say,  we improve by making things better and show what is better,  not by trash talking competition.   I do believe there is room for many more android or ios apps which talks with chameleons, pn532, rfidler, proxmark3 etc.  We haven't seen the best yet.   Same goes with the GUI,   there is a bunch of GUI's and I think they can be better as well.

I will not spend more time on this,  if you feel like you are even more furious and unhappy about this,  you are most welcome to ventilate it here. 
Who knows if it brings some change but after threatning to report to buqtrack and making your repo and the issue on chameleon mini repo,  I doubt that.   You seem determined to chase windmills.

Maybe someone here has a solution for the BLE interoperability problems?
...If that darn app was open source,  the community could have improved it....  but it is what it is.

roblo123Today at 3:48 PM
@iceman1001 First, there is also this: https://github.com/emsec/ChameleonMini/issues/271#issuecomment-679997658. Whatever the hell they are packing is very not cool.
@iceman1001 With respect to the competing app theory as motivation or somehow their app being competition, the app is freely available, open source, available for free on Play Store via an account I personally paid for. More importantly, despite the existence of a rarely trodden paid flavor, I have yet to receive a penny of that money as I will not give Google my routing number. Maybe someday I should donate all $250 by now to a charity.
@iceman1001 Yes, with respect to the under documented BLE support, this is also a problem for users on laptop or desktop machines. I also really do not appreciate the lecture about my motivations when at the heart of it the Proxgrind people are playing games with a very spiteful anticompetitive spirit. This is appaling to me on multiple levels, not the least of which is that their devices are very closely based, and mimic, open source hardware designs and firmware. Again, NOT COOL!
@Akisame WRT https://github.com/maxieds/ChameleonMiniFirmwareDESFireStack/commits/master: Please first note that this firmware is not yet functional, much less full featured for a multi-version inclusive DESFire stack. It is my preference that pull requests be generated to improve the existing code instead of forking, taking the hardest [art of what I have already had to do, and then screwing your own. If you do take the latter route, keep in mind that the new additions to support the DESFire tags are GPL. This means you need to maintain a clear paper trail, post your sources, and do so very publicly with a link to the original repo.

aveToday at 3:58 PM
@roblo123 one semi related question now that you brought it up, did you use the desfire datasheets when doing that?

AkisameToday at 3:59 PM
aah, It was my understanding that it was already semi-serviceable. It may be an idea to change the readme.md to reflect that. At the moment I have no need for copying desfire cards. The suggestion was in response to a request from a user asking for help with a desfire card

iceman1001Today at 4:10 PM
Nobody here breaks open source licenses or violate closed source licenses,   how would that look like?   Morale high ground will disappear.

AkisameToday at 4:55 PM
ooh, if I may mention this. Although it is not in the spirit of open-source it unfortunately is extremely common for companies to take open-source code and designs and implement them in their closed source products. 
If you don't agree with that practice all you can do it not use their products. 
There are indeed some things which may be unusual about the chameleon app of which the biggest complaint is that is has connection to the internet. As linuxgemini mentioned you can sniff this web traffic and you will find that is a time sync. If you are concerned about this it is quite simple to deny an app internet access. 

In regards to iceman's theories about your potential motivation for your fervor with which you try to find suspicious things in the app:
All we can see is that you have a competing app with a paid flavor. We can't see that you haven't collected the money you made with that. 
Also...please understand that I mean no disrespect but you seem a bit... upset about a lot of things. (referring to https://github.com/maxieds/ChameleonMiniLiveDebugger/issues/26 ....I have to agree with google here. Sorry. Collecting user data is very suspicious and normal apps shouldn't collect that)

I have some kind advice: It may be an idea to tone down the politics. US politics are hopeless and nothing good will come of it.

Anyway, I hope you enjoy the rest of your day. I'm out. cya

roblo123Today at 6:17 PM
@Akisame RE: The DESFire stack code that you assholes would literally rip all the hard work off my back for, you need to realize that if you expect to take someone else's hard work and code without credit, you need to pay them very well a hefty salary for it. https://github.com/emsec/ChameleonMini/issues/218#issuecomment-680055556

@Akisame From Prof. to small minded intellectual peasant: Piss off, and FUCK YOU TOO!! I'm off this list.

Take from it what you want but in my honest opinion we were polite at every point. It is "NOT COOL" to go talk bad about others afterwards.

edit2: For full clarity I'll post here what happened afterwards.

DennisRRGToday at 7:21 PM
Olaf was thinking to give her the source code to keep her sane but we decide to see how it progress first. We believe it will do us more harm than benefit over time.

DennisRRGToday at 7:26 PM
She first came wanting lab401 to promote her APP and delist ours from google playstore.
Then said our app is shitty and a malware. She threaten us with bugtraq.
Then escalating it to the official repo
Then to here
All these in 2 days
Yes. We will try to be better

DennisRRGToday at 7:27 PM
She didnt even give us time to rectify or explain
Until today, I am lost in the convo on what is happening
I don’t even have time to write a detailed report to Olaf just yet.
Olaf is preparing the materials in the meantime. If anyone in this community, need the BLE API for your own usage, feel free to reach out to us. We are not against open source but we are just against the copycats in China always eyeing on our products.
#Sharing is caring
We need money to run our business and continue to r&d cool stuffs. So bear with us being not cool with sharing too much openly.

doegoxToday at 7:38 PM
Well if someone is making an opensource app compatible with your BLE API, the API will be de facto public, so maybe you can already publish it. You're making money from the device, not from the app.

DennisRRGToday at 7:39 PM
That’s the part we are afraid. I will tell DXL to push it up to Github tomorrow. No problem on that.
Well. Hope our move will help change the situation a little.
Sorry for the big hoo haa guys.
My apologies

doegoxToday at 7:42 PM
thanks Dennis

iceman1001Today at 8:22 PM
Yeah,   let ppl learn how to speak with the BLE API,   maybe things in the community will lighten up.

@roblo123 does raise some valid question about  it and seem to be under much stress.   It is not the first time an open source contributor gets pissed off at ppl forking and making something that is more ...
I have been there myself.   But as I said,  the best way to compete is to make something better.

And as @doegox said,  we don't tolerate bad language and disrespectful behavior.   Everyone is welcome here to ask questions and learn if they are willing to.   Don't expect answers.

There are many parts of the firmware/client of the different open source repositories which can need some love and cheering.    A star is a start, it doesn't cost you anything.
Making a pull request with a fix, is even nicer,
If you wanna contribute to ppl,   you can just contact them and there will be away.

 Give some love to @roblo123 for that impressive work on that desfirestack for chameleon.

[maxieds]

I think that reproducing that snippet of a much longer winded discussion, or more to the point the last lengthy little diatribe I was subjected to that led me to leave the channel, is VERY MISLEADING. I no longer have access to it, but in the event anyone wants to hold me to some insidious accountability for that which you just quoted in the last post, please do apply reason and take @Akisame-AI's commentary with a grain of salt. In fact, I will politely request that some discord user of that channel post the aforementioned rant at me in full paragraph form (clear which one it is from context). My inability to appreciate this sort of back handed nonsense is unmoving, in general.

Update 4:

In light of the fact that @Akisame-AI cleaned up and edited some of the filthy view points that would make some developers on the discord channel look bad from yesterday, I am reciprocating by removing some of the petty and inflammatory remarks I made back at a few of them. (Edit history intact)

[maxieds]

@roblo123 one semi related question now that you brought it up, did you use the desfire datasheets when doing that?

Well, in principle, I suppose that can be inferred from context. I signed no NDA and all consultation with the DESFire specs that I have had available are publicly available -- and hence, longstanding public knowledge.

[maxieds]

I also want to clarify tone respectfully to any users who get the wrong impression about my attitude to adding headers to my DESFire source code:

/*
The DESFire stack portion of this firmware source 
is free software written by Maxie Dion Schmidt: 
you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the 
License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

The complete license provided with source distributions of this library is available at the following link:
https://github.com/maxieds/ChameleonMiniFirmwareDESFireStack

This notice must be retained at the top of all source files in the repository. 

This source code is only licensed for 
redistribution under the above GPL clause for 
non-commercial users. All commerical use or inclusion of this 
software requires express written consent of the author (MDS). 
This restriction pertains to any binary distributions which 
are derivative works of this software.
*/

What I added to the DESFire firmware source headers does not restrict individual users, even if they use their own compiled versions in commercial applications. What it does is restrict most vendors from redistribution of source or derivative work binaries en masse. :trollface:

Thank you all, that should be enough from me today. Can we please get back to the technical aspects I am currently struggling with in the implementation?

[maxieds]

@david-oswald Can we please close this now filthy issue thread? We should resume the discussion about technical details to the implementation at the issue on my firmware repo.

The DESFire stack I have publicly available is not quite there yet. Will be soon enough. I can start a new issue about how best to merge sources if you all are still interested in emsec native DESFire emulation when the code is well tested and ready for prime time.

--Maxie

[ceres-c]

I've often seen Chinese developers using packers, not only with mobile apps, even for totally legit applications. Why do they do it? I don't know, but they still do.

I'm happy Dennis from the RRG group agreed on posting the BT API specs, which will allow app developers to interface with that hardware revision. I don't know what happened on the Discord channel, but I doubt @iceman1001 or @doegox have any interest in stealing code or keeping the application closed source.

The proposed GPL alteration collides with the general GPL philosophy and, I believe, would make the Chameleon unsuitable for professional uses (pentests), heavily limiting possible uses of the code. Given the permissive official license Chameleon's codebase is distributed with, it would also become hard (if not impossible) to merge the code in the official codebase. This is my personal take on licensing, I'm not a legal scholar, but I believe these points should be considered.

I'd like you all to cool down since the discussion got pretty heated up and this is not the right place to discuss licensing/ethics of a different project, loosely related to this one. This comment also applies to https://github.com/emsec/ChameleonMini/issues/271

[david-oswald]

First @maxieds thanks a lot for picking up the DESFire work, really much appreciated. We'd certainly help with merging into master when ready.

But I also see a big problem with GPLing the code, the ChameleonMini has a non-GPL for several reasons (as pointed out by @ceres-c). Merging GPLed code in would be tricky. As a minimum, I think you'd anyway need to check with @dev-zzo because he wrote already quite a bit of code (under non-GPL I assume).

[doegox]

Moreover the clause This source code is only licensed for redistribution under the above GPL clause for non-commercial users. is not valid with GPLv3. See https://www.gnu.org/licenses/gpl-faq.en.html#NoMilitary and GPLv3 Article 7 All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.

[ceres-c]

Yup, as I tired to point out this is a nonstandard GPL modification. There are other licenses more fit for this purpose, but there would still be practical issues when using the device in pentests. Thanks for pointing out to that particular article of the GPL, though, it might come in handy to know about its existance.

[dev-zzo]

Heyo. I'm here to clarify that all public code I've written is covered by the glorious "Do What The F*ck You Want To Public License" so you are free to do exactly that. I'm happy with being credited where appropriate, of course. :-)

[MAVProxyUser]

sadly @ceres-c as wax poetic as anyone wants to be on GPL licensing, it is not enforceable. Even when pushing FSF or SFConservancy to enforce the "rights", you'll find unless the company is HUGE and made of money (like VMWare) there won't be a lawsuit to solve any GPL licensing.

That said, many folks in the community are staunch GPL pedants and will have pitchforks out for various reasons if GPL code isn't handled properly. There is NO GPL Police though. Enforcement isn't really a thing.

[maxieds]

There seem to be three issues in the posts today to address:

Credit for prior source code

@dev-zzo Can you please provide me with a credit string that I can append to my headers that you are comfortable with? It is by no means my intention to suggest that all of the DESFire sources in my development repo are original. I had to do a lot of reworking, reorganization, a few bug fixes, and then start appending my own newly written code to arrive at the current semi-functional implementation. For example, in the MifareClassicToolLibrary code I came to an arrangement with @ikarus23 where we agreed upon shared header credits and README links to attribute that it was derived from his OSS code (see this file header). I have credited your sources in a separate credits file in this directory, though not in every single file I might have used some of the original DESFire stack code.

RE: Agreeing upon a non-GPL license for inclusion into external firmware sources

I don't know what happened on the Discord channel, but I doubt @iceman1001 or @doegox have any interest in stealing code or keeping the application closed source.

I do not appreciate the personal attacks, digs, nor the spin on events transpired I suffered yesterday by some public and private troll talkers. Much of what was said by Dennis and others was voiced on discord only after I intentionally left the channel (8 hours into that discussion). My email requests to talk with multiple parties (D, lab401, etc.) have been hostile or non-existent. The license I appended was not in reaction to @doegox nor at @iceman1001, both of whom were much more forthcoming and willing to chat with me over email when I pinged them -- and even in my filthy mood these last few days.

I am willing to compromise and modify the license provided that I can keep sane credit headers (that must get preserved) on the source files I created, or significantly authored.

@david-oswald: Is this going to be sufficient to go forward with an eventual merge even if some of the crypto library sources I used are still GPL by header comments? That is something I cannot change, and that is prohibitively painful to write or derive from scratch!

In general, those of you who posted here today have the right viewpoint about acting more as a community. I do not think we should hide what transpired, but instead just move forward working together and try to drop personal issues that will divide users and developers alike in a partisan manner. OSS holy wars tend not to be pretty anyway (three cheers for three BSDs, anyone?). Multiple people lost their cool. Enough said really moving forward.

BT BLE device specs from Proxgrind

I'm happy Dennis from the RRG group agreed on posting the BT API specs, which will allow app developers to interface >with that hardware revision.

I was not aware of a public statement that this was forthcoming. Would someone please ping me when this happens with the spec whereabouts or link? I am not unable to support BT device connections in my Android app without more knowledge of the specifics of the proprietary implementation.

---

Update: Following from @doegox's suggestion to keep these threads mostly uni-purpose / uni-topic, there is a link here.

[maxieds]

While we seem to be posting about disparate topics somewhat within this thread, I want to use this venue (more starred, auto-notified users) to alert users of my Android app (Chameleon Mini Liver Debugger -- com.maxieds.chameleonminilivedebugger), who have installed via a Play Store APK source to please upgrade to v1.1.8 immediately! Without going into conspiracy minded theories about how Google let this happen, I will just link to my GitHub CVE denied endowed security advisory to explain the issue. Thanks, and resume, or continue, so to speak. 😸

[doegox]

Would someone please ping me when this happens with the spec whereabouts or link?

@maxieds they published it, I'll send you a mail to avoid hijacking this unrelated issue.

[maxieds]

@dev-zzo My proposed headers will include credit to your code as follows:

Based in part on the original DESFire code created by 
@dev-zzo (GitHub handle) [Dmitry Janushkevich] available at 
https://github.com/dev-zzo/ChameleonMini/tree/desfire.

Does that work for you? It's fine with me (+/- bleeping either way) that you have "Do What The F*ck You Want To Public License" written above, but some folks strangely won't find that palatable.

[maxieds]

I have had some time to get a lot working with my DESFire emulation support for the firmware. A checklist style table that shows expected working functionality from my host-side testing code provides an outline of what I am still actively working on and developing without user testing input right now. AuthenticateAES is known to work well, as do much of the other scattered collected commands from other Java-based DESFire implementations I have seen nicely documenting the protocol.

If it's all right with you all (say so if not), I will post a separate issues thread asking to enroll more testers to help get the remaining development done with a feedback loop. At that point, I will provide some benchmark binaries for the firmware as releases on my development GitHub repo. Right now, it seems to have been pointed out that the implementation is too memory intensive for the RevE class of older Chameleon devices. I have been testing with the KAOS RevG devices, but have had some BT issues with interference on some of the newer models. Your mileage may vary.

If you all have time, please go ahead and started helping me test out my sources (still under active development, and by no means perfect, yet) by cloning the repo I have and building your own binary. I would especially appreciate more help and participation on the issues threads there.

Also, I want to emphasize how nice @dev-zzo's code from years ago was as a starting point. I'm only now starting to get to grips with why some of the transfer mechanisms were setup that way as I am wrapping up a preliminary implementation. Making the logic from Android-based HCE stacks for DESFire, or for memory (malloc) rich PC-side libfreefare-type ways of emulating these tags skips over how difficult it is to make all of this work on an embedded AVR platform. 😃

[maxieds]

Here is the hex binary output from the most recent commit of the source I have. It seems to work pretty well over AES authentication, though is still missing some features. I am going to take another gander at completing the rest of the main features that I wanted to see this upcoming week. Like I mentioned before, I'm getting to the point where I will need users and testers to help me nail down all of the corner cases, and/or pick apart some undocumented pieces of the protocol (like when encrypted transfers should happen).

[maxieds]

I also want to point out that there are now some custom Chameleon terminal commands that can be used with the DESFire emulation support. Many folks seem to have freaked over some other sources having SAK and enabling Mifare magic modes. So in that spirit, this mod also lets users/testers mock up a DESFire tag with all of the custom 'fixins (so to speak): Clone the UID, set the version command data like batch number bits, software bits, dates manufactured, etc.

This feature aims to be a quick interface to cloning any particular DESFire tag bit-by-bit. That is up to implementation quirks.

[maxieds]

The first testing binaries are available. Please check back for updated binaries soon. The latest release should stay fixed for a while.

[maxieds]

I believe the bulk this feature request is now in the books with the merge of pull request #287, with the exception of a few minor odds and ends noted here. I'm very happy to offer to close out this issue. 😸