The core issue is the use of MAP_FIXED flag with mmap. Basically pthread_allocate_stack for every thread it creates, starting its mapping a new STACK_SIZE memory segment to a fixed address (calculated relative to THREAD_STACK_START_ADDRESS and the number of threads already allocated). The problem is that using the MAP_FIXED flag means that if the desired memory address overlaps a region already allocatead, the overlapped region will simply be unmapped and given over to this new call, potentially corrupting libraries with stack data.

Great series of posts covering the authors research progress and eventual owning of a wireless scoreboard system. Unlike a lot of the attacks we cover, this had more of a hardware and even radio signal focus. What is most interesting is the inclusion of the dead-ends and the thought process involved. Eventually the author manages to sniff the (rather simple) AES key by man-in-the-middle-ing the communication bus but there were several other ideas explored first. While the others did not work, they were educational.

The third post dives into figuring out the actual radio signal being sent, breaking the state of the LFSR RNG in use for “data whitening” by bruteforce. And talks about some interested possible attack that could have been pulled off now that they reversed the encryption key and could maliciously communicate with the scoreboard.