 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 : POKE the ’NOREAD’ register?
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9083 |
Hello.  First and foremost, I don't know if that is the correct term for that register - NOREAD - I just made up that reference. What I want to do, is issue a POKE command that will set the register in the PIC32, that will prevent anyone from trying to read the code in the PIC32 chip. If you set this, OPTION CONSOLE DISABLE, and OPTION AUTORUN ON, then the chip would be reasonably secure against general-purpose attempts to hack it or otherwise read it. I seem to recall you can set this register in the Microchip IPE advanced settings, but I am wondering if there is any way to POKE that register directly. This would secure the code in the PIC32 from being read out of the PIC32 via a PK3, making it very similar to the PICAXE where reading the contents of the chip is denied. Can this be done? Geoff? Peter? Smoke makes things work. When the smoke gets out, it stops! |
||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
No, you have to set it in IPE. This is because it is a flag set in a special part of flash memory. EDIT: I cannot find this feature in IPE (it used to be in the old MPLAB programming function). This means that the flag has to be set at compile time and may possibility prevent MMBasic from running because it needs to manipulate flash memory. There is almost certainly a bit in the hex file which if flipped will turn this feature on. But I don't know which one. Geoff Geoff Graham - http://geoffg.net |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3678 |
Grogs, It's a DEVCFG (device config) bit. You'd have to check each data sheet in case it moves around but it's known as the CP (code protect) bit and in my notes is in DEVCFG0. Looks to be bit 28. I think DEVCFG0 is at 1fc02ffc (but don't trust this - I think it's at runtime in software but you want it when programming!) for the PIC32MX1/2 chips (elsewhere for 765 etc) - see data sheets. You could edit the HEX. You should change it and also the checksum (end of the corresponding line). (goes to look at hex) OK... in the umite HEX I looked at it's in the next to last line. The last 2 hex chars are the checksum and before them is what I think is the correct 2 chars (byte) of 7F. You need to flip the CP bit so 7F goes to 6F. And flip the corresponding bit in the checksum (I think - can't test it easily) -- if IPE even checks the checksum. The sample I saw had 57 as the checksum so it would then be 47. Note: even with CP the actual mmbasic program can still read the code. But IPE etc can't (just as any ICSP program such as pic32prog won't be able to). John |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9083 |
So, the console would still work fine even with CP set, correct? I would expect that to be the case, but with CP set, the device will reject attempts to read it via the ICSP, correct? I have found how to change that in IPE v3.35, which is what I currently have on my computer:  Got this from the IPE manual. 1) Click VIEW, tick SHOW MEMORY. 2) In the memory view window that appears down the bottom, click the drop-down button. 3) Select CONFIG MEMORY 4) Right down the very bottom is the CODE PROTECT bit setting. 5) Click 'Protection Disabled' on the right column. 6) Change this to 'Protection Enabled' I have yet to actually test this out, but this would seem to be where you find that setting anyway. I should be able to READ the 170 for the current running code etc, then change this bit and write it back to the chip, and save a local copy of that HEX for duplication purposes. I need to try this out though. With this bit set, and in MMBASIC turn off the console, and disable the break key, it should be reasonably well protected against your average joe trying to read it. This also has the effect of locking me out of my own code too, but that is why you would keep TWO versions of the same code: one that was a fully editable backup version, and one production version which is locked down. Smoke makes things work. When the smoke gets out, it stops! |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
[quote] With this bit set, and in MMBASIC turn off the console, and disable the break key, it should be reasonably well protected against your average joe trying to read it. [/quote] Normally it will keep anybody out except the ones that use Xray equipment and are sponsored with lots of bucks to crack it. :). BUT and that is an important but, you also need to make your program ERROR free. MMBasic will fall back to a console prompt if an error occurs. You will need to make sure that those are capture with error trapping and use a watchdog for all other unforeseen things. It will still not be 100% protected as it would be possible to try to get the program to fail and wait for the prompt, then quickly type a watchdog stop command. I do not see a OPTION CONSOLE DISABLE in the manual, so i do not know how to stop the console from being accessible after an error. Maybe use OPTION CONSOLE INVERT to make accessing it more difficult. The way i would try to get into the code would be to unplug some devices, like disconnect the LCD or other input/output devices and see if that trips your program. This would only be possible for someone with knowledge about the uMite and its devices. So the change that that happens if it is in the hands of a customer is extremely small. And the fact that the return on investment (time spend to crack it) is probably not worth it. Preventing simple copying (like i tried to do with my Serial/USB/Programmer device) is easy but does not stop others from simply copying the functionality. Something to keep in mind. For me that last reason is why i stopped publishing what i do. The saying goes 'Software wants to be free, but food is not'. Edit: You should also add a PIN, this will ask the user for a pincode before it gets into the console. Another way of protecting the console would be to specify a weird baudrate. That should obviously be the last thing you do as afterwards it will be unaccessible. All depending if you use the console outpt/input for anything else of course. Microblocks. Build with logic. |
||||
Zonker Guru Joined: 18/08/2012 Location: United StatesPosts: 761 |
Nice..! Very helpful Gent's... I was hoping to "protect" the readout of MM devices when wanted.. Thanks for the info..!!  |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
There are shady offers - ( I can't remember details nor was I looking for them ) quoting cracking ( ed - ie memory cell reading via direct physical investigation of the chip ) for a few thousand dollars with 24-hour turnaround, on chips from any major chip manufacturer.  Hardware cryptography seems to be used routinely now, not that I can be bothered using it (yet). Complete with export/import restrictions I guess. |
||||
 Print this page |
