CODEWITHSUNDEEP
cshared-librariesstatic-libraries
João Pereira
João Pereira

Reputation: 713

C questions about static and shared libraries

I have some .c and .h files with the main function encapsulated in the MAIN_FUNC.c. I need to pass them to a guy who is going to integrate the MAIN_FUNC() with his files.

However since my algorithm is confidential I can't just send the .c and .h files and so I've been looking into static and shared libraries. However I still have some doubts.

1: In every tutorial that I've seen the .hs are needed as well. Is there any way that I can send the guy just one single library file that he can #include in his code?

2: Even if I have to pass the .hs files, do i really need to pass all of them? How can I give him only the libMAIN_FUNC.a and the MAIN_FUNC.h?

3: With the .a or .so libraries, is there any way of reverse engineering the files so that one can see the .c and .h code?

Upvotes: 2

Views: 355

Answers (4)

Makketronix
Makketronix

Reputation: 1460

First things first, on reverse engineering. Given infinite time and resources, your code can always be reverse engineered. Having said that, your objective is to make it impractical for others to reverse engineer your code.

Now to answer your question: Generating an executable binary from c code happens in "two major" steps. Compiling and Linking. After compiling, your files.c become object files (machine code). They are not executable yet.

If you have two files: file1.c and file2.c, you will get file1.o and file2.o for example.

Now, the code in file1.c may be calling a function which exists in file2.o. At compilation stage, all what file1.c needs to know is the function prototype.

When the linker is invoked to generate the executable binary, it makes sure that the function called from file1.o exists somewhere, such as in file2.o.

How this affects you:

The header file should not be proprietary (but perhaps it is for legal reasons). The header file is mainly used to tell other .c files what functions and return values to expect (declaration, not implementation).

Now perhaps you have some proprietary function prototypes for whatever reason which you don't want to expose to the world. Say you want the world to start your code by calling the function 

start_magic();

Then, what you do is:

  • Provide a header file: magic.h to be included in the main.c
  • header file will have the function: void start_magic();
  • You then put your proprietary code in algo.c and algo.h
  • algo.c will have start_magic() implementation
  • algo.c will include proprietary algo.h

Now what you can do is compile (no linking) your algo.c file, and strip the debugging symbols to make it hard to reverse engineer. How this is done depends on the compiler you are using.

Now you can provide the object file and the header file to somebody who wants to call the function start_magic().

The implementer of main has to link the program using the object file you provided.

Example

Assume you have algo.c with your algorithms. Let us say algo.c has the function:

float sqrt(float x){ 
    taylor_approx(x); 
}

Suppose that sqrt function will be shared with supplier. However, sqrt function calls on proprietary function taylor_approx(x) to calculate the square root.

You can create an algo.h file to be sent to the users, which contains:

extern float sqrt(float x);

Then you can send your -stripped from debugging symbols- compiled object file, for example, algo.o, to the users and ask them to put algo.h in their main.c

Note that this is one way to do it.

Upvotes: 1

MacedonZero
MacedonZero

Reputation: 216

My understanding is that you have a .c and .h file that someone else will be implementing, but you want to keep your code confidential.

If your only concern is handing out source code, then there is always the option of partial compilation. If you have gone through the trouble of making sure your code works without issue, you can partially compile your program into a .o file.

I don't know the details of your code, but if this other person you've mentioned will just be implementing your functions like a library, then the .o is all he would need.

sample makefile for your end:

all: MAIN_FUNC.o

MAIN_FUNC.o: MAIN_FUNC.c MAIN_FUNC.h
    gcc -c MAIN_FUNC.c

sample makefile for other guy's end:

all: main

main: main.c main.h MAIN_FUNC.o
    gcc -o main.c MAIN_FUNC.o main

A lot of companies do this sort of thing in order to protect their property. When one company sells software to another, they oftentimes sell these .o files. You would only need to provide the knowledge of what the function does (i.e. "This function takes an input from the console and returns the number of words written as an integer")--something basic that would allow the implementation of your work without revealing your source code.

Edit: fixed a typo

Upvotes: 2

mvidelgauz
mvidelgauz

Reputation: 2214

  1. No, you must provide him with at least one .h file.
  2. No, you need to pass only those that are sufficiently define interface between your library and user. I suggest you to read about pimpl paradigm
  3. Theoretically yes, your .a and .so files can be reverse-engineered, but it is very nontrivial.

Upvotes: 2

Eugene Sh.
Eugene Sh.

Reputation: 18381

1) You can compile your C file into a library (*.a or whatever), given it is written properly and distribute it along with the h file. you have to give the h files as they are the interface to your library, which is just a binary blob otherwise.

2) You need to pass the headers declaring the public interface your library is exporting. I.e. the functions and symbols you want the user of the library to have access to.

3) Yes, there is always way of reverse engineering of just anything. The only question is the gain/effort ratio.

Upvotes: 1

Related Questions