 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PICOMITE: Can you read them?
Page 1 of 2   |
|||||
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Just a thought - can you read the contents of what is in any Pico module? With the PIC32 series, you can connect to the chip with a PK3 and read the entire chip into a HEX file, provided you have not locked the chip with the IPE. Can something like that be done to the Pico? I am hoping the answer is NO. I'm just trying to find out if cloning is possible by someone if they wanted to copy what was in the Pico. At this stage, I am ASSUMING that you CAN'T do that, and the Pico is somewhat similar to the PICAXE in that you can download new firmwares to it, erase it completely, but you can't read the internals back out again. However, there might be a 3rd party tool that allows that. Yes? No? Looking to use more and more RP2040 chips and the MMBASIC port to it, due to there still being major shortages of the common PIC32 and ARM processors, while - for the moment anyway - there seems to be bucket-loads of RP2040 chips available and modules of various flavours with it pre-fitted for you that you can incorporate into designs. Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
Loading new MMBasic firmware doesn't always delete your program. A butchered Basic could then do whatever it likes... I definitely wouldn't trust any thing on the slash drive being safe. Jim VK7JH MMedit |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Picotool (https://github.com/raspberrypi/picotool) will do that for you. Geoff Geoff Graham - http://geoffg.net |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
Yes, there is no security. It is trivial to clone the flash chip which is where all the intellectual property resides. There are things you could do to make it slightly harder but nothing foolproof. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
I'm curious - what things? Smoke makes things work. When the smoke gets out, it stops! |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
while the RP2040 chip lacks a unique ID, the flash chip does have one. this unique ID could be used to encrypt your BASIC source code, which is then decrypted into RAM upon running (if running BASIC code from RAM were supported, which it is not). a variant: if PIN protected, your MMbasic program could read the flash chip's unique ID, and simply refuse to run if it did not match the ID hardcoded into your MMbasic program. without access to your source code, it would be difficult to find out where the check was made. down side: every installation would require you first read the unique ID, then edit your basic program before saving it to the pico. peter: how easy is it for MMbasic code to read the flash's unique ID? any checking is then best left to the user code to maximize obfuscation. cheers, rob :-) Edited 2023-01-31 22:24 by robert.rozee |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
Not fool proof by any means but you can make life more difficult by having the code modify itself the first time it is run e.g. Flash chips have a unique ID firmware as built leaves a small area un-programmed in the firmware image First time it is run it writes a heavily encrypted version of the flash unique ID into the un-programmed area Subsequent runs check the encrypted ID against the flash ID and erase the flash if not the same This means you can't just image copy the flash onto another chip - some protection at least MM.INFO(ID) Edited 2023-01-31 22:35 by matherp |
||||
Quazee137 Guru Joined: 07/08/2016 Location: United StatesPosts: 593 |
After redoing five of my controllers to the RP2040 chip now seems to have been a waste of about six months. That is on me for assuming that PIN was working. This thread got me looking and found this IoT hacking Not sure how to continue as the units are sold to the buyer that expects the firmware to be under lock and key. On the MM170 I know is was safe as an installer called and ask if I would send new code. I told him to go through the company on the label. He then told me there was problems there. When I asked for the name of the company he just hung up. Using his area code and phone number I contacted two of companies in that area letting them know of the request. Then got a call back from one company telling me thanks for letting them know as they had four units missing and knew who took them based on the phone number. The installer had used two of the units to make a copy of the board. The other problem is the ADC of the RP2040 in the redesign I used the ADS1115. I guess its looking into how if at all possible to protect code on the RP2040. The code must be protected. Edited 2023-02-05 13:57 by Quazee137 |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Nice ideas flowing here, chums, keep it up.  I like the idea of using the flash unique ID. I had not even discovered that was a thing that was possible, so... Yes, does mean each unit has to be SPECIFICALLY set, but that could potentially make things MUCH more secure in terms of someone simply copying the Pico, and trying to program other modules with the same firmware. That, combined with a PIN number and OPTION BREAK DISABLE I think will be protection enough. Let's face it, if someone is desperate enough to copy your firmware, they WILL find a way to do it, so we really just need to discourage the curious or those who think a simple copy-and-paste of the firmware will work. Some of the designs I have ported the 2040 to now, use the ubiquitous 3232 RTC module, which has it's own area of battery-backed memory you can write to. You could store the ID in there after it has been read, and compare with the RTC stored code at startup. That only works till you need to replace the RTC module or it's battery though, but that does not happen very often at all - the batteries on those RTC modules last for years and years. Just thinking out loud... Smoke makes things work. When the smoke gets out, it stops! |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7939 |
Chips are always readable, ask anyone who has taken the top off an old EPROM and connected a logic probe system directly to the leadout wires because the pins have rotted off. :) There are plenty of very detailed (electron microscope stuff) pics on the web of the Z80 CPU die, taken after removing the encapsulating packaging. Encryption is the way to go. Then you need to sort out how little encryption you can get away with - and how much you can manage on your processor. If someone really wants the contents of a chip and has the resources then that chip is going to give in eventually - and it's unique ID will almost certainly be read too. Your encryption needs to be sound. There is no such thing as 100% secure electronics now. Not until after you've launched it into space - and even then... :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Quazee137 Guru Joined: 07/08/2016 Location: United StatesPosts: 593 |
Just odd thoughts here. Use PIN to read flash ID and encode using PIN number. and if PIN is a one way thing i.e. can not read code period. I am good with that. Also use 1 wire to hold encoded key. For me adding a few 1 wires around the bank of transistors or even next to the on board temp chip. I do not give out the schematic or code with the units sold. They are buying a black box to do what they want it to do. Quazee137 |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
or fire up Linux, plug it in and read the serial number in dmesg. Simpler than getting it from the Windows registry. So if you are trying to obfuscate, be aware that the serial number is in plain sight. Jim VK7JH MMedit |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7939 |
Lets see... There's a 1-wire memory chip. It has 31 blocks of 8 bytes. (thinking of DS28E80 1) Program runs on boot. Gets flash ID Reads one block of 1-wire chip using block number derived from flash ID. Two bytes in that block should have a specific relationship (e.g. result of a logic operation) If result is wrong then re-write the 1-wire block with zeros and crash the program. It can't restart now. Not unless the 1-wire is reprogrammed with the correct contents in the correct block. It can't work with a different flash chip on a Pico (wrong ID). If you change the Pico you have to program a specific 1-wire to go with it (glue the 1-wire onto the Pico?). Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Very interesting Mick. Having never used any one-wire device other then the 11AA160 or 11AA161 devices from Microchip under MM2 and Cfunction control, I will have to look up that part number and do a little more research. As mentioned, not really caring about those that if they REALLY wanted your code, would always find a way to get it. They are almost impossible to stop - but they do need resources and lots of special equipment that the average person does not have. Therefore, just looking to stop the 'Curious George' crowd, and those that think a simple copy-and-paste of the code from a unit would then work in their clones. I think that is a realistic goal, and there are some excellent ideas being posted here. Smoke makes things work. When the smoke gets out, it stops! |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2642 |
The RTC modules usually have a separate 24C32 chip so a dead cell won't matter if you use that rather than the 3232 memory. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Excellent idea!!!  I had totally forgotten about the EEPROM on those modules. I only ever used them for the RTC at the time.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| Quazee137 Guru Joined: 07/08/2016 Location: United StatesPosts: 593 |
Geoff, matherp when picofirmware.uf2 is dropped to the chip is there then a 2nd loader that comes into play? could it look for a 1 wire and save flash ID in a protected area? and save the 1 wire ID in flash. The thought here is to lock the flash to the board and the board to the flash. Replace PIN with LOCK no need for PIN number as we'll not be unlocking. we'll just reload MMBasic and then the program. Once LOCK has been used at startup the firmware will look for the 1 wire and match the two encoded ID's. going another route is to use a PIC10 as a guard dog on the Flash ID and the code. LOCK reads the flash ID sends to the PIC10 in 1 wire mode. Also sends a check sum of the code or some type of ID. At start up the code sends the info to the PIC10 and if match the PIC10 sends the ok to run. Kind of like the hardware watchdog chips used many years ago. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
it sounds like peter is already 'locking' the firmware to the flash chip. all the other suggestions are just operating at a similar level of security ie, no real improvement. one option to provide a addition level may be to encapsulate the RP3040 and flash chip in a mixture of epoxy and fine sand. you could create a small PCB holding just these 2 chips that is fully encased. do not expose the debug pins, possibly even consider not exposing the USB pins - although that would either preclude updating the firmware, or require the firmware provide an update over serial/spi ability. cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Sounds OK. If you want a fair amount of security you need something like that because otherwise someone can go in via the flash chip or debug pins (JTAG/SWD/...) on just about any device - unless it has on-chip flash and the debug pins can be disabled (the PIC32 seems good, but the Pico is not remotely like it in those respects). (That still assumes no-one is going to attach leads to parts of the chip having removed the chip's casing. Not something most could do. There may be other really hi-tech ways in, also beyond all but security forces.) I suspect the various other ideas posted would defeat many bad people. John |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Lets be honest and have a wee comparison here - even the PIC32 chips can be read like that, to create a HEX file that contains MMBASIC and the program code, provided the chip has not been copy protected. I've never done that(copy protected them) with the MM2 series of chips, so technically, anyone with the knowhow, a PK3 and the IPE software can ALREADY read the MM2 chip in any of my products, so......six of one and half a dozen of the other.  Epoxy isn't full-proof either - plenty of designs that have been protected by potting them, have been "Dissolved" in various nasty chemicals to reveal the PCB and from that, they extract the schematic. Nothing is full-proof, if they REALLY want your design or code. As mentioned, this thread is more about just securing the code/module from the likes of Tom-the-tinkerer, or those that think/hope a simple copy-and-paste of the code will work. I think using the unique flash ID code and comparing that would deter MOST of the general-purpose hacker type people. My 2c only - please don't read too much into that!  Trying to stop the hard-core people who will go to just about any length to copy your code and/or device, and have access to the right equipment, I think is actually a waste of effort, cos you can never really stop those people. But you CAN stop - or at least make it very difficult - for the other crowd based on what I have been reading in this thread, and that's the end goal - for me, anyway. I'm going to play with the flash ID idea a bit more on the bench. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
