Automated Static Size and Libc-tuned Proxmark client automated build

cjbrigato · 2016-09-30 05:57:09

Hello world,

I got what is now satisfaction on having Client implementation of proxmark client for arm device with this conditions :

- O3 iceman based.
- musl-libc manual toolchained with full static libraries, SSL being polar or lighter ones
- Stripped to the roots, with relevant blobs being replaces by assembler infitesimals.
- Needs absolutely nothing but the proxmark binary with matching and a relevant kernel and cdc-acm being it module or builtin
- If lua scripting is needed, liblua is working already, so is the script command. Howeved the lua libs (in lua) and scripts (in scripts) are _not_ embeded, and should be made available in the binary working directory.
- ~450 kb in 03, sometimes less, and a little less in 0s, if needed for constrained devices

Edit : Added Info on lua support

Performances are best I could get for every device I have tested it, with negligeable gain but no loose on big arm device like rk3's and other Samsung's SoC
And negligeable gains in classic boards
being boards with ALLWinners H3/A10/A10,
raspies with new Broadcom socs (arm7l or aarch64 if any other has been of courage enough to get through this), and I a whole bunch of totally classic ARM7vl compatible CPU, as long as it has VFPU and basi ARMv7l support.

The more memory constrained systems or older than ARM7vl are the best to profit such clients, as an implementation such booting from Nand to proxmark client up and running an embeded lua could be timed as low as ~400 ms on relevant boards and proper implementation.

It works very well on any android ARMv7 compatible phone, and specially on the bunch of mt6582 which makes a very mobile and flat and battery included free design. You can even take te screen and sensords and all mess out, takes the screen separator as stand for proxmark and tada, you got a phone-thin and totally integrated in the wild device.

I'm making the process integrated in an automatic-builder that will spit it's resulting binary on my github.

As the process will need 1 build per build & CPU, I wanted to know :
- If such process is interesting anyone , first ?
- If details are to be of any interested to be clean, shortened and shared?

And then, more importantly :
- what are the arch that may be on interest for these builds to be availabe ?
- and for what build ?

I was thinking of ARM9 (and relevants) , ARMv7l coverage for now, with builds being :
- Official
- Iceman1001's fork
- Marshmellow fork

Being most popular.

I will not integrate rom-building in this , as these are intended for CONTROLLER devices, not proxmark, which should be prepared for flashing beforehands. It may integrate better-dated builds AND firmwares rom for integrating automatic flashing of such (your job, heh) if needed with the same place, but for this I would prefer contacting the build's maintainers to provide hooks for wich commits are "not to be built", "to be built", with these "builtable" condition, being at their discretion.

Depending on Client build state, the client can binary size can be made as low as 400kB, sometimes less with 0s, and if stripped from unneeded for very specific device, it could drop way below.

---
Addendum about Uclinux and NO-MMU mcu's

I got a working implementation for UCLinux's known's working kernels on STM32f429, f469, f746(disc and zg) in zFlated binaries of ~230kbs so if someone is up into needing this still remembering that integration on devices without mmu is a real thing that can lead to madness, broken laptops, lost girlfriends, and all know diseeases related to classic NO-MMU's-LINUX Induced Paranoia,
I _could_ provide such binaries, as long as you take it up to you for getting in working on your device without assistance, as making threading really working and the mifare's classic on these along with a binary meeting anyhow the requirement sizewize and in compile process compatible a thing I now would never do, and so I won't be of any help about implementation.
For the f746ZG (nucleo), remember the Flash is so short that it could not be used with something else than afboot and a rootfs being at most stripped down shell (as needed) being init and the pm3 binary. This will never ever be automated. I try to get them working with important official update, and might stop on any day. If anyone think of use case which could be really of any use, I'm up into giving the whole as-is process needed for this, without any support no more explanation. Those who now may already understand why in every way.

I can't but recommand trying hackers to rewrite the client from scratch with ST's provided Cubes library and furthzer optimisation , as it is very, very happy and easy and short to do your own implementation of this by looking on client way of comunication with PM3, or understanding how to communicate with pm3, CDC_HOST implementation being already provided by manufacturer, and since not HID anymore very easy to talk with.
Algorithm used for attacks which are of client Business are to be tried and thinked twice, like hardnested will for sure never get on them as-is, but client decrypting crapto's classic are quite easy to be implemented, and with good threading can be very well performing on these.
Could provide code samples without-any-support if wished.

