Re: Fuse settings question

Arv Evans


The QCX uses the same microcontroller as is used in an Arduino.  
The QCX is programmed in C-language.  I suspect that Hans does 
insert a few bytes of machine code as a way to make the code 
more compact, but only Hans could say yes or no to that.

Over the years I have used various means to make proprietary code 
so that it could not be copied.  There are numerous ways to do this.
Using the CPU internal serial number seems to be the most reliable,
but it also works to provide a read and comparison of some keyword 
and a compare to lock up the system if software has been copied, 
tampered with, or replaced.  It would even be possible to use the client's 
purchase number or date and encrypt this as a keyword to make the 
key client-specific.  

Agreed that the QCX is not an Arduino.  It has no bootloader, thus it 
requires that code installs use the SPI programming port bits MOSI, 
MISO, CLK, and RST. 
Point I was trying to make is that the QCX is not an Arduino and that 
there is more to security than simply installing a new operating system.  
Since it has no bootloader the usual bootloader process of setting 
fuses and installing .hex code does not work.  In addition I was trying 
to talk around the security method that Hans uses without giving away 
his secrets.


On Sun, May 24, 2020 at 7:54 AM James Daldry W4JED <jim@...> wrote:

Hi, Arv

The QCX is not an Arduino. The QCX is not an Arduino. The QCX is not an Arduino. Should I write it a few more times?

The QCX is not programmed in C. There has been no Serial.begin(9600) code written into it. Your "simple" string has to be written a half-byte at a time to the LCD. The code to make the comparison and goto a do-nothing loop will be probably 20 bytes. _THERE_  _ISN'T_  _20_  _BYTES_  _TO_  _SPARE_.


On 5/23/20 8:28 PM, Arv Evans wrote:


if (a != b) { Serial.println ("security code violated");
exit(1);  // product validation is simple!

Possibly was in the code from the time when an Ebay vendor tried to sell U3 
boards and expected QRP-Labs to support their marginal products.


On Sat, May 23, 2020 at 6:02 PM Larry Howell <larry.howell.47@...> wrote:
Any non-trivial decryption would require additional flash resources that do not exist.  I'm sure Hans is down to counting bits at this point.
Larry AC8YE

On Sat, May 23, 2020 at 7:54 PM Arv Evans <arvid.evans@...> wrote:
If I were trying to protect my proprietary software from being plagiarized
I would probably copy a key (maybe the CPU serial number) into the .eep 
file and then include code in flash memory to test for a match between 
CPU serial number and that key in the .eep space.  There are several other 
ways to do this.  Multiple tests could be done, or even encrypt the 
embedded key and test for proper decryption.  


On Sat, May 23, 2020 at 5:07 PM Ham Radio <bernard.murphy@...> wrote:
The documentation on the QRP-LABS site should be updated regarding checking the HI fuse for X’D1’ for the first re-flash of the firmware.

If the HI  fuse is not correct, is the micro totally bricked or can the problem  be fixed using the  .eep file?
73, Bernie, VE3FWF

Join to automatically receive all group messages.