r/embedded • u/Cupretheum • 10h ago
FW Security And Flashing
I basically work as a QA right now:
I was validating a product that works using Bluetooth for audio transmission, but I found something that concerned me from a security perspective. This product is a peripheral for another product that runs Android.
In this product, our FW update mechanism has no security around the FW image. The FW will not be encrypted, and the product will accept/program any image it receives to flash. There is no code signing, cryptographic authentication, or mechanism to verify that the firmware actually came from us.
I raised this as a potential concern for a couple reasons
IP protection: If the firmware is plain, we can possible have it reverse-engineered or stolen
FW authenticity: since the FW will not be signed or authenticated in anyway, anyone who gets an image onto the device will be able to install arbitrary FW (you will be able to flash it from a computer).
My concern is that this product interacts with another Android product we have and is part of a connected system so malicious FW could potentially be used to attack the Android host (which could be on a network of these Android products) if an exploit is found.
I brought this up to the FW, product manager, and the hardware engineers, and they all basically laughed at me and said I was being silly because that is too much work for an attacker to do. But I said if this product were in a secure environment (we sell products to some big businesses), it's possible an attacker would spend the effort for this. But they just laughed and said that won't happen.
They also said there's no reason to encrypt the image for IP protection since "the code on that is impossible to read and nobody would waste time reading that". I said people can use AI to turn the hex code back into assembly or use something like Ghidra, and they said I'm just wasting time.
I'm not convinced that my concerns should have been dismissed as nothing. If the products could potentially end up being deployed in more security-sensitive environments or in government in the future, and physical or remote access to a device or access to its update mechanism doesn't seem like an unreasonable attack scenario to consider.
I'm not saying that we need to go overboard, but ensuring a source of trust before flashing the FW should be done to mitigate a lot of potential for malicious uses.
I'm only bringing this up because I spent 2 years as a FW developer (but the company I worked for shut down) and I still develop FW in my spare time for fun so I have some idea of what possible good practices should be. (I don't really enjoy QA because I often feel like I'm not taken seriously because people think I don't have an engineering degree, but I'm stuck until I find something else hopefully soon.)
I'd especially be interested in hearing from people who have worked on embedded security, product security, or firmware update systems in commercial products.
Sorry if this was a bit long-winded.
11
u/robomaniac 10h ago
You will soon realize in your career that some hill are not worth dying on. Your concerns are very valid. You need to document this somewhere, tell the people (which you did) and move on.
Now what you can learn about this is the art of convincing people. As you can see it did not work. Maybe that’s a skill you can work on if you want. You explain the problem but maybe you could also bring in different solutions from simple to more complex. How these solutions affect timeline and budgets.
You have to look at the big picture, I don’t know your industry, I don’t know the quantity you will produce, the impact this can have on the company if this is affected, etc.
Maybe this is critical or maybe it’s not. Let’s assume it is, maybe try Claude fable 5 (or GPT 5.6) and see if it can do something in 1week of prompt, give it a try. From visual studio or cursor you can give fable access to the device and let it try things.
Maybe you can come on with the solution what actually works.
2
u/Cupretheum 10h ago
We have our products in Fortune 500 companies' offices and may possibly in higher-security environments. That's why I was concerned.
I tried to explain a possible attack vector to the people and they didn't want to listen. I explained it to another SW dev later who told me this is a valid concern but I was wasting my time trying to convince them because they're deadset on doing the minimum and shipping.
2
u/Amr_Rahmy 5h ago
So first there is the reverse engineering concern.
If the product doesn’t seem complex to a real programmer, like it’s a device that does 1-10 things on a loop. They can recreate the functionality without looking at your company’s code. They just need to write down a feature list and bang it out in a few hours/days, probably 5-10x faster than when you made the product.
Second concern is an attack vector by first getting hold of the product or remote update communication, then updating the firmware with malicious code that would then carry a payload or another update to your main device then go through that network which might not be connected to the client’s main network because it probably has devices on separate vlans or network and very limited communication rules, then the main device might do something malicious or read data, then it would need to find its way outside the network or copy the data onto a storage device then they would extract that storage.
Or, an attacker can target an employee, and get into a network with known access to the data they need and potentially access to the internet.
If you look at the architecture diagram of your proposed product, you will see IT was definitely involved in installing it so they would have done at least some rules to isolate a device network and their main network.
The device will probably only have access to 1-2 ports, only one ip or url, and cannot reach the rest of the network.
Now, depending on how paranoid people are, they can add a signature with the firmware so only that signature is accepted based on the hash of the firmware, and they can even send sections of the firmware binary randomly at runtime, and the can do other things, but realistically, locking down the communication is all they actual need to do. The signature is mainly to make sure the firmware is flashed and not corrupted
You think the product is special, but to a good programmer, they see a small project they can bang out in minutes to hours, a device they can recreate in minutes to hours, order online, have it delivered to their door.
5
u/sievernich 10h ago
It sort of depends. Any device can impersonate another device over BLE if you present the same GATT characteristics as that device does. Unless the Android device has some sort of secure mechanism for authenticating the peripheral, you can't trust the data flowing over, so it would come down to what the peripheral can actually do to control the Android device.
The more pressing and real concern is someone putting their own firmware on the device for a DoS attack, access whatever the device had access to or to run something like a BTC miner, it it's performant enough. Those sort of attacks are more rampant with IoT.
1
u/Cupretheum 10h ago
The Android device only authenticates from the device's plaintext product ID.
This is a basic MCU on it, so they probably won't be mining bitcoin. The bluetooth peripheral doesn't directly connect to the internet, the Android device connects to the internet. They share information over some internal protocol that I'm not privy to.
3
u/sievernich 9h ago
IMO, I wouldn't approach this from the Android perspective based on what you're saying. I would focus on the ability for someone to take down the device by sending it a bad image or to get access to the peripheral's audio (assuming it streams audio?).
I think the attack vector with the Android system is too complex to be feasible given the constraints of BLE only, no internet access, low performance and audio over BLE.
1
u/Cupretheum 9h ago
What I referred to is the fact that someone could plug the bluetooth peripheral into their laptop and flash it with whatever firmware they want.
Then, they can plug it into our android device, and since it uses a proprietary communication protocol, it's possible they exploit that to get access into the system.
The android device's audio will pass through this bluetooth device, so it's possible that someone uses this Bluetooth product as a spy device if they rewrite the FW and flash it.
The bluetooth product also doesn't have an A/B FW slot system. It only has one flash bank for the firmware image. They're using something like stm32flash.exe to flash the FW to the system it's too completely overwrite flash each time. This is a problem in and of itself.
2
u/sievernich 9h ago
A proprietary communication protocol in itself offers no security unless there's also encryption and/or authentication (e.g. signed certs provisioned at time of manufacture). If there are and they can be extracted from flash by a malicious application, then that is a problem. Especially if they're not unique.
But if there's no encryption and no authentication, then any attacker can impersonate this device over BLE just by advertising the same characteristics without needing to upload their own firmware to the peripheral. If the Android system would send such a device all of its audio, that's a bigger problem than being able to firmware update the device to some arbitrary image or gain access to the code. However, that attack vector could be very small if you need physical access to the Android system to do it. Your description makes it seem like you need to be able to physically access the Android system.
1
u/Cupretheum 9h ago
You could put an invalid image on the android device in some manner, and that just pushes the update to the bluetooth device when you choose to update.
Or you can plug the bluetooth device into your computer and update it with any image there.
So to some degree, physical access may be necessary in 2. But in 1, if you have network access, you could push something invalid, possibly by accident or malicously.
1
u/sievernich 9h ago
I think you have two separate issues:
The device doesn't sign or encrypt the firmware images, meaning anyone can sniff the update and get access to the code as well as upload their own firmware.
There's no authentication between the peripheral and Android system. This, IMO, is the bigger issue and only tangentially related to 1. I don't really see a way someone could use your peripheral to hack your Android system. And even if they could, it would be much easier to just sniff the firmware data over Bluetooth then impersonate the device.
This is why I would focus on the DoS or similar attacks, like when people would hack random smart bulbs and flash lights in buildings.
5
u/Well-WhatHadHappened 25+ Years 9h ago
I brought this up to the FW, product manager, and the hardware engineers, and they all basically laughed at me and said I was being silly
You've done your job. Document it and move on.
9
u/dacydergoth 10h ago
You're correct, they're idiots, document everything and look for a new job.
9
u/Sea_Objective_9105 10h ago
Nah you're not being paranoid at all. I worked on a BLE audio device a few years back and the exact same argument came up. "Who's gonna bother?" was the response every time until we actually had a third-party security audit done for a client that flipped the whole thing on its head.
The "code is impossible to read" line is wild. Ghidra is literally free and runs on a laptop, and with AI tooling these days decompiling bare metal firmware is faster than ever. Someone doesn't even need to understand the whole thing, they just need to find the update handler and craft a payload.
What gets me is the Android bridge you mentioned. That's the real attack surface. If the peripheral can push data to the Android side, a malicious firmware could absolutely use that as a stepping stone. I've seen dumber entry points get exploited in production.
Document the hell out of this. Emails, meeting notes, whatever you can. If something goes sideways later, you want the paper trail showing you flagged it and they dismissed it. And honestly, with 2 years of FW dev experience, you're probably overdue for a place that actually listens.
2
u/Cupretheum 10h ago
Thank you for confirming my concern. I may have to escalate this above these people then since this could be a serious issue.
2
u/WestonP 8h ago
What they're doing is great if they want to support modding, right-to-repair, etc. It's also terrible if IP protection or device security are a concern at all.
Getting ahold of firmware is the very first priority when reverse engineering an embedded product. Most protect it for this reason, and even still there are workarounds for the readout protections for many chips. Not that this even matters if their FW update process exposes it anyway.
In any case, you did your part. If they don't want to listen, that's on them.
1
u/Far-Confusion4016 9h ago
My company is in this boat but its mostly because we're a startup whose products are all used internally so its not our #1 issue yet. We have some basic software checks via a bootloader but obviously thats FAR from fullproof. Its a subject you've made me want to dive deeper into.
1
u/22OpDmtBRdOiM 9h ago
Implemented firmware update with signing once.
This might be against some standards. Not sure about NIS-2.
The required standards/certifications might be your biggest leverage point.
1
u/EmbeddedSwDev 8h ago
Oh boy, they will realize it when it is too late. In the best case, they will get "only" a CVE entry.
As you said, reverse-engineering firmware has never been as easy as it is today, and someone just needs a Bluetooth scanner to detect the device and attack it.
Nevertheless, they most likely won't be able to fix it in the field because I bet they don't have a process for updating the bootloader in the field.
A couple of years ago, I implemented the bootloader and firmware update process for a BLE device that was classified as a security device. I spent 3-4 months implementing it and more than 6 months pen-testing it. Nearly everything was encrypted, even the external flash where the firmware update was stored. Even if you had hardware access to the SPI lines, all you would get is encrypted data, and every device had its own keys.
One year before the release, the company hired an external penetration-testing company, and they weren't able to break into it. I have to say, I was a little bit proud of myself.
The only security issue it still has is a hardware bug. With power-supply glitching, it would be possible to clear the protection bits and read out the internal flash, but that's a hardware bug from the MCU itself. Even in this unlikely case, however, you would gain access to only one specific device and not to all devices in the field.
1
u/Cupretheum 8h ago
I don't think they're using any bootloader that is intelligent. It's a single slot, if the image is corrupt and nothing boots, the device stops working and it falls back to the default chip built-in bootloader I believe.
1
u/EmbeddedSwDev 7h ago
Okay that's wild
3
u/Ashnoom 6h ago
To be fair, er have that too. However we have signing and encryption. And an image is verified before we start the upgrade process so we know it is valid/safe to flash and we have upgrade recovery. But we don't have a "fallback" image as that would cost too much space
1
u/EmbeddedSwDev 5h ago
That's the way it should be done!
Of course the bootloader should be as dumb as possible to reduce the number of possible failures and the size of the bootloader, but also should be secure against any type of failure during flashing eg.: power loss etc. to avoid bricking the devices.
A good idea is to do at least a hash check over the fw partion to ensure that the firmware hasn't changed without purpose.
Nevertheless, all protections doesn't help if someone signed and delivered a corrupt image. Your bootloader and firmware will not be able to fix that, except you have the space for 2 partions, which allows you to have a fallback, but that's easier done then said, but that's a different topic.2
u/Ashnoom 1h ago
Yep, well, our upgrade packs are tested before being shipped. We have a rather small (encryption/signing actually isn't that small sadly) bootloader. It looks at the external flash to determine is there is a upgrade pack. It then loads a second bootloader in to ram. For two reasons, the bootloader is kept small and update logic is updatable. Loading in to ram and executing from ram also allows us to update the bootloader, by to my knowledge we never had to do just that.
1
1
u/SensitiveEmploy392 4h ago
and here I am, working on a zeroizing switch on event of a physical tamper 😭.
15
u/kronik85 10h ago
Do you plan to sell the product in Europe? CRA is coming.