How to allow API access to a secret Object

Sandball

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?

Paul Baker

The decision was made not to enable the use of pre-compiled objects, distribution is open source only.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 3/12/2007 7:39:20 AM GMT

Sandball

Thanks for the quick response. I respect the decision and typically prefer open source but it won't work for this project. I would like to give developers limited access to the technology so I guess my next task is to look into code obfuscation.

T Chap

It's been discussed quite a few times, with no real solutions that can't be cracked.

Please post if you have some ideas to share.

Post Edited (originator) : 3/12/2007 9:26:15 AM GMT

Sandball

I apologize in advance for discussing something that goes against the philosophy of open source. However, I would rather give developers the chance to use my technology (which I'm not comfortable sharing right now) as a black box rather than not making it accessible at all.

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?

potatohead

One does have to consider said use.

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)

Mike Green

Sandball,
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 Pilgrim (PhiPi)

I'm with potatohead. The worst fate an active, creative mind can suffer is to be indispensible. And if you keep secrets from your customers, that's what you become. If the bus doesn't get you first, the mounting stress of supporting an uninformed client base surely will.

-Phil

Paul Baker

Mike discussed my idea, store code as DAT constants, ASM is easy to do, Spin could probably be done as well but would take more tinkering to accomplish.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

OzStamp

Not with anybody in particular.
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

potatohead

Edit: I didn't realize I had posted this text, I've now removed. I'll leave the last bit, as I think it's relevant at this time. Sorry all!

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

Mike Green

Ronald,
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.

OzStamp

Hi Mike

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