3 ms·

Dumb question: why don't manufacturers disable the JTAG interface after all the flashing and testing are done? Don't get me wrong, I really appreciate them lea

by desdiv 11y ago

Dumb question: why don't manufacturers disable the JTAG interface after all the flashing and testing are done? Don't get me wrong, I really appreciate them leaving these devices easily reprogrammable for us hackers, but there's really not much benefit in it for them.

stephen_g 11y ago
Our company leaves them enabled 1) because it's not really worth the effort to disable and 2) it's super handy if you get a product returned to re-flash it if it's somehow been bricked!
- m_eiman 11y ago
  We use NXP MCUs that have a few different code protection modes. The mode we use in release code disables JTAG and Flash access, but allows erasing the entire Flash. This makes it hard(er?) to read and modify our code, while still allowing us to easily wipe a returned device and re-program it using a suitable firmware image. Selecting which mode to use is a simple matter of setting a specific value at a specific position in the Flash image, very handy.
  - duskwuff 11y ago
    The STM32F2 MCU that Amazon used supports similar features; see section 2.6.3 of: http://www.st.com/web/en/resource/technical/document/programming_manual/CD00233952.pdf http://www.st.com/web/en/resource/technical/document/program... In brief, though, the MCU can be put into "level 1" read protection which limits the capabilities of a JTAG debugger, or "level 2", which fully protects the device by disabling JTAG entirely. Given that Adafruit were able to reprogram the device, Amazon must not have used level 2 protection.
VLM 11y ago
There's two parts, the interface on the chip and the easy plugin connection. The interface on the chip can sometimes be disabled in software permanently by various flags when the chip is programmed, but that makes it impossible to troubleshoot something that got returned for failure analysis. Of course some mfgr work around that by never performing any sort of failure analysis or troubleshooting or customer service bug reports of any sort... As for the very convenient jtag port itself each PCB revision costs a substantial amount of time and money and "just rip out these traces and only these traces" as the last step invariably will screw something else up (whoops that JTAG ground pin was actually a via to the I2C bus ground, now the device is dead until the next PCB revision, this is getting very expensive and time consuming). Also faith in the software being finalized and debugged before the final hardware revision is very gratifying, but somewhat unrealistic. Unless you disable the port on the chip itself all you really do it annoy people into soldering wire wrap wires directly to pins, which is easy. (Its hard to get in, there must be something "amazing" in here to get at) Finally the EE world is full of hilarious incredibly expensive stories of mfgrs changing one tiny little bit here or there and not feeling its worth informing the buyers, then suddenly every board with an IC date code over a certain number fails and its costing the company $50K/hr or even worse they shipped and its killing reputation until some EE debugs the problem (oh ha ha sorry about that we didn't think anyone would notice we changed the hardware reset default on that IO pin from pull up to tristate after reset, your software wasn't depending on the unset default was it? oh so sorry to hear.). Slowing the engineer down by intentionally making it harder to debug the board is a great strategy to encourage your competitors to use. We're a little behind you guys, can't you take out your jtag port or somethin so we can catch up on the stuff that matters? After someone ships you a batch of bad/fake chips and "we could prove the chip is a fake or remarked with some other spec but we don't have a jtag connector to really prove it so they'll just have to trust us at the trial" and suddenly your lawsuit gets that much harder to win. Doesn't have to come to a lawsuit even just customer support with the mfgr. Its like chopping the keyboard, mouse, and monitor cable off a server for security, thats funny, but good luck getting support when the raid card breaks and you don't have a keyboard or monitor anymore and they ask you to run a simple diagnostic on the raid card. Its kind of the old DRM argument, how do I distribute encrypted video or whatever and the key to decrypt the video along with it while somehow not letting people access the key, well that's easy, you don't, outside marketing material and lies told to licensed IP holders. (Oh yeah man, chill, don't worry, nobody gonna steal your precious bits to implement your "... on the internet" patent because our jtag is upside down from everyone elses, nobody could eeeever figure that out, your bits are safe) There is no way to keep someone out of hardware they own if there is one person on the entire internet who owns a soldering iron and is motivated enough to use it. You vs the world, good luck with that. The countermeasures that can be attempted are expensive and time consuming yet won't even slow down serious opponents, but trying to implement them WILL impact your financials putting you at a serious measurable disadvantage compared to a competitor who leaves the jtag port ready to use. In summary there's no way to do it, pitiful snake oil-ish attempts that will not work waste a lot of time and money, so its only really viable in non-competitive markets or as security theater to make non-techies happy.
- kabdib 11y ago
  On a couple of projects we figured that if a customer is motivated to break in to the device, they're welcome to whatever is there. That doesn't mean we made it easy, but we didn't go out of our way to obfuscate things or erect barriers: There's SPI, there's the flash bus, have fun. We disabled the debugger that we had on the UART, though. We're not totally crazy. Just getting something working out the door is challenging enough. Firmware always comes in hot.
