Author here: thanks for sharing! I'm curious to hear what other interesting ways people use Binutil commands or if there are other ELF introspection tools that I neglected to mention in the article. I only touched on it at the end but some of the commands in libabigail such as abidiff are really neat and useful too!
> I also was very thankful that CoreBluetooth handles so much for us. I was able to get our firmware updates to get to 85% theoretical speeds
That's awesome! I've generally been pretty happy with the CoreBluetooth framework as well and it's nice that all devices in the iOS ecosystem behave fairly consistently. I have found Bluetooth State Restoration to have some odd quirks from release to release but I think it has gotten better over the years as well.
> I got Ubertooth [0] running for sniffing, but could only successfully follow a connection event about 25-33% of the time.
heh, yeah, the Ubertooth is neat for the price point ... I've used it as cheap spectrum analyzer [0] several times in the past when prepping for BLE RF testing. Could pretty quickly verify that a bluetooth chip was at least entering Direct Test Mode and transmitting on a particular channel using it!
Thanks for sharing the link! I remember watching that presentation ... I really liked how thorough it was. I'll include the links in the article as an additional reference!
> Upping the MTU is "easy" on Android (you can do it, but I've had mixed results)
hehe, yeah, I've definitely run into some interesting issues when changing the MTU on android. There's a class of older devices that seem to only support the default MTU size but will happily negotiate a 512 byte MTU and then drop the data for you :)
Yeah, minidump and breakpad/crashpad can be great when running native code on an OS!
One challenge with embedded devices (i.e ARM Cortex-Ms) is that it is not always safe/viable to try and grab the thread contexts at the time of crash. These MCUs have none or very limited support for memory management (a MPU at best), the OS/application state usually lives in the same RAM area, and the stack dealing with exception handling is usually quite small. For these reasons, it's usually desirable to grab a very simple memory dump and offload as much of the processing as possible to the server. The "core dump" format that is used for linux is saved as an ELF with a few special PT_NOTE sections to convey thread information. This would be hard to generate on most embedded devices. The coredump we collect for embedded devices is closer to a mini-dump. It is basically just a raw memory dump and the current register state on the device. On the server side, we recover the thread contexts and backtraces by using the debug symbols, the RAM capture, and analyzers for the RTOS that was used (i.e FreeRTOS, Zephyr, ThreadX, Mbed OS)