Protecting your code
-
So, after a long time of testing and finally our own hardware design, we want to protect the code in the GPy so it can not be just stolen by the first Chinese company with a computer -sorry for the sarcasm. Does anyone have a good idea of how to protect the code of the device, so we can be somewhat safe in starting to sell these units?
-
@jcaron Gotcha, we will perform new tests and get back. Thanks a lot.
-
@Don-iot I must have a brain freeze, I don’t remember a standard way to include custom files in a build, other than frozen code. Where and how do you include those files? Are you sure they end up where you think? You should probably list files at various levels of your fs hierarchy to check that the files are where you think they are (if they are there at all).
Note that even if there is or was a way to include those files at build time, you would probably need to recreate the fs for those files to appear.
-
-
@kjm and of course the “storage” directory needs to exist beforehand.
-
@Don-iot At the risk of stating the brutally obvious Don, you'll get an ENOENT error for open("/flash/storage/payload.json", "r") if the file doesn't exist, ie you need to have previously created it with something like f=open('/flash/storage/payload.json', 'w'); f.close()
-
@jcaron Thanks for clarification, we will have another go!
-
@robert-hh We specify the full path like this when we want to access a file called "payload.json" in the "storage" directory:
/flash/storage/payload.jsonThis is when we call open(), so for example open("/flash/storage/payload.json", "r"). We get an ENOENT error.
-
@Don-iot what error are you getting? Adding frozen code should not change either the structure of the file system or write access to it.
What is possible is that while building your firmware you somehow got different settings configured, but this is most likely not directly related to the frozen code.
Another possibility is that while rebuilding you changed the layout of the flash (position and size of the partitions) to get more space, and the space for the file system no longer points to a valid file system. You would need to initialise it first.
-
@Don-iot When opening the files for writing & reading, do you specify the full path or do you rely on sys.path settings or the current directory path? I never have seen any differences in file path handling between frozen code and code imported from the file system.
-
@kjm thanks, let us hope that @robert-hh or @jcaron can help us out.
-
@Don-iot beyond my pay grade Don, Robert-hh/jcaron/et al might know?
-
@kjm said in Protecting your code:
For bigger data use a typical python file write (eg with open('mqqt_payload', 'w') as f: f.write(payload)
That is equal to our current approach, however, we do not seem to be able to create new files when we run a device with frozen code, we get OS-related errors. The file are being put at the same location that we are using without any problems on devices running non-frozen code. The files are put in a subpath to /flash/, a directory we call "storage" (so for example a file could be /flash/storage/logs/log.txt). The PyCom documentation is not really clear about where we should put files that we are modifying during operation and that are individual to the device (stored MQTT payloads, device cert files, etc.). So, the question is, essentially, where we should put them so we can proper access them?
-
@Don-iot You can store strings or integers with something like pycom.nvs_set('mqqt_payload', payload). Where the first item in brackets is the register name and the second is the string or integer you wish to store. For bigger data use a typical python file write (eg with open('mqqt_payload', 'w') as f: f.write(payload)
If you're communication with a server you can store config files on the server & download them periodically. This approach has the advantage that you can rejig the config on the server (independent of the pycom module) via a browser.
-
@livius We are storing MQTT payloads between uploads and TLS-certificates for example. We are using our own hardware and board, and it is used on vibrating machines so I rather not use the SD card, even if it is handy. Any more details on storing it in the NVRAM even though the rest of the device is using frozen code?
-
@Don-iot
It depend of config and logs. What do you need to store?
For me SD card is obvious choice, as it is simplest to prepare configs and send to the user. And logs are near unlimited then ;-)
But you can store it in flash too, in nvram.
-
@jcaron @robert-hh or @Gijs -do you know the answer to this question? Would really appreciate your help. So close to putting our device on the market and this is really the last bit of the puzzle.
-
Thanks @livius!
We are succesful in writing to the device and so on, but our main problem after trying with the frozen code is where and how to store config files (device unique) and the log files (changes during operation). They should not be compiled with the other files obviously, but the documentation is struggling a bit on where and how to treat these entities.
-
@Don-iot
Be aware of revision of the chip as some are still not safe even when you "turn on protection"https://www.espressif.com/en/news/Security_Advisory_Concerning_Fault_Injection_and_eFuse_Protections
-
@jcaron and @robert-hh thanks a lot for your insights. Great ideas and I think we have a few ideas moving forward!