davelnewton 11y ago
There are lots of times when in-circuit access is invaluable, including field servicing.

by desdiv 11y ago

stephen_g 11y ago

Our company leaves them enabled 1) because it's not really worth the effort to disable and 2) it's super handy if you get a product returned to re-flash it if it's somehow been bricked!

m_eiman 11y ago
We use NXP MCUs that have a few different code protection modes. The mode we use in release code disables JTAG and Flash access, but allows erasing the entire Flash. This makes it hard(er?) to read and modify our code, while still allowing us to easily wipe a returned device and re-program it using a suitable firmware image. Selecting which mode to use is a simple matter of setting a specific value at a specific position in the Flash image, very handy.
- duskwuff 11y ago
  The STM32F2 MCU that Amazon used supports similar features; see section 2.6.3 of: http://www.st.com/web/en/resource/technical/document/programming_manual/CD00233952.pdf http://www.st.com/web/en/resource/technical/document/program... In brief, though, the MCU can be put into "level 1" read protection which limits the capabilities of a JTAG debugger, or "level 2", which fully protects the device by disabling JTAG entirely. Given that Adafruit were able to reprogram the device, Amazon must not have used level 2 protection.

VLM 11y ago

There's two parts, the interface on the chip and the easy plugin connection. The interface on the chip can sometimes be disabled in software permanently by various flags when the chip is programmed, but that makes it impossible to troubleshoot something that got returned for failure analysis. Of course some mfgr work around that by never performing any sort of failure analysis or troubleshooting or customer service bug reports of any sort... As for the very convenient jtag port itself each PCB revision costs a substantial amount of time and money and "just rip out these traces and only these traces" as the last step invariably will screw something else up (whoops that JTAG ground pin was actually a via to the I2C bus ground, now the device is dead until the next PCB revision, this is getting very expensive and time consuming). Also faith in the software being finalized and debugged before the final hardware revision is very gratifying, but somewhat unrealistic. Unless you disable the port on the chip itself all you really do it annoy people into soldering wire wrap wires directly to pins, which is easy. (Its hard to get in, there must be something "amazing" in here to get at) Finally the EE world is full of hilarious incredibly expensive stories of mfgrs changing one tiny little bit here or there and not feeling its worth informing the buyers, then suddenly every board with an IC date code over a certain number fails and its costing the company $50K/hr or even worse they shipped and its killing reputation until some EE debugs the problem (oh ha ha sorry about that we didn't think anyone would notice we changed the hardware reset default on that IO pin from pull up to tristate after reset, your software wasn't depending on the unset default was it? oh so sorry to hear.). Slowing the engineer down by intentionally making it harder to debug the board is a great strategy to encourage your competitors to use. We're a little behind you guys, can't you take out your jtag port or somethin so we can catch up on the stuff that matters? After someone ships you a batch of bad/fake chips and "we could prove the chip is a fake or remarked with some other spec but we don't have a jtag connector to really prove it so they'll just have to trust us at the trial" and suddenly your lawsuit gets that much harder to win. Doesn't have to come to a lawsuit even just customer support with the mfgr. Its like chopping the keyboard, mouse, and monitor cable off a server for security, thats funny, but good luck getting support when the raid card breaks and you don't have a keyboard or monitor anymore and they ask you to run a simple diagnostic on the raid card. Its kind of the old DRM argument, how do I distribute encrypted video or whatever and the key to decrypt the video along with it while somehow not letting people access the key, well that's easy, you don't, outside marketing material and lies told to licensed IP holders. (Oh yeah man, chill, don't worry, nobody gonna steal your precious bits to implement your "... on the internet" patent because our jtag is upside down from everyone elses, nobody could eeeever figure that out, your bits are safe) There is no way to keep someone out of hardware they own if there is one person on the entire internet who owns a soldering iron and is motivated enough to use it. You vs the world, good luck with that. The countermeasures that can be attempted are expensive and time consuming yet won't even slow down serious opponents, but trying to implement them WILL impact your financials putting you at a serious measurable disadvantage compared to a competitor who leaves the jtag port ready to use. In summary there's no way to do it, pitiful snake oil-ish attempts that will not work waste a lot of time and money, so its only really viable in non-competitive markets or as security theater to make non-techies happy.

kabdib 11y ago
On a couple of projects we figured that if a customer is motivated to break in to the device, they're welcome to whatever is there. That doesn't mean we made it easy, but we didn't go out of our way to obfuscate things or erect barriers: There's SPI, there's the flash bus, have fun. We disabled the debugger that we had on the UART, though. We're not totally crazy. Just getting something working out the door is challenging enough. Firmware always comes in hot.

davelnewton 11y ago

There are lots of times when in-circuit access is invaluable, including field servicing.