ndk-r23b版本 重编译后无法使用 #6
Comments
|
编译结果的格式是没问题的，我这里跟你是一样的，不影响使用： 至于你提到的错误我没有碰到过，也搞不明白为什么，或许可以试试不加Pass直接编译，看能否正常运行？ |
|
您好，经过排查，这个问题已经被解决。 因果分析
到这里为止，没有出现任何错误，接下来就是关键。
值得一提的是，macOS有项特殊功能，就是对于软连接的工具，他会在左下角做特殊标记，右点软连接的工具，也有一个选项会叫做
此时，我意识到，直接ftp下载下来的编译产物，其软连接功能被破坏，如果所料不错，这就是导致我和 #5 出现报错信息的根本原因，至于ndk-r22b不存在这个问题，是因为ndk-r22b本身在Linux下的file信息中，就没有软连接情况，直接ftp下载没有破坏其中关键文件。 于是，我将编译产物压缩包传入Windows，在Windows内解压，对比直接ftp下载的编译产物，发现了其中差别。
确认了问题所在后，我果断将压缩后再传输的编译产物，也就是保有软连接信息的编译产物，往ndk进行移植，果然，一切正常！ 这里顺便提一点，请最好不要直接把编译后的产物直接覆盖到ndk的toolchain，经过观察，lib64目录下，依然有一些相关依赖，是谷歌原生toolchain特有的，而我们自行编译的toolchain中，lib64是有部分内容缺失的，这缺失会在某种情况下，导致依赖缺失问题，就比如l 因此，在移植的过程中，我建议细致一点，秉持着 并且，在我将整体处理好后的ndk-r23b，进行压缩，分享给我的好友时，我发现了一个有趣的小现象。 当前PASS存在的问题
最后如上所述的两个bug，也不知道是我自身问题，还是大佬您的PASS有所疏忽。 另外，由于我的主环境是macOS，可是buily.py编译出来的只有Linux和Windows环境的toolchain。 |
|
经过对build.py的阅读，如需编译macOS版本的toolchain，无法在Linux环境下进行交叉编译。 更新补充，以供后人参考: 不过在实际移植PASS的过程中，我遇到了CryptoUtils.h中的报错。 Unknown endianness of the compilation platform, check this header aes_encrypt.h系MacBookPro设备构架与宏定义的冲突，修改宏定义即可解决问题。 后又尝试利用已经编译好了的，完整的ndk-toolchain-llvm环境。 -Xclang -load -Xclang path/to/passName.so经过测试，方案可行。 |
老师 可以分享下 -Xclang -load -Xclang path/to/passName.so 你改好的-Xclang -load -Xclang path/to/passName.so 的源码不哇 。 我以前是用的https://www.leadroyal.cn/p/1008/ 一样的方案。但是这个项目怎么改成 单独编译so的 无从下手呢 |
您好，很高兴可以为您服务。 事实上，在学习LLVM的Pass时，我也多次拜读LeadroyaL大佬的文章。 这里需要提醒的是，你应该在CMakeLists.txt中将 另外，建议初次尝试时，先不编译三款Pass，只编译一个简单的skeleton。 值得一提的是，我建议在CMakeLists.txt中，指定编译器为我们编译好后的ndk-toolchain中的clang/llvm。 最后，由于 由于我这里已经删除相关代码，所以抱歉，无法直接提供有效帮助。 |
感谢您的 回复。 我有点疑问，请您解答下。 您说是指向输出产物路径。 不对吧，
输出路径不应该在当前目录嘛 |
这个代码您说lib改为lib64么 但是 {LLVM_HOME}/lib64/cmake/llvm 这个路径不存在呢 |
对，我口中的输出产物路径，就是你说的那个意思，没表达清楚，抱歉了。 至于说修改
|
非常感谢 确实lib64我没配置对 |
|
fatal error: 'z3++.h' file not found ,请教下这个问题是怎么弄的了，添加cmake 中添加了还是不行。 |
我当时编译这份pass的时候，他还没有添加z3依赖，所以不存在这个问题。 另外，我试过多次，在ndk高版本中添加ollvm/Pluto后。 我最近有空的话，去看看最新的Pluto在ndk中表现形式如何。 |
See #12 |
hi，pro，在macOs上编译时遇到了一样的问题，macOs 12.1对应的xcode版本是xcode13，本地编译toolchain似乎会遇到xcode的兼容性问题，看到你这边回复时间是2个月前，那么你的mac版本大概率也是12+的，想问下你的系统版本和xcode版本是？ |
macOS:12.2.1 /Library/Developer/CommandLineTools/SDKs和你下载的CommandLineTools的SDK版本有关系，上述目录下有MacOs的SDK，你需要修改默认的SDK版本 sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk突然想起来了，xcode现在默认也会自带Command Line Tools的，你可能需要切换一下CommandLineTools |
牛的，感谢老哥，你这里发起的issue对我编译整个llvm有很大帮助~ |
|
感谢楼上大佬们分享经验，我这边尝试使用了NDK diff --git a/llvm/lib/Transforms/CMakeLists.txt b/llvm/lib/Transforms/CMakeLists.txt
index dda5f6de11e3..a001a7ca9b48 100644
--- a/llvm/lib/Transforms/CMakeLists.txt
+++ b/llvm/lib/Transforms/CMakeLists.txt
@@ -9,3 +9,4 @@ add_subdirectory(Hello)
add_subdirectory(ObjCARC)
add_subdirectory(Coroutines)
add_subdirectory(CFGuard)
+add_subdirectory(Obfuscation)
diff --git a/llvm/lib/Transforms/IPO/CMakeLists.txt b/llvm/lib/Transforms/IPO/CMakeLists.txt
index 2392b13b33a0..d4b4f5e6e555 100644
--- a/llvm/lib/Transforms/IPO/CMakeLists.txt
+++ b/llvm/lib/Transforms/IPO/CMakeLists.txt
@@ -71,4 +71,5 @@ add_llvm_component_library(LLVMipo
TransformUtils
Vectorize
Instrumentation
+ Obfuscation
)
diff --git a/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp b/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
index aa916345954d..e03b96a09afb 100644
--- a/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
+++ b/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
@@ -52,6 +52,8 @@
#include "llvm/Transforms/Vectorize/SLPVectorizer.h"
#include "llvm/Transforms/Vectorize/VectorCombine.h"
+#include "llvm/Transforms/Obfuscation/PassRegistry.h"
+
using namespace llvm;
namespace llvm {
@@ -656,6 +658,9 @@ void PassManagerBuilder::populateModulePassManager(
// is handled separately, so just check this is not the ThinLTO post-link.
bool DefaultOrPreLinkPipeline = !PerformThinLTO;
+ // Add custom obfuscation passes to PassManager
+ registerAllPasses(MPM);
+
MPM.add(createAnnotation2MetadataLegacyPass());
if (!PGOSampleUse.empty()) {此外还添加了 测试代码： #include <cstdio>
#include <cstring>
int main() {
char a[100];
memset(a, 0, 100);
scanf("%s", a);
return 0;
}编译命令： IDA结果（似乎就没有任何变化……）： logs with 不知道是哪个地方改漏了呢？ |
|
您好，因为最近比较忙，您在这个issues新提交的问题刚刚才发现，没能及时回复，非常抱歉。 背景我查了一下资料，您这份移植的pass实际上是没有任何问题的，这个现象主要是LLVM14的版本变化。 解决方案解决方案有两种
参考链接1: Google的一个讨论 |
|
chen@chen-virtual-machine:~/桌面/ploto/jni$ ndk-build1 你好 我使用的LLVM12版本 也/include/llvm/Transforms/Obfuscation /lib/Transforms/Obfuscation 和 /include/Eigen 全部添加 但是使用NDK-build 编译的话 加密效果挺好 但是-MBA -bcf -fla 目测无法生效 求解 还是说最新版本的pluto就是这样？ 我使用clang编译的话可以混淆全开 但是-sub失效 main菜单出现 还有稳定性不妥？ 请问我哪个方面出问题了 能否在ndk-build的情况下 混淆全开 ？ |
|
@SsageParuders 感谢大佬的耐心解答！ |
系Pluto本身存在某些问题，待修复 |
大佬，你好，lib64/cmake/llvm这个目录为啥在我下载的ndk里面没有，也是Mac平台，通过Android Studio下载的，我的路径是/Users/bdd/Library/Android/sdk/ndk/23.1.7779620/toolchains/llvm/prebuilt/darwin-x86_64/lib64，里面找不到你说的目录。
|
环境：macos 13.2 我修改了注册pass的文件： #include "include/PassRegistry.h"
#include "llvm/Support/CommandLine.h"
#include "include/BogusControlFlow.h"
#include "include/Flattening.h"
#include "include/FlatteningEnhanced.h"
#include "include/GlobalsEncryption.h"
#include "include/HelloWorld.h"
#include "include/MBAObfuscation.h"
#include "include/RandomControlFlow.h"
#include "include/SplitBasicBlock.h"
#include "include/Substitution.h"
#include "include/TrapAngr.h"
#include "include/VariableSubstitution.h"
#include "llvm/Transforms/Utils.h"
#include "include/GlobalsEncryption.h"
#include "llvm/Pass.h"
#include "llvm/IR/Function.h"
#include "llvm/Passes/PassBuilder.h"
#include "llvm/Passes/PassPlugin.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/IR/LegacyPassManager.h"
#include "llvm/Transforms/IPO/PassManagerBuilder.h"
using namespace llvm;
static cl::opt<bool>
RunHelloWorld("hlw", cl::init(false),
cl::desc("PlutoObfuscator - HelloWorld Pass"));
static cl::opt<bool>
RunFlattening("fla", cl::init(false),
cl::desc("PlutoObfuscator - Flattening Pass"));
static cl::opt<bool>
RunFlatteningEnhanced("fla-ex", cl::init(false),
cl::desc("PlutoObfuscator - FlatteningEnhanced"));
static cl::opt<bool>
RunBogusControlFlow("bcf", cl::init(false),
cl::desc("PlutoObfuscator - BogusControlFlow Pass"));
static cl::opt<bool>
RunSubstitution("sub", cl::init(false),
cl::desc("PlutoObfuscator - Substitution Pass"));
static cl::opt<bool>
RunGlobalsEncryption("gle", cl::init(false),
cl::desc("PlutoObfuscator - GlobalsEncryption Pass"));
static cl::opt<bool> RunVariableSubstitution(
"vsb", cl::init(false),
cl::desc("PlutoObfuscator - VariableSubstitution Pass"));
static cl::opt<bool>
RunRandomControlFlow("rcf", cl::init(false),
cl::desc("PlutoObfuscator - RandomControlFlow Pass"));
static cl::opt<bool> RunTrapAngr("trap-angr", cl::init(false),
cl::desc("PlutoObfuscator - TrapAngr Pass"));
static cl::opt<bool>
RunMBAObfuscation("mba", cl::init(false),
cl::desc("PlutoObfuscator - MBAObfuscation Pass"));
void llvm::registerModulePasses(legacy::PassManagerBase &MPM) {
MPM.add(createGlobalsEncryptionPass(RunGlobalsEncryption));
// MPM.add(createFlatteningEnhancedPass(RunFlatteningEnhanced));
}
void llvm::registerFunctionPasses(legacy::PassManagerBase &FPM) {
FPM.add(createHelloWorldPass(RunHelloWorld));
FPM.add(createSplitBasicBlockPass());
FPM.add(createLowerSwitchPass());
FPM.add(createFlatteningPass(RunFlattening));
FPM.add(craeteBogusControlFlow(RunBogusControlFlow));
FPM.add(createSubstitutionPass(RunSubstitution));
FPM.add(createVariableSubstitutionPass(RunVariableSubstitution));
// FPM.add(createRandomControlFlow(RunRandomControlFlow));
// FPM.add(createTrapAngrPass(RunTrapAngr));
FPM.add(createMBAObfuscationPass(RunMBAObfuscation));
// FPM.add(createMBAObfuscationPass(RunGlobalsEncryption));
}
static void registerPlutoModulePass(const PassManagerBuilder &,
legacy::PassManagerBase &PM) {
// PM.add(createFunctionWrapperPass(true)); /*broken*/
PM.add(createGlobalsEncryptionPass(RunGlobalsEncryption));
}
static void registerPlutoFunctionPass(const PassManagerBuilder &,
legacy::PassManagerBase &PM) {
PM.add(createHelloWorldPass(RunHelloWorld));
PM.add(createSplitBasicBlockPass());
PM.add(createLowerSwitchPass());
PM.add(createFlatteningPass(RunFlattening));
PM.add(craeteBogusControlFlow(RunBogusControlFlow));
PM.add(createSubstitutionPass(RunSubstitution));
PM.add(createVariableSubstitutionPass(RunVariableSubstitution));
// FPM.add(createRandomControlFlow(RunRandomControlFlow));
// FPM.add(createTrapAngrPass(RunTrapAngr));
PM.add(createMBAObfuscationPass(RunMBAObfuscation));
// FPM.add(createMBAObfuscationPass(RunGlobalsEncryption));
}
static RegisterStandardPasses
RegisterMyPass(PassManagerBuilder::EP_EnabledOnOptLevel0,
registerPlutoModulePass);
static RegisterStandardPasses
RegisterMyPass0(PassManagerBuilder::EP_OptimizerLast,
registerPlutoModulePass);
static RegisterStandardPasses
RegisterMyPass1(PassManagerBuilder::EP_EarlyAsPossible,
registerPlutoFunctionPass);然后集成到ndk中使用： 结果报错如下： |
您好～在发出这份issues之前，我已经仔细拜读了您在看雪论坛的文章，并且在服务器环境尝试复现，但是我遇到了一些问题，请允许我向您详细说明，希望能获得您的帮助，感谢～
复现环境
操作方式
curl https://storage.googleapis.com/git-repo-downloads/repo > /usr/bin/repo chmod a+x /usr/bin/reposudo apt-get install cmake bison find /usr/lib -name libffi.so* ln -s /usr/lib/x86_64-linux-gnu/libffi.so.7 /usr/lib/x86_64-linux-gnu/libffi.so.6这一步大佬在看雪论坛的文章中 漏掉了一些小步骤
不过无伤大雅 下面我简单对步骤进行概括
得益于大佬您的文章介绍，我的编译流程比较顺利，中间没有因为erro而产生中断
出现的问题
就好像 #5 遇到的问题一样
我使用的是ndk-build脚本， #5 貌似使用的是cmake，不过情况都是一样的
我们自己编译的 ndk-r23，在移植后出现一些报错情况，关键内容如下:
在参考了 #5 以后，我也查看了一下编译产物的格式
如果可以，我也想看一看大佬编译产物的格式，确认这之间是否存在差异
自己尝试过的研究
既然说按照大佬的文章操作，我这里出现了一点点问题，那么换一个角度。
我在macOS上按照常规方法操作，将大佬的项目clone下来以后，按照README的说法，使用cmake对大佬的项目进行构建。
即:添加PASS再编译llvm以后，将bin目录生成的工具替换到ndk中的toolchain里面去。
同时将编译后的lib64添加到ndk中toolchain的lib64里面去，同时修复头文件缺失问题以后。
关于llvm编译后生成lib64目录
会不会在编译进PASS之前，bin目录的文件格式正常？
抱着这种想法，我重开项目，并且在没有添加PASS情况下，编译出了out产物。
很遗憾的是，我发现，对于ndk-r23b来说，即使我们没有添加PASS，他的编译产物格式依然如下:
也就是说，我们自己编译的ndk-r23b的toolchain，就是和谷歌官方不一样的文件格式，即使没有添加进PASS
我的第二个分析，似乎是在说明，我们自己编译的toolchain是错误的，无法使用，但是谷歌官方的教程:Instructions to rebuild a particular toolchain release似乎也就是这样，我们并没有遗漏掉什么。
不甘心放弃，于是，我对老版本的
ndk-22.1.7171670进行编译，发现了有意思的事情。对老版本
ndk-22.1.7171670进行编译以后，我对编译产物进行file发现:按照这种方式，编译的老版本ndk居然是正常的！没有出现所谓的
symbolic link to clang.exe！果断添加PASS重新编译 --> 再次file -- > 文件格式正常！ --> 移植ndk -- > 测试
ndk-build让人欣喜的事情来了，在file文件格式全部正常的情况下，使用
ndk-build，编译过程没有任何问题！没有报错！到这里，我们至少确认了一件事，那就是，之前的报错就是因为file文件格式不正确导致的
于是，添加混淆参数，进行混淆编译 --> 未混淆编译产物5kb，混淆后编译产物23kb
貌似成功了？抱着激动的心情，打开ida，分别对比未混淆和混淆后，让我失望的事情来了，混淆前后在ida中的表现是一样的。
也就是说，除了文件体积的变化外，文件并没有得到更安全的保护。
转念一想，大佬您的这款PASS是基于llvm-12编写的，也许他对老版本的ndk所采用的llvm-11是不生效的。
于是，我换用了heroims大佬的PASS，移植结束以后
file文件格式依然全部正常，编译流程没有erro <-- 这里再次证明，ndk-r23b的toolchain之所以报错，就是因为file格式问题
很遗憾的是，虽然编译确实没有报错，混淆前后文件大小确实也产生变化，但是，使用ida进行查看的时候，混淆依然没有生效。
最后
至此，我已经无计可施，本以为是谷歌ndk在r23版本存在某种问题。
但是转念一想，大佬您已经在和我相同的ndk版本下，实测成功，并且上传了examples。
我认为，是我在某些步骤上的操作有所遗漏或者错误。
希望大佬能够分析一下我的流程有哪些地方存在问题，不胜感激～
The text was updated successfully, but these errors were encountered: