anti-counterfeit, laser ablation?

[galahad]

Hello,

one of our products was copied by a chinese company. The HC08 CPU program code was copied, too. We are now looking for anti-counterfeit technologies.

We made some tests with our EPILOG Laser Engraver and tried to remove the markings on the HC08 and some other chips. This seems to work well, but if we hit a pin or several pins with the laser, something gets damaged, and the isolation between pins is suddenly below 100k Ohms or wourse.

Does anybody have experience in de-marking chips using a co2 laser or any other technologie?

Thanks a lot from germany

Joerg

[tonyp]

So, you suspect, because they knew what chip you used, they brute-force attacked it, found your security 'key', and managed to simply download your code using normal programming tools?  And so, hiding the chip will stop them?

All current security schemes are only meant to protect from your average 'amateur' hacker, not the determined professionals with the right (possibly, quite expensive) equipment at their disposal.

Well, if they copied your MCU by photocopying its memory contents (think of X-ray like method), no amount of demarking can hide the chip from them.  They can still see the chip and can even identify it by its internal shape.  No amount of Flash security can make a difference in this case.  They simply copy the Flash contents as-is without using BDM, or other physical connection to the chip.  They don't even have to power it up, so certain anti-tamper schemes to erase all contents also fail.

As you know, the HC08 also has security, and it is even automatically engaged simply by programming the chip, as the security is based on the contents of a certain range of its vector memory.  The S08 only changes the method of security, while allowing the option of no security at all.  But all this security is related to 'entering' the chip the expected way.  If the chip's memory contents, however, can be 'seen' via other methods, all Flash security methods of the current sort will make no difference.  (Only perhaps a different physical construction of the chip may make it very-very hard to copy, but that possibly needs some research, ... and, certainly, chips that aren't produced by the hands of those who will eventually copy them.)

There is no easy solution against a people who respect no copyrights, and who don't mind (fear) selling a clone under a no-brand while using your own (even visible on an LCD) copyright, and while there is no authority to stop them from doing so.

Only stricter US/EU policies against them (e.g., a serious embargo, etc.) may have some effect over time.  Also, a strong campaign to pass the message to people to stop buying illegal copies (as it eventually only backfires into their own economies) may help in the long run.

Until then, good luck!

[kef]

HC08 allows to enter key. One may try all key variants.

S08 doesn't accept any keys over BDM. Backdoor unsecure can by engaged only by software that runs on chip. You can't put some nice little proggy to RAM and execute it. You can't patch flash or EEPROM. You can only erase all the flash. This is much better than it was in old HC08.

I wonder how much does this electronic microscopy / X-ray scanner cost. Certainly it should cost less to develop new firmware.

[galahad]

"I wonder how much does this electronic microscopy / X-ray scanner cost. Certainly it should cost less to develop new firmware."

You don't need to buy such advance tools. There are service company's in china doing that for you. One of them even advertise like this: "more than twelve years in the microcontroller code recovery industry (read out program from locked chips)" So a pirate can buy this service the same way we buy pcb boards.

[bigmac]

Hello,

Presumably, these services provide only a dump of the flash memory contents.  It is a much bigger step to disassemble the code in a sufficiently meaningful manner, so that the source code may be re-generated, and the operation of the firmware is understood sufficiently to make alterations.

With MC9S08 devices, where FIE mode is used, in conjunction with the internal reference frequency, this requires calibration of the reference to achieve a specific bus frequency.  Even if the trim value can be read, this will not necessarily reveal the operating reference frequency with any degree of accuracy.  Perhaps you can make use of this factor, so that simply copying the memory image to a fresh device will limit the yield of successfully working copies.  For example, SCI baud rate may not be sufficiently accurate in many instances.

With this approach, the idea is not to utilize the "standard" flash address for the trim data.  What you might do is to initially program the standard location, as part of the normal programming process.  When the program is run for the first time you would then, from within the code, program another currently unprogrammed flash location with the same trim data, and then possibly zero the standard location.  The trim register setting would utilize the data from the new location.  On subsequent PORs, the new location would be observed as already programmed by the initialisation code.

To discourage experimentation with the trim setting, you might disable normal operation if the new trim location is programmed, and the standard location is either unprogrammed (0xFF), or has a non-zero value.  In the extreme, this could trigger a mass erase process.

