동적으로로드되는 라이브러리를 추적하는 방법

Question

Google 시스템에는 오픈 소스 라이브러리가 있습니다. 까다로운 점은 라이브러리의 복사본이 두 개 있습니다. 하나는 자체 수정 한 것이고 다른 하나는 원본입니다. 두 복사본 모두 소스 트리에 있지만 사용자 정의 된 복사본은 런타임에 호출해야하며 원래 복사본은 빌드시 다른 용도로 사용되어야합니다.

이제는 시스템 업그레이드 중에 사용자 지정 파일이 원래 파일에서 숨겨져있는 것 같습니다. 시스템의 복잡성 때문에 일부 추적을하기 위해 소스 코드를 수정하는 것이 가능하지만 어색합니다. 단서를 얻기 위해 최상위 레벨 라이브러리를 objdump 할 수만 있다면 생각합니다.

여기에 자세한 내용은 다음과 같습니다

1) The customization one and the original one have the same source file names 
2) Their library names are same 
3) The customization is some implementation change at deep within; so it is 
    invisible from outside 
4) The 2 libraries are at different sub directory trees 

가 동적으로 링크되어 있기 때문에, 실제로 objdump를 나에게 어떤 차이를 알 수 있습니다 의심한다. 그러나 어떤 제안도 감사합니다!

Answer 1

클래스 경로 (java 응용 프로그램 인 경우)를 수정하고이 사용자 정의 jar 파일을 원본 파일보다 먼저 추가하십시오.

이렇게하면 문제가 해결됩니다.

가끔 빌드 시간에 사용 된 클래스 경로가 저장되어 런타임 중에 사용되지만 클래스 경로 항목에 대한 java의 명령 줄 매개 변수에서이를 수정할 수도 있습니다. 또는 Tomcat에서 내부적으로 실행되는 경우에도 여전히 수정할 수 있습니다. 같은.

Answer 2

나는 ldd가 이것을 간단히 말해서, 추적보다는 예측으로 생각해야한다고 생각한다. ls 명령에 대한 예를 들어 당신이 AppArmor의 같은 것을 악용 할 수 추적하는

# ldd $(which ls) 
    linux-vdso.so.1 (0x00000333f2a54000) 
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00000333f2610000) 
    libcap.so.2 => /lib64/libcap.so.2 (0x00000333f2408000) 
    libacl.so.1 => /lib64/libacl.so.1 (0x00000333f21f8000) 
    libc.so.6 => /lib64/libc.so.6 (0x00000333f1e48000) 
    libdl.so.2 => /lib64/libdl.so.2 (0x00000333f1c40000) 
    libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00000333f19d8000) 
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000333f17b8000) 
    /lib64/ld-linux-x86-64.so.2 (0x00000333f2838000) 
    libattr.so.1 => /lib64/libattr.so.1 (0x00000333f15b0000) 

이에 대한 모드를 불평하고있다.

또는 GNU 디버거 인 gdb를 사용하십시오. "ls"명령을 실행하는 예제는 다음과 같습니다.

# gdb ls 
GNU gdb (GDB; openSUSE 13.1) 7.6.50.20130731-cvs 
Copyright (C) 2013 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 
This is free software: you are free to change and redistribute it. 
There is NO WARRANTY, to the extent permitted by law. Type "show copying" 
and "show warranty" for details. 
This GDB was configured as "x86_64-suse-linux". 
Type "show configuration" for configuration details. 
For bug reporting instructions, please see: 
<http://bugs.opensuse.org/>. 
Find the GDB manual and other documentation resources online at: 
<http://www.gnu.org/software/gdb/documentation/>. 
For help, type "help". 
Type "apropos word" to search for commands related to "word". 
.. 
Reading symbols from /usr/bin/ls...Missing separate debuginfo for /usr/bin/ls 
Try: zypper install -C "debuginfo(build-id)=eb844a5c20c70a59fc693cd1061f851fb7d046f4" 
(no debugging symbols found)...done. 
(gdb) start 
Function "main" not defined. 
Make breakpoint pending on future shared library load? (y or [n]) y 
Temporary breakpoint 1 (main) pending. 
Starting program: /usr/bin/ls 
warning: Cannot call inferior functions, Linux kernel PaX protection forbids return to non-executable pages! 
Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2 
Try: zypper install -C "debuginfo(build-id)=afa98667969782208459e394f8c8f87ac7510710" 
bak core learning.log  learning.mode lr old   test.log testpolicy  testpolicy.large 
c learn learning.log.uniq ll    lrw paxtest.log test2.log testpolicy.gradm testpolicy.large.gradm 
[Inferior 1 (process 25609) exited normally] 
(gdb) info sharedlibrary 
From    To     Syms Read Shared Object Library 
0x00000342a0556ae0 0x00000342a056ee10 Yes (*)  /lib64/ld-linux-x86-64.so.2 
(*): Shared library is missing debugging information. 
(gdb)