How to allow API access to a secret Object
I'm looking at using the Propeller in an embedded application but I have a specific need. I wish to keep the code within the object secret (binary format is good enough) while still allowing developers to make use of the object through a published API. In the Propeller tool, I can hit F8 to View the Binary of a compiled object and even save it to disk. However, I've been unable to use this binary file in another project. Am I missing something? Is there another solution?
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 3/12/2007 7:39:20 AM GMT
Please post if you have some ideas to share.
Post Edited (originator) : 3/12/2007 9:26:15 AM GMT
That having been said, does anyone have any ideas about a one-way transformation which would render spin code unreadable, but still working and still accessible via the original functions?
All the variable names could be renamed to long sequences of 1, 0, l, and O's- ie l01O1O1+=l010l01 is much more intimidating than Position+=Velocity. Constants could be obscured via offsets or math- which could take advantage of overflows... a[noparse][[/noparse]b[noparse][[/noparse]c-1]+1]. Any other uglification techniques? The techniques should be hard to reverse engineer. It looks like this has been discussed before- is anyone interested in such a script?
Why deal with a black box? This introduces a dependancy between the developer and you. What if you get hit by a bus?
(I'm serious)
It isn't so much a philosophical stance. It's that there's a price to be paid for every mechanism designed to obscure code and, often, the benefit from the mechanism is way less than the cost of it. That has been the nubbin of the discussion. That there's no way to protect proprietary code against a determined cracker.
That said, a good obscuring mechanism would be to write the crucial portions of your algorithm in assembly code designed to run in a cog. The graphics or floating point library would be good starting points for a structure. They act as an interpreter for several basic operations and operands and results are copied back and forth. Once your routines are debugged, you could save the assembled binary code in a file with the Propeller Tool, write a PC program that would translate the routines back into hexadecimal constants that could be cut and pasted into the version of your program that would be distributed. The API portion in Spin isn't really proprietary. The assembly portion is pretty nearly indecipherable except to a determined hacker. The only label that would remain would be that of the first location to be loaded (with COGNEW).
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Love this Forum it is a great example of open source.
But be realistic people. ( for those commercially minded)
Code protection is a std feature ...the decision to turn it on or off is the issue here.
Do not want to start another discussion on way's of how to protect the code...
or how to God knows what...
Zillions of OEM customers all around the world DEMAND Code Protection .
These OEM"s are not individuals with creative minds...
These are the people that buy bucket loads of "OTHER BRANDS"
Some of those OEM's probably look at this Forum as the "WILLY WONKA" chocalate factory
Can look at it but not allow to touch it....
Ronald Nollet
If they are really that worried, they can bury their prop in a blob of something really annoying and call it good.
Post Edited (potatohead) : 3/13/2007 6:25:58 PM GMT
I suggest you follow the threads on a possible C compiler for the Propeller using a "Large Memory Model" in that this is proposed as a standard commercial C compiler from ImageCraft which will, if it follows their regular model, consist of a compiler, assembler, and linker. The linker will provide you with the ability to distribute a binary library without the source code and standard C headers. Encourage ImageCraft, check out their licensing structure for their other products. The "Large Memory Model" will provide faster execution than Spin, yet will allow some routines to execute at near plain assembly speeds. It's not available now, but we're not talking about a huge effort because of the existing code base for other architectures.
Do also keep in mind that the Propeller is very very new. The reliability of the Spin interpreter and the compiler/assembler let alone the chip itself is unusual this early in development and production, particularly for a company this small. I don't really believe that "Zillions" of OEM customers are in fact demanding code protection of the sort you're suggesting (mixed source / binary). I can believe that there are many who would like to protect their finished binary code in their assembled systems in some fashion. That's a different issue.
There are a variety of ways to mix binary and source information in the existing Propeller Tool to make it harder to steal "intellectual property". They're just not built-in to the Propeller Tool.
I know what you mean.
The present hardware does not really allow any code protection at all.
Simply copy the eeprom and your up and running ...okay you can't the see code but still...
What I mean is a simple fuse code protect bit like in all micro's..
With the magic select or not select button .... too easy...
I know all this probably means that hopefully the new Propeller will have have eeprom built in.
That C compiler thread is cool .. again engineers that are comfortable with C will take to that like a duck to water.
And hopefully at the end of the day more customers for us the disties and our friends at Parallax.
It will be like a snowball effect .... as the Propeller is a pretty cool beast.
There needs to be more effort put into the assembly part of it .. more docs with samples..
This is a common question or remark we get from local people here in OZ.
Personally playing with the assembly part again and loving it ...will post some later.
The follow up to my "edgecam" logic hardware post.
Your code and also CJ gave me some pointers ... CJ code was close but not 100% right..
Not complaining ...very thankfull for all the suggestions as alway's...
See I do believe myself in OPEN SOURCE ... I think it is great ...
Cheers
Ronald Nollet