PICAXE compiler thing(not sure of it's name)

There was to be an application, which would allow you to save your current code into a self-contained compliler/programmer, so that you could send updated firmware to clients who were using your PICAXE-based product as an .exe, run it, and it would auto-update your firmware in their product, without revealing your source code.

I heard that this was going ahead, but it may now have been abandoned?

Also, I don't know what RevEd was going to call this application, so hopefully, someone here will enlighten me...

Anyone got any information on this?

Take a look in the new
PICAXE Compiler Support Forum (2 below this one!)
Is that what you wanted?

No, not really.

These compilers work directly from the command-line, and compile a source-code, then attempt to download the program to the PICAXE. At any time using the command-line, the source code could be viewed using a text editor, or just plain TYPE filename.bas command

I am referring to a Windows based compiler, which compiles the code, then combines it with a programming engine, into a single .exe file which can be sent to the client.

They run the exe, which connects to the device, and updates the firmware with the code contained within the .exe itself. This is a reasonably common method of firmware update for other devices such as pagers or MP3 players.

At no time during the running of the .exe, can the user see or review the source code.

Currently, I take my laptop with the full programming editor on it to any sites and program from there, but self-contained .exe updates would be more convenient.

Have a look at this thread in the compiler forum;

http://www.picaxeforum.co.uk/showthread.php?t=9879

BCJKiwi said:

Have a look at this thread in the compiler forum;

http://www.picaxeforum.co.uk/showthread.php?t=9879

Click to expand...

Yes, this sounds like exactly what I want.
Thanks for the link.


I have bookmarked that thread.

We'll have to wait to see what Rev-Ed produce but there are four ways to get firmware updates to a user and into a PICAXE without revealing the code ...

1) Convert the source into an encrypted / obfuscated form which can be compiled as normal under the Programming Editor or at the command line but is not understandable by the user. Only works for 08/08M/14M/20M/18 and 'has issues'.

2) Embed the encrypted source in a .exe, run that, it calls the command line compilers then uploads the program.

3) Compile the source and deliver an encrypted token image which can be uploaded using the command line compilers or a separate utility.

4) As (3) but embed that token image in a .exe file.

There are pro's and cons to each. (2) could be implemented by anyone who had programming skills and wanted to do it themselves. (3) is what I was planning and I think is what Rev-Ed are also producing. (4) is what you are asking for; that shouldn't be too hard to do once (3) is done, and an 'image to .exe' utility can be created by anyone with programming skills if Rev-Ed do not support that.

Most secure and impervious to decoding attempts would be (4).

...or send them a preprogrammed picaxe chip to replace the existing one

Texy

I'd go for the option 2. Easy and functional

I'd agree, option 2 is the easiest to implement and gives the desired functionality.

The biggest problem is that the source code can be fairly easily recovered by someone who wanted to get at it. Encryption only works towards stopping someone decoding what's in the .exe file, it's "security through obscurity" which only works in limited cases.

The code could be obfuscated before being embedded but that complicates the program which injects the source into the .exe and regardless of whatever encryption is used it should be no more than a five minute job to determine what that source code is ... if anyone wants to challenge me on that ;-)

Nothing's uncrackable, you can simply make it not worth people's while. How valuable the product is is the key. Option 2 would probably work with 'naive business users', but would fall flat if they sent the .exe and a wad of cash to someone who knew what they were doing.

PS : If you haven't written the code for Option 2 yourself, how can you trust it ? You'd never know if there were a 'back door' which could simply dump the source code out to the screen.

PPS : None of the solutions would really be that immune to having source code extracted in a few minutes, with the right toolset in place, so never over estimate perceived security. Texy's "send them a new chip" is the most secure, providing it's an 18A or above.

I was reading of another similar scheme in an industrial electronics magazine a few weeks ago but cannot locate it at short notice.

This scheme involves sending a software transport "chip" to the local service technician who can plug it into the end-users circuit and it automatically updates the end-users software. The "chip is designed so it has a pre-defined number of downloads before it expires and was also implimented so that the code could not be copied out the the software transport "chip" thereby circumventing illegal copying by end user or the technician.

hippy said:

PPS : None of the solutions would really be that immune to having source code extracted in a few minutes, with the right toolset in place, so never over estimate perceived security. Texy's "send them a new chip" is the most secure, providing it's an 18A or above.

Click to expand...

I seem to remember a thread from about a year ago saying that code-in-the-chip was not immune to cracking -- it was just harder to get at. Is that the 18A or above issue you mentioned?

