編譯so確保能解析所有符號

『壹』 如何查看ndk編譯的動態庫符號表

$ /path/to/ndk/buid/prebuilt/windows/arm-eabi-4.4.0/bin/arm-eabi-nm libs/armeabi/libsanangeles.so

00003600 T java_com_example_SanAngeles_DemoGLSurfaceView_nativePause

00003638 T Java_com_example_SanAngeles_DemoRenderer_nativeDone

0000367c T Java_com_example_SanAngeles_DemoRenderer_nativeInit

000035b4 T Java_com_example_SanAngeles_DemoRenderer_nativeRender

00003644 T Java_com_example_SanAngeles_DemoRenderer_nativeResize

00007334 a _DYNAMIC

0000740c a _GLOBAL_OFFSET_TABLE_

復制代碼

這里可以看到幾乎所有的函數名全局變數名都會被導出。其中有Java_com_example_SanAngeles_為前綴的JNI介面函數，有importGLInit這些普通函數，有freeGLObject這些局部（static）函數，還有sStartTick等全局變數名。其實在這個動態發布的時候，只需要導出java_com_開頭的jni函數就可以了，裡面這些細節函數名完全不需要暴露出來。
如何做到這一點呢？首先，我們需要了解gcc新引進的選項-fvisibility=hidden，這個編譯選項可以把所有的符號名（包括函數名和全局變數名）都強制標記成隱藏屬性。我們可以在android.mk中可以通過修改LOCAL_CFLAGS選項加入-fvisibility=hidden來做到這一點，這樣編譯之後的.so看到的符號表為：

000033d0 t Java_com_example_SanAngeles_DemoGLSurfaceView_nativePause

00003408 t Java_com_example_SanAngeles_DemoRenderer_nativeDone

0000344c t Java_com_example_SanAngeles_DemoRenderer_nativeInit

00003384 t Java_com_example_SanAngeles_DemoRenderer_nativeRender

00003414 t Java_com_example_SanAngeles_DemoRenderer_nativeResize

00007104 a _DYNAMIC

『貳』 linux c調用so

實例代碼（soTest.c）：

1 #include <stdio.h>
2 #include <dlfcn.h>
3
4 int main(int argc, char *argv[]){
5 void * libm_handle = NULL;
6 float (*cosf_method)(float);
7 char *errorInfo;
8 float result;
9
10 // dlopen 函數還會自動解析共享庫中的依賴項。這樣，如果您打開了一個依賴於其他共享庫的對象，它就會自動載入它們。
11 // 函數返回一個句柄，該句柄用於後續的 API 調用
12 libm_handle = dlopen("libm.so", RTLD_LAZY );
13 // 如果返回 NULL 句柄，表示無法找到對象文件，過程結束。否則的話，將會得到對象的一個句柄，可以進一步詢問對象
14 if (!libm_handle){
15 // 如果返回 NULL 句柄,通過dlerror方法可以取得無法訪問對象的原因
16 printf("Open Error:%s.\n",dlerror());
17 return 0;
18 }
19
20 // 使用 dlsym 函數，嘗試解析新打開的對象文件中的符號。您將會得到一個有效的指向該符號的指針，或者是得到一個 NULL 並返回一個錯誤
21 cosf_method = dlsym(libm_handle,"cosf");
22 errorInfo = dlerror();// 調用dlerror方法，返回錯誤信息的同時，內存中的錯誤信息被清空
23 if (errorInfo != NULL){
24 printf("Dlsym Error:%s.\n",errorInfo);
25 return 0;
26 }
27
28 // 執行「cosf」方法
29 result = (*cosf_method)(0.0);
30 printf("result = %f.\n",result);
31
32 // 調用 ELF 對象中的目標函數後，通過調用 dlclose 來關閉對它的訪問
33 dlclose(libm_handle);
34
35 return 0;
36 }

在這個例子中主要是調用了 math 庫（libm.so）中的「cosf」函數，dlopen函數的第二個參數表示載入庫文件的模式，主要有兩種：RTLD_LAZY 暫緩決定，等有需要時再解出符號；RTLD_NOW 立即決定，返回前解除所有未決定的符號。另外記得引用包含API的頭文件「#include <dlfcn.h>」（^_^）。

『叄』 golang編譯androidso無法載入

Golang編譯so動態庫載入失敗的原因可能有很多，首先，檢查動態庫文件是否正確安裝，其次，檢查編譯選項是否正確，比如-shared參數是否被正確設置，最後，追蹤運行時出現的導致載入失敗的錯誤，可能是某個符號沒有被找到或者版本不匹配等情況。

『肆』 如何在麒麟系統中調用so讀卡動態庫

