Microcontroller recommendation

[JKnightandKARR]

   Ok, was just thinking of an option for a microcontroller for my Knight Rider dash project.  I don't mind learning new language(s) if needed, but I do have atleast one requirement for it, and an optional that REALLY would be nice.  What I REALLY WANT is, only MYSELF being able to put program on it, and it NOT be able to be pulled off the MCU by Jimbo the thief or is this just wishful thinking??  Since I am going to try and sell this stuff, and there's never been thieves out there........  I'd want the best way to keep my work secure.  I'd love something like the propeller with multiple cores, atleast for the Speedometer/Odometer and the message center, planning on it not only play random messages like in the series, but also tell stuff like "Service Engine Soon" and "Brake Warning".
   Or if someone has an idea how I can protect my work, other then sanding the information off the IC chips and maybe using epoxy over some of the pins to protect data lines.  I guess I could protect the data lines by putting them inside a 4 layer PCB, then just epoxy the pins, and just use what controller I want.  I already have speedo/message center programs for the propeller.  I assume P2 uses all the same code, plus more of its own?  I tried looking at the documentation for P2, but its not the same as P1 doc as far as me being able to understand what I am looking at.  Prefer to use the Prop for this since I can multiplex and run each board from 1 chip.

[Chris Savage]

Ok, was just thinking of an option for a microcontroller for my Knight Rider dash project.  I don't mind learning new language(s) if needed, but I do have atleast one requirement for it, and an optional that REALLY would be nice.  What I REALLY WANT is, only MYSELF being able to put program on it, and it NOT be able to be pulled off the MCU by Jimbo the thief or is this just wishful thinking??

This is just "wishful thinking". I learned a long time ago; if someone really wants to get at your code, they will find a way. Many people have done it on microcontrollers that have the ability to "lock" the program from being read.  Where there's a will, there's a way.

This is more likely to happen if you have a high-demand product that is pricey. I would surmise the Knight Rider franchise is somewhat of a niche market, relatively speaking. I wouldn't try to over-complicate the hardware in a futile attempt to protect the code.

That said, there are microcontrollers that, as I mentioned, have the ability to lock the code from being read. Atmel is a good example. Both AVR and ATmega MCUs have lock bits that can be set to prevent reading / cloning of the program data. I believe it is even possible to protect Arduino code by downloading the program using the Atmel IDE and / or using the IDE to set the lock bits after.

While I have never used the lock bits, the ATtiny can be locked as well and I used to use those as co-processors for the BASIC Stamp modules back in the day.

Slightly off-tangent: In the past I had Parallax customers ask me how to interface hardware to the BASIC Stamp module or P8X32A for production products. I was usually unable to get the hardware, often for NDA reasons. However, when given documentation or the datasheet for some hardware, I was able to program another device to "act like" or "emulate" the hardware I didn't have, so I could help with the code. It really depends on how clever someone is as to what they're capable of.

[JKnightandKARR]

Was afraid this is the case... maybe SMT P1 sanding all info off will make it harder on its own.   Thanks for the info Chris, its appreciated.

Edit: I guess, I could hide code using unused I/O pins to display certain patterns or in message center something like "JKnight Electronics" when activated with an IDnumber to indicate what set it came from... least it would give id to the source..

[Chris Savage]

As someone who has used the P1 in designs I can tell you, there's nothing you can do that will protect your code. The Propeller Chip uses external EEPROM to store the program. The whole thing is loaded into memory during start-up. So simply putting a logic analyzer on the bus of the EEPROM will give you access to the data at start-up.

Sanding off the numbers isn't very effective either. Remember, we now have easy access to inexpensive tools that give you a lot of information about hardware. JTAGulator, Logic Analyzers, and if you know the platform, the dev tools themselves in some cases.

I used to design boards based around the Z80. To keep people from disassembling my code, I embedded the data for various subroutines at the end of each subroutine. The idea was that as the disassembler is going through the code, it hits data blocks which are not valid code, mucking up the works. It sounded good when I did it. Then I lost the source code to a project and had to reverse engineer it.

It didn't take long. The disassembler did exactly as expected, but it wasn't difficult to follow what the code was doing and comment the data bytes within the various subs. In fact, it was easier than I expected since I understood the Z80 code. I myself have reversed Z80 hardware / software designs from other companies.

