7 ms·

> Trying to hide your code is a stupid thing to do That's not what I hear from reputable reverse engineers, at least for IoT devices. Even though security by

> Trying to hide your code is a stupid thing to do That's not what I hear from reputable reverse engineers, at least for IoT devices. Even though security by obscurity should be frowned upon, and being understood that hiding code might give a false sense of security, most RE workflows assume availability of firmware, and it is a giant pain to start breaking platforms where the unknown firmware must be manually extracted first, especially the boot loader.

maxbond 7y ago
I agree. I've said before on this site, obscurity is a totally valid tactic to impose additional costs on attackers. It's best to think of it more as a preemptive strike than a defensive layer. Thinking of it as a defensive layer can lead to complacency, but thinking of it as an opening gambit is totally fine. One shouldn't be obsequious to heuristics like "never use security through obscurity," one should understand the systems they're building and make considered choices. Additionally, preventing people from dumping your firmware is usually not about security as much as it is preventing some fly-by-night company from reversing your product & selling it as their own. Why engineer a product when you can steal someone else's IP?
- saagarjha 7y ago
  It also gives security engineers who are looking for bugs in your code more reason to hate you, and heaven forbid that they have less perseverance than a determined attacker. Also, what’s so special about your slow and buggy libc and statically linked in crypto?
  - maxbond 7y ago
    The salary of the engineer who built it. If you hire those security engineers, you can give them access to the source code. If you didn't hire them, there is no way to tell benign attackers from other attackers, and they can deal. It probably won't give them much trouble anyway. :)
    - saagarjha 7y ago
      > If you didn't hire them, there is no way to tell benign attackers from other attackers, and they can deal. The better way to deal with this is to make your firmware secure regardless of whether someone can pull it off your device. Making security engineers’ lives difficult just means that you’ll find out about bugs from the news when they’re being sold to authoritarian countries to suppress dissents rather than the paper on firmware security that a graduate student was going to write before they decided to move to a much nicer platform.
      - maxbond 7y ago
        This is baffling to me for two reasons. The first is that my thesis is explicitly that this is not a defense and is not an excuse for poor memory handling etc. in your firmware. (And the more I invest in creating a robust firmware, the more I stand to lose if someone rips off my product & undercuts me - security risks are not the only type of risk.) The second is that the notion that I should rely on the charity of unpaid graduate students to discover bugs in my firmware is both inequitable and unsound.
- zdkl 7y ago
  > obscurity is a totally valid tactic to impose additional costs on attackers But there's the rub: you'll only impose additional costs to the least sophisticated/determined adversaries. While that works to keep random scriptkiddies/scans out, I'd argue it has little to no effect if you require serious security guarantees.
  - zwirbl 7y ago
    At least the bar for entry is a little bit higher, this in itself might be worth it then
  - maxbond 7y ago
    It imposes costs on all attackers. The value of that cost is skill dependent, but no one has unlimited time on their hands. In other contexts, like hiding an admin login page, shutting out low skill attackers means your log files have better signal to noise, and you can focus more resources on the more significant threats. The reason I say to think of it as a preemptive strike rather than a defense is that you still do need strong defensive layers. This is basically just setting a compiler flag. It's free for you and costs something for the attacker.
- baybal2 7y ago
  Firmware extraction from STM32 family costs around $20-25k in China, including hardened varieties. While getting crypto keys from gemalto around $10k. Not a big impediment.
  - maxbond 7y ago
    In what universe is $20k not a big impediment? Did you mean $20?
    - saagarjha 7y ago
      In the universe of a persistent attacker?
    - baybal2 7y ago
      $20K is nothing for a consumer product manufacturing run. For 9 out of 10 consumer devices, no factory will even listen to you if you are not willing to commit to put forward $1m Only really simple, small gadgets are profitably manufacturable under <$100k
saagarjha 7y ago
As someone who is currently working on a firmware reverse-engineering project (with others who actually know a lot more about what they’re talking about!) pulling tricks like these is just a massive annoyance that we’ll usually get around anyways; we’ll just curse you the entire time we’re doing it.

maxbond 7y ago

I agree. I've said before on this site, obscurity is a totally valid tactic to impose additional costs on attackers. It's best to think of it more as a preemptive strike than a defensive layer. Thinking of it as a defensive layer can lead to complacency, but thinking of it as an opening gambit is totally fine. One shouldn't be obsequious to heuristics like "never use security through obscurity," one should understand the systems they're building and make considered choices. Additionally, preventing people from dumping your firmware is usually not about security as much as it is preventing some fly-by-night company from reversing your product & selling it as their own. Why engineer a product when you can steal someone else's IP?

saagarjha 7y ago
It also gives security engineers who are looking for bugs in your code more reason to hate you, and heaven forbid that they have less perseverance than a determined attacker. Also, what’s so special about your slow and buggy libc and statically linked in crypto?
- maxbond 7y ago
  The salary of the engineer who built it. If you hire those security engineers, you can give them access to the source code. If you didn't hire them, there is no way to tell benign attackers from other attackers, and they can deal. It probably won't give them much trouble anyway. :)
  - saagarjha 7y ago
    > If you didn't hire them, there is no way to tell benign attackers from other attackers, and they can deal. The better way to deal with this is to make your firmware secure regardless of whether someone can pull it off your device. Making security engineers’ lives difficult just means that you’ll find out about bugs from the news when they’re being sold to authoritarian countries to suppress dissents rather than the paper on firmware security that a graduate student was going to write before they decided to move to a much nicer platform.
    - maxbond 7y ago
      This is baffling to me for two reasons. The first is that my thesis is explicitly that this is not a defense and is not an excuse for poor memory handling etc. in your firmware. (And the more I invest in creating a robust firmware, the more I stand to lose if someone rips off my product & undercuts me - security risks are not the only type of risk.) The second is that the notion that I should rely on the charity of unpaid graduate students to discover bugs in my firmware is both inequitable and unsound.
zdkl 7y ago
> obscurity is a totally valid tactic to impose additional costs on attackers But there's the rub: you'll only impose additional costs to the least sophisticated/determined adversaries. While that works to keep random scriptkiddies/scans out, I'd argue it has little to no effect if you require serious security guarantees.
- zwirbl 7y ago
  At least the bar for entry is a little bit higher, this in itself might be worth it then
- maxbond 7y ago
  It imposes costs on all attackers. The value of that cost is skill dependent, but no one has unlimited time on their hands. In other contexts, like hiding an admin login page, shutting out low skill attackers means your log files have better signal to noise, and you can focus more resources on the more significant threats. The reason I say to think of it as a preemptive strike rather than a defense is that you still do need strong defensive layers. This is basically just setting a compiler flag. It's free for you and costs something for the attacker.
baybal2 7y ago
Firmware extraction from STM32 family costs around $20-25k in China, including hardened varieties. While getting crypto keys from gemalto around $10k. Not a big impediment.
- maxbond 7y ago
  In what universe is $20k not a big impediment? Did you mean $20?
  - saagarjha 7y ago
    In the universe of a persistent attacker?
  - baybal2 7y ago
    $20K is nothing for a consumer product manufacturing run. For 9 out of 10 consumer devices, no factory will even listen to you if you are not willing to commit to put forward $1m Only really simple, small gadgets are profitably manufacturable under <$100k

saagarjha 7y ago

As someone who is currently working on a firmware reverse-engineering project (with others who actually know a lot more about what they’re talking about!) pulling tricks like these is just a massive annoyance that we’ll usually get around anyways; we’ll just curse you the entire time we’re doing it.