A. android中的armeabi、armeabi-v7a、arm64-v8a及x86的詳解
一. lib和libs
放在lib中的是被reference的，放在libs中的是被include的。
放在libs中的文件會自動被編輯器所include。所以不要把API放到libs里去。
lib的內容是不會被打包到APK中，libs中的內容是會被打包進APK中
二. .so庫
NDK編譯出來的動態鏈接庫。
一些重要的加密演算法或者核心協議一般都用c寫然後給java調用。這樣可以避免反編譯後查看到應用的源碼。
三. .so庫該如何存放
放置 .so 文件的正確姿勢其實就兩句話：
• 為了減小 apk 體積，只保留 armeabi 和 armeabi-v7a 兩個文件夾，並保證這兩個文件夾中 .so 數量一致
• 對只提供 armeabi 版本的第三方 .so，原樣復制一份到 armeabi-v7a 文件夾
存放so的規則：
你應該盡可能的提供專為每個ABI優化過的.so文件，但要麼全部支持，要麼都不支持：你不應該混合著使用。你應該為每個ABI目錄提供對應的.so文件。
四. libs下armeabi等的作用是什麼
存放.so庫，主要針對不同的設備兼容，也可以說是專門針對不同Android手機下CPU架構的兼容。
Android 設備的CPU類型(通常稱為」ABIs」)
早期的Android系統幾乎只支持ARMv5的CPU架構，後面發展到支持七種不同的CPU架構：ARMv5，ARMv7 (從2010年起)，x86 (從2011年起)，MIPS (從2012年起)，ARMv8，MIPS64和x86_64 (從2014年起)，每一種都關聯著一個相應的ABI。
應用程序二進制介面（Application Binary Interface）定義了二進制文件（尤其是.so文件）如何運行在相應的系統平台上，從使用的指令集，內存對齊到可用的系統函數庫。在Android 系統上，每一個CPU架構對應一個ABI：armeabi，armeabi-v7a，x86，mips，arm64- v8a，mips64，x86_64。
armeabi-v7a: 第7代及以上的 ARM 處理器。2011年以後生產的大部分Android設備都使用它.
arm64-v8a: 第8代、64位ARM處理器，很少設備，三星 Galaxy S6是其中之一。
armeabi: 第5代、第6代的ARM處理器，早期的手機用的比較多。
x86: 平板、模擬器用得比較多。
x86_64: 64位的平板。
如果項目只包含了 armeabi，那麼在所有Android設備都可以運行；
如果項目只包含了 armeabi-v7a，除armeabi架構的設備外都可以運行；
如果項目只包含了 x86，那麼armeabi架構和armeabi-v7a的Android設備是無法運行的； 如果同時包含了 armeabi， armeabi-v7a和x86，所有設備都可以運行，程序在運行的時候去載入不同平台對應的so，這是較為完美的一種解決方案，同時也會導致包變大。
最後，如果我們只想支持armeabi-v7a，那麼需要在gradle中配置
因為默認情況下，打包後會自動生成armeabi 到 x86的所有文件夾。這就有可能導致一些x86的設備因為在x86文件夾下找不到so文件而崩潰。
B. linux 下如何將動態鏈接庫.so進行反編譯後,換編譯器重新編譯
程序能不能正常運行取決於程序和動態庫之間的ABI是否兼容。只要ABI兼容那麼編譯器版本就沒有影響。高版本的編譯器同樣可以使用低版本的ABI來生成目標代碼，但這個問題要具體分析。你解決問題的思路完全不對。
C. android開發libs下的armeabi、armeabi-v7a、arm64-v8a等及導入so所踩過的坑
項目中需要使用第三方的sdk，集成完成後在小米4設備上能夠正常運行，但在三星S6上面運行的時候crash，日誌如下：
Android 設備的CPU類型(通常稱為」ABIs」)
早期的Android系統幾乎只支持ARMv5的CPU架構，現在可以支持七種不同的CPU架構：ARMv5，ARMv7 (從2010年起)，x86 (從2011年起)，MIPS (從2012年起)，ARMv8，MIPS64和x86_64 (從2014年起)，每一種都關聯著一個相應的ABI。 應用程序二進制介面定義了二進制文件（尤其是.so文件）如何運行在相應的系統平台上，從使用的指令集，內存對齊到可用的系統函數庫。在Android 系統上，每一個CPU架構對應一個ABI：armeabi，armeabi-v7a，x86，mips，arm64- v8a，mips64，x86_64。
各版本分析如下：
mips / mips64: 極少用於手機可以忽略
x86 / x86_64: x86 架構的手機都會包含由 Intel 提供的稱為 Houdini 的指令集動態轉碼工具，實現 對 arm .so 的兼容，再考慮 x86 1% 以下的市場佔有率，x86 相關的兩個 .so 也是可以忽略的
armeabi: ARM v5 這是相當老舊的一個版本，缺少對浮點數計算的硬體支持，在需要大量計算時有性能瓶頸
armeabi-v7a: ARM v7 目前主流版本
arm64-v8a: 64位支持
所謂的ARMv8架構，就是在MIPS64架構上增加了ARMv7架構中已經擁有的的TrustZone技術、虛擬化技術及NEON advanced SIMD技術等特性，研發成的。
PS:在2011年11月，ARM公司發布了新一代處理器64位架構ARMv8的部分技術細節（也就是我們常說的Cortex-A57A53），代表著未來移動處理器邁入64位行列。我們得明確一點，ARM公司自己本身並沒有64位晶元設計技術，他是通過了收購MIPS64處理器架構的部分技術使用權，再結合ARM的一些特性設計出來的。也就是說：MIPS、ARM、X86三大架構中，唯一沒有64位技術的ARM，通過收購MIPS的形式得到了64位。
介紹參考資源如下：
http://www.jianshu.com/p/34ee91ae5547
寶劍鋒從磨礪出，梅花香自苦寒來
D. 求助：arm-linux-gcc4.4.3編譯問題：libstdc++.so.6
so。你需要確認你的編譯環境中包含相關arm的libstdc++，應該是你本地缺少libstdc++，這個so庫是arm架構的，不是指本地的x86的.6的庫文件.so你使用交叉編譯工具，可以看看makefile中如何指定的.6庫
E. 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
Demo
鏈接： https://pan..com/s/1vKC1SevvHfeI7f0d2c6IqQ
找到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!