Hi, I am working on a compression algorithm for embedded systems. I wish to sell my algorithm as a closed source proprietary library specially for ARM7, ARM8, Cortex M3 architectures. Also I plan to implement it in 8-bit MCUs as well. I don't have much idea on building a library.
My questions are- 1. How can I build a closed source proprietary library for ARM7, ARM9 and Cortex series ?
2. How safe the library will be in terms of disassembly and hack proof. Also is there any built in compiler support for protection of my algorithm?
3. What will be most secured possible solution to sell my library which can be bought and implemented by systems designers in different MCUs?
4. Is it possible to build MCU architecture independent or compiler independent library (as my algorithm only uses core CPU functionalities like addition, shifting, multiplication etc).
5. How can I build an external library to use in Keil CARM or RVCT? Is there any API type to integrate a library?
Please also suggest me some links, books and resources to study more on this.
Thank you.
You are really interested in getting examples. Haven't you spent any time looking for examples yourself that you may have questions about?
Trivial example: The C runtime library supplied with the Keil compiler. Normal users only get a pre-compiled library. Advanced users may pay a premium charge to get the full source. What protection has Keil added? Probably none, since the contents is to generic to make it worth it.
A step up - the Key real-time OS or their TCP/IP stack. Most probably not protected by any special methods either - Keil expect their professional customers to buy since it is cheaper/quicker than to reverse-engineer.
The reason why I asked about your compression was to figure out if it would include anything fancy. If it is just a nice package of something already known, then there will be limited interests to hack your library. If the library contains any new concept that is non-obvious and where the library gives a big advantage to their users, then there is more economical reasons for someone to try and figure out the internals.
But if you have a stream-compression library, you must compress better or with significantly lower CPU usage that the traditional implementations. If you don't, then it is cheaper to download a reference implementation of a compression algorithm and rewrite into optimized code for the specific target.
In the end, the likelyhood of anyone trying to crack your library is probably very, very small. Your main problem will not be to protect your code, but instead to make a package that gives enough value to the customer that they will buy instead of trying to code their own solutions.
You have to look at the driving forces for reverse-engineering code. Some of them may be: - you have a proprietary protocol, and a competitor want to sell a compatible product that can be a plug-in replacement for your product. - you have a new high-tech algorithm that gives significant military or economic advantages by being faster/more sensitive/more accurate/stealthier/... - you have a mass-produced product, and someone wants to duplicate not just your software but also the hardware and sell fake copies. If the hardware copy is perfect, then they can run a straight copy of the software. But they may have chosen lower-quality components and may have to downgrade the software to fit the downgraded hardware while still look/behave as the original. - you have a commercial PC/Game/Multimedia product but have a media licensing scheme that people want to get around - you have a commercial PC/Game/Multimedia product and people want to "abuse" your product by running other software on it - possibly Linux with a graphics card that doesn't have official Linux drivers, or replacing the original OS in a mobile phone/PDA or similar. - you have a hobbyist who are bored and has decided to learn how something really functions. - you have a competitor who believes that your program is in fact a rip-off of their program so they want to check if they can sue you or have the court stop the sales of your product.
Do you think that your product will fit into any of these categories, or do you have another category that you can add to the list?
Trying to obfuscate code that people are not likely to want to disassemble is about as productive as starting to optimize the code before first having checked what parts of the code that consumes time. Your support costs will go up a lot without any real gain - but a big chance of strange (and hard to debug) errors.