Conference turris::digital_unix

10048.0. "stripping/hiding local symbols in a program executable" by RDGENG::WOOD_J ([email protected]) Thu Jun 05 1997 08:07

A two-part question:

 1) Is there a way to strip redundant symbols from an executable file?
    That is, so that I can hide routine-name symbols local to my program?
    Just stripping the symbol table is not enough.

    E.g. if I have two source modules:

        m1.c:
            #include <stdio.h>
            void sub1();
            int main()
            {
                printf( "hello from prog\n" );
                sub1();
                return 1;
            }

        s1.c
            #include <stdio.h>
            void sub1()
            {
                printf( "hello from subroutine\n" );
            }

    I want the function-name "sub1" to be hidden; i.e. I don't want users of
    my program to know there's a symbol called "sub1" in the program. I build 
    an executable by doing:

        % cc -s -x -hidden_symbol sub1 m1.c s1.c

    But if I do

        % strings -a a.out | grep sub1

    then this shows that there is a string called "sub1" in the resultant
    executable. Thus I have not been successful in hiding my symbol names.

    Reading note 4244 of this conference, it seems that the ld flag of
    -hidden_symbol ony applies to shared objects. And in tests on shared
    objects, I found that applying -hidden_symbol doesn't actually prevent
    the routine-name symbol from appearing in the shared object; rather it 
    just causes that symbol to have LOCAL (rather than GLOBAL) binding.

    If sub1() was in the same module as main(), then I could qualify sub1()
    as static, which prevents it from becoming visible. However this is not
    an acceptable solution due to the nature of the source-code.

    Is there some other way of hiding the names of my local symbols?


 2) In the absense of knowing a supported way to surpress local routine names,
    the s/w vendor has created a utility which enables him to replace symbol
    names in the executable with zeros. When he runs the hacked program, it
    works, but it doesn't work when he ships the program to a customer.

    Is it permissible to replace the local routine name strings with some
    dummy data? The s/w vendor has tried zapping the strings with binary
    zeros, and also names like a0001, a0002, a0003; both hacked executables
    work on his system, but not on his end-users'. Of course, he can't (and
    doesn't) zap external routine references such as "printf" in the above
    example.


The software vendor has symbol names like "calculate_password" which he wants
to hide. He uses the zapping-the-binary technique on Sun systems. 

An alternative approach would be to mangle his symbol names by passing his
source code through a preprocessor.

Thanks,
  John Wood
  Software Partner Engineering (UK)

> 1) Is there a way to strip redundant symbols from an executable file?
>    That is, so that I can hide routine-name symbols local to my program?
>    Just stripping the symbol table is not enough.


There are two symbol tables in a call-shared executable.  
      1. The debug symbol table which you can remove with "strip"
         or "ld -s".
      2. The dynamic symbol table which is used by the loader.  This
         cannot be stripped.

Have you considered building non-shared?  Non-shared executables do
not have a dynamic symbol table so:

  % cc -s -non_shared m1.c s1.c
  m1.c:
  s1.c:
  % strings -a a.out | grep sub1
  % 

>    Is it permissible to replace the local routine name strings with some
>    dummy data? The s/w vendor has tried zapping the strings with binary
>    zeros, and also names like a0001, a0002, a0003; both hacked executables
>    work on his system, but not on his end-users'. Of course, he can't (and
>    doesn't) zap external routine references such as "printf" in the above
>    example.

Of course it's not permissible.  It is, as you correctly described it, a
hack.  It might work under some circumstances, but there's no guarantee.
Did the vendor also regenerate the dynamic hash table?