It can be quite annoying when one comes across a controller lacking decent documentation and one has to repair it or make it fit the application. It's standard practice to have the complete internal logic listing provided with every machine delivered in industrial installations. And most are using a PLC setup that are live editable so that any electrician can sort out the issues.


Evan

@ westaust55: That sounds like a glorified version of the Basic Stamp Stash (?) although I cannot find any links to it. Download your program into it then download from that into the actual chip.

This version has some aids to security but still isn't infallible. It needs a trustworthy installation technician who never let it out of their hands and that's great for an end user doing the illegal copying because they'd have a trusted technician who would swear blind that copying hadn't happened !

If this device were sent out unattended it's even easier to copy and it would come back and pass any security audits.

In many cases improved security is an illusion. The more complicated it gets, the more likely it is to miss the weak points. Look at all the complexity of Microsoft WGA which can make life a nightmare for genuine users and yet pirates simply use a boot-legged registration code and never even have to worry about it.

@ wapo54001 : Yes, 18A upwards are far more immune to determining the code in the chip ( beyond most people's capabilities ), not that it's a particularly easy job for the others. Again it comes down to how much effort one's prepared to put into it.

This requirement has been going on for years.
A nice simple approach would a la St*** where you can supply customers with a Single executable compiled by the Editor. Clickety-click ad job done. Obv there is no copy protection, but it's very convenient for your customers.

A lot of this depends on your Customer base and product. If it's a very exciting product and for the public you'll have to be careful and sending upgrades is tricky. If it's very specialised or dull and your customer is a Tax Consultant then you needn't worry. In some products which are upgrdeable the manuf has written the main operating system firmware too and the 'upgrade' is just a part. Therefore the upgrade code on it's own is semi-useless.

Alternatively you just supply the MkII version next year at an 'upgrade' price.

I can't think of anything off-hand more secure/easy/cheap than sending a new chip... I just hope the customer has an SMD rework station - just kidding.

One thing which is important, which Dippy touches on, is what one is trying to do -

Make it easy for a customer
Protect the source code from the casually curious
Protect the source code from being obtained by a determined customer

The first two are easy, the third is impossible.

They also offer a handy device called Stache (pronounced "stash"), a portable Stamp programmer. "

That other website " at:
http://www.parallax.com/Store/Accessories/Tools/tabid/162/CategoryID/37/List/0/Level/a/ProductID/45/Default.aspx?SortField=ProductName,ProductName

Will have to have a better look tomorrow for the device I read about.
What was in the photo I saw was far more compact. Basically just a specially encoded IC that the end users equipment would read in the data from to reprogram itself.

Ok, I've had another idea that can be very good.

How about an executable that reads from a web address (piece o' cake). That'd be very simple to hack, as the user could just decompile the exe, and get the web address.

Then, here comes the great thing about it. It'd be a smart page that is able to recognize where the request comes from (an uuid token could be used maybe).

So, when the VB app access the webpage, the webpage expects to receive a taken. If this token is OK, then the web app "releases" the code to be downloaded by the desktop application. The desktop application won't really donwload it, but store it in memory, use it and throw it away.

I guess I don't need to mention that this token can just be used one time

Can you guys see any flaw on that?

Cheers

hippy said:

The first two are easy, the third is impossible.

Click to expand...

I havent looked into how the picaxe works behind the scenes, but I believe PE compiles at least some of the code into c or something, so if we send this compiled code to the customer, how can they get the original basic code.

Well I don't know what the end result of the editor 'compilation' (C??) is but I think people are referring here to simply copying the code from an 'upgrade' file and stuffing it into another PICAXE.
Maybe someone will invent the Miracle de-compiler which will add comments too

evanh said:

It can be quite annoying when one comes across a controller lacking decent documentation and one has to repair it or make it fit the application. ...

Click to expand...

The usually way to solve this problem is to throw the offending unit away and buy a different brand that has the appropriate tools and documentation supplied.

Very similar to the open source market but applies to manufacturing instead of database work.


Evan

marcos.placona said:

How about an executable that reads from a web address ... Then, here comes the great thing about it. It'd be a smart page that is able to recognize where the request comes from ... Can you guys see any flaw on that?

Click to expand...

It depends on what you're trying to achieve or prevent. If it's limiting distribution of code to authorised customers then that's fine. It won't stop them extracting the source code once they have it if that's their intent.

Apart from a desire to provide a secure solution, I cannot see many cases where it would be that damaging to simply put the source code up in public with little or no protection. The most compelling reason is to not let a customer paying good money see that it's just a few lines of trivial code they are paying for.

hippy said:

Apart from a desire to provide a secure solution, I cannot see many cases where it would be that damaging to simply put the source code up in public with little or no protection. The most compelling reason is to not let a customer paying good money see that it's just a few lines of trivial code they are paying for.

Click to expand...

I think that is probably very close to the truth!
Unfortunatley, there is also a great snobbery about programming languages as well. There is a large customer base which thinks that anything written in BASIC can't be any good and probably won't do what they want. This has even turned into a marketing gimmick with lines such as "firmware written entirely in C". To be honest, I'd actually question a product which made a statement like that.

hippy said:

that it's just a few lines of trivial code they are paying for.

Click to expand...

Might I add a little to Hippy's comment?

a few lines of
seemingly trivial code

that took years of experience, and hours of work, to refine to its present state.

e.

True, it can cover both, the genuinely trivial, and that which looks trivial but isn't.

That then goes full circle to the usual argument for protecting source, to protect Intellectual Property Rights or more accurately keeping knowledge others don't have which is therefore worth money secret.

Probably not that many of those in the PICAXE world but there have been a few which could have perhaps have been capitalised on if they hadn't been put into the public domain. Maybe some are being used we don't know about.

"firmware written entirely in C" - Not sure I can think of any language which would be less safe to use. Yet people are impressed by such proclamations. Frightening.

"firmware written entirely in C" - Not sure I can think of any language which would be less safe to use. Yet people are impressed by such proclamations. Frightening.

I agree fully, if it's written in C then you might as well give your code away.

A bit off Picaxes, but when I write something important and I want a bit more security, I use FORTH. That is an order of magnitude more difficult to get any "secret" code out. Especially if the code is "Headerless". As well, once you learn its syntax, much easier to write code. (The hard part is learning it)

A pity Rev-Ed don't also have Picaxes with Forth.
Each language has it's merits and Basic is very good for teaching programming - that's why it was created in the first place. In my opinion, Forth would be an excellent second language to teach beginners.

I'd love to see a good implementation of Forth in a chip like the PIC. There is one available but costly and sadly, not good.
Until then, I use a microprocessor (as opposed to a microcontroller) for any custom control products.

it amazing how things like programming language is used in marketing schemes for certain devices,

at one of the last shows for the water and utilities industries, there was one company selling dataloggers and one of the lines they had in their broshure was "high performance C language based firmware"

the language arguments are a bit of a laugh because when you look at the generated code produced by some of these compilers it generally ends up roughly the same anyway,

For marketing hype it seems you cannot beat "Open Source" and "GPL" despite for the most part Open Source delivering no real advantages and GPL far from being non-restrictive is actually the opposite, and does more harm than good IMO.

hippy said:

For marketing hype it seems you cannot beat "Open Source" and "GPL" despite for the most part Open Source delivering no real advantages and GPL far from being non-restrictive is actually the opposite, and does more harm than good IMO.

Click to expand...

i had a good chuckle at that one too,

Welcome to computer snobbery.

He can programme in C++++++ ... we're not worthy.
He knows all the jargon .... we're in the presence of Genius.
He uses Unix ... oh he's a God.
He uses Linux .... oh he thinks he's a God

Dippy said:

Welcome to computer snobbery.

He can programme in C++++++ ... we're not worthy.
He knows all the jargon .... we're in the presence of Genius.
He uses Unix ... oh he's a God.
He uses Linux .... oh he thinks he's a God

Click to expand...

Hey, I use Linux, and my mum says I'm a Greek God (though I ain't greek)

Linux really rocks!!

Linux really rocks !!

.--.--.--.--.--.

*-__-*

Linux Spring. The future of computing beyond the "gates"

hippy said:

I'd agree, option 2 is the easiest to implement and gives the desired functionality.

The biggest problem is that the source code can be fairly easily recovered by someone who wanted to get at it. Encryption only works towards stopping someone decoding what's in the .exe file, it's "security through obscurity" which only works in limited cases.

The code could be obfuscated before being embedded but that complicates the program which injects the source into the .exe and regardless of whatever encryption is used it should be no more than a five minute job to determine what that source code is ... if anyone wants to challenge me on that ;-)

