PE6 Program Editor and Assembly Code Generation

Jeremy Harris

Senior Member
Does that mean a picaxe chip can't be copied.Can it be read including the boot loader? I don't have a programmer to test.
AFAIK, there is no way to read out the code in a Picaxe chip. I think several have tried in the past, as a challenge, and have failed! The code that's stored in programme memory is a tokenised form of the BASIC text programme, but in a form that would, I assume, be fairly hard to reconstruct into the source code, even if you could read out the programme memory area somehow (my understanding is that that area is notionally blocked from being externally read, but there may well be a way to get at it somehow).

I've always considered this to be a fairly good feature, in terms of being able to ensure that the code is fairly secure from hacking. Nothings 100% secure, but I think that things like secure access codes should be reasonable secure, if obscure enough. I use a form of two way validation for a remote control system, that isn't particularly security sensitive (it would only be a nuisance if it were hacked) and I'm confident that the Picaxe if the strongest link; the RF data link is the weak link, but if that were a secure wire connection then I'd think the system would be pretty robust.
 

hippy

Technical Support
Staff member
Does that mean a picaxe chip can't be copied.Can it be read including the boot loader?
Yes and No.
I first read that as an enigmatic "sort of", but it is correct; the chip cannot be copied, and the bootloader code cannot be extracted.

The chip has its read protect bits set so it is not possible to read the flash which contains the bootloader code and user program without the chip first being erased.
 

Buzby

Senior Member
Under specific circumstances it is possible to read the tokenised code stored in a Picaxe.

With a 20X2 and an I2C EEPROM the code can be downloaded to #slot1, which is in the I2C EEPROM.

The EEPROM can then be read byte by byte, either by plugging the EEPROM into a programming device, or just use the PICAXE itself.

This is the easy part.

The difficult part is decoding the tokenised code.

I've tried, and even knowing some of the techniques used in the tokenisation process, it's a devil of a task.

I've long since given up trying to decode stuff just for the heck of it, but a determined individual could write a 'decompiler' to convert the tokens back to Picaxe BASIC.

An even more determined individual could write PIC ( or any other micro ) code to run the tokenised code.

However, anybody with the skills capable of doing this doesn't need to reverse engineer a Picaxe, they could start from scratch and build something better in a fraction of the time.
 

Buzby

Senior Member
Yes Westie,

It was your notes that revived an idea I'd had an interest in for years, 'Could a Picaxe execute self-modifying code ?.'

There is obviously no chance of self-modifying the 'built in' Picaxe EEPROM, the addressing mechanisms are locked too tightly.

But when I realised that downloading to a #slot could put the code in a modifiable location I thought there was a good possibility of experimenting with self-modifying code.

It was for this reason I started to decode the tokens, but it soon became obvious that there would be a huge effort to get even a simple 'modify one variable' test working.

As it was, I got distracted by a real project, and I've not investigated de-tokenising any further.

Cheers,

Buzby
 

Jeremy Harris

Senior Member
As a further point, it's the security and robustness of the code that I really like about the Picaxe. When I was working, we had a real problem with a safety critical item (an engine control unit) that had to be sourced from different suppliers (for reasons of security of supply - it was a critical part). Each supplier used the same basic hardware (that was a requirement to allow field repair) but each wrote their own code, in C++. The problem was that we discovered that different compilers produce different object code when given the same source code. As the only way of getting an adequate safety verification was to do a static code walk-through of the object (machine) code, checking that no untoward states could occur, we thought we'd only need to do three of these safety verification checks, one for the code from each supplier. It turned out that we needed to do over a dozen verifications, because the suppliers didn't always use the same C++ compiler, so we had different object code coming from the same source code!

As an aside, this is related in part, to the reason that the UK refused to allow some Chinooks purchased with US flight instruments to fly - there was no code verification and the manufacturers would not release the source code and object code to allow a static-code walk-through safety check. The UK flight safety authority refused to allow them to fly on this basis, so they sat in hangars for years, unused.

It's also a major concern I have with the Arduino. Unless you write, and verify, every single library you use then you are accepting the use of SOUP*** in your final code. To me that's unacceptable, as you have no way of knowing what might be embedded in any third party library you choose to use. At least with the Picaxe we have no SOUP at all, and can be reasonably confident, after all these years, that most of the bugs in the Picaxe interpreter have been found and fixed, or are at least, thanks to this forum, known about. Combined with the inherent security of not being able to read out the programme code (normally) this makes the Picaxe a pretty safe and reliable system, probably the best in this respect in the hobby market, by a fair margin.


*** SOUP = Software Of Unknown Provenance.

In general it's code that was written by someone unknown with an unknown level of verification and where the full attributes of its functions may also be unknown. Examples would be code snippets inserted into libraries to send data back to a third party whenever a device is connected to the internet somehow (perhaps via the programming interface) or to do something malicious under certain circumstances. It's most likly to be code that just wasn't fully tested, so has bugs that the author never found, though.
 

srnet

Senior Member
It's also a major concern I have with the Arduino. Unless you write, and verify, every single library you use then you are accepting the use of SOUP*** in your final code. To me that's unacceptable, as you have no way of knowing what might be embedded in any third party library you choose to use. At least with the Picaxe we have no SOUP at all, and can be reasonably confident, after all these years, that most of the bugs in the Picaxe interpreter have been found and fixed, or are at least, thanks to this forum, known about. Combined with the inherent security of not being able to read out the programme code (normally) this makes the Picaxe a pretty safe and reliable system, probably the best in this respect in the hobby market, by a fair margin.
This topic came up during the $50SAT project, a lot of people were fairly dismissive about our use of a PICAXE and lots of people told us a PICAXE was the wrong controller.

Ultimatly the choice was made on reliability grounds, the PICAXE interpreter was know to be very reliable and that was a lot more important than being picky about functionality.

The obvious other choice was Arduino, but as you say can you really trust 'open source' and unsupported libraries ?
 

Jeremy Harris

Senior Member
With my background, I absolutely would not trust code libraries that didn't have an acceptable form of verification, especially for a high-reliability project like yours.

The Arduino is a great toy for hobbyists, but the massive reliability and security implications inherent in the unknown provenance of so many of it's libraries make it an exceptionally poor choice for any project that requires a high degree of reliability and/or security. I don't think we can even be sure that the Arduino complier is robust, as based on my personal experience of C compliers it seems that there are many that are not, and could produce object code that doesn't behave exactly as you might expect under extreme circumstances.

None of this is probably relevant to the average hobby project, but is well worth thinking about for those of us who build projects where code unreliability could have a significant safety or inconvenience aspect. For me, our hot water depends on two Picaxes, one making some accurate measurements of true power and transmitting data over an RF link and the other verifying that data and turning on and off a 3 kW water heating element. Thankfully, those two Picaxes have been working away, 24/7, for over two years now, without a hiccup. They've withstood power cuts and brown outs, a nearby lightning strike and, in the case of the outdoor unit that makes the measurement and transmits the data, some extremes of weather. It gives me confidence in the Picaxe and its programming environment as a robust system.
 

stan74

Senior Member
I just dug out some 15 year old pics.Obsolete 16f628 and 16f876, just to try out with a free compiler called Great Cow basic.
They still work.You can set the write protect and that's very secure.You can see the pure assembler it produces.
 
Top