creating commercial library

 creating commercial library

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.

 RE: creating commercial library

The documentation for each tool chain will tell you how to build a library. Note that a library is basically a collection of object files stored in a single file.

Of course there are no compiler options to create hack-proof libraries. A compiler is intended to generate efficient (size and/or speed) code. Any attempts you do to make it harder to disassemble will make it slower and/or harder to maintain. But why bother? Have you invented a magic compression? The people who know how to disassemble already know about good compression algorithms.

The library must be compatible with the relevant toolchain. That means that you can't mix ARM and 8051. And the ABI (how to pass arguments, return values and store data in structs, ...) must be identical so you will need one library for each memory model - and for the different settings of some specific compiler flags.

Still nothing magic with a library - just a collection of object data.

What type of compression where you planning?

Compression of initialized data?
Compression of runnable code?
Compression of transmitted data on serial port?
...

 RE: creating commercial library

Hi,
Thanks for your reply.

No, this is not any magic compression algorithm. But it is for very specific purpose and for very specific datatype. This is to compress data, encrypt and then transfer.

I understand the reality of decompile, disassembly. But want to know how to make it harder.

Is there anyway to build library as DLL file? Like DLL file will work with Keil where user can select MCU, memory model, and can configure library options. Then based on that configuration library file will be generated and will be integrated in users project?

Please suggest me some books or links or articles on building commercial library.

Thank you.

 RE: creating commercial library

The user can't selection options and generate the library unless you give the source code to the user.

So if you want to protect your code, you must supply multiple library files and have the user select which file to link.

 RE: creating commercial library

I begin to translate pascal code demonstration,into C for test . when you like i make another good ebook .

 Obfuscate source code

Have you looked into source code obfuscators? They might be able to help you achieve some of your goals.

 RE: Obfuscate source code

Hi,
Yes Obfuscator is a good option.I will have to dig that well.

I was searching- if it is possible to make a licensing system using DLL or EXE application which will contain the libraries in it. Only libraries will directly be compiled from that DLL or EXE file?

I have found the following article which tells how to call external EXE during compilation. Is that helpful in my case anyway?

http://www.keil.com/support/docs/1878.htm

I need your suggestions and help.

Thanks in advance.

 RE: Obfuscate source code

1) Code obfuscators are used when you supply source code, but reformat it and rename all variables and functions.

But in this case, you want to supply libraries, i.e. already compiled modules. Then it doesn't matter if you run a code obfuscator that plays with symbol names. You need to let the program perform conditional tests based on computed variables that you get from other strange parts of the code where you do magic jumps and evaluations based on yet another strange decision.

But in your case, I think you will have a big problem selling your libraries. The embedded platforms don't use dll or exe files. An exe file is started by a free-standing operating system on request from a user. But embedded systems normally do not have an operating system with a command line or GUI where you may start an application.

And since you do not have an OS that starts one or more applications, you do not have an OS loader that will perform any dynamic linking when the applications gets started.

A traditional embedded system has one application and that application may be linked into an operating system - not because of a need for a GUI or command line, but to allow the real-time OS (RTOS) to handle task switches between different parts of the application.

You can write a library that exports a single function - but that function will be statically linked with your application. Or you will pre-program your library as a binary block into a fixed address range in the processor and have the application jump to a pre-defined address or vector.

 RE: Obfuscate source code

Thanks Mr. Per Westermark,
Can you provide me some example of proprietary libraries for embedded systems? I want to study their business strategy and how they are managing all the things (like pricing, implementation, clients, services etc).

Thank you.

 RE: IP Protection

Protecting IP falls into three categories.

The basics are these:

1) IP that can be hacked by a casual user

- Example: the user modifies an .ini file to gain features not intended to be allowed a simple user can do this with little knowledge.

2) IP that can be hacked by the enthusiast/hobbyist/professional

- Requires more in-depth knowledge on how things work

- Example: reading the code from memory, modifying the file to enable features, and reloading the code.

3) IP that can be hacked with expensive methods

- Requires in-depth knowledge and sophisticated equipment.

- Example: UV laser to disable the firmware lock bit.

When protecting your IP from these hackers, you must determine who you are trying to thwart. Type 3 requires the highest level of prevention techniques: including (tiny) explosives to obliterate the IP upon tampering detection. Type 3 hackers are usually backed by organized criminals or government agencies with plenty of funding. IP protected against type 3 hacking is usually reserved for very high-tech stuff. Almost all IP protection efforts falls into the type 2 category.

The type 1 hacker is fairly easy to thwart in the design process, and usually pushes the IP protection methods into the type 2 category. The type 2 category goal is to make the reverse engineering process more costly than the re-development process that would be required to replicate your IP.

Since your library will be a type 2, you must expect that there will be an attempt to hack into it since your intended users are knowledgeable enough to do so.

Your goal is to make that reverse engineering process difficult, hence costly. In your case, you might think about non-standard methods of accessing data or functions just to make them more confusing. Possibly by using function pointers, an index table into data stores, etc. to make the process of stepping through your linked library complicated and a pain to decipher. This will most likely slow your IP solutions down. But again, it is the cost of reverse engineering versus the sale price of your library.

If your library costs $15,000 then you'll have an impossible tasks preventing people from hacking into it. If it cost only $15, then your customer base won't bother with hacking it.

Nothing is fully protected against hacking. Just make the cost of reverse engineering higher than your sale price... and remember, in some countries, the labor cost is cheap.

This information was off the top of my head, so if you research IP protection methods, you'll find a more comprehensive explanation of these basic categories: and much better examples.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

P.S. I'm back from vacation, and just got caught up on the threads. I hope you all had a good Christmas, and plan on having a sane new-years
celebration.

 RE: IP Protection

Hi,
Thanks a lot for your well explanation. It's really helpful to clear my mind up.

Will you please advise me some proprietary library selling companies so that I can learn their views and business strategies?

Finally, it seems you had enjoyed a great vacation. I wish you and all to pass another great year :)

Thank you.

 RE: IP Protection

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.