2

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?

João Pereira
  • 673
  • 1
  • 9
  • 29
  • 2
    The .h files you distribute do *not* have to be the same ones you use to compile your library, as long as you ensure the function prototypes match exactly. That said, it's better to distribute the ones you actually used so there's no potential for a mismatch. You can restructure your .h files so one of them contains only the exported functions and nothing else.\ – Mark Ransom Jun 24 '16 at 16:00
  • Ah ok, that helps a lot. I have some Macros in my .h files and that's why I did not want to give them away. – João Pereira Jun 24 '16 at 16:03

4 Answers4

2
  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.
mvidelgauz
  • 2,176
  • 1
  • 16
  • 23
  • I still don't understand how to add only the main header file, even with the pimpl paradigm. The way I'm doing it with `gcc` and `ar` to make the .a library, I need to include all the header files.. Can you help me here? – João Pereira Jun 27 '16 at 17:39
  • @JoãoPereira Probably yes, SO community can help you to certain extend, but you'll need to elaborate your problem and I ask a more concrete question(s). This is going to be a kind of small design review. You'll have to explain what you library is doing, what interface you want to expose to its users, what is in your .h files. Currently it seems that they are not organized well. Basically, you what to give user a header file with things that have to be exposed, and keep internal stuff in other headers... I think Mark Ransom has phrased this idea better in their comment than I did – mvidelgauz Jun 27 '16 at 20:32
2

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

MacedonZero
  • 216
  • 1
  • 9
1

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.

Eugene Sh.
  • 17,802
  • 8
  • 40
  • 61
  • Ty for the answer. About point 2: how can I do that? Any tutorial link will be enough – João Pereira Jun 24 '16 at 16:01
  • @JoãoPereira Write a header file that declares all the functions that are part of your library's API. More is not needed. – fuz Jun 24 '16 at 16:27
  • I still don't understand how to add only the main header file. The way I'm doing it with `gcc` and `ar` to make the .a library, I need to include all the header files.. Can you help me here? – João Pereira Jun 27 '16 at 17:38
1

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.

Makketronix
  • 1,389
  • 1
  • 11
  • 31
  • I still don't understand how to add only the main header file. The way I'm doing it with `gcc` and `ar` to make the .a library, I need to include all the header files.. Can you help me here? – João Pereira Jun 27 '16 at 17:10
  • You need to include all the header files, where? In the main function? You must provide a definition to the functions to be called. It would be helpful if you provide more information. You can call your functions func1(), func2(), ... – Makketronix Jun 28 '16 at 15:27
  • Let's say I have 5 .c and 5.h files. file1.h includes file2.h which in turn includes file3.h and so on and so on. How do I make a library in this case and have only file1.h + libXXX.a? – João Pereira Jun 28 '16 at 15:48
  • You only need to provide information about the functions that the users will be using in a separate file. Make sure to use "extern" to tell the compiler that they are defined in another place. Does my added example clarifies it? – Makketronix Jun 28 '16 at 15:53
  • 1
    These links show what I have in mind: http://www.network-theory.co.uk/docs/gccintro/gccintro_13.html and http://www.network-theory.co.uk/docs/gccintro/gccintro_14.html . Basically, Use gcc -c to compile to object files – Makketronix Jun 28 '16 at 16:03
  • Ty for the help @Makketronix. It cleared things up a little bit ;) – João Pereira Jun 28 '16 at 16:32