Protect data in memory flash

Hi, how are you?

I would like to know if there is any way to protect the information in flash memory so that not anyone who connects to the serialport can get the javascript source code.

Is this possible?

Thank you in advance.

Most MCs have this option. But since Espruino pulls most of the code into the RAM for execution, it is not that simple. Is there a way to keep secret stuff server side and not in Espruino?

An appealing value proposition may not need the protection of code in the sensing device.

You can:

• Use E.setPassword to stop anyone logging in via the REPL
  
• Use something like LoopbackA.setConsole() to move the REPL somewhere it can't be accessed by anyone at all
  
• Store your JS code in flash memory as an encrypted string and then decrypt that into RAM at runtime.
  
• Minify/obfuscate your code using standard JS tools - this is the easiest (minification is an option in the IDE) and realistically it's going to make your code very hard to reverse engineer, while also using less memory.
  
• Make your code check getSerial() to ensure it will only run on one device
  
  

I'd suggest a combination of the them - making the REPL inaccessible, minifying your code, and checking the serial number should give you pretty good protection, and even if someone attaches a debugger and completely reads out saved code and writes it to a new device, it will still refuse to work.

Thank you for your answers!
At this moment I do not have time to investigate this and create a solution, but as soon as I do I will let you know by reliving the post

Thanks for your answer.
The issue is that I need to authenticate the device over the internet, so I figured I could store a token somewhere in the Espruino and check it in the cloud

Yes, you could do that - or just send back the code from getSerial() - so you can then see the serial number of the actual chip, and you can have a list of your devices?

Yes, I would list on my webserver the serials and compare them against what returns me getSerial (). That would serve to authenticate it on the server. But I have a query that may be due to a misunderstanding of my concept.

Is there any way to read the data that has been flashed in Espruino?
Because if so, someone could read that getSerial () and authenticate as if it were my device. This is true?

Is there any way to protect Espruino from unwanted flash read/write?

To a certain extent I answered that with my first reply above.

Yes, you could reflash the board and find out the serial number - but then you'd have to create your own software that faked your device and sent out the same serial number. I imagine that's a step too far for most people, especially if you stored some encryption key in your software.

I understood your first explanation, but I get the following doubt:
Beyond obfuscating my code and so on. Any malicious customer, can access that code in flash memory?

Why is it so, even if you have reason to tell me that the client would have to recreate the flash code, obtaining the serial number of the board and a possible random data stored in flash memory (if you can read it and hence my doubt ) could falsify the device and access my server via API or whatever it is, since the authentication mechanism is the serial number (Qe can be obtained by flashing) and a salt that is housed in the flash memory (if it is can, I think so)

Yes, a malicious customer could read out obfuscated code in flash memory - but it is compressed, and fragmented over the memory space.

It's a hugely difficult task to do anything with. I would find it very hard, and I wrote it. Maybe try it yourself and see what you can do? Personally I'd say it's more difficult than reading the ARM Thumb assembly code created by normal C compilers.

Honestly, if you're worried that somebody may be willing to totally recreate your software and hardware from scratch and fake it, then you'll need to hire a specialist to design the software for you - not try and make it yourself.

Sure, you could use compiled C code and turn on the 'flash protection' bit, but I can pretty much guarantee that won't stop a skilled group of people with infinite time and resources from faking it.