3 ms·
I have a pile of IOT devices in the field that I made malfunction en-masse with a buffer overrun. I used the boilerplate, generated bluetooth LE stubs to make
by smackeyacky 6y ago
I have a pile of IOT devices in the field that I made malfunction en-masse with a buffer overrun. I used the boilerplate, generated bluetooth LE stubs to make a GATT interface and didn't pay much attention to what it generated (in C). In my defence it was the first embedded system I made and the fact that it worked at all amazed me.
At one point during the first year, I changed some code in the android app that set up the device and wrote a larger value into a characteristic than it was expecting (32 bit int instead of 8). The boilerplate code checks the length of the incoming data and copies it in full. I managed to overwrite the structure in memory for the next couple of characteristics which made the devices malfunction.
Kicked myself a few times, managed to salvage the situation, got customers up and running (mostly) but at the time it seemed like a company killing disaster.
However later on, when dealing with a new feature that dropped the battery usage I realised that setting the characteristic for power in my interface sometimes caused problems itself due to a problem with the way I was accessing the radio on the device during operation, which was not supported.
However, remembering that the buffer overrun worked, I was able to craft a set of bytes that didn't trigger the original problem but allowed me to change the radio setting without triggering the radio code (the device sets the radio on its 4 hourly reboot).
In the end the buffer overrun saved me a lot more time than getting 10,000 devices back to have new firmware installed.