「llvm混淆java」svm混淆矩阵
今天给各位分享llvm混淆java的知识，其中也会对svm混淆矩阵进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
破解“贪吃蛇大作战”的签名信息服务端验证机制
Android安全交流群：478084054
第一次尝试做一些简单的逆向分析，内容比较简单，高手们莫见笑。
“贪吃蛇大作战”这个游戏最近玩的人挺多，我也在玩。5分钟限时版，最好成绩也就3000多。
我分析的版本是v2.0.1：
经过修改，玩了一把5分钟限时赛：长度69224，击杀1456。
将原包重新签名，安装到手机上，一直提示网络无法连接，原包没有问题。这里很明显是将签名信息上传到了服务器端，在服务器端进行了签名校验，校验失败则断开与此客户端的连接。
写一个小程序进行注入（利用ptrace），对一些关键函数进行hook，比如libc.so的fopen函数。
在hook_entry中，对libc.so的fopen作inline hook，监测一下程序都打开了哪些文件。
我本意是想看看，它是否会在运行时直接去读取apk包，自己解析其中的与签名信息相关的文件。结果是没有，但发现它一直在读cmdline文件，猜测可能是在作反调试（未去证实，因为后面的分析和修改并未借助动态调试）。
这里说一下，假设它是自己打开apk文件，从中读取与签名相关的文件，提取签名信息。那么我们可以在某个位置放一个原包，然后hook关键函数，将其读取的文件路径修改为原包位置，即可绕过这种签名校验。
举一反三，这种方式也可以绕过大部分反调试措施。比如常见的检测traceid是否非0的反调方式，我们可以hook fopen/open，然后在它要读取该文件之前先读取该文件，并将其traceid重新修改为0，并将其写到sd卡某个目录下，再将打开文件的位置重定向到该文件，那它就检测不到ptrace了。
还有一些anti-hook机制，大概思路是校验本地文件的数据和加载到内存中的数据是否一致。通过类似方式也可以轻松绕过，一句话，因为我们可以先注入，先完成hook，先做各种Anti-anti。
因为它没有在运行时直接fopen/open apk文件，所以考虑应该还是通过调用系统api读取的签名信息。
将原包解压，发现只有两个so，其中libweibosdkcore.so看起来是微博sdk。将另一个libJustATest.so拖到IDA中看一下，没加壳，并且只看到xxx_getATestString这么一个有用的导出函数，从名字上看，很可能就是获取上传到服务器端的校验字符串。
跳转到该方法，f5，进行一些简单的参数名和参数类型以及函数调用的修正。发现它里面进行了一大通的各种字符串的拼接，最后将该字符串返回（根据之前的猜测，该字符串可能就是发送给服务端的校验字符串）。
发现里面调用了java层com.wepie.snake.helper.update.QiniuEtagUtil类的getSignString函数。用AndroidKiller反编译一下APK包（该APK没有作任何防反编译的措施，dex也没加壳），找到getSignString函数。
没错，就是在这里调用系统API获取的签名（其实，我们可以一开始就全局搜索某些关键API，来定位获取签名的位置）。
借助xposed hook getSignString方法，将正确的签名字符串通过日志打印出来。
正确的签名字符串是（作了MD5计算后的结果）：678a930b9829b54a44f92a840916f7d1
剩下的工作就简单了，修改smali，将getSignString的返回结果固定为上面的这个正确的签名字符串。
重新编译、打包、签名、安装，发现用新签名的APK包已经可以正常使用了。
其实破解签名校验之后，基本上是想改什么改什么了，因为原包没有做任何的加壳和混淆的工作。比如，看看下面这个类，应该知道怎么下手了吧（修改的时候注意一下，它里面好像有一些简单的数据合理性校验之类的东西，我没细看）。
最后，大家学习就好，别做什么破坏，也别释放出什么破解版之类的东西。初次尝试一点简单的逆向分析，大牛们绕过吧。
附：我认为现在so端最有用的加固措施是llvm混淆，因为普通加解密壳从机制上来说比较容易脱掉。dex端已经出现了解释器壳（伪vmp），纯粹的类抽取的话，通过自定义rom（定制dalvik或art，遍历class_def加载并初始化，然后dump…）也可以脱掉大部分的。
如何用llvm-obfuscator混淆 js
LLVM是什么？
（1）LLVM是lowlevel virtual machine的简称，是一个编译器框架。苹果公司的Xcode 4.0之后用的都是LLVM编译器。
（2）LLVM 诞生于2003.10伊利诺伊大学香槟分校，创始人ChrisLattner，现任苹果公司『开发者工具』部门的主管。
二、 LLVM-Obfuscator 是什么?
（1）LLVM-Obfuscator 是瑞士西北应用科技大学安全实验室针对LLVM编译组件开发的代码混淆工具，该工具完全开源，目的是为了增加逆向工程的难度，保证代码的安全性。
（2）Obfuscator-llvm最新版本集成了LLVM-3.4编译器，并且兼容LLVM支持的所有语言（C,C++, Objective-C, Ada and Fortran）和平台(x86, x86-64, PowerPC, PowerPC-64,ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ,and XCore)。
纯手打，望采纳！
如何用llvm-obfuscator混淆代码
混淆方法一: InstructionsSubstitution
[html] view plain copy
-mllvm -sub: activate instructions substitution
-mllvm -funcSUB="func1,func2,func3": if instructions substitution is activated, apply it only on functions func1, func2 and func3
-mllvm -perSUB=20: if instructions substitution is activated, apply it with a probability of 20% on each function
2. 混淆方法二: BogusControlFlow
[html] view plain copy
-mllvm -bcf: activates the bogus control flow pass
-mllvm -funcBCF="func1,func2,func3": if the pass is activated, applies it only on functions func1, func2, func3
-mllvm -perBCF=20: if the pass is activated, applies it on all functions with a probability of 20%. Default: 100
-mllvm -boguscf-loop=3: if the pass is activated, applies it 3 times on a function. Default: 1
-mllvm -boguscf-prob=40: if the pass is activated, a basic bloc will be obfuscated with a probability of 40%. Default: 30
3. 混淆方法三: ControlFlow Flattening
[html] view plain copy
-mllvm -fla: activates control flow flattening
-mllvm -funcFLA="func1,func2,func3": if control flow flattening is activated, apply it only on functions func1, func2 and func3
-mllvm -perFLA=20: if control flow flattening is activated, apply it with a probability of 20% on each function
4. 如何用开源 source code 编译出混淆器O-LLVM ？
[cpp] view plain copy
$ git clone -b llvm-3.5
$ mkdir build
$ cd build
$ cmake -DCMAKE_BUILD_TYPE:String=Release ../obfuscator/
$ make -j5
编译后的结果只有bin 和 lib 是有用的，其余的都可以删除：
llvm混淆java的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于svm混淆矩阵、llvm混淆java的信息别忘了在本站进行查找喔。