Last edited by cjbrigato (2016-09-30 10:48:12)

iceman · 2016-09-30 08:08:30

This is most amazing device work. This kind of dedication and passion makes me happy. Even think for all those proxdroid, raspberrypie hackers what a goldminel. So much innovation can be made.

Keep it up bro!
Which is your github account?

cjbrigato · 2016-09-30 10:45:16

Hello back,

Thanks for such motivation on the idea, but it is very strange to hear such compliments of what is result of what is just evidence

As Iceman1001 knows, I can't but make a lot of words to explain myself on everything, so Here is a mark of useless anecdotal fact you may avoid block, and get past to the end
===========ANECDOTAL USELESS DETAILS========
- where I saw the client was wished to use
- Indecence of the very high frequency "how to compile" appeareance
- what device I got which are quite common and have thought it could run.
=> Static binary for ARM is a very simple solution to this

Making good static binaries, by pure chance has been a basic need of mastering in my work, so I got quite used on making a process for it, and then basic optimization, with only not having performance downside.
If you are used to how the whole toolchain is made, and have only one time heard of glibc alternative and made a real try, then you never get back, as when glibc is not used, everything is simple, like new world. By chance of blablabla I got same past experience with ARM, so just do it.
Optimization base is what I would do for every static binary (again, as consequence of my work ), so the case was closed.

Then I thought it would still be better to get a little more dedicated binaries as there are quite big difference on ARM 7vl and precedessor and succesor spec which would benefit from being dedicated, and thanks to Linux Foundation, the process is the _very_same_ , just tell the compiler what to spit out.
Make it for every specific needs #2 : builds.
Automate it for the 100000x times it will have to be done when "Go To Market"™ .
============= END OF ANECDOTAL USELESS HISTORY======

In fact the github repo was already done some weeks ago but I thought that I should have missed something to propose static portable binaries and that would be usefull, and thought i'll add automation and publicity at least to have anything to offer,

but it seems that there are really not been such simple whole process before, so I'm glad I come here with real offer.

Will be on the same github as the mods repo, which is of no use to be shared again while not being online.
I will wait a day or two for confirmation that it is sufficient at start, as it is always more painful to add thing to a started automated process than when first implentation..

Also I added infos on lua support. If it may have sens to have it embedded in the binary I could, but I can't see why embedding lua script in the binary would benefit more than pure c in the client source code.

Last edited by cjbrigato (2016-09-30 10:49:21)

cjbrigato · 2016-09-30 14:46:38

Iceman1001, you got _short_ mail on this.
Too late for today for me, but still answerable.

cjbrigato · 2016-10-01 10:23:24

People, you would be really apreciated on this case
Iceman, as you are the only one I'm ensured to be lurking somehow here I know the same, and still would want to know before going "Go to Market™" what could happen when magic is to be gaven. I didn't do extensive test , as It came from there. It was used in mods. I really don't want to restart the whole process because of an obvious error when it came to testing not on device I got mechanical habits.

cjbrigato · 2016-11-29 22:46:17

Hello people..Any news on this ?

Still want some kind of list of wanted-builds to make it public

iceman · 2016-11-30 09:51:50

The most interesting forks at the moment for PM3, is according to me the following.

- Official
- Iceman1001's fork
- Marshmellow fork
- peter filmoore's fork
- piwi's fork (branch hardnested)

Proxmark3 community

Announcement

#1 2016-09-30 05:57:09

Automated Static Size and Libc-tuned Proxmark client automated build

#2 2016-09-30 08:08:30

Re: Automated Static Size and Libc-tuned Proxmark client automated build

#3 2016-09-30 10:45:16

Re: Automated Static Size and Libc-tuned Proxmark client automated build

#4 2016-09-30 14:46:38

Re: Automated Static Size and Libc-tuned Proxmark client automated build

#5 2016-10-01 10:23:24

Re: Automated Static Size and Libc-tuned Proxmark client automated build

#6 2016-11-29 22:46:17

Re: Automated Static Size and Libc-tuned Proxmark client automated build

#7 2016-11-30 09:51:50

Re: Automated Static Size and Libc-tuned Proxmark client automated build

Board footer