The best you can do is build a quality product and sell it for a fair price. Don't give anyone a reason to want to put the effort into trying to reverse engineer it. The reason I put the effort into one of the products I reverse-engineered was that BG Micro, a close-out / overstock distributor no longer in business sold an unnamed product simply listed as "unknown telephone device". It was $5.00! But it contained a Z80, EPROM, SRAM, I/O, etc inside a white plastic case that had a P/S and two telephone jacks on it. BG Micro had no information on the device, but for $5.00 a buddy of mine bought 4 units and gave me one to reverse engineer, which I did in short order.

The idea was that would could repurpose the board and save money having to make our own PCB (this was in 1993). The only problem was, when we went back to get more, they were sold out! Had we bought the 1,000+ units they had, we could have made a killing on the hardware. My point is that these were easy to reverse engineer and super cheap, so worth the effort for someone like me at that time.

The 80s and 90s saw many attempts to protect IP via software and hardware. Sometimes a combination of the two. For example, there were pieces of software which employed and external dongle that plugged into the hardware in order to run the software. Sometimes people would try to reverse engineer the hardware. Sometimes they would scan the code to see where it looked for the dongle and just patch it to bypass that.

Another option is that, if you're using multiple pieces of hardware, you could serialize your peripheral devices and check for those serial numbers from the main controller. There are examples of devices / products that do this. If the end-user replaces some component, the serial number no longer matches and the device stops operating until serviced by an authorized tech who can update the serial numbers.

For example, if I was selling Knight Rider dashboard components, I might make each device with an ATtiny MCU that has a unique serial number. When connected to the main computer, this device would be activated with a code. The code wouldn't work for anyone else, only the person with the computer that has the correct serial number. Now if someone copies hardware, the would not be able to (anytime soon) get the device to work without first decoding the software on both ends to determine how the algorithm works.

That was just an off-the-cuff thought. I hadn't really created a flow-chart to flesh it out, but as I said there are devices that something like this. Even with M$ Windows when you install the system creates a hash checksum related to your hardware and registration information. You can image your drive and restore your system from that image, but if you try to put it on another PC (even the same configuration), Windows will complain that the hardware is different.

[JKnightandKARR]

Yeah, that's the one thing about the Prop I don't really like. The ext EEPROM... I could always make mock code to do trash job for it, n have it on different address then 00 or whatever, and try and hide address lines, but like you said, wouldn't take but time.. so guess best I can do is just make it and dist required files to only those who need to know, mainly for proof and ID, any stolen work if mine originally.. Sadly even if it happens, not much todo about it.. Esp since Universal Studios owned, lucky most of the stuff in these cases is either Firebird parts or the fiberglass conversion..

I actually have 1 or 2 of those dongles... Parallel port to be exact. Lol

Oh well....... was just a thought anyhow... thanks for info

[Chris Savage]

I actually have 1 or 2 of those dongles... Parallel port to be exact. Lol

I actually saved the dongles for software years after it was obsolete. I took all of them apart one day. Some were simple with just a resistor, an RC circuit or just jumper wires. A couple had a blob IC. But I never forgot how, if you were a skilled programmer, you could just go into the code and bypass the check altogether.

Reminds me of the days (C=64) where some games stored their character info on a floppy disk and you could use a track / sector editor to manipulate the values. Helped a friend do that once for Dungeons & Dragons RPG game. Pools of Radiance, maybe? Anyway, we mapped out the stats using my software and could add gold, stam, mana, etc.

Ah, the old days...now much is in the cloud and you must be connected online to play.

[JKnightandKARR]

I know the feeling..  Don't always like online stuff... very little infact.. work arounds or key gens lol long time ago...

They brought Atari 26/7800 back... nothing more then emulator that plays cartrages vs roms..

[granz]

