Where to find the dlopen() source?
Gary Pearman
loads into memory.
Does anyone have a link to to libdl source, so I can take a peek at the
dlopen function to see what it's doing?
Regards,
Gaz.
Lars Kellogg-Stedman
> dlopen function to see what it's doing?
If you're running any common Linux distribution
(RedHat/Fedora/Debian/Suse/etc.), you already have the source handy.
(1) Figure out what package owns that file:
On RedHat-ish systems:
$ rpm -qf /lib/libdl-2.3.2.so
glibc-2.3.2-27.9.7
Or on Debian-ish systems:
$ dpkg-query -S /lib/libdl-2.3.2.so
libc6: /lib/libdl-2.3.2.so
(2) Go grab the corresponding source package from your distribution.
Alternatively, now that you know libdl is part of glibc, you can just go
fetch the sources from <http://www.gnu.org/software/libc/>.
-- Lars
--
Lars Kellogg-Stedman <8273grk...@jetable.net>
This email address will expire on 2005-11-23.
Gary Pearman
Paul Pluzhnikov
> I need to write a custom dlopen function that decrypts library as it
> loads into memory.
Presumably to implement a copy-protection scheme.
This effort will be largely wasted, as anybody who has even a
minimal skill with debugger will be able to stop your process just
after your "decrypting dlopen" returns, and observe/copy the
decrypted code and data.
There is a further complication: on Linux a call to dlopen()
results in an intricate dance, where libdl calls into ld-linux and
vice versa, using *private* interface (which changes with releases).
This means that if you supply your own dlopen() replacement, you'll
have to supply one for each version of glibc that your customer
may have, and then arrange for the appropriate replacement to be
called. This is a maintenance nightmare.
> Does anyone have a link to to libdl source, so I can take a peek at the
Download glibc-2.x.y.src.rpm and look in glic-2.x.y/elf/dl-open.c
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Gary Pearman
Correct. Good points, and well made :-)
I've just looked at the source code and it does seem be, well, let's put
it this way, a tad complex.
The other idea was to decrypt the library to a ram disk, then do a dlopen
on it from there. The actual system itself would be enclosed in a cabinet,
so for someone to try and debug the machine, the cab would need to be
opened (or have a big hole drilled in it).
Regards,
Gaz.
Paul Pluzhnikov
> The other idea was to decrypt the library to a ram disk, then do a dlopen
> on it from there. The actual system itself would be enclosed in a cabinet,
> so for someone to try and debug the machine, the cab would need to be
> opened (or have a big hole drilled in it).
I don't get it.
If the machine is physically-secure and has no network logins,
then what's the point of protecting anything on it?
If it does have network logins, then what does it matter that it
is in a closed cabinet?
Gary Pearman
Nothing is _totally_ physically secure :-)
The machine has software on it which is loaded as a shared library that
we'd rather people didn't get to copy from the machine, hack, edit,
reverse engineer etc.
Tauno Voipio
>>If the machine is physically-secure and has no network logins,
>
>
> Nothing is _totally_ physically secure :-)
>
> The machine has software on it which is loaded as a shared library that
> we'd rather people didn't get to copy from the machine, hack, edit,
> reverse engineer etc.
>
What prevents the hacker from making a wrapper around your
dlopen() wrapper?
(Methinks that copy-protection schemes are kind of
flame-attracting topics in open source community.
Are you going to make the sources available or
make sure that you're not going to modify any
GPL'ed sources for your purposes?)
--
Tauno Voipio
tauno voipio (at) iki fi
Kasper Dupont
>
> Are you going to make the sources available or
> make sure that you're not going to modify any
> GPL'ed sources for your purposes?)
They have to make sources available even if
they are not modified.
--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.
Kasper Dupont
dlopen does not read the library into memory. Any attempt at
decrypting will be tricky, and will waste a lot of memory.
Russell Shaw
>>Does anyone have a link to to libdl source, so I can take a peek at the
>>dlopen function to see what it's doing?
>
> If you're running any common Linux distribution
> (RedHat/Fedora/Debian/Suse/etc.), you already have the source handy.
>
> (1) Figure out what package owns that file:
>
> On RedHat-ish systems:
>
> $ rpm -qf /lib/libdl-2.3.2.so
> glibc-2.3.2-27.9.7
>
> Or on Debian-ish systems:
>
> $ dpkg-query -S /lib/libdl-2.3.2.so
> libc6: /lib/libdl-2.3.2.so
Can also do: $ dpkg -S /lib/libdl-2.3.2.so
Gary Pearman
> Tauno Voipio wrote:
>>
>> Are you going to make the sources available or
>> make sure that you're not going to modify any
>> GPL'ed sources for your purposes?)
>
> They have to make sources available even if
> they are not modified.
Yes, the sources will all be made available, where it is necessary to do
so.
Gary Pearman
> dlopen does not read the library into memory. Any attempt at
> decrypting will be tricky, and will waste a lot of memory.
Not knowing much about Linux system structures etc. how easy would it be
to actually write my own dlopen type function that _does_ load the library
into memory.
Do you have any links or info I could use to swat up on Linux shared
object loading etc?
Thanks,
Gary.
Josef Moellers
>>If the machine is physically-secure and has no network logins,
>
>
> Nothing is _totally_ physically secure :-)
>
> The machine has software on it which is loaded as a shared library that
> we'd rather people didn't get to copy from the machine, hack, edit,
> reverse engineer etc.
What prevents your hacker from dlopen() your library, then look at his
own /proc/pid/maps to find where it's loaded, then just read from the
locations? Even if it were not loaded in advance, reading from the
virtual addresses will pagefault the library into memory.
--
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize
-- T. Pratchett
Bernhard Agthe
> The machine has software on it which is loaded as a shared library that
> we'd rather people didn't get to copy from the machine, hack, edit,
> reverse engineer etc.
is it correct to assume you want to check that the library has not been
modified by using a cryptographic signature? I think this is a possible
(and may be necessary) feature.
Why don't you add the check just before dlopening the library - this way
a cracker would need to modify your program to remove the check - so you
should check your program on startup. The second possible attack would
be an insertion of a faulty library just after the check has been
performed. But who would want a bad library anyway? You would not
protect your system completely but you'd make it quite hard to tamper with.
Ciao,
Berny Agthe
x
Tauno Voipio
You could start with:
Daniel P. Bovet, Marco Cesati, Understanding the Linux Kernel,
Second edition, O'Reilly, ISBN 0-596-00213-0
Especially important for your problem are the parts of memory
management and process execution environment.
The shared library is loaded page-by-page only when needed
by any of the using processes. What complicates the planned
decryption is that the library may (and often will) end at
different logical addresses with different processes.
The dynamic load commands only map the library file to
the logical address space of the calling process, so
no decryption can be handled here.
The Linux shared libraries are *not* Windows DLL:s.