Nothing's uncrackable, you can simply make it not worth people's while. How valuable the product is is the key. Option 2 would probably work with 'naive business users', but would fall flat if they sent the .exe and a wad of cash to someone who knew what they were doing.

PS : If you haven't written the code for Option 2 yourself, how can you trust it ? You'd never know if there were a 'back door' which could simply dump the source code out to the screen.

PPS : None of the solutions would really be that immune to having source code extracted in a few minutes, with the right toolset in place, so never over estimate perceived security. Texy's "send them a new chip" is the most secure, providing it's an 18A or above.

Click to expand...

You make some good points here, hippy.


However, unless it was a product that was to threaten the likes of Microsoft, NASA, the FBI, CIA, NSA or the global crude-oil interests, I don't really think that anyone would take the time and money to discover your code - the .exe and other methods are more of a "Stop the honest people" approach.

I hear what you are saying, and I don't doubt that people with the knowledge could crack the source code - people have decompiled the source for Windows with little effort...

If the product in question was really that valuable, then this is where lawyers, patents and non-reverse-engineering agreements and/or lawsuits come into play.

For the most part, we just want to make the source code in-accessible to "Joe Bloggs" who does know how to use a computer, but does not know how to decompile applications or software to discover code. Again - keep the honest people out.

You have to be a realist in that you can't assume that everyone is out to decompile your source code for any or all projects you might create. If you did, you would never finish the project!

