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.
Quote from: JKnightandKARR on Nov 27, 2024, 10:28 AMOk, 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.
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..
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.
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
Quote from: JKnightandKARR on Nov 27, 2024, 04:40 PMI 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.
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..
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.
Quote from: granz on Nov 27, 2024, 08:38 PMOne 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
Quote from: granz on Nov 27, 2024, 08:38 PMOne 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.
Quote from: JKnightandKARR on Nov 27, 2024, 09:01 PMInteresting 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 (https://savagecircuits.com/z80-control-board/) were done this way, meaning using a CPU instead of an MCU.
Got ya
Quote from: Chris Savage on Nov 27, 2024, 09:05 PMThe 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.
Quote from: granz on Nov 28, 2024, 08:00 AMYeah, 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.
Quote from: Chris Savage on Nov 28, 2024, 08:21 PMAs 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. :P )
Quote from: granz on Nov 29, 2024, 07:27 AMThis 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. :P )
I think it's a good idea. On a larger project like this, I would be inclined to use MCUs as co-processors for individual sub-functions, with an ACM running the show. A Z80 would be perfectly capable of running such a system with plenty of speed @ 8MHz. If you need more, the W65C02 runs at upwards of 20MHz, I believe. Still, this scrambling of the data lines could then be implemented on the main code. You could use Atmel MCUs (or Arduino via the Atmel IDE) for the sub-functions and you've have really good protection overall.
I can't remember what chip it was, but I remember reading a post somewhere about a commercial IC, I think from the 80s, whose data lines were backwards, such that, when connecting it to a system, you would wire D0 to the D7 on the data bus and so on.
Quote from: Chris Savage on Nov 29, 2024, 01:43 PMI can't remember what chip it was, but I remember reading a post somewhere about a commercial IC, I think from the 80s, whose data lines were backwards, such that, when connecting it to a system, you would wire D0 to the D7 on the data bus and so on.
Hmm, I don't remember that one. That does seem strange, though.
Quote from: granz on Nov 29, 2024, 07:27 AMJoe - 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. :P )
I can check that out. Thanks, but might as well just use what I know, and call it a day.
Quote from: JKnightandKARR on Nov 30, 2024, 12:00 PMI can check that out. Thanks, but might as well just use what I know, and call it a day.
Yep, that is often a good idea.
On the other hand, the WebMite (Raspberry Pi Pico with MicroMite BASIC as the firmware - https://geoffg.net/webmite.html) is an excellent option. It has a VERY capable BASIC compiler (it runs very much like TurboBASIC where it acts like an interpreted language.) BASIC gets quite a few nasty comments, but almost all of them come from people who are stuck in the 1960s; this BASIC has nearly all of the modern language attributes. In addition, it is very difficult to beat modern BASICs for ease of learning, and rapid development. Finally, you can get a Pico from MicroCenter (get the Wireless for built-in WiFi networking, and pay the extra $1 for them to solder in the male headers - easier to breadboard.) The price for both the Wireless, and the header, options is only $7 - I've gotten several (plus more each time I visit MicroCenter) for playing/experimenting. If you want the Pico without the WiFi option, there is a PicoMite BASIC (https://geoffg.net/picomite.html) which replaces the wireless networking commands with some better GUI commands for the LCD displays - yes, GUI commands already built-in for many different LCD modules, plus the opportunity to write your own driver for an LCD which is not natively supported.
If you are already set on Forth, Python (MicroPython) or C, then those are also options, plus probably more.
Quote from: granz on Nov 30, 2024, 06:29 AMHmm, I don't remember that one. That does seem strange, though.
I think it may have been a sound chip from the 70s / 80s.
Jeez... The whole reason that I brought up the WebMite is because of the "security" built-in, and I totally forgot when I wrote my last reply. The user's manual (https://geoffg.net/Downloads/picomite/WebMite_User_Manual.pdf, page 79) shows that the OPTION PIN gives protection against reading/modifying the source code. It is probably not an extremely secure protection, but who is it that you are worried about reading your code? This should provide protection from most people, just like the security fuses on AVRs, PICs and other controllers.
I actually have a couple of those, i think i modified 1 already. Need to figure out what i did with them and try it.
Quote from: JKnightandKARR on Dec 01, 2024, 03:53 PMI actually have a couple of those, i think i modified 1 already. Need to figure out what i did with them and try it.
Just checking in to see where you're at on this project. I didn't know if you ever hashed out how you were going to proceed.
Quote from: Chris Savage on Feb 27, 2025, 01:49 PMQuote from: JKnightandKARR on Dec 01, 2024, 03:53 PMI actually have a couple of those, i think i modified 1 already. Need to figure out what i did with them and try it.
Just checking in to see where you're at on this project. I didn't know if you ever hashed out how you were going to proceed.
I've started by looking over the manuals on it. I figured that would be the best place to start.
Quote from: JKnightandKARR on Feb 28, 2025, 12:16 AMI've started by looking over the manuals on it. I figured that would be the best place to start.
Okay, well let us know if you need any help with that information. 8)
I know y'all will help if I need it. Thanks!
Quote from: JKnightandKARR on Feb 28, 2025, 12:16 AMI've started by looking over the manuals on it. I figured that would be the best place to start.
So which manuals are you looking over? And, which microcontroller are you considering?
Quote from: granz on Mar 01, 2025, 05:39 AMQuote from: JKnightandKARR on Feb 28, 2025, 12:16 AMI've started by looking over the manuals on it. I figured that would be the best place to start.
So which manuals are you looking over? And, which microcontroller are you considering?
Probly P1 and the PicoMite you mentioned before
Quote from: JKnightandKARR on Mar 01, 2025, 02:47 PMProbly P1 and the PicoMite you mentioned before
One of the things that I like most about the Raspberry Pi Pico is the PicoMite BASIC language. It is probably the best all-around controller BASIC, and is extremely powerful on it's own. And, BASIC is one of the best/easiest languages for beginners. The PicoMite manual has a tutorial for easily learning their brand of BASIC (https://geoffg.net/Downloads/picomite/PicoMite_User_Manual.pdf .)
That said, if you want to go with other languages (including C, and assembly) you can get the Pico, and just use it in the Arduino environment, or use Python. Using C, or assembly, you can get some pretty good speed. Although, PicoMite BASIC allows you to under-/over-clock the controller, right from BASIC command line - from 48 MHz all the way up to 378 MHz! Right darn fast, there.
If you do not have a Pico, and are going to buy one, I recommend that you get a Pico 2H - it is the newer version of the Pico, and the headers are already soldered on, it's only a couple bucks more than the plain. The included header will save you a bit of time (although with the way my eyes are going, I am trying to get all my Picos with the headers soldered on. :( )
Quote from: granz on Mar 01, 2025, 03:22 PMQuote from: JKnightandKARR on Mar 01, 2025, 02:47 PMProbly P1 and the PicoMite you mentioned before
One of the things that I like most about the Raspberry Pi Pico is the PicoMite BASIC language. It is probably the best all-around controller BASIC, and is extremely powerful on it's own. And, BASIC is one of the best/easiest languages for beginners. The PicoMite manual has a tutorial for easily learning their brand of BASIC (https://geoffg.net/Downloads/picomite/PicoMite_User_Manual.pdf .)
That said, if you want to go with other languages (including C, and assembly) you can get the Pico, and just use it in the Arduino environment, or use Python. Using C, or assembly, you can get some pretty good speed. Although, PicoMite BASIC allows you to under-/over-clock the controller, right from BASIC command line - from 48 MHz all the way up to 378 MHz! Right darn fast, there.
If you do not have a Pico, and are going to buy one, I recommend that you get a Pico 2H - it is the newer version of the Pico, and the headers are already soldered on, it's only a couple bucks more than the plain. The included header will save you a bit of time (although with the way my eyes are going, I am trying to get all my Picos with the headers soldered on. :( )
I actually got couple of Pico's from MicroCenter in Columbus last year sometime. I know i got 1 set up already from my laptop.
Quote from: JKnightandKARR on Mar 01, 2025, 07:46 PMI actually got couple of Pico's from MicroCenter in Columbus last year sometime. I know i got 1 set up already from my laptop.
So, did you set it up with PicoMite BASIC, or Arduino, or something else?
PicoMite actually.
Quote from: JKnightandKARR on Mar 01, 2025, 09:32 PMPicoMite actually.
Nice. Well, like Chris said, let us know if you have any troubles.
Will do