IoT devices are resource constrained. Oftentimes vendors will go to great lengths to avoid using TCP. This is not a bad decision on its own: UDP is stateless. But that means you're rolling your own resiliency in.
Now that we know how the firmware is loaded, it's time to look at what the firmware looks like. For this attack to work, we need to be able to load our own code. Ideally, the device will continue to function as it was intended. How hard will this be?
But before we attack the firmware, we need more information. Let's look at how control software interacts with the device.
Most IoT hardware isn't reverse engineer resistant. Note how I don't say "reverse engineer proof." This would be a fallacy. As long as you don't control where the hardware is, you can't plan to resist every attack.
We now know that a naive, hash-based approach has trivial weaknesses. HMAC on its own prevents image modification. But it's likely easy to steal the key for either scheme. If all devices use the same key, forging a compromised firmware image is easy. So what are our options?
Nothing will leave your product more vulnerable than a badly designed firmware update process.
A large number of attacks on IoT devices rely on being able to write to where code can execute from. Dump your shell code into a buffer. Overwrite the return pointer on stack. Presto, you're running unauthorized code!
If there's one thing that is often screwed up, in all systems, it's cryptography.
Embedded systems security is a balancing act. On one hand, you need a comprehensive threat model. Chances are, your device is in a malfeasant actor's hands. But, you also have limited resources with which to defend against a wide range of attacks this opens up.
Hardware is magic. Software is scary. Together they are a horrifying monster. This monster will bend to the will of whoever has the magic incantation to control it.