概念
載入動態鏈接庫，首先為共享庫分配物理內存，然後在進程對應的頁表項中建立虛擬頁和物理頁面之間的映射。你可以認為系統中存在一種引用計數機制， 每當一個進程載入了共享庫（在該進程的頁表中進行一次映射），引用計數加一；一個進程顯式卸載（通過dlclose等）共享庫或進程退出時，引用計數減 一，當減少到0時，系統卸載共享庫。
頭文件

#include <dlfcn.h>
相關函數介紹

(1)打開動態鏈接庫：dlopen
函數原型

void *dlopen (const char *filename, int flag);
flag：分為這兩種
RTLD_NOW：在dlopen返回前，解析出全部沒有定義的符號，解析不出來返回NULL。
RT_GLOBAL：動態庫定義的符號可被其後打開的其他庫解析。
RT_LOCAL：和上面相反，不能被其他庫解析。默認。
RTLD_LAZY：暫緩決定，等有需要時再解出符號

返回值:

打開錯誤返回NULL
成功，返回庫引用
dlopen用於打開指定名字(filename)的動態鏈接庫(最好文件絕對路徑)，並返回操作句柄。
(2)取函數執行地址：dlsym

函數原型

void *dlsym(void *handle, char *symbol);
dlsym根據動態鏈接庫操作句柄(handle)與符號(symbol)，返回符號對應的函數的執行代碼地址。
(3)關閉動態鏈接庫：dlclose

函數原型

int dlclose (void *handle);
returns 0 on success, and nonzero on error.
dlclose用於關閉指定句柄的動態鏈接庫，只有當此動態鏈接庫的使用計數為0時,才會真正被系統卸載。

(4)動態庫錯誤函數：dlerror
函數原型

const char *dlerror(void);
當動態鏈接庫操作函數執行失敗時，dlerror可以返回出錯信息，返回值為NULL時表示操作函數執行成功。

示例
#include <stdio.h>
#include <dlfcn.h>
int main(int argc, char **argv) {
void *handle;
double (*cosine)(double);
char *error;
handle = dlopen ("/tmp/libtest.so", RTLD_LAZY);
if (!handle) {
fprintf (stderr, "%s ", dlerror());
exit(1);
}
cosine = (double(*)(double))dlsym(handle, "cos");
if ((error = dlerror()) != NULL) {
fprintf (stderr, "%s ", error);
exit(1);
}
printf ("%f ", (*cosine)(2.0));
dlclose(handle);
return 0;
}

『伍』 re從零開始的反編譯教程

寫在開頭，引用很喜歡的一句話： 要麼學！要麼不學！學和不學之間沒有中間值 不學就放棄,學就要去認真的學！ --致選擇

為了回溯編譯過程（或對程序進行逆向工程），我們使用各種工具來撤銷匯編和編譯過程，這些工具就叫反匯編器和反編譯器。反匯編器撤銷匯編過程，因此我們可以得到匯編語言形式的輸出結果。反編譯器則以匯編語言甚至是機器語言為輸入，其輸出結果為高級語言。

