最近空闲时间搞了个小工具，9102 年逆向遇到的 multi-dex 越来越多，这个工具可以快速寻找到指定类所在的 dex，使用起来还是很方便的，比之前 grep 优雅多了。

前些天iPhoneSE正式退役，换了一台安卓机做主力机，三星 A60 元气版，刷微博的时候总是刷到非常低俗恶心的广告，网上经常看到去广告版的微博，全都是被加固过，怕被人暗算，不敢用，周末就自己搞了一下。之前微博平白无故把老子的号给封了，这是第二篇杠微博的文章。

额外多说几句，本文首发于2019.6.11，网上的去广告版有些被加固过，不知道作者有没有夹杂私货，我是不敢用，不建议使用。

最近帮他们查了一下线上出现了一个神奇的 bug，先加载A库再加载 B 库 和 先加载 B 库再加载 A 库，会有不一致的行为，看起来不一致的行为是环境变量引起的，仔细排查了发现是strtok引起的，运行时会偷偷抹掉原本的字符串，稍微科普一下。

最近在修花指令，脚本修复 ldr 的时候，如果是从 PC 开始计算，发现ida的表现和keystone 的表现是不一致的，查了很久没找到原因。直到后面翻arm手册，才发现一个小细节。

ndkr19默认用的是llvm-8.0.2，而今天才发布的llvm-8.0.0，之前是用7.0.0将就的，今天终于不用将就了，重新搭建了一下环境，对 ndk 使用 llvm 的理解更加深刻。本文介绍一下开发环境的搭建。

从小老师就教育我们，从c到exe经历了编译、连接，试卷上可能会出现；这么多年过去了，我也只知道这句话，最近有幸研究了一下 obj 的文件格式，对重定位有了一定的了解，写篇文章造福一下后人。

上篇介绍了一些基础知识，中篇详细讲一下其他的几个重定位项的格式。不全，但这些是我遇到的，对准确性负责。

前些天用 C 和 CPP 写了一个较为大型的项目（可能也没有那么大型），其中模块间有相互依赖关系，配环境时候卡了很久，主要是对 CMake 的多模块不熟悉，查资料、抄 llvm、瞎测搞出了一些规律，本文不保证很准确，选择性地阅读。

本文不保证很准确，请选择性地阅读。

最近要用 C 写一个比较大的项目，里面有非常多的模块，而且不容易整个项目一起跑，于是准备使用 CLion + Boost 来进行单元测试，搭建环境花了挺久的，记一下吧！

2018年11月13日，我长期使用的微博（@LeadroyaL 时日不多了）被炸号了，但里面有不少有价值的东西，于是想办法dump出来，新注册微博并且重新发布一遍，不到1000条微博吧，作为一个逆向选手，趁闲暇时间，使用脚本实现了一下。（本文计划写于12月，但拖到了春节前）

本来今天高高兴兴，准备写一点在 Mac 上运行的32位的可执行文件，编译半天老是报错，最后发现在SDK.10.14后32位的编译库被苹果移除了，记一下降级流程。

热烈庆祝blog断更，点开查看详情。

本文最初是在 RNG 失利的时候，以及后面 EDG 失利期间的一些想法，但一拖再拖，拖得iG都夺冠了，整个氛围都没了，哈哈；随便聊聊游戏，聊聊心情，好久没更这种稀奇古怪的文章了，与技术基本无关。其实我也是个情感细腻的人呀~

讲了那么多基础知识，现在我们实际操作一下，讲一下Pass的注册和简单用途，通俗易懂，看不懂只能说明你脑子不够用。

手头的整个项目差不多完结了，一个月左右的时间，对 llvm 的 pass 理解感觉还行，稍微总结一下从易到难的知识点吧。

最近开发参考了几个项目，仔细阅读源码的过程中，看到一些不大理解的地方。本来准备先写点基础知识的，看到hikari的作者在自己的 blog 里列举了其他人的 bug，作为后辈我也列举一下前人的 bug 好了。
本文包括一个ollvm的 bug，多个hikari的bug。（不代表 Armariris 没 bug，因为写的太挫了，没忍心看。。。）
2020年01月20日，又发现一个ollvm的 bug，然后发现hikari 作者在 2019.1.1已将其修复，点赞。

昨天搞交叉编译，中间其实有些没解决的问题都跳过了，最近有小伙伴联系我说加载不上的问题，符号各种找不到。刚好今天在做选型的工作，必须要面对这个问题了。

接触soot很久了，网上资料比较少，很多时候都是学术界在搞这个，工业界用它的人并不多，之前也有朋友想让我开这个系列，我觉得也有必要为后人留下一点有用的东西。开个系列吧，估计是个长期的栏目，试试水。

一、背景

Soot提供的功能有很多，使用时候配置的东西也很多，一时半会是讲不完的，我用它主要是从安全人员的角度出发，从逆向的角度，去审计一些jar和apk，从而节省人力成本。

类似的工具，见过的不多，能数出来的、公开的产品可能是FindSecBugs、FlowDroid、360写的火线、据传阿里聚安全提供的apk扫描，主要思路都一样，反汇编，构造调用图，制定规则。因为各个轮子提供的API都各种各样，所以我用Soot只是一个巧合，可能是因为Flanker前辈最开始用的是soot，后来工作时接的FlowDroid也是soot，现在接的扫描器前人也是用soot写的。也就这么一直用下去了，也推荐后人使用它，至少我觉得这玩意还是很好用的。

目前我在维护自家的产品，要做代码审计，8102年了，肯定要自动化的。学习了很多比较成熟的厂商的案例，例如BAT、数字提供的在线扫apk的业务，通过表现猜测应该是较为完备的正则（我不知道啊，我乱猜的），也有美丽联合SRC公开的扫源码工具，自己构造AST，自己写规则，支持很多语言；其他的不大记得，反正看的挺多的。

扫源码和扫jar包，二者是类似的，但又不完全一样。如果抛开解析文件，只考虑功能的话，扫源码时，依赖的第三方jar的扫不到的，有时候gradle插件搞得东西也扫不到。而扫jar包的话，又会丢失注释的信息，丢失文件的信息。可以说二者各有利弊吧，我偏向是扫jar包，毕竟我是个逆向工程师，不喜欢看源码。

话不多说，看下简单的用法吧，背景的话看其他人的文章去吧。

二、解析一系列class

首先，要我们要写一个待扫描的工程，我一般使用IntellijIdea，点击build，就会在看到了。

既然是8102年了，当然要用最好的构建工具gradle，我们创建一个gradle项目，引入soot的release包。

1
2
3
4
5
6
7

maven {
    url "https://soot-build.cs.uni-paderborn.de/nexus/repository/soot-release/"
}

dependencies {
    compile group: 'ca.mcgill.sable', name: 'soot', version: '3.1.0'
}

三、解析一个普通jar包

四、学习方法

emmmmm 搞了一天的移植和交叉编译，是真真的脑阔疼，本来想把这部分内容放在后面，但好不容易折腾出来，趁热写掉吧。不出意外的话，全网首发？突然感觉高大上了起来有木有！

上篇讲了单独编译一个 Pass，加载起来非常优雅，而ollvm等项目非常不优雅，为了方便开发，就把它们都移植了一下。工欲善其事必先利其器，突然发现这玩意支持 CLion，开发起来更加优雅了。