Open source...

Let's Make Robots Project Ideas
1

Hi Mike,

As you know the original SSC-32 was made open source. The concept was to invite others to make firmware flavors for the SSC-32 hardware we make. There has been no firmwares submitted from the beginning. A while back, the SSC-32 hardware and firmware was copied in China. They added an xbee interface, but beyond that it is 100% copied. Obviously too late, but we decided to pull the info and did so. Recently a person from Japan inquired about the code and was told it is no longer open source. He found the firmwares on the Internet and posted them in several places intending to irritate us. Saying Lynxmotion, respect your words… Well the code he spread around was not the firmware we made open source. That was the old Mega 8 firmware. He posted the new mega 168 firmware and the GP firmware. From what I remember they were not the source, just the hex code. This latest run of 2500 SSC-32’s hopefully will be the last. We intend to reinstate the original open source files, but nothing beyond that. So…

Do you think we could lock down the I/O processors code?

I don’t think the copy is making a serious dent in sales, but honestly there is no way to tell for sure. What are your thoughts concerning open source on the new SSC-32?

2

Jim,

I remember a knock-off of the SSC-32 a couple of years back that was pretty obvious. It looked like they didn’t even bother to use the source code, just read out the contents of a chip, found where the version string was, and changed “SSC-32” to something else. The open source status of the software didn’t make any difference in that case.

One thing I think is very important in today’s market is the ability to update firmware in the field, even stuff like the I/O processor. I am all in favor of putting up roadblocks to theft, but only if it doesn’t prevent us from having an important capability. I’ll have to investigate what the possibilities are to make it difficult to copy the contents of the I/O processor. In the end, though, it is probably not possible to thwart a determined pirate.

I don’t see a need to release the complete SSC-32 application software (on the main processor) as open source. But I think we should offer an open source library to allow people to easily create their own applications on the board. The SSC-32 application would use the library to create a complete and fairly complex product. Of course, people would probably appreciate it if we made the SSC-32 app available as an example. But it would probably be just as good to port over some Basic Atom apps as examples of how to use the library.

This was sort of meandering. My instinct is always to be open with information, but I understand the desire to protect business interests in a case like this. I think we can come up with a compromise that keeps some of the information proprietary but still allows maximum flexibility for legitimate users/customers.

Mike

3

Jim,

OK, I mulled this over during my bike ride tonight. What I think we are after is a way to make it difficult for pirates to steal this and sell it as their own, without making things more difficult for users. Note that I said difficult for pirates to steal, not impossible. There are some really smart people out there. But the harder it is, the more likely they are to move on and find a different approach. (Unless you get somebody who just enjoys a challenge.) So I would like to start some brainstorming on how to make it more difficult for a pirate.

The idea that I thought about tonight was to make it difficult to conceal the fact that this is a Lynxmotion product. The old SSC-32 knock-off was pretty easy because the string “SSC-32” is there in the flash memory, in plain ASCII text. It’s easy to change to make the version string say anything, as long as the new string is no longer than the original. So why not obfuscate it so it is difficult to change and/or if changed the product will not work correctly. Here is a proposal:

  1. Keep the I/O processor source code and the SSC-32 application proprietary. (But make the library open source.)
  2. In the I/O processor have a command to read the version string. The I/O processor will not function until the version string is read. The version string will say “SSC-8-V1.23© 2011 Lynxmotion” or something like that. The string will be obfuscated in the flash so it is difficult to find. And/or there might be an interlock such that if the string is changed the I/O processor will not function.
    ==> Since this string cannot be changed (easily) and must be read, monitoring the bus would make it obvious that it is a Lynxmotion product.
  3. Similarly, in the main processor obfuscate the version string and/or have an interlock that causes the app to fail if the string is changed.
  4. In the main processor, have a new command to print the I/O processor version strings.
  5. Consider having the main processor send all version information to the USB port on power-up. (But not to the TTL serial port.)
  6. Consider having undocumented commands in the I/O processor and main processor that return the Lynxmotion copyright notice.

None of these would prevent somebody from copying the code in the I/O processor or the main processor, but they would make it difficult to hide the origin of the code. I think that would serve as a deterrent.

Just some thoughts to get discussion going.

Mike

4

I checked the datasheet for the I/O processor. It supports a secure mode that prevents reading flash without first erasing the device. Unfortunately it might also prevent me from using the chip in some of the ways I was planning, so we will need to see how that plays out. But I will certainly use the secure mode if possible without compromising functionality.

The security hole then would be when reflashing the I/O processor (an unusual event, but it will probably happen either as a bug fix or new feature). I plan to create an app for the main processor to flash the I/O processors. The reflashing process could also be obfuscated to make it more difficult to figure out by snooping. I have some ideas about how to manage that.

Mike

5

Hi Mike, Sorry for the delay in commenting. I’ve missed some time and am trying to catch up. The ideas you have mentioned are all good. I also do not want you to get bogged down in this. Do what you can, but don’t let it restrict functionality. It’s true that you can’t stop a determined pirate, Arrr! but we should not put everything on a silver platter. :smiley: Thanks!