Personally, I scratch off the markings on the top of the chip, so there is no easy way for anyone to work out exactly which microcontroller you are using - they can guess, but they can't EASILY be sure with no markings on the chip.

Texy's comment is the most secure, sure, but you have to assume that the person at the other end has the competence to be able to install the new chip - it's easy for non-electronic minded persons to install any DIL chip like a Picaxe around the wrong way...

hippy said:

For marketing hype it seems you cannot beat "Open Source" and "GPL" despite for the most part Open Source delivering no real advantages and GPL far from being non-restrictive is actually the opposite, and does more harm than good IMO.

Click to expand...

I didn't really expect that comment from you hippy.

The Free Software/Open Source market doesn't have the big promotional budgets of the comercial entities. The only hype it gets is word of mouth. The whole market barely competes with a single comercial product for promotions. I'd argue that there is a massive campaign to keep it suppressed.

GPL is a natural reaction to the choke-hold restrictive licences that have made it very hard to share code. GPL wouldn't have to exist if everyone would co-operate.

GPL is the only thing that allowed any alternative to a total worldwide monopoly. That's a good thing. Just like regulation is a good thing. Without regulation, the free market takes you ultimately to monopoly of markets.


Evan

If anyone mentions "copyleft" I'll be sick.

I've no objection to people going open source ( in any of its forms ) nor applying whatever license conditions they want. I disagree though that GPL is the best solution or that without it there'd only be world wide monopoly. People often jump on the GPL bandwagon without thinking because they've been told it's the best option when it may not be. It's not the notion of GPL and the like I object to it's the implementation of GPL which is restrictive and consequently counter to the advancement of everyone.

The restrictions within GPL can stifle advancement of an idea because those who could advance the idea do not accept the restrictions. GPL is no different to the licenses the GPL community hate in that both seek to place restrictions on how their code may or may not be used ...

Proprietory Licence - Stops anyone who will not comply with the licence from using the code.

GPL - Stops anyone who will not comply with the licence from using the code.

There's no real fundamental difference there. A license which doesn't restrict anyone from using the code in any way is far more beneficial in my opinion. It doesn't matter that someone may take it and create a proprietary solution which itself is not published. They haven't monopolised the world, no one has stifled further development, anyone else can take the idea and do exactly the same if they wish. Is it better to have my idea commercially exploited and benefit at least some than have it waste away because no one pursued it and those who could were prevented from doing so ?

Sure, we all think that if Microsoft take our lines of code and make billions from it we should get a fair cut, but how likely is it ? A nice dream, nothing more. GPL to me is simply saying "I cannot exploit this so nor may anyone else", it's forcing everyone into the same philosophy of the author just as a proprietary license does. If the notion and philosophy of restrictiveness is condemnable in a proprietary licence then it must be the same in a non-proprietary license.

Authors may select GPL without realising or understanding the consequences simply because of the pervasive GPL ( "their restrictions bad, our restrictions good" ) is best message being given out by those who seek to push GPL for their own political motives or by rote. What authors intend may be curtailed by selecting GPL and similarly restrictive licenses. Licenses such as MIT may be more in line with what they intend and are less restrictive than GPL.