數組的表示方式是：在基本類型前加上前中括弧「[」，例如int數組和float數組分別表示為：[I、[F；對象的表示則以L作為開頭，格式是 LpackageName/objectName;

（注意必須有個分號跟在最後），例如String對象在smali中為： Ljava/lang/String; ，其中 java/lang 對應 java.lang 包，String就是定義在該包中的一個對象。或許有人問，既然類是用 LpackageName/objectName; 來表示，那類裡面的內部類又如何在smali中引用呢？
答案是：在 LpackageName/objectName/subObjectName 的 subObjectName 前加 $ 符號。

方法的定義一般為： Func-Name (Para-Type1Para-Type2Para-Type3...)Return-Type
注意參數與參數之間沒有任何分隔符，同樣舉幾個例子就容易明白

無序列表的使用，在符號"-"後加空格使用。如下：

https://www.jianshu.com/p/1c54c1ccf5cc

https://www.cnblogs.com/onelikeone/p/7594177.html

解決：點擊進去jd-gui，刪除試一試。再不行換最新版本

解析結束後進行編譯報錯
解決方法： https://blog.csdn.net/fuchaosz/article/details/104800802

Failed parse ring installPackageLI: Targeting R+ (version 30 and above) requires the resources.arsc of installed APKs to be stored uncompress

解決方法：

降低gradle里版本，若出現
signatures do not match the previously installed version; ，

使用adb install命令在手機上安裝app時，遇到這個報錯。原因是新裝的app和手機上現有的舊版app沖突了。
解決方法：刪除手機上原來的app，再重新安裝即可。

可是轉念一想如果反編譯的apk都是Version 30 R+以上，難道我解壓後挨個改一遍gradle？太徹淡了，一定有解決方法，所以有了下面探究出現這個問題的解決方法：既然報錯是資源文件高版本不支持，而且沒有4位對齊，那麼不編譯資源文件就好了

APK簽名工具之jarsigner和apksigner：

https://blog.csdn.net/xzytl60937234/article/details/89088215?utm_medium=distribute.pc_relevant.none-task-blog-js_landingword-1&spm=1001.2101.3001.4242

利用apktool反編譯apk，並且重新簽名打包：

https://blog.csdn.net/qq_21007661/article/details/109851522?utm_medium=distribute.pc_relevant.none-task-blog-js_title-4&spm=1001.2101.3001.4242

驗證apktool能否使用

apktool -r d apk名字.apk，不反編譯資源文件，為什麼這么做，先挖個坑

錯誤提示沒有4位對齊和不支持30版本以上的資源文件。所有嘗試不編譯資源文件

解決4位對齊的方法：

查看當前目錄，生成了新文件：abc.keystor

使用JarSigner對apk進行簽名，命令如下

jarsigner -verbose -keystore abc.keystore -signedjar testx.apk src.apk abc.keystore

直接反編譯的apk產生上述錯誤

但是只編譯資源文件的apk安裝時

發現沒有使用V2進行簽名，這時候進行V2簽名， (apksigner,默認同時使用V1和V2簽名 ）

所以先對只編譯資源文件的apk進行V2嘗試看能否成功

重復1（進行apktool -r d apk名字.apk）-->2 -->3 -->4( 不使用jarsigner而使用apksigner )

將生成的abc.keystore和打包回的apk（ apktoolapp-debugdist 里的app-debug.apk）放入 C:Users aowei.lianAppDataLocalAndroidSdkuild-tools30.0.3 下，因為Android studio的SDK下有apksigner.bat.

對jarsigner只是apk進行了V1簽名；在Android7.0引入了V2簽名，因此，當進入sdk25.0.0及後續版本，會發現一個apksigner.bat執行腳本。

我們可以通過apksigner進行V2簽名，當然，apksigner默認是同時支持V1與V2的，於是：

學習了公鑰和密鑰的使用和區別，使用私鑰的加密演算法稱為對稱加密演算法，這種演算法實現是接收方和發送方公用一道密鑰，優點是效率高，缺點是安全性差，如果被第三人得知密鑰則信息泄露，由此衍生了公鑰加密演算法，也就是非對稱加密演算法，這個演算法是接收方給發送方公鑰，發送方用公鑰加密後發給接收方，接受方再用私鑰解密。這樣即使所有人知道公鑰也不會造成信息泄露。缺點是效率非常低。

此外了解了RSA簽名的大致過程，發送方擁有公鑰和私鑰，對信息進行摘要然後把摘要通過密鑰進行簽名，然後把簽名和信息一起發出去，那麼如何驗證該信息就是發送方發出的呢，這時候就使用到了公鑰驗證，通過公鑰對信息進行解簽，然後使用一樣的摘要演算法得到摘要，如果得到的摘要和解簽後的內容一致則說明是發送方發出。
總結就是公鑰加密，私鑰解密。公鑰驗證，私鑰簽名

RSA 密碼體制是一種公鑰密碼體制，公鑰公開，私鑰保密，它的加密解密演算法是公開的。由公鑰加密的內容可以並且只能由私鑰進行解密，而由私鑰加密的內容可以並且只能由公鑰進行解密。也就是說，RSA 的這一對公鑰、私鑰都可以用來加密和解密，並且一方加密的內容可以由並且只能由對方進行解密。

因為公鑰是公開的，任何公鑰持有者都可以將想要發送給私鑰持有者的信息進行加密後發送，而這個信息只有私鑰持有者才能解密。

它和加密有什麼區別呢？因為公鑰是公開的，所以任何持有公鑰的人都能解密私鑰加密過的密文，所以這個過程並不能保證消息的安全性，但是它卻能保證消息來源的准確性和不可否認性，也就是說，如果使用公鑰能正常解密某一個密文，那麼就能證明這段密文一定是由私鑰持有者發布的，而不是其他第三方發布的，並且私鑰持有者不能否認他曾經發布過該消息。故此將該過程稱為「簽名」。

Android 簽名機制 v1、v2、v3

進入JDK/bin, 輸入命令

參數:

進入Android SDK/build-tools/SDK版本, 輸入命令

參數:

例如:

最後安裝加 -t ：

附上參考鏈接：

https://blog.csdn.net/A807296772/article/details/102298970

配置NDK的時候如果按鈕是灰色的，手動配置

直接在javac後面指定編碼是UTF-8就是了。

需要注意的是要加上* -classpath .其中classpath後面的一個黑點是不能省略的。

編譯好後如何導入so庫

成功運行後發現lib目錄下已經apk編進去so了

https://www.52pojie.cn/thread-732298-1-1.html
本節所有到的工具和Demo

IDA
鏈接： https://pan..com/s/15uCX8o6tTSSelgG_RN7kBQ

密碼：ftie

Demo
鏈接： https://pan..com/s/1vKC1SevvHfeI7f0d2c6IqQ

密碼：u1an

找到so並打開它 因為我的機型是支持arm的所以我這里打開的是armeabi文件夾下的so 如果機型是x86模式的那麼這里要打開x86模式下的libJniTest.so

編譯過程：

按住鍵盤組合鍵 shift + f12 打開字元串窗口 這個窗口將會列舉出so中所包含的所有字元串 因為上節課我們只編寫了一個字元串 所以這里只有一個hello 52pojie! 如果打開的是x86的so這里還會有一些.so 但是字元串只有這一個

滑鼠點在hello 52pojie!字元串上,打開 Hex mp窗口,修改hello 52pojie!對應內存地址的內容
關於字元對應的16進制可以在網路搜索ascii碼表 找到字元所對應的16進制

因為我要把hello 52pojie！修改成hello world! 是不是只要找到每個字元所對應的hex修改就好了
這里我看到 hello 52pojie!對應的hex是:68 65 6C 6C 6F 20 35 32 70 6F 6A 69 65 21
我在ascii碼表上找到world所對應的十六進制是:77 6F 72 6C 64
所以hello world! 對應的十六進制是:68 65 6C 6C 6F 20 77 6F 72 6C 64 21

注意編輯的時候游標暫停的位置只有先輸入字母才能更改成功，修改好後 右鍵Apply changes應用

退出後保存

此時已經so修改完畢

大功告成，hello 52pojie! --> hello world!

『陸』 請問我有一個.so文件，如何在Linux下編程使用呢

-lxx

xx是你的.so文件名

其實使用方法和你使用數學庫函數是一樣的，源代碼中添加

#include <math.h>，編譯的時候，加上-lm參數。

註：linux下的.so文件為共享庫，相當於windows下的dll文件。

(6)編譯so確保能解析所有符號擴展閱讀：

linux下編寫調用so文件實例

.so是Linux(Unix)下的動態鏈接庫. 和.dll類似.

比如：

文件有: a.c, b.c, c.c

gcc -c a.c

gcc -c b.c

gcc -c c.c

gcc -shared libXXX.so a.o b.o c.o

要使用的話也很簡單. 比如編譯d.c, 使用到libXXX.so中的函數, libXXX.so地址是MYPATH
gcc d.c -o d -LMYPATH -lXXX

注意不是-llibXXX

test.c文件和一個test.h，這兩個文件要生成libsotest.so文件。然後我還有一個testso.c文件，在這個文件裡面調用libsotest.so中的函數。

編寫的過程中，首先是編譯so文件，我沒有編寫makefile文件，而是參考的2裡面說的直接寫的gcc命令。

因為so文件裡面沒有main函數，所以是不可執行的，所以編譯的時候要加上-c，只生成目標文件。

『柒』 linux下c語言編譯so問題

不需要在自己的.so中調用別人的.so，只需要編譯自己的，編譯.so時，系統不會檢查未定義的函數。
直接在編譯自己的應用程序時鏈接這兩個.so就可以了！
gcc
-o
exec_file
mysrc.c
-L./
-lXXX
-L/usr/lib
-lmysqlclient

『捌』 如何查看linux下so庫里的符號

這個一般沒有要求。一般/lib /usr/lib 其它的要看具體情況。。。 如果你是自己編譯的應用程序，.so文件一般就在安裝目錄下的lib目錄中。

『玖』 so中導出符號與非導出符號怎麼查看

什麼是導出符號？

符號，是軟體鏈接過程的用到的術語。
我們編寫自己的軟體生成目標文件，通常情況下，只有自己的目標文件是不夠的。

比如我們用c++編寫的程序，必然要與C++的運行時庫鏈接在一起才能工作，否
則我們在代碼中使用的fopen或者std::cout之類的符號要到哪裡去找。

在鏈接的過程中，相當於是讓目標文件之間鑲嵌到一起，因此最重要的是找到精
確的接入點，這就是符號。
ldd命令:
ldd命令用於輸出可執行文件或者庫文件所依賴的共享庫列表。

nm命令:
nm命令用於輸出可執行文件或者庫文件的符號表。

readelf命令:
readelf命令用來顯示一個或者多個elf格式的目標文件的信息，可以通過它的選項來控制顯示哪些信息。
常用的選項：

-s --syms --symbols 顯示符號表段中的項（如果有的話）。
-d --dynamic 顯示動態段的信息。
1
2
1
2
ar命令:
ar命令可以用來創建、修改庫，也可以從庫中提出單個模塊。

objmp命令:
objmp命令是用查看目標文件或者可執行的目標文件的構成的gcc工具。
常用選項：

-T --dynamic-syms
1
1
顯示文件的動態符號表入口，僅僅對動態目標文件意義，比如某些共享庫。它顯示的信息類似於 nm -D|–dynamic 顯示的