When I compile a set of files and make them into a library they contain
filenames of the original source files. Every compiler works like that
including those running under unix/linux.

You don't need to be very smart in order to use some dumping utilities which
will extract this information on compiled objects or libraries. Since some
of my files contain specific information (in their filenames) about
algorithms I used, I know that some attackers might find it useful to
investigate my files which I naturally have no interest in.

What I'd like to do is to compile all files as a sequence of pseudo random
names. So my_super_cool_algorithm.c / .o will become "randomfile1".o and
when made into a library the original name "my_super_cool_algorithm" won't
be visible anymore.

I know this is possible because I've already investigated other libraries
where all object files were named a0, a1, a2, a3, a4, a5... etc.

So I wrote a program which writes a "table" of new names. It takes the
original filename as input and gives a new name as output (written to
stdout). Additionally there is a lookup table in this program so if the
input file is given twice, the same output file name will be printed out.

My thought is to intergrate this utility with make tools (since I already
use make for building) but so far I havn't figured out how or IF it's even
possible.

Anyone got a clue how to hide original filenames in library files?
The alternative is to make a post-processing utility which will do a string
based search and replacement. However I think some object files (on some
platforms) have checksums and similar which I worry about will be changed if
I do it this way.

Any suggestions?

Thanks in advance.
-- John

[ Post a follow-up to this message ]

"John Smith" <john.smith@intheunknown.net> writes:
quote:

> When I compile a set of files and make them into a library they contain
> filenames of the original source files. Every compiler works like that
> including those running under unix/linux.
>
> You don't need to be very smart in order to use some dumping utilities whi
ch
> will extract this information on compiled objects or libraries. Since some
> of my files contain specific information (in their filenames) about
> algorithms I used, I know that some attackers might find it useful to
> investigate my files which I naturally have no interest in.
>
> What I'd like to do is to compile all files as a sequence of pseudo random
> names. So my_super_cool_algorithm.c / .o will become "randomfile1".o and
> when made into a library the original name "my_super_cool_algorithm" won't
> be visible anymore.


man strip

--
Måns Rullgård
mru@kth.se

[ Post a follow-up to this message ]

"John Smith" <john.smith@intheunknown.net> writes:
quote:

> My thought is to intergrate this utility with make tools (since I already
> use make for building) but so far I havn't figured out how or IF it's even
> possible.


Just have that utility create a new copy of your source tree (with
files renamed), and a new Makefile.

mru@kth.se (Måns Rullgård) writes:
quote:

> man strip


John's final product is a linkable library (if I understood him
correctly). A library composed from stripped objects will not do
his customers much good.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

> Just have that utility create a new copy of your source tree (with
quote:

> files renamed), and a new Makefile.
>


Even though it's not really perfect it's surely a workable idea. Thanks for
the suggestion. It's the best one I've gotten so far.
quote:

> mru@kth.se (Måns Rullgård) writes: 
>
> John's final product is a linkable library (if I understood him
> correctly). A library composed from stripped objects will not do
> his customers much good.


Thats correct. I distribute libraries containing object files.

-- John

[ Post a follow-up to this message ]

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:
quote:

> mru@kth.se (Måns Rullgård) writes: 
>
> John's final product is a linkable library (if I understood him
> correctly). A library composed from stripped objects will not do
> his customers much good.


It's perfectly possible to link with stripped objects.  The linker
doesn't need to know the name of the source file or any other
debugging information.  If he's worried about the names of library
entry points revealing information he should probably not be releasing
it at all.

--
Måns Rullgård
mru@kth.se

[ Post a follow-up to this message ]

Paul Pluzhnikov wrote:
quote:

> "John Smith" <john.smith@intheunknown.net> writes:
>
> 
>
>
> Just have that utility create a new copy of your source tree (with
> files renamed), and a new Makefile.


Another option would be to make one more C file called, say, wrapper.c.
This file would simply #include all the other C files. Compile that and
put it in a library which will show only wrapper.o. Of course linked
binaries may get bigger as they'll take all the code from this library
instead of just what they need. Depending on the size of the library
that may or may not be a big deal.

MB

[ Post a follow-up to this message ]

mru@kth.se (Måns Rullgård) writes:
quote:

> It's perfectly possible to link with stripped objects.


It is possible to link with *partially* stripped objects.
quote:

> The linker
> doesn't need to know the name of the source file or any other
> debugging information.


On many systems 'strip' will remove both source/debug info, *and*
symbol table, making the object unusable.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:
quote:

> mru@kth.se (Måns Rullgård) writes:
> 
>
> It is possible to link with *partially* stripped objects.
> 
>
> On many systems 'strip' will remove both source/debug info, *and*
> symbol table, making the object unusable.


Those that I have used removed only as much as possible without
damaging the usability of the files.  There can obviously be strip
programs with other behaviors out there.

--
Måns Rullgård
mru@kth.se

[ Post a follow-up to this message ]

> Another option would be to make one more C file called, say, wrapper.c.
quote:

> This file would simply #include all the other C files. Compile that and
> put it in a library which will show only wrapper.o. Of course linked
> binaries may get bigger as they'll take all the code from this library
> instead of just what they need. Depending on the size of the library
> that may or may not be a big deal.
>

Thanks alot for the suggestion.
From all the possibilities this one is surely the easiest one because it
works with any compiler and requires no extra tools.
I did it on my code and to my surprise the library size went from 300 kb to
100 kb. Yes the linked file will be larger but with 100 kb libraries I
couldn't care less.

-- John

[ Post a follow-up to this message ]