Bcm43430a1 karma

[mame82]

trafficstars

Working KARMA mod for RPi0W / RPi3 firmware including a dedicated runtime configuration tool.

Details are here: https://github.com/mame82/P4wnP1_nexmon_additions/blob/master/README.md

(including help screen of tool)

So it is done before christmas

[matthiasseemoo]

Hi mame82,

thank you for your nice karma implementation, however, I do not want to add it directly into the nexmon repository. I intend to keep only the basic functionality such as injection and monitor mode in the nexmon repository and place any additional patches into separate repositories. For example, we also created a new repository for our jammer (https://github.com/seemoo-lab/wisec2017_nexmon_jammer_demo_firmware). By using external repositories, we can reduce the amount of function we need to find to support a new firmware version when it comes out and the maintainers of nexmon extension would have to update to newer firmwares on their own. I could however include your patches to the structs.h and wrapper.c files.

For the future, it might be worth investigating a firmware extension strategy to extend firmwares during runtime. I already have a nice way to compile position independent code ready.

Matthias

[mame82]

Hi Matthias,

thanks for your reply. I'm fine with your decission, feel free to add in the patches in structs.common.h + wrapper.c.

According the firmware "hot patching": I thought about something similar. As you may have noticed, I extended the IOCTLs with mem_dump functionality (used to transfer custom runtime structs of firmware to userland python tool, namely the linked lists of SSIDs which are transfered entry by entry). Doing this I ended up with the idea of an additional "write what where" IOCTL to change data/code of firmware during runtime. To be honest, today I stumpled across research doing exactly this in order to bring up a dynamic tracer with minimal (static) firmware manipulation effort https://conference.hitb.org/hitbsecconf2015ams/sessions/eight-ou-two-mobile/

Reading the whitepaper, it became clear to me that I didn't considered non-writable memory regions, which are handled via flashpatching by the researcher.

I'm glad that you're working on a dynamic patching system, too.

This would open the door for creation of "firmware plugins" which could be loaded / unloaded on-demand, without bloating the firmware.

If you agree I'll keep my fork with KARMA patches up (for P4wnP1).

Merry Christmas

Marcus