4

Chinese have decided to ripoff a PIC product I make. Switching to ARM for other reasons anyhow, mainly that Microchip is a joke, either STM32 or NXP LPC, exact chip is open still.

There are sites that claim to have vulnerabilities for various Cortex chips.

  • As I understand it, there could be a decapping process where the die is exposed and messed with
  • There could be a JTAG/SWD hack with a special process or over/under voltage exploit, I don't know this exists for ARM, but I know it's possible on other chip (F U PIC)
  • There is also a non-removable bootloader on almost all consumer ARM Cortex parts. I think STM32 is a USB and serial bootloader. NXP or Freescale or someone have a full Mass Storage Class bootloader. Since the code is kept hidden, there could be an undisclosed exploit there too.

Is there anything I can do to keep my code secure? Almost no one in my industry would have any idea what to do even if I handed them the C code. It's Chinese knock-offs / clones I need to worry about since they are using our name, logos, cloned hardware, my code, and undercutting official dealers.

  • The plan I have currently is to require online authentication. So that if I see a chip that isn't on my masterlist, I burn it with bad firmware. If I see a duplicated chip I verify the original and burn the clones. If the chip is valid, I like it to the user's info and move along. The legit user should see nothing but an interface for their product.

With the above idea, some one ripping us off would still get the ROM so I still have the encryption keys in the wind. While the module wouldn't really work without using it online as the interface, it's still annoying and a potential issue.

One consideration is the Chinese haven't been willing or really likely able to replicate the code without 1:1 ripping it. So I sort of think it's a leap to assume they'd rip my code, then go to reverse engineering, because that just doesn't seem like the same class of criminal that's cloning our stuff. I think they attacked us because it's such simple PCB and the code was easy to get. They likely aren't going to also reverse all the online work to make an offline interface for it, I don't think anyhow.

Thoughts on anything else I could do?

mint branch conditioner
  • 41
  • 1
  • Have you considered TrustZone for ARM chips? – ThoriumBR Sep 09 '15 at 19:53
  • TrustZone as I understand it does not apply to Cortex-M chips. Nor does it seem to apply to decapping / protection-defeat methods. I could be mistaken, but my impression of TrustZone was it's a hypervisor system in place for systems where the user will run their own code, like on A-series chips that go in phones. For the most part... What I'm gathering from my research is that whatever keys I put in place, could be eventually read out by some method. I am uncertain if the entire bootloader I make could be read as well. Leaving me where I am now, vulnerable to offline Chinese clones. – mint branch conditioner Sep 10 '15 at 17:54
  • I SHOULD NOTE: That each ARM chip seems to come with a 96-128bit unique serial ID. My plan as been to capture this ID at manufacturing and compare that to when a user plugs one in and logs in with it.... I wrote that above but failed to mention the Unique Serial ID aspect of it. – mint branch conditioner Sep 10 '15 at 17:56

1 Answers1

3

"Burning chips with bad firmware." This can result in extremely serious consequences that might even jeopardize lives.

There is definition for this type of activity. It is called sabotage and can have very serious legal consequences.

You are essentially running a cyber attack on hardware by maliciously inserting corrupted firmware with the sole purpose of bricking the device.

This is a technique used by black hats to cause irreparable damage to targets they attack. There is a chance that you will be treated as a criminal and wind up doing jail time. You can also be sued in court for countless amounts in damages.

I would not advise this unless you want to open a colossal can of worms. People understand the need to protect IP but this type of sabotage not only crosses the line but literally jumps over it. It moves from the realm of simply protecting IP and into the realm of malice.

You seriously need to consider a different way to go about this issue without causing destruction to hardware.