There are arguments for and against every license type, there is no best. People should choose the license which matches their own desires. It should deliver what they want to achieve, not be dictated by someone with their own agenda.

Dippy said:

If anyone mentions "copyleft" I'll be sick.

Click to expand...

When I see open source talks I already get sick. This kind of conversation never gets people anywhere.

Free stuff don't have the same promotional budget, but just for the fact of being free, it's more than enough.

Anyways.. this conversation makes me sick. people try to prove that open source / freeware are good, but are still using Windows on their personal pc's, and wouldn't even dare to migrate their Oracle Databases for MySQL databases for example.

Having that said, I think open source sux for business usage, and wouldn't leave my good old licensed stuff

I'm a snob?

Dippy said:

Welcome to computer snobbery.

He can programme in C++++++ ... we're not worthy.
He knows all the jargon .... we're in the presence of Genius.
He uses Unix ... oh he's a God.
He uses Linux .... oh he thinks he's a God

Click to expand...

Does being a C programmer and system admin on UNIX in the mid-80's (DEC PDP 11/70) qualify?

Yes, I could reboot the 11/70 using the front panel keys ;-)

John

We've drifted a little off-topic here!


It's an interesting read, though.


Back to the compiler related topic:

hippy mentions the fact that any Picaxe from an 18A or above is "More or less" impractical/impossible to crack - the code stored in these chips is obviously much more difficult to get at then the other Picaxe's such as the 08/08M/14M.

QUESTIONS:

1) Why are the lower spec chips hinted as being easier to crack then the 18A and above?

2) What makes the 18A and above more difficult to crack?

My current project uses an 18X, and I have other projects that use the 40X(first version - I think now referred to as 40X1), 14M, 08M and 08.

They work very well, but essentially, if they are for the most part "Unreadable" once programmed, taking the full programming-editor with me on my laptop when I need to update code is probably the best method anyway - even over and above using a compiler as I was thinking about at the start of this thread. Only I can ever see the code, as the laptop is never loaned to anyone else, and the code for the various projects is stored on a USB flash-drive, which never leaves my bunch of keys, so even if the laptop was to be stolen, the code would not be stolen with it.

That said, I find that firmware updates are not needed all that often anyway, if you have written your first final of the code correctly, so you should not have to do that many updates!

Perhaps Texy's comment is really the best and easiest method - supply pre-programmed chips with updated firmware in them, and perhaps instruct that a local electronics service-person install the chip - require proof that the tech did the physical replacement, to ensure that the chip was not put in back-to-front.

But then, even us techs can sometimes put chips in back-to-front if we let our mind wander for some reason while doing the replacement(i have done it! ), so it looks like there is no 100% fool-proof method, is there?(rhetorical)

hippy said:

People often jump on the GPL bandwagon without thinking because they've been told it's the best option when it may not be.

Click to expand...

That's a new one on me. Sounds like part of the suppression campaign again. GPL is like any regulation system, it is simply needed to stop corruption/abuse.

GPL is no different to the licenses the GPL community hate in that both seek to place restrictions on how their code may or may not be used ...

Proprietory Licence - Stops anyone who will not comply with the licence from using the code.

GPL - Stops anyone who will not comply with the licence from using the code.

Click to expand...

Of course. The purpose of any licence ever written is to restrict usage.

The GPL's primary restriction is that everyone must be allow to view the source code. And, yes, this is viral.

The most common restriction of commercial licences is the source code must stay hidden. And this is this viral also.

A license which doesn't restrict anyone from using the code in any way is far more beneficial in my opinion.

Click to expand...

That's not really a licence at all.

Sure, we all think that if Microsoft take our lines of code and make billions from it we should get a fair cut, but how likely is it ?

Click to expand...

The GPL makes no claims to royalties. Just that the souce be readable by all and reuasble under the GPL.

However, money is made from both purely and partly GPL'd code.

Authors may select GPL without realising or understanding the consequences simply because of the pervasive GPL ( "their restrictions bad, our restrictions good" ) is best message being given out by those who seek to push GPL for their own political motives or by rote. What authors intend may be curtailed by selecting GPL and similarly restrictive licenses. Licenses such as MIT may be more in line with what they intend and are less restrictive than GPL.

Click to expand...

It looks like this is your biggest concern.

The author can rerelease under another licence at a later date. What the author can't do is remove the licence from what was released in the past. So, if one is wanting to share the code in general, the best first licence is always the GPL. You would need to be very sure about what you were doing before using something else.


Evan