One thing that I remember from many years ago (this won't work with microcontrollers, but may spark an idea from someone,) is to take and scramble the data lines. In other words, D0 from the CPU goes to D3 on the memory, D1 goes to D4, etc. This would require some special programming to correctly burn the ROM (whatever kind you use,) but without knowing what order the data lines go from the ROM to the CPU, no one could get anything out of the software stored in the ROM - it would all appear to be "random trash." The CPU doesn't care that the data in the ROM is scrambled, so long as it is decoded by the PCB traces taking the data from the ROM and "unscrambling" it on the way to the CPU.

I'm not sure if you are interested in building your own "microcontroller" from a Z-80, 1802, 6802, whatever, but it may work.

[JKnightandKARR]

One thing that I remember from many years ago (this won't work with microcontrollers, but may spark an idea from someone,) is to take and scramble the data lines. In other words, D0 from the CPU goes to D3 on the memory, D1 goes to D4, etc. This would require some special programming to correctly burn the ROM (whatever kind you use,) but without knowing what order the data lines go from the ROM to the CPU, no one could get anything out of the software stored in the ROM - it would all appear to be "random trash." The CPU doesn't care that the data in the ROM is scrambled, so long as it is decoded by the PCB traces taking the data from the ROM and "unscrambling" it on the way to the CPU.

I'm not sure if you are interested in building your own "microcontroller" from a Z-80, 1802, 6802, whatever, but it may work.

Interesting idea... too bad the Propeller only uses 2 lines... lol

[Chris Savage]

One thing that I remember from many years ago (this won't work with microcontrollers, but may spark an idea from someone,) is to take and scramble the data lines. In other words, D0 from the CPU goes to D3 on the memory, D1 goes to D4, etc. This would require some special programming to correctly burn the ROM (whatever kind you use,) but

The way I would do this would be to compile the program normally, then run the binary image through a PC app that can rearrange the bits the way the data lines are set up. This would take mere minutes to do, then you could burn the binary normally, but it would only run if the I/O was scrambled the same way the bits were rearranged. Simple, but neat idea. Could make things much harder. I like the way you think, granz.

[Chris Savage]

Interesting idea... too bad the Propeller only uses 2 lines... lol

He was referring to, if you used a CPU rather than a MCU. My original control boards for my automotive computer were done this way, meaning using a CPU instead of an MCU.

[JKnightandKARR]

Got ya

[granz]

The way I would do this would be to compile the program normally, then run the binary image through a PC app that can rearrange the bits the way the data lines are set up. This would take mere minutes to do, then you could burn the binary normally, but it would only run if the I/O was scrambled the same way the bits were rearranged. Simple, but neat idea. Could make things much harder. I like the way you think, granz.

Yeah, that would work - IIRC, my idea, at the time, was to manually write the monitor code (by hand on paper) and then rearrange that by hand then burn it into the EPROM. Your idea is much easier, quicker and better overall.

[Chris Savage]

Yeah, that would work - IIRC, my idea, at the time, was to manually write the monitor code (by hand on paper) and then rearrange that by hand then burn it into the EPROM. Your idea is much easier, quicker and better overall.

As someone who has written software on PC since the DOS days, I have often had to write utilities to upgrade files from one version to another. I'm no stranger to writing code to read the contents of one file and output them to a new file with changes, so that's how I think of this scenario.

[granz]

As someone who has written software on PC since the DOS days, I have often had to write utilities to upgrade files from one version to another. I'm no stranger to writing code to read the contents of one file and output them to a new file with changes, so that's how I think of this scenario.

Yep, I got started well before the PC came out. In fact, in the early '90s, I had a job where one of my tasks was to take data tapes (from old mainframe computers) use a data service to convert the data to QIC-80 tapes, and then convert the data from EBCDIC to ASCII. I was the only person in the company who knew what EBCDIC was.

This idea, however, came from long before that job, it was in the early-mid '80s when my home computers had 1K - 16K RAM, and the computers that I was designing were all custom point-to-point circuits. And, I never really implemented that idea - I just never had the need. It was just from my work with computers and the stuff that I saw about cryptography. By the time the PC rolled out, I wasn't all that worried about protecting my programs.

Joe - the type of controller that I was describing was (like Chris said) just a CPU along with some (E)ROM, some RAM and some I/O chips. This could all fit onto a smallish PCB, and then be used in place of an Arduino, or Prop. A good example of this is San Bergmans' Nano-6802 (https://www.sbprojects.net/projects/nano6802/index.php). If you were to wire up his circuit, and then scramble the data lines between the EPROM and the M6802 CPU (but leave the data lines unscrambled between the CPU and the 6821 PIA,) and then "scramble the program/data in the EPROM, you would have a controller that acts kind of like an Arduino - but anyone taking the ROM (without noticing the scrambled data lines) would be unable to read the program. (Wow - sorry about the run-on sentence.  )