Of course, if the source code has been reverse-engineered, this approach can be easily disabled, and not all copies will be sufficiently affected by the calibration error.  However, it may be sufficient to create an impression of an "unreliable" copy.

Regards,

Mac

[galahad]

Interesting idea, thank you Mac!

[peg]

Hello,

The best you can do is annoy these people for a little bit longer.

In the above example:

They know your SCI baudrate from the working sample.

From the dump they have the clock rate from the setup register writes.

They know you are running internal clock cause there is no external parts.

They know they have to customise the trim for each chip cause its in the manual.

They are already searching for accesses to the volatile and non-volatile trim registers.

They find your mess, couldn't be bothered to figure it out so just break it and add their own init code up the top.

Fixed!

[bigmac]

Hello Peg,

I think the idea is to annoy these people for a lot longer, sufficiently longer so that they will give up on your project, and tackle an easier target.  I am making the assumption that they will not want to reverse-engineer any significant portion of your code because this will require more time and effort that writing the code from scratch.  Certainly the skills required to reverse engineer at the disassembly level are greater than those to write the code.

I propose that there are some additional strategies that could be adopted, in conjunction with those measures already mentioned.

---

peg wrote:

In the above example:

They know your SCI baudrate from the working sample.

From the dump they have the clock rate from the setup register writes.

They know you are running internal clock cause there is no external parts.

They know they have to customise the trim for each chip cause its in the manual.

They are already searching for accesses to the volatile and non-volatile trim registers.

They find your mess, couldn't be bothered to figure it out so just break it and add their own init code up the top.

Fixed! 

---

The highlighted points require recognition and understanding of which code constitutes your initialisation code.  However, this could be camoflaged within the disassembly listing by the use of indexed addressing modes, rather than direct writes.  For C programming, the use of structures within the initialisation process may help.  By all means provide direct code that initialises the some of the registers to incorrect values, so as to confuse the issue.  But then use the indexed method later, to provide the values actually required.

To deter the addition of custom initialisation code, a CRC value for the flash memory can be calculated during normal operation.  This does not necessarily need to be done during the initialisation process.  The test for a specific CRC value can be well buried within the code.  (The CRC value would assume that the standard NV trim location was zero.)  You could also make use of a custom CRC polynomial.

As a further deterent, you might delay the tampered code becoming inoperative until after a number of PORs have occurred (using multiple writes to one or more flash locations).  In theory, the number of PORs required could be a somewhat  "random" value, perhaps based on the re-positioned NV trim value.

Obviously, the security measures that are taken would need to be very well documented within the source code.

Regards,

Mac

[peg]

Hi Mac,

Its difficult to know whether it is all worth it.

Going back to more conventional theft, like cars and houses. You put up with all the alarms, false alarms, fuel solenoids and locks etc on your car and then they skull drag it up on to a tilt tray (or cradle lift) tow truck and defeat everything in one fell swoop. With your house you put bars on all the windows and big doors with many locks then they remove a few tiles from the roof and jump through the ceiling.

Back to the subject, they have already copied all your hardware and some how obtained an image of your FLASH. They are already heavily invested by the time they figure out you have laid some additional traps.

You have to do all he additional work to lay the traps then you have to put up with working around them yourself for upgrades and the like. Then the big question - Have you done more than the thieves are willing to undo?

Another unknown (at least to me) is how difficult/expensive is it to obtain a FLASH image from something like an S08 HC08?

[kef]

You are right. Google found impressive list of Freescale MCU's on pcb-reverse dot com. Those S08/S12 are also listed :smileysad:

[galahad]

Thank you very much so far.

I know that there is no perfekt solution for this anti-counterfeit problem. But at least, we want to make it more difficult (= more expensive) to copy our designs. Next step is to cover parts of the board with epoxy resin. I know, its possible to remove that too.

The isolation between pins was indeed reduced by the dust residue after using the laser. We were to stupid to recognise that :smileysad:

[kef]

Removing chip markings won't prevent counterfeiters copying your designs. First of all they saw your old design and know your preferences. Even if you change the chip, power, oscillator and a-to-d pin numbers give them a clue what chip it might be.

IMO it is much better to stop using old HC08 and switch to S08 or other chips with flash security.

Regarding damaging MCU with laser. Of course excessive heat may damage the chip. Heat also can make some smoke emitted from plastic. I don't know, but maybe some smoke substances are conductive...