I think, rather than preventing the dump, the aim is clone prevention, locking the code to the board using Flash Unique ID, preventing the code running if uploaded to a different board without the same ID - with some added encoding, encryption or obfuscation applied to the mix.No idea what you are really trying to do in your code.
I did some adventuring in locking code to a board because that's all you have on an RP2040 and it turned out to be quite tricky to stop evil actors bypassing locking - viewtopic.php?t=336409
My conclusions were there are two main things to consider -
Hiding and obfuscating any locking data in Flash if generated automatically. Storing multiple copies with hashes and a hash around all those with the algorithm being adjusted every time the UF2 is built. This makes analysis of dumped Flash harder and it's harder to replace the data if an attacker takes that path.
Hiding the checks for the code being locked. A single check called at the start of main was easy enough to find. There needs to be multiple checks and I would play dirty; allow it run and then check and crash after some random time - maybe hours or more. I'd let the thief put it in the hands of users then have to deal with those users complaining it randomly crashes and wanting their money back, the reputational damage done.
One won't stop a determined thief but you can slow them down and make the effort outweigh the gains for most. In most cases it will be someone trying to build a cheaper clone than it is to buy to save money who will soon throw in the towel when cloning doesn't work or isn't reliable.
Statistics: Posted by hippy — Thu Dec 18, 2025 11:24 am