Adding support for a smaller configure type script

[maxieds]

After some discussion with @ceres-c, I think we came to the conclusion that the firmware options and multitudes of configuration settings are becoming overload to all fit on a single binary at once. There seem to be a few options that are nice to set in a more automated way with out having to edit the Makefile for each custom firmware binary build:

• The configurations enabled (important to have a flexible way to set/unset these due to memory constraints)
• The FRAM memory size. It can benefit the memory profile to reduce the overall space of the configuration settings stored on the Chameleon.
• The number of settings and the size of each setting (4K will work for most tag emulation). Once the FRAM size allocated in the Makefile sets the size, one is determined by the other.

I think it would be useful to write a small bash configure-like script to automate building particular custom flavors of the firmware based on variations of these options. Then things like the GitHub actions setup in #277 can be setup very easily to script the scheduled builds.

I can do this pretty easily. My question before starting on the task is whether this is useful to other developers?

[maxieds]

@david-oswald Updating my proposed method from before. Can you tell me whether a pull request adding this functionality is welcome before I spend an afternoon writing a mucho-tweaked out implementation?

In the spirit of the best, and my long loved Linux kernel's make menuconfig, I think that we can add a way to customize the build parameters for users easily on-the-fly. I propose doing a make chameleon_custom_build target that calls some Python scripting located in a new directory in Firmware/Chameleon-Mini. The text-GUI would rely on curses and the widget library npyscreen, each kind of standard fare. If the user has Python installed, then one initialization routine can check whether these libraries are found, and if not load them in upfront with pip install.

Just for reference, and for anyone that misses the reference, I'm thinking a structured listing (with help, info, etc.) on the order of the following Linux terminal favorite:

[ceres-c]

I quite much dislike ncurses, termcap & alike, to be 100% honest. After wrestling with termcap to run the Proxmark client on non cooperative hardware, I'd like to stick with the good old Makefile configuration. It's reliable, it's solid and most importantly it's portable. Everyone has a text editor, not everyone has pip: I don't use pip in my Arch install

[maxieds]

@ceres-c It wouldn't be enabled by default. Anyone that runs make can use the existing compilation scheme: default, or custom edit the Makefile by hand. If the user types make custom_build, then the python-based curses interface pops up in the style of make menuconfig.

How else do you suggest handling the problem with all of the available tags being enabled at once overloading the memory capacity of the Chameleon AVR? This is a sane graphical way to custom configure the kernel firmware build. It can be made to look spiffy too. Any suggestions for alternate options are welcome. I found the GitHub Actions scheme to be kludgy and really not worth it. It is also, for example, going to be necessary to configure a custom build whenever my DESFire emulation code gets submitted as a new PR. I think many users will want to have that easily available. Just pointing out prospective solutions.

I would appreciate some consensus on whether I should go ahead and write the custom build config scripting. I'm going to be mostly away from this project (at large) from tomorrow through the weekend.

[ceres-c]

I don't know, maybe I'm gatekeeping, but I believe this is a project built by hackers for hackers. The end user should be able to understand a makefile and quickly edit it to compile only the parts he needs. I believe that it is indeed necessary to fir a warning about possible issues with the output, but we don't have to babysit our users. I wouldn't do this if I were you, but this is of course welcomed.

This is only my take about this and it means next to nothing, let's see what the emsec folks think about it.

[maxieds]

@ceres-c Noted. It is a time sink to do the make menuconfig tribute the right way.

How do you suggest we handle the problem that arises when my DESFire code gets merged? That single (and maybe one more other) config takes up all of the room on the device. Crypto structures and accounting are not cheap. I was under the impression that many people will want to use a Chameleon for this if the emulation works well. That is a barrier because other users will expect other tag types, and to be able to switch quickly between them without reflashing. Do we make a separate Makefile for the DESFire build?

[ceres-c]

I followed this route https://github.com/emsec/ChameleonMini/pull/284 because I believe it should be enough to have a warning. We could then add a note in the Readme for the users to know how to handle the size restrictions, I believe. Something along the line "Comment out things you don't need and increase FLASH_DATA_ADDR until it builds"

Ok, even I have realized that this particular solution is indeed gatekeeping

[david-oswald]

I agree with @ceres-c to not have a graphical configuration interface. We could have a few specialized build targets in the Makefile, such as make iso15693 or make desfire, and make sure that for those (and the default build) we're pretty confident we don't wrap over into card data flash with normal compilers/settings (plus have a very clear warning if we do). For more "exotic" configurations, Makefile fiddling it is.

[maxieds]

Got it, no graphical config.

I will add the DESFire make target with the pull request for my new emulation support for these tags. Most likely, the best way to handle this is going to be to create a new separate Makefile variable just for configurations enabled in the build. Then this can get reset in the target to whatever that specific build type requires. Otherwise, resetting the complete SETTINGS variable for custom builds can be very painful.

I also think that the developers / maintainers of the repo need to eventually update the documentation for configurations and possible make targets.

You can consider this a closed issue at will now. :)