WAR10CK
  • 161
  • 3
  • 1
    "There's a chance" - That is - if they get who you are, and that you are doing this, you *will* face criminal charges. This situation hapenned very closely to what OP described here in Brazil - a Mechanic was sabotaging cars he was supposedly to fix because they were not using the system that someone related to he developed. He was sentenced to 25 years and had to pay a huge fine (or did not pay, I don't really know. This case is old.) – Malavos Sep 16 '15 at 16:40
  • 1
    Exactly my point. If the hardware you manufacture was used by a government and you sabotaged it because of counterfeit chips, you would be looking at multiple criminal charges and spending a very very long time in prison. – WAR10CK Sep 16 '15 at 16:58
  • Quite a difference between the scenario here and the mechanic mentioned by Malavos. Here, OP will not be destroying anything. His server will just be replying to a request with a non-functional firmware file. The device itself will perform the destructive action (erasing the original firmware in preparation to load the downloaded one), based on instructions already in the device, not the downloaded data, and it seems hard to hold anyone liable for that except the (illegitimate) device manufacturer who loaded the (stolen) destructive code into the device. – Ben Voigt Sep 16 '15 at 18:56
  • Obviously, there would be problems in case of false positives, because if a legitimate device were to destroy itself, the legitimate manufacturer would be held responsible. – Ben Voigt Sep 16 '15 at 18:56
  • OP will still be responsible because the malicious function is on a server OWNED by OP. Also if OP did not know that the function was on the server then it could be brushed off as a glitch or what not which the court would order OP to fix. But this post reveals the OP does know about this and knowingly & willfully designed it with clear intent on what it is meant to do. That is what will determine OP's fate in court and it will not be a good thing. Infringement or not OP will NOT be let off the hook. OP will still face the music for his/her actions. Two wrongs do not make a right. – WAR10CK Sep 16 '15 at 20:49
  • Some massively incorrect assumptions here! 1. No, I would not be liable for anything if I burn the knockoffs. My parts have no firmware for it's intended application out of the box. All modules are shipped Bootloader only, a legit chip gets it's app firmware online. Knockoff would get burned and would flag itself with a constant red light for our customer service department to easily spot. 2. Yes, false positive could be an issue, but a risk I'd be willing to take with the right implementation, cheaper to RMA a few modules than lose $100k-400k in lost sales to knockoffs! – mint branch conditioner Sep 18 '15 at 22:56
  • Aside from the derailment about assumed liability of something no one here could possibly actually determine... What I'm seeing is that no one seems to have pointed out a flaw in the authorization scheme I'm considering or in what other way knockoff/clones could be dealt with. – mint branch conditioner Sep 18 '15 at 22:59
  • 2
    Have your heard of the FTDIgate scandal? Your little burning tactic is almost exactly like this: https://www.youtube.com/watch?v=eU66as4Bbds&feature=youtube_gdata_player Do you really want to be the next FTDIgate? – WAR10CK Sep 19 '15 at 15:38
  • I had not really followed FTDI"gate"... But what they did was absolutely fine. You use their drivers with illegal counterfeit chips and you can expect bad results. In my case, we're talking an exceptionally rare part compared to FTDI-anything. So yes, you use my site to try and load my code to your counterfeit device - sorry. There is no legal precedent that would put any liability on me (which there could be none, since knockoffs are themselves illegal, and you're using MY side under YOUR free will). It's also an unfair comparison since my part requires connection to my site before use. – mint branch conditioner Sep 22 '15 at 17:22
  • 1
    Ok let's take this to another level: Say I manufacture a device that requires the same scheme you are using, and if the device that connects to my servers is an illegal clone then my server sends a command to cause the device to burst into flames, I guess that means I would not be held to any legal accountability because they connected to my site and their illegal clone detonated in their face. I just got away with harming someone and possibly killing them. So this means I can cause all sorts of mayhem and say it was their fault. Two wrongs DO make right now apparently. – WAR10CK Oct 02 '15 at 00:16
  • OR.... You could stop being so dramatic and hyperbolic. No one is suggesting bursting into flames or hurting anyone. We're talking about taking a non-functioning illegal clone and when you connect to an official server it breaks it so it can never attempt to reconnect to an official server again. Which happens all the time, the best example I can think of is Microsoft banning hacked Xboxes from ever connecting again. There are plenty of other examples, but you'll never get there if you just go immediate overboard. – mint branch conditioner Oct 05 '15 at 18:32
  • 1
    But Microsoft does not brick hacked XBoxes, they simply refuse to provide them with service. If your solution simply refused to give updates to clones, it would be perfectly legal, but actually damaging property which _you do not own_ is illegal. Yes, you own the copyright, but you do not own the actual devices. Intentionally causing physical damage to physical devices you do not own is a felony, and you can easily be sued for a huge amount if these destroyed devices result in lost income for a company or actual injury to an individual, whether intentionally or due to a false positive. – forest Dec 10 '17 at 07:39