Adding support to the firmware for DESFire emulation? #218
Comments
|
Hi @maxieds 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 |
|
I would also be very happy if the support for DESFire will be further developed. |
|
Anything new here ? |
|
+1 for this |
|
+1 |
|
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 ***@***.***> wrote:
+1
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#218 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFJDROHXNIUPT544ULUNIDLRLNVLHANCNFSM4HEMZ7RA>
.
|
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. |
|
@maxieds bump |
|
@street-grease-coder |
|
@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 < ***@***.*** > 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 (
#218 (comment) )
, or unsubscribe (
https://github.com/notifications/unsubscribe-auth/AFLGOUOEYUWVBAPBH5FAGK3RTIQE3ANCNFSM4HEMZ7RA
).
|
|
@bayan9 |
|
@maxieds This sounds much like a responsible disclosure timeline. Should we expect some interesting news about DESfire in the coming months? :-) |
|
@ceres-c 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. |
|
a-bit-early bump |
|
@street-grease-coder 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? |
|
If the problems are in the anti collision loop, this means it is stuck in the 14443A -3 protocol. |
|
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 --Edit-- |
|
@ceres-c @street-grease-coder 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. |
|
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 |
|
@david-oswald 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. |
|
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: This is just a FYI for firmware hackers making their own custom mods. Enjoy the free code. 🍻🍻🍻 |
|
@lvandenb FYI, I'm still working with the same Identive SCM SCL3711 USB stick that is compatible with libnfc right now. |
|
You really misunderstood a lot right there....We wouldn't take your code without asking. I was referring to Sorry for the misunderstanding. 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. 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: |
|
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) |
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. |
|
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. 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? |
|
@david-oswald 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 |
|
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 #271 |
|
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). |
|
Moreover the clause |
|
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. |
|
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. :-) |
|
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. |
|
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 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 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. |
|
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 |
@maxieds they published it, I'll send you a mail to avoid hijacking this unrelated issue. |
|
@dev-zzo 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. |
|
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 |
|
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). |
|
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 This feature aims to be a quick interface to cloning any particular DESFire tag bit-by-bit. That is up to implementation quirks. |
|
The first testing binaries are available. Please check back for updated binaries soon. The latest release should stay fixed for a while. |
|
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. 😸 |
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?
The text was updated successfully, but these errors were encountered: