View Single Post
Old 05-20-2012, 08:58 AM   #3
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Quote:
Originally Posted by eureka View Post
If you'll build a new compiled program linked with liblipc.so and will use functions exported by this library, everything will be possible (with regard to implemented abilities of LIPC).
That might not work, since lipc may be keeping its information in its process address space.
Your additions would have to be made within the lipc process address space.

But since this is a dynamically loaded library, that is possible.
-----
A few command examples to get you started.
Here, using a copy of my K3-3.2.1 system image mounted at /mnt/k321 but the principles remain the same.
Remember, "man(ual)" is your friend for details of these commands.

Locate the dynamic library(ies):
Code:
core2quad k321 $ find . -name 'liblipc*'
./usr/lib/liblipc.so
./usr/lib/liblipc.so.0
./usr/lib/liblipc.so.0.1
Find which are the links and which is the binary:
Code:
core2quad k321 $ cd ./usr/lib
core2quad lib $ ls -l liblipc.so*
lrwxrwxrwx 1 root root    14 2011-04-06 19:15 liblipc.so -> liblipc.so.0.1
lrwxrwxrwx 1 root root    14 2011-04-06 19:15 liblipc.so.0 -> liblipc.so.0.1
-rwxr-xr-x 1 root root 73326 2011-04-06 19:15 liblipc.so.0.1
When you want to link code against that library, the *.so is presumed and the "-l" in the compiler's link options is shorthand for "lib" so to specify this library: "-llipc".

Use one of the symbol listing tools to list the external entry points.
For detailed information, including disassembly, objdump is probably the tool of choice.

For a quick listing of the symbol names use nm without any options.
Get a list of the defined (external) symbols:
Code:
core2quad lib $ nm -g --defined-only liblipc.so.0.1
- - - -
00005ce8 T LipcRegisterHasharrayProperties
00005e88 T LipcRegisterHasharrayProperty
0000620c T LipcRegisterIntProperties
0000639c T LipcRegisterIntProperty
00005f80 T LipcRegisterStringProperties
00006110 T LipcRegisterStringProperty
- - - -
0000839c T LipcSetEventCallback
- - - -
00008420 T LipcSubscribe
- - - -
There are 93 of them in this copy of the library, the above ones may be of interest to this question.
Any or all of them might be of general interest, but this may be a starting point.

Next you will need the symbol's parameter list and return values.
Since this is a compiler generated object file, the entry and exit to the functions match known patterns, making this step much easier than it might be otherwise.
You could even get by using just objdump, although there are fancier tools for the purpose.

Note: In the USA, determining the user interface to a closed source binary is legal, your country might have different rules/laws.

Next question: "I know the symbol's entry and exit interface, how do I make use of that?"

Let us imagine that the user of this dynamic library is an executable named "lipc".
We can't (legally) disassemble, modify, re-assemble and distrbute a closed source executable.

This is a dynamically loaded library, so we don't have to.
You can write a "wedge" library layer that provides your changed entry points and use the LD_PRELOAD dynamic loader variable on executions of "lipc".
Instead of:
lipc <parms>
The execution would be:
LD_PRELOAD=my_wedge.so lipc <parms>
Which can be implemented by a simple (shell) wrapper around the original lipc.

Where my_wedge.so would provide the new and/or modified features and it would dlopen liblipc.so to provide all the other, existing, features.
The "lipc" executable would never know the difference.

For a complete worked example of how this is all done, study the "fakeroot" utility.
http://anonscm.debian.org/gitweb/?p=...oot.git;a=tree
http://alioth.debian.org/projects/fakeroot/

Note: There is also a way to do this using the PTRACE facility, see: fakeroot-ng

Last edited by knc1; 05-20-2012 at 10:08 AM.
knc1 is offline   Reply With Quote