Timeline for Protecting firmware .bin from reverse engineering
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 30, 2020 at 6:09 | comment | added | Marcus Müller | @JörgWMittag again, very few people actually deal with consumer mass product that have so much of a community that'd be interested in breaking their product's security. Thread modeling models basically any device with a lower need for security than a gaming console. And thinking a motivated student is worse at this than some half-educated engineer at a Chinese clone shop is really not founded in reality, as you've noticed. | |
| Jul 29, 2020 at 21:06 | comment | added | Jörg W Mittag | @MarcusMüller: I am not assuming that. Microsoft was assuming that and they got burnt by it. They defended against organized copyright pirates, but were beaten by hobbyists. For the original XBox, specifically, they assumed that copyright pirates couldn't afford the high speed oscilloscope required to sniff the secret key off the bus, but instead the key was recovered by a student who didn't need to afford such an oscilloscope because the EE department at his university had invented and built one. | |
| Jul 25, 2020 at 19:00 | comment | added | Marcus Müller | I find it interesting that you assume Warez groups have better personell than motivated groups of students / Linux users. | |
| Jul 25, 2020 at 15:02 | comment | added | Jörg W Mittag | @MarcusMüller: "These people usually don't have the greatest engineers" – In the world of ubiquitous information, they don't need to. The XBox was cracked not by counterfeiters or warez groups but by students wanting to run Linux. DRM schemes were cracked not by pirates but by students wanting to watch their legally acquired movies on Linux. Licensing schemes were cracked not by warez groups but by legitimate users getting fed up with the licensing software crashing their PC. | |
| Jul 24, 2020 at 21:34 | comment | added | Charles Duffy | (Certainly, a sufficiently resourced and motivated attacker will eventually get into anything, but doing one's job well enough can make a different part of a target's infrastructure be the easiest way in, rather than the device one is responsible for engineering; even if it leads to a supply-chain attack rather than a pure software one, it looks better for an engineering organization's reputation if something had to be physically tampered with to compromise a customer). | |
| Jul 24, 2020 at 21:31 | comment | added | Charles Duffy | @MasonWheeler, ...that said, how tempting of a target a given device is matters. Not everything is sold into consumer markets. That's good and bad -- you might have fewer people interested in taking a shot at breaking the firmware, but they might be significantly better-funded or more nefarious in their intent. | |
| Jul 24, 2020 at 14:46 | comment | added | Mason Wheeler | @MarcusMüller Yes, I explicitly said this is an extremely black-and-white issue because the nature of the world-wide web means that cracked once anywhere is cracked everywhere forever. There are a lot of places where black-and-white thinking doesn't apply, but in this particular case, it absolutely does. | |
| Jul 24, 2020 at 9:42 | comment | added | Graham | @MarcusMüller So you pick the low-hanging fruit - disable your JTAG ports, and so on. You don't make it trivially easy. But when it gets to someone spending serious time with a memory analyser or anything like that, you have to accept that you're going to lose that battle. As MasonWheeler says, the answer then is not to play, because you're just falling into a money pit. Put the same money into designing new features, and the reverse-engineers will always be on the back foot because you're constantly upgrading your firmware. | |
| Jul 23, 2020 at 19:21 | comment | added | Marcus Müller | @MasonWheeler I wholeheartedly disagree. You're also using a very black&white picture of reality: The reality is that people will sell counterfeits of mass products. These people usually don't have the greatest engineers (their's higher-margin jobs for great engineers than cloning a bluetooth headphone). Not being the manufacturer that has the easiest to read firmware is a boon. You don't realize how low a bar can hang and still make a lot of commercial difference. | |
| S Jul 23, 2020 at 18:52 | history | suggested | jpaugh | CC BY-SA 4.0 |
Link to referenced question
|
| Jul 23, 2020 at 18:08 | comment | added | Mason Wheeler | @jpaugh No, the only winning move is to not even try to protect software you distribute into the hands of third parties from cracks. It's a fools errand and always has been. | |
| Jul 23, 2020 at 18:05 | comment | added | jpaugh | @MasonWheeler The only wining move is not to write software? That's not practical. Perhaps, by publishing the source code and encouraging an active community around it, you can convince folks to notify you of bugs before other folks exploit them. | |
| Jul 23, 2020 at 18:04 | comment | added | Mason Wheeler | +1. "Code security" is an extremely black-and-white topic in the age of the Web: if one person anywhere in the world manages to reverse-engineer your system and posts a crack online, it's cracked for everybody, forever. So your security is either perfect or it's worthless... and it's never perfect. The only winning move is not to play. | |
| Jul 23, 2020 at 18:01 | review | Suggested edits | |||
| S Jul 23, 2020 at 18:52 | |||||
| Jul 23, 2020 at 14:23 | history | edited | multithr3at3d | CC BY-SA 4.0 |
added 50 characters in body; added 380 characters in body
|
| Jul 23, 2020 at 12:48 | history | answered | multithr3at3d | CC BY-SA 4.0 |