mao
mao
对齐跟ndk有关，按谷歌文档升级了ndk不用管，它ndk默认就配置了。有问题不确定你可以用谷歌提供的脚本检测一下。 默认是把opcode随机化了，随机化后的指令数据在.so中，这些只需要静态反编译就能看到。如果对dalvik指令熟悉能找到规律，再分析vm就能还原随机化之前的指令重新构建dex就行。通过分析还原还算正常需要花时间的手段，就怕别人做出自动化脚本秒还原。动态分析工具frida、还有什么模拟执行的，其他就不清楚了。 最后就是加固范围，别把开源代码或者公开的sdk这些加固进去，这些公开的别人有你加固前的指令流，只需要简单对比随机化后的指令流就能找到opcode前后关系，根本不用分析vm
还有就是项目开源的，各种数据结构公开的，别人分析只需要导入这些数据结构就能比较容易分析编译后的代码。
对齐还有种情况就是so未压缩直接放入apk中，之前需要4k对齐，后面应该16k对齐，这个应该跟mmap系统调用有关。因为谷歌一直推荐aab，所以很少自己处理apk，也没测试apk的16k对齐，如果你遇到可以改一下apk里添加so这部分，加上对齐https://github.com/maoabc/nmmp/blob/e77de28e93de67007ee1b12f2cab4cecdacdccbf/nmm-protect/apkprotect/src/main/java/com/nmmedit/apkprotect/ApkProtect.java#L159
原本页是4K是2^12,4倍不就是2^14。编译参数生没生效可以看.cxx目录下build.ninja或者CMakeCache.txt。
这里有注释，如果不压缩现在需要16K对齐，当时写注释时是4K。https://github.com/maoabc/nmmp/blob/e77de28e93de67007ee1b12f2cab4cecdacdccbf/nmm-protect/apkprotect/src/main/java/com/nmmedit/apkprotect/ApkProtect.java#L159
改名 ，相关方法在nmm-protect/apkprotect/src/main/java/com/nmmedit/apkprotect/dex2c/DexConfig.java中。编译后so命名在BuildNativeLib.java中，缩减成一个so需要改CMake以及一些打包逻辑，这些在源码中都有注释。
你找一下打包获得so文件相关逻辑，以及查看ndk编译后是否正确生成文件。打包这部分逻辑简单，没有细致处理java代码跟cmake文件之间匹配问题，实际看报错改。
我仔细看了你日志，你没使用修改后的代码。需要更新vmsrc.zip,在mksrc目录下有独立的cmake文件跟vmsrc.zip生成脚本，这里修改后运行脚本就能更新vmsrc.zip。
这是安卓6的打包相关，代码中也有相关注释https://github.com/maoabc/nmmp/blob/7a5802081a97900955dca78689443436e1d694a1/nmm-protect/apkprotect/src/main/java/com/nmmedit/apkprotect/ApkProtect.java#L159