oaciaのBbBlog~

dexguard反混淆-unidbg去除BR寄存器跳转

2024-09-08T10:14:21.000Z

# 前言

这几天一直在和 so 层的强混淆对抗，前几天有朋友问我有没有试过 IL 层面的反混淆，正好这个月遇到了一个 dexguard 的强混淆样本，所以就想试试 IL 层面的反混淆，ida 中最为出名的应该就是 ida microcode 了，但即使在两年前曾经为了研究区块链合约的字节码而学习过李樾和谭添老师的静态分析，然而并没有什么太大的进展… 果然 static analysis 是一门大学问呐 ref Hex-Rays Microcode API vs. Obfuscating Compiler

之后又去试了试 Binary Ninja , 现在它的 medium IL 从编译器层面已经优化已经棒了，甚至有些 br 跳转的地址都可以自动在 IL 中体现出来

不过还是没有办法直接去操作 IL, 所以最终回归到了 aarch64 汇编层面的 patch, 只是倘若遇到不透明谓词和指令替换的话，bninja 就没有办法自动计算出来这个这个自动计算的地址了

所以为了可以完整的去除 br 寄存器跳转，还得是 unidbg 呀！

关于 unidbg 的基本用法，可以参考 unidbg 学习笔记

一篇非常好的文章 [原创] 记一次基于 unidbg 模拟执行的去除 ollvm 混淆

# unidug 环境搭建

首先在 unidbg-android/src/test/java 新建一个我们自己的 package 和类，然后初始化一下

	antibr(){
	instructions = new ArrayDeque<>();
	patch_list = new ArrayList<>();
	emulator = AndroidEmulatorBuilder.for64Bit()
	.setProcessName("com.test.antibr")
	//.addBackendFactory(new Unicorn2Factory(true))
	.build(); // 创建模拟器实例，要模拟 32 位或者 64 位，在这里区分
	final Memory memory = emulator.getMemory(); // 模拟器的内存操作接口
	memory.setLibraryResolver(new AndroidResolver(23)); // 设置系统类库解析

	vm = emulator.createDalvikVM(); // 创建 Android 虚拟机
	vm.setVerbose(false); // 设置是否打印 Jni 调用细节
	DalvikModule dm = vm.loadLibrary(new File("unidbg-android/src/test/resources/test/libbdae.so"), false); // 加载 libttEncrypt.so 到 unicorn 虚拟内存，加载成功以后会默认调用 init_array 等函数

	module = dm.getModule();
	code_walk();
	dm.callJNI_OnLoad(emulator); // 手动执行 JNI_OnLoad 函数
	doPatch();
	}

接下来，我们将对每一条运行过的指令利用 unidbg 的 unicorn 引擎进行 hook, 基本用法如下

	public void code_walk()
	{
	emulator.getBackend().hook_add_new(new CodeHook() {
	@Override
	public void hook(Backend backend, long address, int size, Object user) {
	Capstone capstone = new Capstone(Capstone.CS_ARCH_ARM64,Capstone.CS_MODE_ARM);
	byte[] bytes = emulator.getBackend().mem_read(address, 4);
	Instruction[] disasm = capstone.disasm(bytes, 0);
	System.out.printf("%x:%s %s %s\n",address-module.base ,disasm[0].getMnemonic(),disasm[0].getOpStr(),disasm[0].getOperands());
	}

	@Override
	public void onAttach(UnHook unHook) {

	}

	@Override
	public void detach() {

	}
	}, module.base, module.base+module.size, null);
	}

# 寄存器跳转基本类型

接下来我们考虑寄存器跳转混淆的基本类型，总体可以分为直接跳转和分支跳转这两种类型

# 直接跳转

对于直接跳转来说，我们只需要在 BR 或 BLR 跳转的地方直接 patch 这一行汇编即可完成去混淆

BR 直接跳转

BLR 直接跳转

# 分支跳转

一个标准的分支跳转由下面的四行指令构成，依次为比较 ( CMP 或 TST ), 条件赋值 ( CSEL ), 地址取值 ( LDR ), 跳转 ( BR )

假设条件 EQ 满足时赋值为 [X12] , 所跳转的地址为 loc_a ; 条件 EQ 不满足时赋值为 [X9] , 所跳转的地址为 loc_b

由此我们可以将一个分支跳转还原成如下的指令:

	NOP #原 CMP 或 TST 需要被 NOP
	NOP #原 CSEL 需要被 NOP
	B.EQ loc_a #LDR 指令 patch 为 B.EQ 条件满足时的地址
	B loc_b #BR 指令 patch 为 B 条件不满足时跳转的地址

这样即可完成一次分支跳转的修复

当然我们需要考虑到一些特殊的情况，例如下图所示

在 LDR 指令和 BR 指令间包含了其他的运行相关的指令，此时假如我们将 LDR 指令 patch 为分支跳转，将会导致参数的丢失，所以我们需要进行指令移动，将 LDR 指令下移到 BR 指令的上一行，同时将 BR 和 LDR 之间的指令上移一行

这一种情况经过修复之后的汇编应如下所示

	NOP
	NOP
	MOV W19, #0x5D1D8BC9
	MOV X20, XZR
	B.NE loc_a
	B loc_b

# unidbg 反混淆

要想对寄存器跳转去混淆，我们首先需要去辩别这个 BR 跳转究竟有没有分支，即判断之前运行过的指令中有没有 CSEL 相关的指令，为了实现指令和寄存器的回溯，我们必须要去维护一个数据结构去保存他们，倘若使用 Stack 这种后进先出的模式，那么随着指令的不断运行，这个 stack 会变地越来越大，这其实是我们不希望看到的。而 Queue 这种先进先出的模式，确实可以让我们维护一个最近运行的十条指令的循环队列，但是这也会带来一个问题就是当我们想进行指令回溯的时候，获取到的第一条指令并非 BR 跳转指令的上一条指令，所以这里的数据结构我们可以选择 Deque 这种双端队列的结构，来方便的去实现 添加元素到队尾 ， 取队尾元素并删除 以及当队列长度达到设定的阈值时，进行 取队首元素并删除 的操作

首先定义一个指令类 InsAndCtx ，在这个类定义了每运行一条指令后，需要记录的地址，汇编以及寄存器

	// 保存指令和寄存器环境类：
	class InsAndCtx
	{
	long addr;
	Instruction ins;
	List<Number> regs;

	public long getAddr() {
	return addr;
	}

	public void setAddr(long addr) {
	this.addr = addr;
	}

	public void setIns(Instruction ins) {
	this.ins = ins;
	}

	public Instruction getIns() {
	return ins;
	}

	public void setRegs(List<Number> regs) {
	this.regs = regs;
	}

	public List<Number> getRegs() {
	return regs;
	}
	}

随后在 code_walk 中维护一个大小为 10 的循环双端队列

	public void code_walk()
	{
	emulator.getBackend().hook_add_new(new CodeHook() {
	@Override
	public void hook(Backend backend, long address, int size, Object user) {
	Capstone capstone = new Capstone(Capstone.CS_ARCH_ARM64,Capstone.CS_MODE_ARM);
	byte[] bytes = emulator.getBackend().mem_read(address, 4);
	Instruction[] disasm = capstone.disasm(bytes, 0);
	InsAndCtx iac = new InsAndCtx();
	iac.setIns(disasm[0]);
	iac.setRegs(saveRegs(backend));
	iac.setAddr(address);
	// 可以当作一个队列去理解，当队列的大小超过 10 时，就删除队首的元素
	if(instructions.size()>10){
	instructions.removeFirst();
	}
	// 向队列的队尾添加元素
	instructions.addLast(iac);
	}

	@Override
	public void onAttach(UnHook unHook) {
	}

	@Override
	public void detach() {
	}
	}, module.base, module.base+module.size, null);
	}

而在 br 寄存器跳转去混淆之前，因为所有的 patch 都是在 unidbg 运行结束后进行 patch 的，所以我们需要定义一个 patch 类，用来记录 patch 相关的信息

	private List<PatchBR> patch_list;

	//patch 类
	class PatchIns{
	long addr;//patch 地址
	String ins;//patch 的指令

	public long getAddr() {
	return addr;
	}

	public void setAddr(long addr) {
	this.addr = addr;
	}

	public String getIns() {
	return ins;
	}

	public void setIns(String ins) {
	this.ins = ins;
	}
	}

	enum br_type
	{
	direct_br,direct_blr,indirect_br;
	}
	enum error_type{
	ok,
	conflict_br_type,
	conflict_b_jump_address
	}

	class PatchBR{
	List<PatchIns> patchs;
	List<Long> br_jump_to;
	long br_addr;
	br_type type;
	error_type errorno;
	String error_info;
	PatchBR() {
	patchs = new ArrayList<>();
	br_jump_to = new ArrayList<>();
	errorno = error_type.ok;
	}
	}

之后便是寄存器跳转核心识别代码的编写了，主要就是将前面找出的基本类型所对应的情况一一判断过去

而 dexguard 的 BLR 寄存器跳转，是会跳转到外部的导入函数中去执行的，对于这种情况跳转，待跳转的地址在混淆库的外部，符号是不可知的，具体形如这种样子

在这种情况下，我们可以使用 unidbg 提供的 findClosestSymbolByAddress 函数来找到对应的符号

unidbg自实现地址反推符号 findHookedSymbol

自实现地址反推符号被确认其实是非必要的，此处仅作记录用

首先在 unidbg-api/src/main/java/com/github/unidbg/spi/ 下增加一个 HookedSymbol 类

	package com.github.unidbg.spi;

	public class HookedSymbol {
	private final long address;
	private final String library;
	private final String symbol;

	public HookedSymbol(long address, String library, String symbol) {
	this.address = address;
	this.library = library;
	this.symbol = symbol;
	}

	public long getAddress() {
	return address;
	}

	public String getLibrary() {
	return library;
	}

	public String getSymbol() {
	return symbol;
	}
	}

随后修改 unidbg-api/src/main/java/com/github/unidbg/spi/AbstractLoader.java , 修改的部分如图所示

	protected final Map<Long, HookedSymbol> hookedSymbolMap = new HashMap<>();
	public final HookedSymbol findHookedSymbol(long address) {
	return hookedSymbolMap.get(address);
	}
	@Override
	public final void addHookListener(HookListener listener) {
	//hookListeners.add(listener);
	hookListeners.add((svcMemory, libraryName, symbolName, old) -> {
	long addr = listener.hook(svcMemory, libraryName, symbolName, old);
	if (addr > 0) {
	hookedSymbolMap.put(addr, new HookedSymbol(addr, libraryName, symbolName));
	}
	return addr;
	});
	}

之后在 unidbg-api/src/main/java/com/github/unidbg/spi/Loader.java 中加上先前添加的函数 findHookedSymbol

HookedSymbol findHookedSymbol(long address);

随后来到 unidbg-android/src/main/java/com/github/unidbg/linux/LinuxModule.java , 在此处重载 findClosestSymbolByAddress 函数

	@Override
	public Symbol findClosestSymbolByAddress(long address, boolean fast) {
	class Mutable {
	Symbol bestSymbol = null;
	}
	Mutable mutable = new Mutable();
	symbols.forEach((name, value) -> {
	if (value.peer > address) return;
	if (mutable.bestSymbol == null \|\| mutable.bestSymbol.getAddress() < value.peer) {
	mutable.bestSymbol = new VirtualSymbol(name, this, value.peer);
	}
	});
	return mutable.bestSymbol;
	}

通过地址寻找符号的代码如下，但是需要注意的是，其实 JNI 函数的调用也会用到 BLR 寄存器跳转，所以说如果我们发现一个非法地址无法找到对应的符号，那么保留这个 BLR 的寄存器跳转就可以啦

	if(pb.br_jump_to.get(0)<0\|\|pb.br_jump_to.get(0)>module.size){
	long debug_addr = getRegValue(blr.ins.getOpStr(),blr.getRegs()).longValue();
	Module module2 = emulator.getMemory().findModuleByAddress(debug_addr);
	Symbol symbol = module2 == null ? null : module2.findClosestSymbolByAddress(debug_addr, true);
	String moduleName = null;
	if (module2 != null) {
	moduleName = module2.name;
	}
	String symbolName = null;
	if (symbol != null) {
	symbolName = symbol.getName();
	}
	long symbolAddr = 0;
	if (symbol != null) {
	symbolAddr = symbol.getAddress();
	System.out.println("[debug] try to resolve symbol: "+moduleName+","+symbolName+","+symbolAddr);
	}

	}

所以说最终的 br 反混淆代码如下～

	package com.test.antibr;

	import capstone.Capstone;
	import capstone.api.Instruction;
	import com.alibaba.fastjson.util.IOUtils;
	import com.github.unidbg.AndroidEmulator;
	import com.github.unidbg.Module;
	import com.github.unidbg.Symbol;
	import com.github.unidbg.arm.backend.Backend;
	import com.github.unidbg.arm.backend.CodeHook;
	import com.github.unidbg.arm.backend.UnHook;
	import com.github.unidbg.arm.backend.Unicorn2Factory;
	import com.github.unidbg.linux.android.AndroidEmulatorBuilder;
	import com.github.unidbg.linux.android.AndroidResolver;
	import com.github.unidbg.linux.android.dvm.DalvikModule;
	import com.github.unidbg.linux.android.dvm.VM;
	import com.github.unidbg.memory.Memory;
	import com.github.unidbg.spi.HookedSymbol;
	import com.github.unidbg.spi.LibraryFile;
	import com.github.unidbg.utils.Inspector;
	import keystone.Keystone;
	import keystone.KeystoneArchitecture;
	import keystone.KeystoneEncoded;
	import keystone.KeystoneMode;
	import unicorn.Arm64Const;

	import java.io.File;
	import java.io.FileInputStream;
	import java.io.FileOutputStream;
	import java.util.*;


	public class antibr {
	private final AndroidEmulator emulator;
	private final VM vm;
	private final Module module;
	private Deque<InsAndCtx> instructions;
	private List<PatchBR> patch_list;
	private static final String inName = "D:\\work\\test\\aiti-br\\libbdae.so";
	private static final String outName = "D:\\work\\test\\aiti-br\\libbdae_fix.so";

	// 保存指令和寄存器环境类：
	class InsAndCtx
	{
	long addr;
	Instruction ins;
	List<Number> regs;

	public long getAddr() {
	return addr;
	}

	public void setAddr(long addr) {
	this.addr = addr;
	}

	public void setIns(Instruction ins) {
	this.ins = ins;
	}

	public Instruction getIns() {
	return ins;
	}

	public void setRegs(List<Number> regs) {
	this.regs = regs;
	}

	public List<Number> getRegs() {
	return regs;
	}
	}

	//patch 类
	class PatchIns{
	long addr;//patch 地址
	String ins;//patch 的指令

	public long getAddr() {
	return addr;
	}

	public void setAddr(long addr) {
	this.addr = addr;
	}

	public String getIns() {
	return ins;
	}

	public void setIns(String ins) {
	this.ins = ins;
	}
	}

	enum br_type
	{
	direct_br,direct_blr,indirect_br;
	}
	enum error_type{
	ok,
	conflict_br_type,
	conflict_b_jump_address
	}

	class PatchBR{
	List<PatchIns> patchs;
	List<Long> br_jump_to;
	long br_addr;
	br_type type;
	error_type errorno;
	String error_info;
	PatchBR() {
	patchs = new ArrayList<>();
	br_jump_to = new ArrayList<>();
	errorno = error_type.ok;
	}
	}

	public List<Number> saveRegs(Backend bk)
	{
	List<Number> nb = new ArrayList<>();
	for(int i=0;i<29;i++)
	{
	nb.add(bk.reg_read(i+ Arm64Const.UC_ARM64_REG_X0));
	}
	nb.add(bk.reg_read(Arm64Const.UC_ARM64_REG_FP));
	nb.add(bk.reg_read(Arm64Const.UC_ARM64_REG_LR));
	return nb;
	}

	public Number getRegValue(String reg,List<Number> regsaved)
	{
	if(reg.equals("xzr"))
	{
	return 0;
	}
	return regsaved.get(Integer.parseInt(reg.substring(1)));
	}

	public boolean validBRPatch(PatchBR pb){
	for (PatchBR _pb : patch_list) {
	if (pb.br_addr == _pb.br_addr) {
	if(pb.type!=_pb.type){
	pb.errorno = error_type.conflict_br_type;
	pb.error_info = "[error]confict br jump type at 0x"+Integer.toHexString((int) pb.br_addr)+"type->"+pb.type+" "+_pb.type;
	}
	else if(pb.br_jump_to!=_pb.br_jump_to){
	pb.errorno = error_type.conflict_b_jump_address;
	pb.error_info = "[error]confict b jump address at 0x"+Integer.toHexString((int) pb.br_addr)+"addr->"+pb.br_jump_to.toString()+" "+_pb.br_jump_to.toString();
	}
	return false;
	}
	}
	return true;
	}

	public long readInt64(Backend bk,long addr)
	{
	byte[] bytes = bk.mem_read(addr, 8);
	long res = 0;
	for (int i=0;i<bytes.length;i++)
	{
	res =((bytes[i]&0xffL) << (8*i)) + res;
	}
	return res;
	}

	antibr(){
	instructions = new ArrayDeque<>();
	patch_list = new ArrayList<>();
	emulator = AndroidEmulatorBuilder.for64Bit()
	.setProcessName("com.test.antibr")
	//.addBackendFactory(new Unicorn2Factory(true))
	.build(); // 创建模拟器实例，要模拟 32 位或者 64 位，在这里区分
	final Memory memory = emulator.getMemory(); // 模拟器的内存操作接口
	memory.setLibraryResolver(new AndroidResolver(23)); // 设置系统类库解析

	vm = emulator.createDalvikVM(); // 创建 Android 虚拟机
	vm.setVerbose(false); // 设置是否打印 Jni 调用细节
	DalvikModule dm = vm.loadLibrary(new File("unidbg-android/src/test/resources/test/libbdae.so"), false); // 加载 libttEncrypt.so 到 unicorn 虚拟内存，加载成功以后会默认调用 init_array 等函数

	module = dm.getModule();
	code_walk();
	dm.callJNI_OnLoad(emulator); // 手动执行 JNI_OnLoad 函数
	doPatch();
	}

	public static void main(String[] args) throws Exception {
	antibr test = new antibr();
	test.destroy();
	}
	public void code_walk()
	{
	emulator.getBackend().hook_add_new(new CodeHook() {
	@Override
	public void hook(Backend backend, long address, int size, Object user) {
	Capstone capstone = new Capstone(Capstone.CS_ARCH_ARM64,Capstone.CS_MODE_ARM);
	byte[] bytes = emulator.getBackend().mem_read(address, 4);
	Instruction[] disasm = capstone.disasm(bytes, 0);
	InsAndCtx iac = new InsAndCtx();
	iac.setIns(disasm[0]);
	iac.setRegs(saveRegs(backend));
	iac.setAddr(address);
	// 可以当作一个队列去理解，当队列的大小超过 10 时，就删除队首的元素
	if(instructions.size()>10){
	instructions.removeFirst();
	}
	// 向队列的队尾添加元素
	instructions.addLast(iac);
	do_processbr(backend);
	//System.out.printf("%x:%s %s %s\n",address-module.base ,disasm[0].getMnemonic(),disasm[0].getOpStr(),disasm[0].getOperands());
	}

	@Override
	public void onAttach(UnHook unHook) {
	}

	@Override
	public void detach() {
	}
	}, module.base, module.base+module.size, null);
	}

	public void doPatch()
	{
	try {
	File f = new File(inName);
	FileInputStream fis = new FileInputStream(f);
	byte[] data = new byte[(int) f.length()];
	fis.read(data);
	fis.close();
	for(PatchBR pb:patch_list)
	{
	if(pb.errorno==error_type.ok){
	for(PatchIns pi:pb.patchs){
	System.out.println("procrss addr: 0x"+Integer.toHexString((int) pi.addr)+",code: "+pi.getIns());
	Keystone ks = new Keystone(KeystoneArchitecture.Arm64, KeystoneMode.LittleEndian);
	KeystoneEncoded assemble = ks.assemble(pi.getIns(),(int)pi.getAddr());
	for(int i=0;i<assemble.getMachineCode().length;i++)
	{
	data[(int) pi.addr+i] = assemble.getMachineCode()[i];
	}
	}
	}
	else{
	System.out.println("[error] unable to patch at 0x"+Integer.toHexString((int)(pb.br_addr))+pb.error_info);
	}
	}
	File fo = new File(outName);
	FileOutputStream fos = new FileOutputStream(fo);
	fos.write(data);
	fos.flush();
	fos.close();
	System.out.println("finish");
	}
	catch (Exception e)
	{
	e.printStackTrace();
	}
	}

	public void do_processbr(Backend backend)
	{
	InsAndCtx br = null,ldr = null,csel = null,cmp = null;
	List<InsAndCtx> others = new ArrayList<>();
	InsAndCtx blr = null;
	InsAndCtx iac = instructions.peekLast();

	if(iac.ins.getMnemonic().equals("br"))
	{
	br = iac;
	instructions.removeLast();
	try {
	while (!instructions.isEmpty())
	{
	iac = instructions.removeLast();
	String[] split = iac.ins.getOpStr().split(",");
	if(ldr==null && iac.ins.getMnemonic().equals("ldr")){
	if(split[0].toLowerCase(Locale.ROOT).trim().equals(br.ins.getOpStr())){
	ldr = iac;
	}
	}
	else if(csel==null && iac.ins.getMnemonic().equals("csel")){
	csel = iac;
	}
	else if(cmp==null && csel!=null && (iac.ins.getMnemonic().equals("cmp")\|\|iac.ins.getMnemonic().equals("tst"))){
	cmp = iac;
	}
	else{
	others.add(iac);
	}
	}

	//br 直接跳转
	if(csel==null){
	PatchBR pb = new PatchBR();
	pb.type = br_type.direct_br;
	pb.br_addr = br.getAddr()-module.base;

	long pi1_addr = br.getAddr()-module.base;
	String pi1_ins = "b 0x" + Integer.toHexString((int)(getRegValue(br.ins.getOpStr(),br.getRegs()).longValue()-module.base));
	pb.br_jump_to.add(getRegValue(br.ins.getOpStr(),br.getRegs()).longValue()-module.base);
	PatchIns pi1 = new PatchIns();
	pi1.setAddr(pi1_addr);
	pi1.setIns(pi1_ins);

	pb.patchs.add(pi1);

	if(validBRPatch(pb)){
	System.out.println("[info] find br jump at 0x"+Integer.toHexString((int)(pb.br_addr))+" type:"+pb.type);
	patch_list.add(pb);
	}

	//System.out.println("0x"+Integer.toHexString((int)(pi1_addr)) +" "+pi1_ins);
	}
	//csel br 间接跳转
	else{
	PatchBR pb = new PatchBR();
	pb.type = br_type.indirect_br;
	pb.br_addr = br.getAddr()-module.base;

	//System.out.println("[debug] found cesl-br at 0x"+Integer.toHexString((int)(pb.br_addr))+" type:"+pb.type);
	if(cmp!=null){
	PatchIns pi1 = new PatchIns();
	pi1.setAddr(cmp.getAddr()-module.base);
	pi1.setIns("nop");
	pb.patchs.add(pi1);
	}
	else{
	System.out.println("[warn] cmp/tst not found at 0x"+Integer.toHexString((int)(pb.br_addr))+" type:"+pb.type);
	}

	String[] sp = csel.ins.getOpStr().toLowerCase(Locale.ROOT).split(",");
	String reg1 = sp[1].trim();
	String reg2 = sp[2].trim();
	String cond = sp[3].trim();
	long branch1 = readInt64(backend,getRegValue(reg1,csel.getRegs()).longValue())-module.base;
	long branch2 = readInt64(backend,getRegValue(reg2,csel.getRegs()).longValue())-module.base;

	PatchIns pi2 = new PatchIns();
	pi2.setAddr(csel.getAddr()-module.base);
	pi2.setIns("nop");
	pb.patchs.add(pi2);

	if(ldr!=null){
	// 需要进行指令上移
	if(ldr.getAddr()-br.getAddr()>4){
	for(InsAndCtx _iac: others){
	if(_iac.getAddr()< ldr.getAddr() && _iac.getAddr()>br.getAddr()){
	PatchIns _pi = new PatchIns();
	_pi.setAddr(_iac.getAddr()-module.base-4);
	_pi.setIns(_iac.ins.toString());
	pb.patchs.add(_pi);
	}
	}
	}
	long current_br_jump_to = getRegValue(br.ins.getOpStr(),br.getRegs()).longValue()-module.base;
	if((!(current_br_jump_to==branch1))&&(!(current_br_jump_to==branch2))){
	System.out.println("[error] wrong jump address at 0x"+Integer.toHexString((int)(pb.br_addr))+" type:"+pb.type);
	}
	else{
	PatchIns pi3 = new PatchIns();
	pi3.setAddr(pb.br_addr-4);
	pi3.setIns("b"+cond.toLowerCase(Locale.ROOT) + " 0x"+ Integer.toHexString((int) (branch1)));
	pb.br_jump_to.add(branch1);
	pb.patchs.add(pi3);

	PatchIns pi4 = new PatchIns();
	pi4.setAddr(pb.br_addr);
	pi4.setIns("b" + " 0x"+ Integer.toHexString((int) (branch2)));
	pb.br_jump_to.add(branch2);
	pb.patchs.add(pi4);
	}

	if(validBRPatch(pb)){
	System.out.println("[info] find br jump at 0x"+Integer.toHexString((int)(pb.br_addr))+" type:"+pb.type);
	patch_list.add(pb);
	}
	}
	else{
	System.out.println("[error] ldr not found at 0x"+Integer.toHexString((int)(pb.br_addr))+" type:"+pb.type);
	}


	}


	}catch (Exception e)
	{
	e.printStackTrace();
	}

	instructions.clear();
	}
	//blr 直接跳转
	else if(iac.ins.getMnemonic().equals("blr")){
	blr = iac;
	instructions.removeLast();

	PatchBR pb = new PatchBR();
	pb.type = br_type.direct_blr;
	pb.br_addr = blr.getAddr()-module.base;

	long pi1_addr = blr.getAddr()-module.base;
	String pi1_ins = "bl 0x" + Integer.toHexString((int)(getRegValue(blr.ins.getOpStr(),blr.getRegs()).longValue()-module.base));
	pb.br_jump_to.add(getRegValue(blr.ins.getOpStr(),blr.getRegs()).longValue()-module.base);
	PatchIns pi1 = new PatchIns();
	pi1.setAddr(pi1_addr);
	pi1.setIns(pi1_ins);

	pb.patchs.add(pi1);

	if(validBRPatch(pb)){


	if(pb.br_jump_to.get(0)<0\|\|pb.br_jump_to.get(0)>module.size){
	long debug_addr = getRegValue(blr.ins.getOpStr(),blr.getRegs()).longValue();
	Module module2 = emulator.getMemory().findModuleByAddress(debug_addr);
	Symbol symbol = module2 == null ? null : module2.findClosestSymbolByAddress(debug_addr, true);
	String moduleName = null;
	if (module2 != null) {
	moduleName = module2.name;
	}

	String symbolName = null;
	long symbolAddr = 0;
	if (symbol != null) {
	symbolName = symbol.getName();
	symbolAddr = symbol.getAddress();
	System.out.println("[symbol] resolve symbol ok: "+moduleName+","+symbolName+","+symbolAddr);
	System.out.println("[info] find br jump at 0x"+Integer.toHexString((int)(pb.br_addr))+" type:"+pb.type);
	patch_list.add(pb);
	}
	}
	else{
	System.out.println("[info] find br jump at 0x"+Integer.toHexString((int)(pb.br_addr))+" type:"+pb.type);
	patch_list.add(pb);
	}
	}


	instructions.clear();
	}
	}

	void destroy() {
	IOUtils.close(emulator);
	System.out.println("destroy");
	}
	}

# 参考资料

[原创] 记一次基于 unidbg 模拟执行的去除 ollvm 混淆
吾爱破解 2024 春节红包活动 WP (全，含 Android 高级题)

DexGuard java字符串反混淆

2024-09-03T10:14:21.000Z

# 前言

最近分析的 app 发现加了 DexGuard , 所以在 java 层遇到了非常强力的字符串混淆，甚至 jeb 这么强大的 java 反混淆工具都不能把字符串解密出来，所以本文是对 java 字符串反混淆的过程记录，通过 frida 的 RPC 调用，利用 python flask 搭建一个主动调用 java 字符串解密函数的 GET 接口，随后编写 jeb 脚本访问这个本地端口，并传入字符串解密函数的参数，获取字符串解密后的结果后替换 Element, 实现基于 frida RPC 主动调用的 java 字符串的反混淆

# 神奇的防 hook 手段

DexGuard 有一个非常神奇的地方就是这个混淆的字符串解密函数竟然没有办法 hook 到返回值？！

将核心的部分提取出来之后写个 demo, 其 Java 代码如下，逻辑很简单，就是在调用 get_helloworld 获取拼接的字符串之前，先定义了一个 arr_object 对象数组并作为参数传入 get_helloworld 中，随后在 get_helloworld 中经过一顿拼接操作，将最终的返回值赋值给传入参数中的 arr_object , 随后调用 Toast.makeText 打印拼接后的字符串

	private static void get_helloworld(String hello,String world,Object[]){
	String ret_value = hello+world+"get!";
	arr_object[0]=ret_value;
	}
	@Override
	protected void onCreate(Bundle savedInstanceState) {
	super.onCreate(savedInstanceState);

	Object[] arr_object = new Object[1];
	get_helloworld("hello","world",arr_object);
	Toast.makeText(global_context, (String)arr_object[0], Toast.LENGTH_SHORT).show();
	}

通过这种方式进行函数返回值的传递，被证实确实是可行的，我们看到弹窗弹出的内容也符合 get_helloworld 函数执行完后的预期

然而当我们尝试用的 frida 代码去 hook get_helloworld , 想要读取通过对象数组传递的返回值之后却发现

	function hook(){
	console.log('start hook');
	Java.perform(() =>{
	var app = Java.use("com.example.mytest.MainActivity");
	app.get_helloworld.implementation = function (str1,str2,arr_object) {
	console.log('before call get_helloworld: str1=',str1,'str2=',str2,'arr_object=',arr_object);
	var ret = this.get_helloworld(str1,str2,arr_object);
	console.log('after call get_helloworld: str1=',str1,'str2=',str2,'arr_object=',arr_object,',ret=',ret);
	return ret;
	}
	})
	}

	setImmediate(hook)

nothing happened… 打印调用原函数前后的 arr_object , 发现都是空值

在这个地方纠结了好几天之后我就在想，究竟是什么原因导致 hook 这个对象的返回值失败了呢？难道是 frida 有 bug, 所以我就去看了 frida art hook 的源码和原理，感觉也没啥问题呀，还是说我的 frida 的打开方式有问题呢

那来看看这个对象有哪些属性吧

console.log('arr_object has those properties->', Object.getOwnPropertyNames(arr_object));

欸打印看看这个 $w , 没想到竟然可以成功的打印出 Object 来？！

这个 $w 是什么东西，为什么 arr_object 用 $w 属性就可以拿到正确的对象，但是打印原始的 arr_object 却一直是空？

进到 frida-java-bridge 里面去看看是什么情况

首先找到 $w 定义的地方，这个 this[Symbol.for('w')] 是什么呢？

向下翻翻源码后我们发现，没想到 $w 是 classWrapper , 拿到这个 classWrapper 之后才算是拿到了最初的值，amazing~

# frida RPC 调用

在字符串解密函数的返回值可以被成功的 hook 到之后，接下来我们便开始正式的字符串反混淆，这里需要用到 frida RPC 来主动调用字符串的解密函数，因为对于字符串混淆来说，不论解密的过程多么的复杂，我们只需要调用一下解密函数拿到解密后的结果就足够了

frida 的 rpc 调用代码如下，需要注意的是函数传入的是什么类型的数组，我们在构造函数的入参的时候也要用 Java.array 转换成对应类型的数组

	function string_decrypt(a1,a2,a3,a4){
	var result;
	Java.perform(function (){
	var app = Java.use("com.test.Activity");
	if(a1==null){
	a1 = Java.array('int',[]);
	}
	else{
	a1 = Java.array('int',[a1]);
	}

	if(a2==null){
	a2 = Java.array('char',[]);
	}
	else{
	a2 = Java.array('char',[a2]);
	}
	a4 = Java.array('byte',a4);
	var ret;
	var obj_cls = Java.use('[Ljava.lang.Object;');
	ret = Java.array('Ljava.lang.Object;',[null]);
	app.bc(a1,a2,a3,a4,ret);

	var objArr = Java.cast(ret.$w, obj_cls);
	var ArrayClz = Java.use("java.lang.reflect.Array");
	var len = ArrayClz.getLength(objArr);
	var arr =[]
	for(let i=0;i!==len;i++){
	arr.push(ArrayClz.get(objArr,i).toString());
	}
	console.log('hook return value123->',arr[0]);
	result = arr[0];
	})
	return result;
	}

	rpc.exports = {
	// 如果 js 导出函数中包含驼峰命名，则 python 需要将大写替换成_小写，如 getUser => get_user
	stringdecrypt:string_decrypt,
	};

同时因为 dexguard 是有 frida 检测的，一旦检测到 frida 进程就会闪退，所以我们可以在 frida 的检测点之前找个点去 hook, 例如可以 hook Activity 的 attachBaseContext , 然后通过 Thread.sleep(9999); 让进程永久的暂停下去，虽然 Thread 已经 sleep 了，但是我们的 RPC 主动调用解密函数这个过程依然可以正常进行

# flask 搭个本地服务器

接下来我们用 flask 去搭一个本地的接口，来让 jeb 脚本可以访问到啦，这里我使用的是 flask , 由于 flask 支持的是 wsgi 协议，而 uvicorn 只能用 asgi 协议，所以我们需要用 asgiref 中的 WsgiToAsgi 将 asgi 转换成 wsgi , 代码如下

	import codecs
	import frida
	from flask import Flask, request
	from asgiref.wsgi import WsgiToAsgi
	from time import sleep
	import json
	import uvicorn
	def onMessage(message, data):
	#print(message)
	if message["type"] == 'send':
	print(u"[*] {0}".format(message['payload']))
	else:
	print(message)
	app = Flask(import_name=__name__)
	asgi_app = WsgiToAsgi(app)
	device = frida.get_device_manager().add_remote_device("127.0.0.1:1234")
	pkg = "com.test.activ" #包名

	pid = device.spawn([pkg])
	session = device.attach(pid)

	with codecs.open('./str_dec.js', 'r', encoding='utf-8') as f:
	source = f.read()
	script = session.create_script(source)
	script.on('message', onMessage)
	script.load()#注入脚本
	device.resume(pid)
	sleep(1)#这里得 sleep 1 秒，来让脚本加载完成
	rpc = script.exports_sync

	# 通过 methods 设置 GET 请求
	@app.route('/strdec', methods=["GET"])
	def json_request():
	# 接收处理 json 数据请求
	data = eval(request.args.get("body"))
	print(f'[*] receive {data}')
	print(type(data))
	method = data["method"]
	result = None
	if method == "bc":#处理函数名为 bc 的字符串加密函数
	argv1 = data['argv1']
	argv2 = data['argv2']
	argv3 = data['argv3']
	argv4 = data['argv4']
	result = rpc.stringDecrypt(argv1,argv2,argv3,argv4)
	return result

	uvicorn.run(asgi_app,host='127.0.0.1', port=8080)

# Jeb Script 反混淆

这里字符串混淆的代码和之前用过的差不多，只是字符串解密函数 bc_decryptstring 这里，需要注意用 jeb 自带的网络库 Net().query 和先前 flask 创建的接口交互，到了这里基于主动调用的字符串反混淆就基本上完成了

	# coding=utf-8
	from com.pnfsoftware.jeb.client.api import IScript, IconType, ButtonGroupType
	from com.pnfsoftware.jeb.core import RuntimeProjectUtil
	from com.pnfsoftware.jeb.core.units.code.java import IJavaSourceUnit
	from com.pnfsoftware.jeb.core.units.code import ICodeUnit, ICodeItem
	from com.pnfsoftware.jeb.core.output.text import ITextDocument
	from com.pnfsoftware.jeb.core.units.code.java import IJavaAssignment, IJavaSourceUnit, IJavaStaticField, IJavaNewArray, IJavaConstant, IJavaCall, IJavaField, IJavaMethod, IJavaClass
	from com.pnfsoftware.jeb.core.events import JebEvent, J
	from com.pnfsoftware.jeb.core.util import DecompilerHelper

	from com.pnfsoftware.jeb.util.net import Net
	import json
	# 解密字符串函数的类名以及方法名
	methodName = ['Lcom/test/Activity;', 'bc']

	class dec_str_test(IScript):
	def run(self, ctx):
	print('start deal with strings')
	self.ctx = ctx
	engctx = ctx.getEnginesContext()
	if not engctx:
	print('Back-end engines not initialized')
	return

	projects = engctx.getProjects()
	if not projects:
	print('There is no opened project')
	return

	units = RuntimeProjectUtil.findUnitsByType(projects[0], IJavaSourceUnit, False)
	for unit in units:
	javaClass = unit.getClassElement()
	print('[+] decrypt:' + javaClass.getName())
	self.cstbuilder = unit.getFactories().getConstantFactory()
	#self.elebuilder = unit.getFactories().getElementFactory()
	self.processClass(javaClass)
	unit.notifyListeners(JebEvent(J.UnitChange))
	print('Done.')

	def processClass(self, javaClass):
	# if javaClass.getName() == methodName[0]:
	# return
	for method in javaClass.getMethods():
	block = method.getBody()
	i = 0
	while i < block.size():
	stm = block.get(i)
	self.checkElement(block, stm)
	i += 1

	def checkElement(self, parent, e):
	try:
	if isinstance(e, IJavaCall):
	mmethod = e.getMethod()
	mname = mmethod.getName()
	msig = mmethod.getSignature()
	if mname == methodName[1] and methodName[0] in msig:
	v = []
	args = e.getArguments();
	decstr = self.bc_decryptstring(args[0],args[1],args[2],args[3])
	if decstr:
	print(e)
	print("decrypt bc->",decstr)
	parent.replaceSubElement(e, self.cstbuilder.createString(decstr))
	for subelt in e.getSubElements():
	if isinstance(subelt, IJavaClass) or isinstance(subelt, IJavaField) or isinstance(subelt, IJavaMethod):
	continue
	self.checkElement(e, subelt)
	except Exception,e:
	print(e)

	def read_array(self,arr):
	if arr.getType()==None:
	return None
	res = []
	arr = arr.getInitialValues()
	for i in range(len(arr)):
	res.append(arr[i].getByte())
	return res

	def bc_decryptstring(self, args1,args2,args3,args4):
	argv1= self.read_array(args1)
	argv2 = self.read_array(args2)
	argv3 = args3.getInt()
	argv4 = self.read_array(args4)
	body = {
	'method':'bc',
	'argv1':argv1,
	'argv2':argv2,
	'argv3':argv3,
	'argv4':argv4
	}

	r = Net().query("http://127.0.0.1:8080/strdec", {"body":str(body)})
	return r

初探抖音六神之字符串解密算法分析

2024-08-20T13:52:00.000Z

# 前言

抖音六神算法，一听这名字就超 cooool 的，正好最近也没有什么别的事情，于是就趁着周末来逆一逆抖音 APP, 在分析六神算法的过程中，它的 java 层的字符串加密算法我感觉很有意思，于是就写了这篇文章来记录一下～

本文所分析的抖音版本为 300600

# ssl pinning 绕过

打开 app 之后用 repable 抓包，抖音直接显示无网络，所以想都不用想，肯定是有 ssl pinning，但是常规的过 ssl pinning 的代码没有用，因为抖音和其他 app 不一样，它的 ssl 校验是在 native 层的

hook apk 打开的 so 库，一般网络库的加载都是在最前面的，在 libsscronet.so 找到 ssl 相关的函数

这一块应该是在 so 中用自定义的函数去进行 ssl 的验证

搜索字符串发现有很多 certificate , 那大概率就是在这个 so 里面进行 ssl pinning 的

看了一下导入函数，感觉 SSL_CTX_set_custom_verify 有点像校验的样子

SSL_CTX_set_custom_verify 证书校验异步操作，相比 OpenSSL，BoringSSL 单独将认证证书的流程拿出来从而提供更详细的认证控制

再细看一下这个函数

	void SSL_CTX_set_custom_verify(
	SSL_CTX *ctx, int mode,
	enum ssl_verify_result_t (callback)(SSL ssl, uint8_t *out_alert)) {
	ctx->verify_mode = mode;
	ctx->custom_verify_callback = callback;
	}

其中的 mode 用来验证客户端，mode 的值为 1 进行验证，但是如果取 0 就是不验证

	// SSL_VERIFY_NONE, on a client, verifies the server certificate but does not
	// make errors fatal. The result may be checked with \|SSL_get_verify_result\|. On
	// a server it does not request a client certificate. This is the default.
	#define SSL_VERIFY_NONE 0x00

	// SSL_VERIFY_PEER, on a client, makes server certificate errors fatal. On a
	// server it requests a client certificate and makes errors fatal. However,
	// anonymous clients are still allowed. See
	// \|SSL_VERIFY_FAIL_IF_NO_PEER_CERT\|.
	#define SSL_VERIFY_PEER 0x01

	// SSL_VERIFY_FAIL_IF_NO_PEER_CERT configures a server to reject connections if
	// the client declines to send a certificate. This flag must be used together
	// with \|SSL_VERIFY_PEER\|, otherwise it won't work.
	#define SSL_VERIFY_FAIL_IF_NO_PEER_CERT 0x02

	// SSL_VERIFY_PEER_IF_NO_OBC configures a server to request a client certificate
	// if and only if Channel ID is not negotiated.
	#define SSL_VERIFY_PEER_IF_NO_OBC 0x04

所以我们可以直接用 frida patch 第二个参数的值为 0

	function hook_dlopen(soName = '') {
	Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
	{
	onEnter: function (args) {
	var pathptr = args[0];
	if (pathptr !== undefined && pathptr != null) {
	var path = ptr(pathptr).readCString();
	//console.log('load ',path);
	if (path.indexOf(soName) >= 0) {
	this.is_can_hook = true;
	}
	}
	},
	onLeave: function (retval) {
	if (this.is_can_hook) {
	ssl_bypass();
	//do your own code
	}
	}
	}
	);
	}

	function ssl_bypass(){
	let SSL_CTX_set_custom_verify = Module.getExportByName('libsscronet.so', 'SSL_CTX_set_custom_verify');
	console.log('start hook SSL_CTX_set_custom_verify')
	if (SSL_CTX_set_custom_verify != null) {
	Interceptor.attach(SSL_CTX_set_custom_verify, {
	onEnter: function (args) {
	console.log('SSL_CTX_set_custom_verify mode: ',args[1]);
	args[1] = ptr(0);
	console.log('patch mode from 1 to 0 to bypass ssl')
	},
	onLeave: function (retval) {

	}
	});
	}
	}

	//frida -H 127.0.0.1:1234 -l .\douyin\hook.js -f com.ss.android.ugc.aweme
	setImmediate(hook_dlopen, "libsscronet.so")

抓到包啦

在请求头中出现的六个 x- 带头的参数就是六神算法

# 定位参数位置

接下来就是去定位这些参数的位置咯，该怎么定位呢？

其实很简单，按照正向安全开发的经验来说，对于大型的 APP, 这种关键参数所涉及的算法基本上是不可能在 java 层中出现的，他们通常极大概率是把加密算法下沉到 native 层中去调用，所以说，我们就只需要找 so 就可以啦，而这种含有关键算法的 so 一般都有一个共性，就是 so 中不会出现静态注册的 java 方法，并且 so 被混淆的非常滴厉害，各种花指令寄存器跳转啥的通通来一遍让我们一打开 IDA 反编译连伪代码都看不了，找到这类 so，那就离关键算法不远了，而其他无关紧要的 so 基本不会做防护，要是也加上高强度的混淆，可能会出 bug 不说，还会拖慢 APP 启动速度影响用户体验

而小型的 APP, 由于很少会在安全上花功夫，所以说我们在 java 层中搜索参数名称，一般就可以找到参数所在的位置了

而在之前我们已经知道进行 ssl pinning 的 so 库的名称是 libsscronet.so , 那对参数进行加密的 so 库一般就在网络库的附近加载，感觉 libmetasec_ml.so 这个 so 挺像的

一用 IDA 反编译 so 之后引入眼帘的就是让人感到亲切的 BR 寄存器跳转！

接下来看看这个 so 动态注册了什么方法咯

	function getModuleInfoByPtr(fnPtr) {
	var modules = Process.enumerateModules();
	var modname = null,
	base = null;
	modules.forEach(function (mod) {
	if (mod.base <= fnPtr && fnPtr.toInt32() <= mod.base.toInt32() + mod.size) {
	modname = mod.name;
	base = mod.base;
	return false;
	}
	});
	return [modname, base];
	}
	function hook_registNatives() {
	var env = Java.vm.getEnv();
	var handlePointer = env.handle.readPointer();
	console.log("handle: " + handlePointer);
	var nativePointer = handlePointer.add(215 * Process.pointerSize).readPointer();
	console.log("register: " + nativePointer);
	/**
	typedef struct {
	const char* name;
	const char* signature;
	void* fnPtr;
	} JNINativeMethod;
	jint RegisterNatives(JNIEnv* env, jclass clazz, const JNINativeMethod* methods, jint nMethods)
	*/

	Interceptor.attach(nativePointer, {
	onEnter: function onEnter(args) {
	var env = Java.vm.getEnv();
	var p_size = Process.pointerSize;
	var methods = args[2];
	var methodcount = args[3].toInt32();
	var name = env.getClassName(args[1]);
	console.log("==== class: " + name + " ====");
	console.log("==== methods: " + methods + " nMethods: " + methodcount + " ====");

	for (var i = 0; i < methodcount; i++) {
	var idx = i * p_size * 3;
	var fnPtr = methods.add(idx + p_size * 2).readPointer();
	var infoArr = getModuleInfoByPtr(fnPtr);
	var modulename = infoArr[0];
	var modulebase = infoArr[1];
	var logstr = "name: " + methods.add(idx).readPointer().readCString() + ", signature: " + methods.add(idx + p_size).readPointer().readCString() + ", fnPtr: " + fnPtr + ", modulename: " + modulename + " -> base: " + modulebase;

	if (null != modulebase) {
	logstr += ", offset: " + fnPtr.sub(modulebase);
	}

	console.log(logstr);
	}
	}
	});
	}

这里注册了 ms.bd.c.l.a , 它的方法签名是 (IIJLjava/lang/String;Ljava/lang/Object;)Ljava/lang/Object; , 并且在 so 中的偏移是 0x126e30

直接对偏移 0x126e30 的传入传出参数进行 hook, 发现就是六神算法的生成位置～

而在对 ms.bd.c.l.a 进行交叉引用后发现，这个 native 函数还有一个字符串加密的功能如图所示，通过调用 l.a 函数，并传入 code 为 0x1000001 来实现 java 层的字符串加密，接下来我们来对这个字符串加密算法进行更加深入的研究

# libmetasec_ml.so 反混淆

这个 so 的花指令主要有五类 (其实还有一类是 CSEL-BR 寄存器跳转混淆，但是由于字符串解密算法不涉及 CSEL-BR 混淆，所以此处没有给出相关的示例)

BL-BR 寄存器跳转
这个寄存器跳转简单读一下汇编就可以很清楚的知道是怎么实现的啦，主要是通过一个函数获取到了当前 BL 指令下一行的内存地址，然后通过加上一个偏移使用 BR 寄存器跳转的形式跳过去，所以我们只要把中间越过的指令直接 NOP 掉就好啦
B.GT-CBNZ 垃圾指令
这里出现了一大段 IDA 无法解析的指令

其实对于此处的汇编来说，它执行后最终的值是固定的

	MOV W8, #0x1B5
	MOV W9, #0x16F
	STR W8, [SP,#0x4C]
	STR W9, [SP,#0x48]
	LDR W8, [SP,#0x4C]
	LDR W9, [SP,#0x48]
	CMP W9, #0x4C ; 'L'
	B.GT
	MOV W9, #1
	MADD W8, W8, W8, W9
	MOV W9, #7
	UDIV W9, W8, W9
	SUB W9, W9, W9,LSL#3
	ADD W8, W8, W9
	CBNZ W8, loc_55318

我们可以使用 unicorn 将这段汇编运行一下看看具体的值

	# code for test-fla.elf
	from unicorn import *
	from unicorn.arm64_const import *
	from keystone import * # pip install keystone-engine
	from capstone import * # pip install capstone

	BASE = 0x0
	CODE = BASE + 0x0
	CODE_SIZE = 0x100000
	STACK = 0x7F00000000
	STACK_SIZE = 0x100000
	FS = 0x7FF0000000
	FS_SIZE = 0x100000
	ks = Ks(KS_ARCH_ARM64, KS_MODE_LITTLE_ENDIAN) # 汇编引擎
	uc = Uc(UC_ARCH_ARM64, UC_MODE_LITTLE_ENDIAN) # 模拟执行引擎
	cs = Cs(CS_ARCH_ARM64, CS_MODE_LITTLE_ENDIAN) # 反汇编引擎


	def hook_code(uc: unicorn.Uc, address, size, user_data):
	# print(hex(address))
	for i in cs.disasm(CODE_DATA[address - BASE:address - BASE + size], address):
	# arm 架构是 NZCV 寄存器，32 位的寄存器最左边开始的四位依次存储 N,Z,C,V 标志
	ZF_flag = (uc.reg_read(UC_ARM64_REG_NZCV) >>30)&1

	if i.mnemonic == "b.gt":
	print(f"0x{i.address}: {i.mnemonic} {i.op_str} ; ZF = {ZF_flag}")
	uc.reg_write(UC_ARM64_REG_PC, address + size)
	elif i.mnemonic == "cmp":
	w9 = uc.reg_read(UC_ARM64_REG_W9)
	print(f"0x{i.address}: {i.mnemonic} {i.op_str} ; ZF = {ZF_flag}, w9 = {hex(w9)}")
	elif i.mnemonic == "cbnz":
	w8 = uc.reg_read(UC_ARM64_REG_W8)
	print(f"0x{i.address}: {i.mnemonic} {i.op_str} ; ZF = {ZF_flag}, w8 = {hex(w8)}")
	uc.reg_write(UC_ARM64_REG_PC, address + size)
	else:
	print(f"0x{i.address}: {i.mnemonic} {i.op_str} ; ZF = {ZF_flag}")


	def hook_mem_access(uc: unicorn.Uc, type, address, size, value, userdata):
	pc = uc.reg_read(UC_ARM64_REG_PC) # UC_ARM64_REG_PC

	print('pc:%x type:%d addr:%x size:%x' % (pc, type, address, size))
	# uc.emu_stop()
	return True


	def inituc(uc):
	uc.mem_map(CODE, CODE_SIZE, UC_PROT_ALL)
	uc.mem_map(STACK, STACK_SIZE, UC_PROT_ALL)

	uc.mem_write(CODE, CODE_DATA)
	uc.reg_write(UC_ARM64_REG_SP, STACK + 0x1000)

	uc.hook_add(UC_HOOK_CODE, hook_code)
	uc.hook_add(UC_HOOK_MEM_UNMAPPED \| UC_HOOK_INTR, hook_mem_access)


	shellcode = '''
	MOV W8, #0x1B5
	MOV W9, #0x16F
	STR W8, [SP,#0x4C]
	STR W9, [SP,#0x48]
	LDR W8, [SP,#0x4C]
	LDR W9, [SP,#0x48]
	CMP W9, #0x4C
	B.GT #0x55318

	MOV W9, #1
	MADD W8, W8, W8, W9
	MOV W9, #7
	UDIV W9, W8, W9
	SUB W9, W9, W9,LSL#3
	ADD W8, W8, W9
	CBNZ W8, #0x55318
	'''
	CODE_DATA,count = ks.asm(shellcode)
	CODE_DATA = bytes(CODE_DATA)
	inituc(uc)
	try:
	uc.emu_start(0x0, len(CODE_DATA))
	except Exception as e:
	print(e)

输出如下，可以发现 cmp w9, #0x4c 将 ZF 标志位置为 1, b.gt 大于跳转永远成立， cbnz 跳转也永远成立，也就是不管怎么样，最终都会越过中间这段无用的指令，而跳转到 0x55318 的位置

	0x0: mov w8, #0x1b5 ; ZF = 1
	0x4: mov w9, #0x16f ; ZF = 1
	0x8: str w8, [sp, #0x4c] ; ZF = 1
	0x12: str w9, [sp, #0x48] ; ZF = 1
	0x16: ldr w8, [sp, #0x4c] ; ZF = 1
	0x20: ldr w9, [sp, #0x48] ; ZF = 1
	0x24: cmp w9, #0x4c ; ZF = 1, w9 = 0x16f
	0x28: b.gt #0x55318 ; ZF = 0
	0x32: mov w9, #1 ; ZF = 0
	0x36: madd w8, w8, w8, w9 ; ZF = 0
	0x40: mov w9, #7 ; ZF = 0
	0x44: udiv w9, w8, w9 ; ZF = 0
	0x48: sub w9, w9, w9, lsl #3 ; ZF = 0
	0x52: add w8, w8, w9 ; ZF = 0
	0x56: cbnz w8, #0x55318 ; ZF = 0, w8 = 0x3

所以对于这种 ida 无法识别的无用指令，我们直接 nop 掉即可

F1 F6 77 FF 1F 20 03 D5 1F 20 03 D5 1F 20 03 D5 , 这个花指令主要是用来进行 so 完整性校验的，但是我们主要是进行静态分析，所以对于影响我们看汇编的指令，直接 nop 掉

EB FF 1F D6 01 00 00 D4 , 这个被 ida 解析成了 svc 调用，实际上看看上下文根本没有给 x8 赋值的语句，所以这八字节也是花指令

01 00 00 D4 DE 01 70 47 , 同样的，这里出现的 svc 也不是真的 svc, 是花指令，直接 patch 掉就好啦

所以最终的去花代码如下

	import ida_segment
	import idautils
	import idc
	import ida_bytes
	from keystone import *
	def patch_nop(begin, end): # arm64 中的 NOP 指令是 b'\x1F\x20\x03\xD5'
	while end > begin:
	ida_bytes.patch_bytes(begin, b'\x1F\x20\x03\xD5')
	begin = begin + 4

	# 获取 text 段的起始地址
	text_seg = ida_segment.get_segm_by_name(".text")
	start, end = text_seg.start_ea, text_seg.end_ea
	#start,end = 0x533A4,0x533E0#BL-BR 结构寄存器跳转单个情况测试
	#start,end = 0x55288,0x55318#B.GT-CBNZ 跳转垃圾指令测试
	#start,end = 0x94048,0x94070#B.GT-CBNZ 跳转垃圾指令测试 1
	#去除花指令
	pattern = ["01 00 00 D4 DE 01 70 47",
	"EB FF 1F D6 01 00 00 D4",
	"F1 F6 77 FF 1F 20 03 D5 1F 20 03 D5 1F 20 03 D5"]
	for i in range(len(pattern)):
	cur_addr = start
	end_addr = end
	while cur_addr < end_addr:
	cur_addr = idc.find_binary(cur_addr, idc.SEARCH_DOWN, pattern[i])
	if cur_addr == idc.BADADDR:
	break
	else:
	print("patch flower code: " + hex(cur_addr)) # 打印提示信息
	#patch_nop(cur_addr, cur_addr + len(pattern[i].split(' ')))
	cur_addr = idc.next_head(cur_addr)



	current_addr = start
	while current_addr < end:
	# BL-BR 结构寄存器跳转
	if idc.print_insn_mnem(current_addr) == "BR":
	BR_addr = current_addr
	BL_addr,nop_count = 0,0

	temp_addr = current_addr
	for _ in range(4):
	if idc.print_insn_mnem(temp_addr) == "BL":
	BL_addr = temp_addr
	elif idc.print_insn_mnem(temp_addr) == "ADD":
	nop_count = idc.get_operand_value(temp_addr, 2)
	temp_addr = idc.prev_head(temp_addr)
	if BL_addr and nop_count:
	print(f"patch BL-BR from {hex(BL_addr)} to {hex(idc.next_head(BL_addr)+nop_count)}")
	patch_nop(BL_addr, idc.next_head(BL_addr) + nop_count)
	#B.GT-CBNZ 跳转
	elif idc.print_insn_mnem(current_addr) == "CBNZ":
	CBNZ_addr = current_addr
	CBNZ_jmp_addr = idc.get_operand_value(current_addr,1)
	BGT_addr = 0
	temp_addr = current_addr
	for _ in range(10):
	if idc.print_insn_mnem(temp_addr) == "B.GT":
	BGT_jmp_addr = idc.get_operand_value(temp_addr,0)
	if CBNZ_jmp_addr==BGT_jmp_addr:
	print(f"patch B.GT-CBNZ junk code from {hex(CBNZ_addr+4)} to {hex(CBNZ_jmp_addr)}")
	patch_nop(CBNZ_addr+4, CBNZ_jmp_addr)
	break
	temp_addr = idc.prev_head(temp_addr)

	current_addr = idc.next_head(current_addr)

# 自加载 libmetasec_ml.so

为了防止其他的 so 对我们的干扰，所以可以写个 demo 加载这个 so，但一加载这个 so 的时候程序就崩溃了并留下了下面这一串报错，既然调用了这个类 com.bytedance.mobsec.metasec.ml.MS ，那肯定和算法有些许的联系

而这个 MS 类，他继承了 e0 类

而这个 e0 类，他又继承了 ms.bd.c.l 这个类，这个类就是 libmetasec_ml.so 唯一动态注册的函数 a 所在的类，在 e0 中，又定义了四个函数，但是他们的函数竟然啥内容都没有

	package ms.bd.c;

	import com.bytedance.covode.number.Covode;

	public class e0 extends l {
	static {
	Covode.recordClassIndex(1018605);
	}

	private static final void Bill() {
	}

	public strictfp void Francies() {
	}

	public static final void Louis() {
	}

	public static final void Zeoy() {
	}
	}

把缺少的类补上去之后，随便调用一个字符串加密的函数

Log.d(TAG,(String)l.a(0x1000001, 0, 0L, "d8044a", new byte[]{0x30, 41, 3, 72, 10, 0x72, 39, 27, 100, 97, 0x7B, 0x7A, 81, 69, 12, 0x7F, 0x74, 13, 100, 0x76, 59}));

没想到竟然输出了乱码

为什么调用本来的字符串加密算法不能正常输出解密之后的字符串呢？

我思考了一下有以下几种可能的情况存在

包名 / 签名校验：然而我 hook 了一圈都没找到相关的函数，包名改成和抖音一样的还是不行
异常环境检测：但是我放到正常的手机上，log 输出的还是同样的结果
检查 / 读取特定的文件：难道是检查 app 私有目录下有没有特定的文件，如果有特定的文件，就给解密的算法赋值正确的密钥？
利用 binder 或者 socket 和其他的进程通讯来获取初始密钥？

下面是我对第三种情况读取文件的排查过程，因为考虑到最安全的调用系统函数的方式是 svc 调用

# SVC 调用

svc 的各个 code 对应的含义可以在此处找到

ida 搜索 svc 特征汇编 01 00 00 D4 找到如下位置，在 sub_13E274 中

对这个函数 hook 一下

	function hook_svc() {
	var module = Process.findModuleByName("libmetasec_ml.so")
	Interceptor.attach(module.base.add(0x13E274),
	{
	onEnter: function (args) {
	console.log('hook svc code->',this.context.x8.toInt32());
	},
	onLeave: function (retval) {

	}
	}
	);
	}

但是却崩溃了？

用 frida 打个内存读写的断点看看

	function memory_read_hook(){
	var module = Process.findModuleByName("libmetasec_ml.so")
	MemoryAccessMonitor.enable(
	{
	base:module.base.add(0x13E274),
	size:48
	},{
	onAccess: function (details) {
	console.log(details.operation)
	console.log(get_addr_in_so(details.from));
	}
	}
	)
	}

	function get_addr_in_so(addr){
	var process_Obj_Module_Arr = Process.enumerateModules();
	for(var i = 0; i < process_Obj_Module_Arr.length; i++) {
	if(addr>process_Obj_Module_Arr[i].base && addr<process_Obj_Module_Arr[i].base.add(process_Obj_Module_Arr[i].size)){
	return addr.toString(16)+" is in "+process_Obj_Module_Arr[i].name+" offset: 0x"+(addr-process_Obj_Module_Arr[i].base).toString(16);
	}
	}
	return addr.toString(16);
	}

需要注意的是我们需要在对 svc 的 hook 完成之后，延迟三秒在打内存读写断点

frida 打印出了如下日志随后进程退出

跳转到 0x13e030 看看，看来是对 svc 函数的完整性做了校验来防 hook

那就对这个函数进行 hook 把校验的值强制改成 0x312768B , 没想到又崩溃了，但是打印的地址还是和先前相同，因为 frida MemoryAccessMonitor 自身的限制，只在第一次访问内存页的时候产生回调，后续的访问就不显示了，这个特性在 frida 的官方文档中有所提及

接下来考虑打个硬件断点看看

stackplz 打硬件断点

./stackplz --rpc --stack

hook 代码如下

	function log(msg) {
	console.log(`${msg}`);
	}

	async function SetHWBrk(brk_addr, brk_type) {
	try {
	let size_len = 4;

	let brk_options = {
	// brk_pid: Process.id,
	brk_pid: -1,
	brk_len: 4,
	brk_type: brk_type,
	brk_addr: brk_addr,
	};
	// open conn
	log(`[SetHWBrk] open conn`);
	// stackplz --rpc-path
	var conn = await Socket.connect({
	family: "ipv4",
	host: "localhost",
	port: 41718,
	});

	let payload = JSON.stringify(brk_options);
	log(`brk_options -> ${payload}`);

	let msg_len = payload.length;

	// send payload size
	let size_buffer = Memory.alloc(size_len);
	size_buffer.writeU32(msg_len);
	await conn.output.writeAll(size_buffer.readByteArray(size_len));

	// send payload
	let payload_buffer = Memory.alloc(payload.length);
	payload_buffer.writeUtf8String(payload);
	await conn.output.writeAll(payload_buffer.readByteArray(payload.length));

	// try read resp size
	let resp_size_buffer = await conn.input.readAll(size_len);
	let resp_size = resp_size_buffer.unwrap().readU32();
	let resp = await conn.input.readAll(resp_size);
	log(`resp -> ${hexdump(resp)}`);
	// close conn
	await conn.close();
	} catch (error) {
	log(`[SetHWBrk] error ${error}`);
	}
	}

	function do_hw_brk() {
	// modify here
	try {
	let lib = Process.getModuleByName("libmetasec_ml.so");
	SetHWBrk(lib.base.add(0x13E274), "r");
	} catch (error) {
	log(`error ${error}`);
	}
	}

遇到这个 unable to create socket: Operation not permitted , 这是由于测试的 demo 没有给网络权限所以不能建立 socket

在 AndroidManifest.xml 里面加上这个权限就可以了

<uses-permission android:name="android.permission.INTERNET"/>

但是貌似 hit 不到， 0x23c00 跳转过去是空的并没有代码

使用 rwprocmem33 打硬件断点，发现硬件断点命中了上千万次，而检测点的偏移计算出来是 0x13e0e8

这个检测点就是我们先前去除垃圾指令后看到的这个函数

这不是和我们之前用 frida 的 MemoryAccessMonitor 找到的监测点一模一样吗，那为啥下面这个脚本没办法过检测呢？直接把 checksum 修改成和正确的值 0x312768B 一样不应该行得通的嘛

	function bypass_svc_func_check() {
	var module = Process.findModuleByName("libmetasec_ml.so")
	Interceptor.attach(module.base.add(0x13E10C),
	{
	onEnter: function (args) {

	console.log('internal svc func check bypass, x8 ',this.context.x8,'-> 0x312768B');
	this.context.x8 = 0x312768B;
	},
	onLeave: function (retval) {

	}
	}
	);
	}

但是我们想想，rwprocmem33 打印出来的硬件断点，命中次数达到了上千万次，那么这绝对是另外起了一个线程来专门对这个地方做检测的

所以这个检测线程既然如此暴力，那么我们索性也一不做二不休，直接把检测的汇编暴力 patch 了不就好了！

具体代码如下，使用 Memory.protect 将这个 so 设为 rwx , 然后直接修改内存，把 B.NE 跳转改为 B 跳转

这样这个 so 不管起多少线程，其内部线程的执行逻辑都将以我们期望的方式运行

	function bypass_svc_func_check() {
	var libso = Process.getModuleByName("libmetasec_ml.so");
	console.log("[name]:", libso.name);
	console.log("[base]:", libso.base);
	console.log("[size]:", ptr(libso.size));
	console.log("[path]:", libso.path);
	Memory.protect(ptr(libso.base), libso.size, 'rwx');
	Memory.writeByteArray(ptr(libso.base).add(0x13E110),[0X03, 0X00, 0X00, 0X14]);
	}

终于我们也是成功的 hook 到了 svc 的调用码

各个 svc code 的含义如下

	hook svc code-> 56(__NR_openat) open /proc/self/exe
	hook svc code-> 62(__NR3264_lseek)
	hook svc code-> 63(__NR_read)
	hook svc code-> 57(__NR_close)
	hook svc code-> 135(__NR_rt_sigprocmask)
	hook svc code-> 172(__NR_getpid)
	hook svc code-> 178(__NR_gettid)
	hook svc code-> 135(__NR_rt_sigprocmask)

但是感觉没有 open 什么有意义的文件的样子…

# svc 函数 hook 检测的 bug

但是这个检测是有 bug 的，其实这个点我其实在最初就发现了，但是本着严谨的态度于是就顺着这段检测代码想要的方式去过检测

回到检测函数我们看到这个检测函数对 sub_13E274 的 12 行汇编进行完整性检测

但是被检查的函数，可是有 13 行的，所以我们直接对 RET 这行所在的地址进行 hook, 别的什么都不用做就可以成功的绕过完整性检测～

# 字符串解密算法分析

那么如何才能成功的输出解密后的字符串呢？我又回去看了看 hook ms.bd.c.l.a 函数之后打印出来的日志，于是想着去调用最初的几个字符串参数去看看情况

没想到 .ms 和 .md 一起调用的时候， com.bytedance.ttnet.TTNetInit 可以正常输出

而单独调用 com.bytedance.ttnet.TTNetInit 输出的却是乱码

那先调用 .ms 和 .md , 再调用之前解密出乱码的那个密文？

这次字符串被成功的解密出来了！

所以这个加密算法也很明了了，前两次被解密的字符串初始化了密钥，他们和后续字符串解密算法所使用的密钥有所关联的

现在我们用 jnitrace 去 trace 一下解密 .ms 时的 JNI 调用

jnitrace -l libmetasec_ml.so -b fuzzy com.ss.android.ugc.awemea

在 0x128b24 的位置读取了传入的字符串密钥和密文，它所在的函数名为 sub_128AAC

在 0x5664c 的位置是出现了被解密的字符串，它所在的函数名为 sub_5611C

进入 sub_128B88 后我们发现，实际上在 sub_5611C 最后调用的 sub_128B88 才是 NewStringUTF 的位置

接下来我们在读取输入的函数 sub_128AAC 打印一下堆栈，来看看究竟是什么函数调用了他们

结果如下，堆栈回溯的地址都指向了 sub_5611C

在这个函数中，初始密钥为 0x71,0x62,0x13,0x14,0x5f,0x77,0x63,0x41,0x31,0x30 , 随后做了读取 str 密钥，密文的操作，并将初始密钥与传入的密钥循环异或生成二次密钥

随后二次密钥与密文循环异或实现解密，但是如果没有没有实现字符串解密的两次初始化 .ms 和 .md 的话，将会对解密后的数组再次异或密钥，并异或 0x55, 通过这种方式来隐去密钥的相关特征

所以最终的字符串解密算法如下～

	#code: 0x1000001
	def douyin_str_dec(key: str, enc: list):
	init_key = [0x71, 0x62, 0x13, 0x14, 0x5f, 0x77, 0x63, 0x41, 0x31, 0x30]
	key = [ord(key[i % len(key)]) ^ init_key[i] for i in range(len(init_key))]
	ret = [enc[i] ^ key[i % len(key)] for i in range(len(enc))]
	return bytes(ret).decode()

	# com.bytedance.ttnet.TTNetInit
	print(douyin_str_dec("976bf9",
	[43, 58, 72, 88, 91, 55, 46, 19, 99, 51, 38, 54, 64, 88, 77, 58, 52, 19, 115, 124, 28,1, 107, 19, 77, 7, 52, 31, 115]))

frida inline hook原理分析及实践

2024-08-12T19:11:00.000Z

# 前言

最近需要对一个固件的 arm64 linux 系统中的一个进程进行 inline hook, 然而当把 frida-inject 上传上去之后运行却发现，由于 linux 版本为 4.4 有些古老了，并且比正常的 linux 缺了一些文件，导致 frida 一运行就报错退出，所以就想着能不能自己去实现一个 inline hook. 但在这之前我们得先知道原理才行～如果想知道 inline hook 的原理是什么样子的，我认为最好的办法就是直接去看看 hook 之后的代码变成了什么样子，用调试的方法研究 frida 实现 inline hook 的具体实现

首先我们对一个测试 apk 注入下面的脚本实现 hook

	function hook_dlopen(soName = '') {
	Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
	{
	onEnter: function (args) {
	var pathptr = args[0];
	if (pathptr !== undefined && pathptr != null) {
	var path = ptr(pathptr).readCString();
	if (path.indexOf(soName) >= 0) {
	this.is_can_hook = true;
	}
	}
	},
	onLeave: function (retval) {
	if (this.is_can_hook) {
	//do your own code
	hook_native()
	}
	}
	}
	);
	}

	function hook_native(){
	var module = Process.findModuleByName("liboacia.so");
	Interceptor.attach(module.base.add(0x10B0), {
	onEnter: function (args) {
	console.log("hook test apk at ",module.base.add(0x10B0))
	console.log("pid = ",Process.getCurrentThreadId())
	console.log(this.context.x0)
	},
	onLeave: function (ret) {
	}
	});
	}

	setImmediate(hook_dlopen, "liboacia.so")

	oriole:/ # /data/local/tmp/fs16.3.3 &
	frida -U -l .\hook.js -f com.oacia.apk_protect

被 hook 的代码如图所示

注入完成之后，我们使用 lldb 去调试看看

# lldb 动态调试

先到 ndk\26.1.10909125\toolchains\llvm\prebuilt\windows-x86_64\lib\clang\17\lib\linux\aarch64 把 lldb-server 推送到手机上

adb push .\lldb-server /data/local/tmp

随后在手机上启动 lldb-server

./lldb-server platform --server --listen unix-abstract:///data/local/tmp/debug.sock &

然后找到 ndk\26.1.10909125\toolchains\llvm\prebuilt\windows-x86_64\bin\lldb.cmd , 运行这个 cmd

.\lldb.cmd

进入后设置要连接的类型为 remote-android

platform select remote-android

然后连接安卓中的 lldb-server

platform connect unix-abstract-connect:///data/local/tmp/debug.sock

使用 platform status 查看是否已经连接

之后 attach 到指定的包名上

process attach -p [pid]

error: attach failed: Connection shut down...

我在使用 lldb 的过程中出现了这个报错

	(lldb) process attach -p 32883
	error: attach failed: Connection shut down by remote side while waiting for reply to initial handshake packet

网上都说是开了 SELinux 的问题，我把 SELinux 临时设置为 0 还是没有解决这个 error

	oriole:/data/local/tmp # setenforce 0
	oriole:/data/local/tmp # getenforce Permissive

没办法，只能用 logcat 看看日志了，随后发现了这条日志，但是木有作用

E adbd: failed to connect to socket 'localabstract:': could not connect to localabstract address 'localabstract:'

后来排查了一下午，原来是我为了防止进程名检测，保留了过去 ida-server 和 frida-server push 到手机里面之后修改文件名的习惯，把 llbd-server 的名字改成了 lldb26 , 然后…attach 的时候就报错了（改个文件名都不行 -,-

随后打个断点

(lldb) breakpoint set -s liboacia.so -a 0x10B0

通过对 hook 地址的反编译，发现了很有意思的点就是从 hook 地址开始的后 16 个字节的汇编都和原来不一样了，但是 lldb 的汇编看起来很奇怪

	0x6e84a900b0: 0x58000050 ldr x16, #0x8
	0x6e84a900b4: 0xd61f0200 br x16
	0x6e84a900b8: 0xb092a400 adrp x0, -895871
	0x6e84a900bc: 0x00000071 udf #0x71

这段汇编给 x16 寄存器赋值为相对偏移 #0x8 位置的值，然后再去进行 BR 跳转，这后两行的指令 adrp x0, -895871 和 udf #0x71 压根就不是指令，而是一个八字节的一级跳板要跳往的地址

不得不说 lldb 确实是一个非常强大的动调工具，我觉得使用 lldb 的 python API 直接用脚本和汇编交互的样子一定非常的厉害，等之后分析抖音的 vmp 的时候在用它吧

想看正确的汇编怎么办呢，上 IDA!

# IDA 动态调试分析 hook 跳板

IDA 直接附加的话是附加不上的，原因在于 apk 设置了 android:extractNativeLibs="false" 导致 so 不会被解压到 /data/app/...com.oacia.apk_protect/lib/arm64 文件夹中，而是直接从 apk 中加载，所以 IDA 也就找不到这个 so 加载的时候了，这种情况下我们把要调试的 liboacia.so 用 MT 管理器直接复制到 /data/app/...com.oacia.apk_protect/lib/arm64 里面去就可以了，同时注意需要给这个 so rwx 的运行权限

# 一级跳板

有了 IDA 强大的反编译功能，这里的汇编也是显示了出来，从 hook 点开始的 16 个字节全部被一级跳板的字节码覆盖了，前 8 字节是两行汇编，用来实现跳板的跳转，后八字节存储了跳板要跳往的地址

这里使用的是 x16 和 x17 寄存器，那为什么使用这两个寄存器呢？

根据 arm64 官网描述，x16 和 x17 是程序内调用临时寄存器，也就是平时根本不会用他们，所以把这两个寄存器用作跳板是再合适不过的

X16 and X17 are IP0 and IP1, intra-procedure-call temporary registers. These can be used by call veneers and similar code, or as temporary registers for intermediate values between subroutine calls. They are corruptible by a function. Veneers are small pieces of code which are automatically inserted by the linker, for example when the branch target is out of range of the branch instruction.

那顺便也记一下其他寄存器的作用好了

X0-X7: 参数寄存器，用于传递函数参数和返回结果，要是参数比八个多的话就会用堆栈去传递
X8: 用来存放函数返回值的，不过这个寄存器比较特殊一点，只有当返回值是大型结构体的时候才会用 x8 去返回，其余情况都是用 x0 去返回的
X9-X15: 临时寄存器，这 7 个寄存器是用来存储临时数据的
X16-X17: 他们是给编译器使用的，正常的程序都不会使用他们，所以当作跳板是相当的合适
X18: 平台寄存器，基本是不用的
X19-X28: 保存寄存器，这 10 个寄存器用来保存函数调用上下文
X29: FP 寄存器，用于连接栈帧
X30: 也叫 LR 寄存器，用于保存子程序的返回地址
X31: SP 寄存器，用于指向每个函数的栈顶
SP： SP 是栈顶指针寄存器，类似 Intel 64 中的 RSP 寄存器
PC： PC 寄存器存储当前要执行的指令地址，类似 Intel 64 中的 RIP 寄存器

# 二级跳板

二级跳板中 X17 保存了返回地址，也就是我们本身的 hook 地址的值，而 X16 则保存了三级跳版的位置，而在二级跳板的下方，竟然还有一个跳板，不过现在还没有看到它的用途所在

这里二级跳板有啥用？为啥不直接跳到三级跳板？

# 三级跳板

这三级跳板总共干了三件事情

# 保存寄存器环境

# 跳转到核心代码

经过三个跳板的层层跳转，我们也是终于来到了 frida_agent_64.so 中执行我们编写的 hook 逻辑比如打印寄存器，读取内存等操作了

# 恢复寄存器环境

使用 LDP 加载栈中保存的寄存器环境

# 恢复执行流

由于 hook 所生成的跳板函数会对 hook 位置的 16 字节汇编进行覆盖，所以必须要对被覆盖的那 16 字节汇编再次执行，否则将会对执行流产生影响。在三级跳板的最后 RET X16 , 将会来到跳转到此处执行先前未完成的汇编

# 自实现 inline hook

虽说要 hook 的目标是 arm64 linux, 但是本人对于安卓更为熟悉一些，所以这里的示例也使用的是 android (毕竟都是 arm64 架构，hook 肯定是通用的)

先写个一键编译的 run.bat 脚本，这样运行一下连带编译传输到手机上的步骤都一步到位了～

	"E:\Program Files\CLion 2024.1\bin\cmake\win\x64\bin\cmake.exe" --build E:\analysis\frida-inline-hook\self_hook\cmake-build-android --target hook-server -j 14
	adb push .\cmake-build-android\hook-server /data/local/tmp
	adb shell "chmod 777 /data/local/tmp/hook-server"
	adb shell su -c "/data/local/tmp/hook-server"

# ptrace 注入

如果我们要自己去实现对进程的注入，那么首先要做的就是使用 ptrace 的 PTRACE_ATTACH 附加到这个进程上面去

	void ptraceAttach(pid_t pid){
	if(ptrace(PTRACE_ATTACH,pid,NULL,NULL)==-1){
	printf("[ptrace] Failed to attach:%d\n",pid);
	}
	else{
	printf("[ptrace] Attach to pid %d\n",pid);
	}
	int stat=0;
	/* 在用 ptrace 去 attach 一个进程之后，那个被 attach 的进程某种意义上说可以算作那个 attach
	* 进程的子进程，这种情况下，就可以通过 waitpid 这个函数来知道被调试的进程何时停止运行
	*
	* @param option->WUNTRACED: 如果子进程进入暂停状态，则马上返回。*/
	waitpid(pid,&stat,WUNTRACED);
	}

一旦我们使用 ptrace 附加了上去，这就意味着我们有了对这个进程空间中的内存进行操作的权力，现在我们需要知道的是目标 so 库的基址在什么地方，这样我们才可以通过在 ida 中静态分析找到的 hook 点的偏移，来找到 hook 点的虚拟内存地址，而这可以通过遍历 maps 来实现

	void* findModuleByName(pid_t pid,const char* libname){
	// 获取 hook-server 的 pid, 这样可以通过本地 libc 库函数地址 - 本地 libc 基址 + 远程 libc 基址得到远程 libc 库函数地址
	if(pid==-1){
	pid=getpid();
	}
	char maps[MAX_PATH];
	void* base_addr = 0;
	snprintf(maps,MAX_PATH,"/proc/%d/maps",pid);
	FILE *f = fopen(maps,"r");
	char line[MAX_PATH],name[MAX_PATH];
	char *base;
	while(!feof(f)){
	memset(line,0,MAX_PATH);
	fgets(line,MAX_PATH,f);
	//printf("%s\n",line);
	// 查找指定模块是否在某行出现
	if(strstr(line,libname)){
	//maps 形式: base-end [rwxsp] offset dev inode pathname
	//eg. 6f1305e000-6f13060000 r-xp 00000000 fe:2e 90655 /lib/arm64/liboacia.so

	/*
	* https://man7.org/linux/man-pages/man5/proc_pid_maps.5.html
	* The [offset] field is the offset into the file/whatever;
	* [dev] is the device (major:minor);
	* [inode] is the inode on that device. 0 indicates that no inode is associated with the memory
	* region, as would be the case with BSS (uninitialized data).
	* If the [pathname] field is blank, this is an anonymous mapping as obtained
	* via the mmap(2) function. There is no easy way to coordinate this back to
	* a process's source, short of running it through gdb(1), strace(1), or similar.*/
	base = strtok(line, "-");// 以 `-` 为分隔符，读取基址
	base_addr = (void*)strtoul(base, NULL, 16);
	printf("[maps] find module [%s] base at 0x%08lx\n",libname,base_addr);
	break;
	}
	}
	fclose(f);
	return base_addr;
	}

现在我们尝试去读取一下 hook 点的汇编，来看看 ptrace 究竟有没有生效，这可以通过 PTRACE_PEEKTEXT 来实现

	void ptraceReadData(pid_t pid,void* addr,char*data,size_t len){
	size_t i=0;
	long rdata;
	for(;i<len;i+=sizeof(long)){
	rdata=ptrace(PTRACE_PEEKTEXT,pid,(long)addr+i,NULL);
	(long)&data[i]=rdata;
	}
	}

nice, 将通过 ptrace 读取的汇编和 ida 中反编译出来的汇编对比一下，简直就是一模一样～

# 为字符串分配内存

接下来我们需要通过 dlopen 加载我们的功能库 so, 而这必定会涉及到字符串相关的内存，为了让目标字符串可以被远程的进程访问到，所以我们必须要通过 mmap 在远程的进程空间中分配一块属于我们自己的，可以自由操控的内存

在这之前，我们先对当前的寄存器环境进行保存，以便之后可以还原寄存器的环境

	void ptraceGetRegs(pid_t pid,struct user_pt_regs *regs_addr){
	struct iovec io;
	io.iov_base = regs_addr;
	io.iov_len = sizeof(struct user_pt_regs);
	//NT_PRSTATUS: general-purpose registers, 定义在 elf.h 中
	/**
	* PTRACE_GETREGSET
	* 读取被追踪者寄存器。addr 参数决定读取寄存器的类型。
	* 如果 addr 是 NT_PRSTATUS，则读取通用寄存器。
	* 如果 addr 是 NT_foo，则读取浮点或向量寄存器（如果有的话)。data 参数指向 iovec 类型：
	*/
	if(ptrace(PTRACE_GETREGSET,pid,NT_PRSTATUS,&io)==-1){
	printf("Get regs failed");
	}
	}
	void inject(pid_t pid){
	...
	struct user_pt_regs oldRegs;
	struct user_pt_regs regs;
	// 保存寄存器环境
	ptraceGetRegs(pid,&oldRegs);
	memcpy(&regs,&oldRegs, sizeof(struct user_pt_regs));
	...
	}

接下来我们去获取一下 mmap 在远程空间中的位置，在 android 中， mmap 是在 libc 库中被定义的，具体的位置是在 /apex/com.android.runtime/lib64/bionic/libc.so , 由于 mmap 在 libc.so 中的相对偏移是固定的，而我们可以在 hook-server 内部直接获取到 mmap 函数的本地地址 (利用 *mmap 获取函数指针即可实现), 所以我们再读取一下 hook-server 中的 libc.so 的基址，相减即可得到 mmap 函数的相对偏移，把这个相对偏移再加上被 hook 的进程中的 libc.so 的基址，不就可以得到 mmap 函数在远程进程中的地址咯

	void* getRemoteLibFunc(pid_t pid,const char* libname,void* LocalFuncAddr){
	void LocalLibBase,RemoteLibBase,*RemoteFuncAddr;
	LocalLibBase = findModuleByName(-1,libname);//-1 表示在当前 hook-server 的 maps 中寻找库的基址
	RemoteLibBase = findModuleByName(pid,libname);
	RemoteFuncAddr = LocalFuncAddr-LocalLibBase+RemoteLibBase;
	printf("LocalLibBase: 0x%08lx, LocalFuncAddr: 0x%08lx\nRemoteLibBase: 0x%08lx, func offset: 0x%08lx\n",LocalLibBase,LocalFuncAddr,RemoteLibBase,LocalFuncAddr-LocalLibBase);
	return RemoteFuncAddr;
	}

	void inject(pid_t pid){
	...
	// 通过 mmap 为跳板分配内存
	void* RemoteMmapAddr = getRemoteLibFunc(pid,"libc.so",(void*)mmap);
	printf("[libc] find remote mmap addr at 0x%08lx\n",(long)RemoteMmapAddr);
	...

	}

随后再去设置一下寄存器和 pc 的值，mmap 就能被我们成功的调用了，ptrace 主动调用的细节可以看我写的注释↓

	#define CPSR_T_MASK (1u<<5)
	#define ARM_lr regs[30]
	void ptraceCall(pid_t pid,void* funcaddr,int argc,long* argv,struct user_pt_regs *regs){
	// 比八个参数多的话，多出的参数通过栈去传参
	if(argc>8){
	regs->sp =regs->sp - (argc-8)*(sizeof(long));// 申请 8 个寄存器的栈空间
	ptraceWriteData(pid,(void)regs->sp,(char)&argv[8],sizeof(long)*(argc-8));
	}
	// 少于 8 个参数，就通过 x0~x7 寄存器去传参
	for(size_t i=0;i<8;i++){
	regs->regs[i] = argv[i];
	}

	regs->pc = (__u64) funcaddr;// 将 pc 寄存器的值修改为函数地址，这样我们就可以跳转到函数的目标地址去执行 arm64 指令了
	printf("[ptraceCall] funcaddr: 0x%08lx\n",regs->pc);
	if(regs->pc&1){
	//thumb 模式
	// 当 pc 的最后一位为 1, 即 pc 为奇数时，设置 pstate CPSR 的 T 标志位为 1, 表示接下来的指令以 thumb 模式执行
	regs->pc&=~1;
	//pstate, 这是 arm64v8a 的叫法，在 armv7a 中叫 CPSR 寄存器
	//more-> https://blog.csdn.net/longwang155069/article/details/105204547
	regs->pstate\|=CPSR_T_MASK;
	}else{
	//arm 模式
	// 当 pc 的最后一位为 0, 即 pc 为偶数时，清除 pstate CPSR 的 T 标志位，表示接下来的指令以 arm 模式执行
	regs->pstate&=~CPSR_T_MASK;
	}

	regs->ARM_lr = 0;// 设置 lr 寄存器为 0, 要是函数执行完毕之后返回 0 地址会抛出异常，这个异常在后面是有用的
	ptraceSetRegs(pid,regs);// 设置寄存器的值，把函数的参数和地址传进寄存器里面
	int stat = 0;
	/**
	* 对于使用 ptrace_cont 重新运行的进程，它会在 3 种情况下进入暂停状态
	* 1. 下一次系统调用
	* 2. 子进程退出
	* 3. 子进程的执行发生错误
	* 这里的 0xb7f 我们可以拆分成两部分来看，后 2 字节 0x7f, 表示进程进入了暂停的状态
	* (如果后两字节是 0x00 则表示子进程退出状态), 而前两字节 0xb, 表示进程发送的错误信号为 11 (SIGSEGV),
	* 即内存访问异常，因为我们之前将 lr 寄存器的值设为了 0, 所以当远程函数调用完毕之后会抛出异常，
	* 当 ptrace 收到这个异常信号时，就知道远程函数调用以及完成了～
	*/
	while(stat!=0xb7f){
	ptraceContinue(pid);// 让被 ptrace 的线程开始运行
	waitpid(pid,&stat,WUNTRACED);
	printf("[ptraceCall] stat: 0x%04x\n",stat);
	}

	ptraceGetRegs(pid,regs);// 当远程函数调用完成之后，读取寄存器获取返回值
	}

	void inject(pid_t pid){
	...
	// 调用 mmap 函数
	long paras[6];
	paras[0]= 0;
	paras[1]=0x1000;
	paras[2]=PROT_READ\|PROT_WRITE\|PROT_EXEC;
	paras[3]=MAP_ANONYMOUS\|MAP_PRIVATE;
	paras[4]=0;
	paras[5]=0;
	ptraceCall(pid,RemoteMmapAddr,6,paras,&regs);
	void RemoteMemAddr = (void )regs.regs[0];//mmap 返回值存储在 x0 中，从 x0 获取远程的 mmap 函数分配的内存
	printf("[libc] mmap alloc memory at 0x%08lx\n",(long)RemoteMemAddr);
	...
	}

# 加载 hook 功能库 so

现在我们已经通过 mmap 成功的在被 hook 进程中分配了一块内存，接下来要做的是在被 hook 进程中加载我们的 hook 功能库 so, 这个 so 是跳板最终要跳往的地方，用来执行打印或修改寄存器的操作，我们现在就把这个 so 的名称叫做 libhook-agent.so 吧，当前代码如下，通过远程调用 work_func 来观察我们的 so 是否被成功的加载进来

	//hook-agent.c
	#include "stdio.h"
	#include <android/log.h>

	#define LOG_TAG "hook-agent"
	#define LOGD(...) ((void)__android_log_print(ANDROID_LOG_DEBUG , LOG_TAG, __VA_ARGS__))
	int work_func(){
	LOGD("call work_func ok!");
	return 777;
	}

首先我们先获取一下 dlopen 在远程进程中的地址，随后将要加载的 so 的绝对地址写入 mmap 分配的内存中，再去调用 ptrace 调用一下 dlopen 函数就可以啦

	// 获取 dlopen 在远程进程中的地址
	void* RemoteDlopenAddr = getRemoteLibFunc(pid,"libdl.so",(void*)dlopen);
	printf("[libdl] find remote dlopen addr at 0x%08lx\n",(long)RemoteDlopenAddr);

	/**
	* 将要加载的 so 的绝对地址写入 mmap 分配的内存中，可以把 so 放在 app 的私有目录下面，
	* 要是放在 /data/local/tmp 目录下面，会遇到 avc denied,
	* 这个时候需要使用 setenforce 0 临时禁用掉 selinux 才可以
	*/
	ptraceWriteData(pid,RemoteMemAddr,"/data/data/com.oacia.apk_protect/libhook-agent.so",strlen("/data/data/com.oacia.apk_protect/libhook-agent.so")+1);

	// 调用 dlopen 函数
	paras[0] = (long) RemoteMemAddr;
	paras[1]=RTLD_NOW\|RTLD_GLOBAL;
	ptraceCall(pid,RemoteDlopenAddr,2,paras,&regs);
	void HookAgentAddr = (void )regs.regs[0];//dlopen 返回值存储在 x0 中，从 x0 获取远程的 dlopen 返回的 handle
	printf("[libdl] dlopen libhook-agent.so addr: 0x%08lx\n\n",(long)HookAgentAddr);

HookAgentAddr 的值不为空，说明 libhook-agent.so 被成功的加载了进来

随后我们再使用远程进程的 dlsym , 找到 libhook-agent.so 功能函数的地址，并主动调用 work_func 来看一下情况

	//dlsym 获取调用函数的地址
	void* RemoteDlsymAddr = getRemoteLibFunc(pid,"libdl.so",(void*)dlsym);
	printf("[libdl] find remote dlsym addr at 0x%08lx\n",(long)RemoteDlsymAddr);
	// 将被调用函数的函数名写入 mmap 分配的内存中
	ptraceWriteData(pid,RemoteMemAddr,"work_func",strlen("work_func")+1);
	paras[0] = (long) HookAgentAddr;
	paras[1]= (long) RemoteMemAddr;
	ptraceCall(pid,RemoteDlsymAddr,2,paras,&regs);
	void* remoteFuncAddr = (void *)regs.regs[0];
	printf("[libdl] dlsym find hook-agent function addr at 0x%08lx\n",(long)remoteFuncAddr);
	ptraceCall(pid,remoteFuncAddr,0,paras,&regs);// 主动调用 hook-agent 中的 work_func
	int checkOK = (int)regs.regs[0];
	printf("call wrok_func in libhook-agent.so, ret -> %d\n",checkOK);

nice! 函数被成功的调用了，并且返回值也是和 work_func 中的返回值一模一样

而此时的 logcat, 也有日志被正确的打印出来

# 在 hook 点 patch 上跳板

现在我们需要在 hook 点 patch 跳板，目前来看最初使用的跨进程通过 ptrace 的 PTRACE_POKETEXT 在进程中写入跳板的方式，似乎是存在 bug 的，写入字节的次数的过多的话被 hook 进程就会崩溃，并且跨进程通过 ptrace 调用 mprotect 将 hook 处的页属性改为 rwx 没有生效，写入时进程就会崩溃

通过ptrace的`PTRACE_POKETEXT`进行patch

接下来我们使用 X16 寄存器，在 hook 点 patch 上一级跳板，这个一级跳板将会跳往二级跳板

	void write_trampoline_stage1(pid_t pid,void* target,char* libname,int offset,char* save_code){
	void* RemoteLibBase = findModuleByName(pid,libname);
	long hook_addr = (long)RemoteLibBase+offset;

	// 生成跳板函数
	unsigned char trampoline[16] = {
	0x50,0x00,0x00,0x58,//LDR X16,#0x8
	0x00,0x02,0x1f,0xD6,//BR X16
	};
	for(int i=0;i<8;i++){
	trampoline[i+8] = ((char)target+i);
	}

	// 读取即将被覆盖的指令
	ptraceReadData(pid, (void *) hook_addr, save_code, 0x10);

	// 写入跳板
	ptraceWriteData(pid, (void ) hook_addr, (char)trampoline, 16,0);
	}

	// 写入一级跳板汇编
	char save_code[16];// 保存被跳板覆盖的指令，在完成 hook 之后这 4 行汇编需要被执行
	memset(save_code,0,16);
	write_trampoline_stage1(pid,RemoteMemAddr,"liboacia.so",0x10B0,save_code);

在二级跳板这里，我们直接将保存寄存器环境，跳往功能函数，恢复寄存器环境，执行被跳板覆盖的汇编的这四个过程直接合在一起

	void write_trampoline_stage2(pid_t pid,void* patch_addr,char* libname,int offset,const char* save_code,void* hook_agent_func_addr){
	void* RemoteLibBase = findModuleByName(pid,libname);
	long hook_addr = (long)RemoteLibBase+offset;
	long ret_addr = hook_addr+16;
	// 生成跳板函数，trampoline bytes are from frida hook decompile
	char trampoline[360] = {
	// 保存寄存器环境
	0xff,0x43,0x00,0xd1,
	0xfe,0x7f,0xbf,0xad,
	0xfc,0x77,0xbf,0xad,
	0xfa,0x6f,0xbf,0xad,
	0xf8,0x67,0xbf,0xad,
	0xf6,0x5f,0xbf,0xad,
	0xf4,0x57,0xbf,0xad,
	0xf2,0x4f,0xbf,0xad,
	0xf0,0x47,0xbf,0xad,
	0xee,0x3f,0xbf,0xad,
	0xec,0x37,0xbf,0xad,
	0xea,0x2f,0xbf,0xad,
	0xe8,0x27,0xbf,0xad,
	0xe6,0x1f,0xbf,0xad,
	0xe4,0x17,0xbf,0xad,
	0xe2,0x0f,0xbf,0xad,
	0xe0,0x07,0xbf,0xad,
	0xfd,0x7b,0xbf,0xa9,
	0xfb,0x73,0xbf,0xa9,
	0xf9,0x6b,0xbf,0xa9,
	0xf7,0x63,0xbf,0xa9,
	0xf5,0x5b,0xbf,0xa9,
	0xf3,0x53,0xbf,0xa9,
	0xf1,0x4b,0xbf,0xa9,
	0xef,0x43,0xbf,0xa9,
	0xed,0x3b,0xbf,0xa9,
	0xeb,0x33,0xbf,0xa9,
	0xe9,0x2b,0xbf,0xa9,
	0xe7,0x23,0xbf,0xa9,
	0xe5,0x1b,0xbf,0xa9,
	0xe3,0x13,0xbf,0xa9,
	0xe1,0x0b,0xbf,0xa9,
	0x01,0x42,0x3b,0xd5,
	0xe1,0x03,0xbf,0xa9,
	0xe0,0x43,0x0c,0x91,
	0xff,0x03,0xbf,0xa9,
	0xfe,0x8f,0x01,0xf9,
	0xfd,0x8b,0x01,0xf9,
	0xfd,0x43,0x0c,0x91,
	0xe1,0x03,0x00,0x91,
	0xe2,0x23,0x04,0x91,
	0xe3,0x43,0x0c,0x91,

	// 跳转到核心代码
	0xe0,0x03,0x11,0xaa,
	0x64,0x05,0x00,0x58,
	0x80,0x00,0x3f,0xd6,

	// 还原寄存器环境
	0xff,0x43,0x00,0x91,
	0xe1,0x03,0xc1,0xa8,
	0x01,0x42,0x1b,0xd5,
	0xe1,0x0b,0xc1,0xa8,
	0xe3,0x13,0xc1,0xa8,
	0xe5,0x1b,0xc1,0xa8,
	0xe7,0x23,0xc1,0xa8,
	0xe9,0x2b,0xc1,0xa8,
	0xeb,0x33,0xc1,0xa8,
	0xed,0x3b,0xc1,0xa8,
	0xef,0x43,0xc1,0xa8,
	0xf1,0x4b,0xc1,0xa8,
	0xf3,0x53,0xc1,0xa8,
	0xf5,0x5b,0xc1,0xa8,
	0xf7,0x63,0xc1,0xa8,
	0xf9,0x6b,0xc1,0xa8,
	0xfb,0x73,0xc1,0xa8,
	0xfd,0x7b,0xc1,0xa8,
	0xe0,0x07,0xc1,0xac,
	0xe2,0x0f,0xc1,0xac,
	0xe4,0x17,0xc1,0xac,
	0xe6,0x1f,0xc1,0xac,
	0xe8,0x27,0xc1,0xac,
	0xea,0x2f,0xc1,0xac,
	0xec,0x37,0xc1,0xac,
	0xee,0x3f,0xc1,0xac,
	0xf0,0x47,0xc1,0xac,
	0xf2,0x4f,0xc1,0xac,
	0xf4,0x57,0xc1,0xac,
	0xf6,0x5f,0xc1,0xac,
	0xf8,0x67,0xc1,0xac,
	0xfa,0x6f,0xc1,0xac,
	0xfc,0x77,0xc1,0xac,
	0xfe,0x7f,0xc1,0xac,
	0xf0,0x47,0xc1,0xa8,

	// 执行先前因 patch 跳板被覆盖的代码，16 字节占位
	0xaa,0xaa,0xaa,0xaa,
	0xaa,0xaa,0xaa,0xaa,
	0xaa,0xaa,0xaa,0xaa,
	0xaa,0xaa,0xaa,0xaa,

	// 返回 hook 点之后的位置继续执行逻辑
	0x50,0x00,0x00,0x58,
	0x00,0x02,0x1f,0xD6,

	//8 字节占位，存储功能函数的地址
	0xbb,0xbb,0xbb,0xbb,
	0xbb,0xbb,0xbb,0xbb,

	//8 字节占位，存储功能 hook 完成后返回到原来程序的地址
	0xcc,0xcc,0xcc,0xcc,
	0xcc,0xcc,0xcc,0xcc,

	};
	for(int i=0;i<16;i++){
	trampoline[i+320] = save_code[i];
	}
	for(int i=0;i<8;i++){
	trampoline[i+344] = ((char)hook_agent_func_addr+i);
	}

	for(int i=0;i<8;i++){
	trampoline[i+352] = ((char)ret_addr+i);
	}

	ptraceWriteData(pid, (void *) patch_addr, trampoline, 360,0);

	}

所以可以想想换一种方法，既然 so 可以注入进去，那就直接在 so 加载的时候，通过 __attribute__((constructor)) , 在通过这个 so 在被 hook 进程内部执行 patch 跳板的逻辑不就可以了

	/**
	* 完成一次完整的 hook, 需要先由 hook 点的一级跳板跳转到二级跳板的位置，
	* 一级跳板通过 BR X16 跳往二级跳板，二级跳板保存寄存器的环境，跳转到 hook 的
	* 功能函数位置，随后还原寄存器环境，并执行先前被覆盖的四条汇编
	* , 随后通过 BR X16 寄存器，跳往 hook 点之后的位置，完成一次完整的 hook
	*
	*/
	static __attribute__((constructor)) void ctor()
	{
	u_long hook_addr = (u_long)findModuleByName(-1,"liboacia.so")+0x10B8;
	LOGD("hook-agent init!");
	extern u_long _trampoline_,_shellcode_addr_,_shellcode_start_,_shellcode_end_,_origin_patched_code_,_hook_main_func_addr_,_hook_finish_return_addr_;
	u_long total_len = (u_long)&_shellcode_end_ - (u_long)&_shellcode_start_;
	LOGD("shellcode len: %lu, hook_addr: 0x%08lx,offset: 0x%04x",total_len,hook_addr,0x10B8);

	// 为 shellcode 分配内存
	u_long page_size = getpagesize();
	u_long shellcode_mem_start = (u_long)mmap(0, page_size, PROT_READ \| PROT_WRITE \| PROT_EXEC, MAP_ANONYMOUS \| MAP_PRIVATE, 0, 0);
	memset((void *)shellcode_mem_start, 0, page_size);
	memcpy((void )shellcode_mem_start, (void )&_shellcode_start_, total_len);
	LOGD("_shellcode_addr_: 0x%08lx,shellcode_mem_start: 0x%08lx",(u_long)&_shellcode_addr_, shellcode_mem_start);

	// 尝试了一下好像没有办法给_shellcode_addr_赋值 (很奇怪)
	// 所以索性直接这样赋值了 (u_long)(hook_addr + 8) = shellcode_mem_start;
	//(u_long)&_shellcode_addr_ = (u_long)shellcode_mem_start;

	// 通过相对偏移的方式，定位到需要替换的地址在 mmap 分配的内存中的地址
	u_long mem_hook_main_func_addr_ = (u_long)&_hook_main_func_addr_ - (u_long)&_shellcode_start_ + shellcode_mem_start;
	u_long mem_origin_patched_code_ = (u_long)&_origin_patched_code_ - (u_long)&_shellcode_start_ + shellcode_mem_start;
	u_long mem_hook_finish_return_addr_ = (u_long)&_hook_finish_return_addr_ - (u_long)&_shellcode_start_ + shellcode_mem_start;
	//hook 的功能函数的地址
	(u_long)mem_hook_main_func_addr_ = (u_long)hook_main;
	// 被跳板覆盖前，hook 点的 16 字节
	(u_long)mem_origin_patched_code_ = (u_long)hook_addr;
	(u_long)(mem_origin_patched_code_ + 8) = (u_long)(hook_addr + 8);

	//hook 执行完毕后的返回地址
	(u_long)mem_hook_finish_return_addr_ = (u_long)hook_addr + 0x10;
	//patch 上我们的跳板
	u_long entry_page_start = (u_long)(hook_addr) & (~(page_size-1));
	mprotect((u_long*)entry_page_start, page_size, PROT_READ \| PROT_WRITE \| PROT_EXEC);
	(u_long)hook_addr = (u_long)&_trampoline_;
	(u_long)(hook_addr + 8) = shellcode_mem_start;
	}

相关的 shellcode 如下，在保存寄存器环境时，CPSR 寄存器也要一起保存，但是看 frida hook 之后的样子，只需要保存 NZCV 寄存器就足够了，所以这里也不对 CPSR 寄存器的其他字段作保存了

	#在hook点patch上跳板,跳转到我们的shellcode
	.global _trampoline_
	#shellcode所在的地址,跳板需要跳转到shellcode
	.global _shellcode_addr_
	#shellcode的起始地址和结束地址,用来定位shellcode的大小以及字节
	.global _shellcode_start_
	.global _shellcode_end_
	#被跳板覆盖的16字节指令,这些指令我们需要在hook完成之后再次执行,才不会影响到原本的逻辑
	.global _origin_patched_code_
	#跳转到hook的核心功能函数的地址去执行读取寄存器/修改寄存器等操作
	.global _hook_main_func_addr_
	#当所有的hook逻辑执行完毕之后,需要返回到hook点后16字节的位置去执行后续的指令
	.global _hook_finish_return_addr_
	_trampoline_:
	LDR X16, SHELLCODE_ADDR
	BR x16
	#这里需要先声明SHELLCODE_ADDR的地址,否则会出现ld: error: relocation R_AARCH64_LD_PREL_LO19 cannot be used against symbol '_shellcode_addr_'
	#就是说不能用已经声明过全局的符号来作重定位
	SHELLCODE_ADDR:
	_shellcode_addr_:
	.dword 0x1234567812345678
	_shellcode_start_:
	#本来想参考https://github.com/zzyccs/inlineHook/blob/master/app/src/main/cpp/inline_shellcode.S
	#手动通过STP寄存器的大小一个一个算出存入堆栈的地址的
	#但是看了一下frida,直接用STP Xt1, Xt2, [Xn\|SP, #imm]! ; 64-bit
	#这种预索引的方式修改SP的值,这样就不需要size0,size1...的方式去计算寄存器存储的位置
	#可以达到持续入栈的效果,太厉害啦
	STP Q30, Q31, [SP,#-0x20]!
	STP Q28, Q29, [SP,#-0x20]!
	STP Q26, Q27, [SP,#-0x20]!
	STP Q24, Q25, [SP,#-0x20]!
	STP Q22, Q23, [SP,#-0x20]!
	STP Q20, Q21, [SP,#-0x20]!
	STP Q18, Q19, [SP,#-0x20]!
	STP Q16, Q17, [SP,#-0x20]!
	STP Q14, Q15, [SP,#-0x20]!
	STP Q12, Q13, [SP,#-0x20]!
	STP Q10, Q11, [SP,#-0x20]!
	STP Q8, Q9, [SP,#-0x20]!
	STP Q6, Q7, [SP,#-0x20]!
	STP Q4, Q5, [SP,#-0x20]!
	STP Q2, Q3, [SP,#-0x20]!
	STP Q0, Q1, [SP,#-0x20]!
	STP X30, X31, [SP,#-0x10]!
	STP X28, X29, [SP,#-0x10]!
	STP X26, X27, [SP,#-0x10]!
	STP X24, X25, [SP,#-0x10]!
	STP X22, X23, [SP,#-0x10]!
	STP X20, X21, [SP,#-0x10]!
	STP X18, X19, [SP,#-0x10]!
	STP X16, X17, [SP,#-0x10]!
	STP X14, X15, [SP,#-0x10]!
	STP X12, X13, [SP,#-0x10]!
	STP X10, X11, [SP,#-0x10]!
	STP X8, X9, [SP,#-0x10]!
	STP X6, X7, [SP,#-0x10]!
	STP X4, X5, [SP,#-0x10]!
	STP X2, X3, [SP,#-0x10]!
	STP X0, X1, [SP,#-0x10]!
	#特别注意,CPSR寄存器也要保存,不然只能打印一次值然后就崩溃了-m-
	#aarch64不能和aarch32一样,直接访问CPSR得到所有的值,所以得分开来访问
	#看frida的hook之后的样子,看上去只需要保存NZCV寄存器就足够了
	MRS X1, NZCV
	#MRS X0, DAIF
	STP X0, X1,[SP,#-0x10]!

	MOV X0, SP
	LDR X16, HOOK_MAIN_FUNC_ADDR
	BLR X16

	#恢复CPSR寄存器
	LDP X0, X1, [SP],#0x10
	MSR NZCV, X1
	#MSR DAIF, X0
	#恢复X0-X31,Q0-Q31寄存器
	LDP X0, X1, [SP],#0x10
	LDP X2, X3, [SP],#0x10
	LDP X4, X5, [SP],#0x10
	LDP X6, X7, [SP],#0x10
	LDP X8, X9, [SP],#0x10
	LDP X10, X11, [SP],#0x10
	LDP X12, X13, [SP],#0x10
	LDP X14, X15, [SP],#0x10
	LDP X16, X17, [SP],#0x10
	LDP X18, X19, [SP],#0x10
	LDP X20, X21, [SP],#0x10
	LDP X22, X23, [SP],#0x10
	LDP X24, X25, [SP],#0x10
	LDP X26, X27, [SP],#0x10
	LDP X28, X29, [SP],#0x10
	LDP X30, X31, [SP],#0x10
	LDP Q0, Q1, [SP],#0x20
	LDP Q2, Q3, [SP],#0x20
	LDP Q4, Q5, [SP],#0x20
	LDP Q6, Q7, [SP],#0x20
	LDP Q8, Q9, [SP],#0x20
	LDP Q10, Q11, [SP],#0x20
	LDP Q12, Q13, [SP],#0x20
	LDP Q14, Q15, [SP],#0x20
	LDP Q16, Q17, [SP],#0x20
	LDP Q18, Q19, [SP],#0x20
	LDP Q20, Q21, [SP],#0x20
	LDP Q22, Q23, [SP],#0x20
	LDP Q24, Q25, [SP],#0x20
	LDP Q26, Q27, [SP],#0x20
	LDP Q28, Q29, [SP],#0x20
	LDP Q30, Q31, [SP],#0x20
	_origin_patched_code_:
	.dword 0x1234567812345678
	.dword 0x1234567812345678
	LDR X16, HOOK_FINISH_RETURN_ADDR
	BR X16
	HOOK_MAIN_FUNC_ADDR:
	_hook_main_func_addr_:
	.dword 0x1234567812345678
	HOOK_FINISH_RETURN_ADDR:
	_hook_finish_return_addr_:
	.dword 0x1234567812345678
	_shellcode_end_:

# 执行 hook 逻辑

这里我们的 hook 逻辑很简单，就是打印调用函数 strlen 之后 X0 的值

	void hook_main(u_long sp){
	LOGD("enter hook main!");
	//sp -- sp+0x10 存储的是 NZCV 寄存器，从 sp+0x10 开始才是 x0-x31 的位置
	u_long strlen_ret_value = (u_long)(sp+0x10);
	LOGD("hook done! target function strlen return value is 0x%08lx",strlen_ret_value);
	}

终于现在我们也可以自己完成一次简单的 hook 了！

完整代码已经传到 github 上面啦 https://github.com/oacia/inlinehook_demo

# 参考资料

Mac 中：用 lldb 调试安卓 app 进程
【工具使用】Android 调试利器之 LLDB
Android LLDB debugging
使用 GDB、LLDB 调试安卓程序
[原创] Frida inlineHook 原理分析及简单设计一款 AArch64 inlineHook 工具
Android 下实现 ptrace 注入 & hook
使用 ptrace 向已运行进程中注入.so 并执行相关函数
Android 注入要点记录

b站app漫展抢票

2024-07-13T10:14:21.000Z

# 前言

最近萌生了想去漫展的想法，毕竟这么久了还没有去过一次漫展嘞，听说 cp30 好像不错，不过问题就是票特别的难抢😔

趁现在 cp30 买票还没开始，今天也没有什么其他的事情，所以就简单分析了一下 b 站的 app，写了个抢票脚本自娱自乐一下

感觉这个 app 还是很有意思的，它把主要的 webview 业务逻辑放到子进程里运行我觉得还是很不错滴，这样 frida 注入到主进程就 hook 不到了（我就被卡了快一个小时！）

但这个抢票脚本写的相当的简陋，我就不好意思放出来啦😂不过相信大家在 github 上应该可以找到更加完善的项目吧 :)

还有就是为什么不直接去 b 站会员购网页端分析呢，这样购票接口不是一下子就看到了嘛就不需要绕各种检测了

just for fun!

# 基本信息

包名: tv.danmaku.bili

入口: tv.danmaku.bili.MainActivityV2

# frida 反调试

先看看会员购页面是哪一个 activity 的

PS D:\work\analysis\bilibili> adb shell "dumpsys activity top | grep ACTIVITY"

  ACTIVITY com.google.android.apps.nexuslauncher/.NexusLauncherActivity ad36d3f pid=2139

  ACTIVITY tv.danmaku.bili/.MainActivityV2 e753a0a pid=12505

用 frida 写个简单的 hook 脚本注入进去看看情况

	function hook(){
	Java.perform(function(){
	const activity = Java.use("com.mall.ui.page.base.MallWebFragmentLoaderActivity");
	activity.onCreate.overload('android.os.Bundle').implementation = function(x){
	const retv = this.onCreate(x);
	return retv;
	}
	})
	}

	setImmediate(hook,0);

	oriole:/data/local/tmp # /data/local/tmp/fs16.3.3 -l 0.0.0.0:1234
	adb forward tcp:1234 tcp:1234
	frida -H 127.0.0.1:1234 -l .\hook.js -f tv.danmaku.bili

注入进去之后不出意料的卡在主界面不动了

去看看是在哪一个 so 卡住的

	function hook_dlopen() {
	Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
	{
	onEnter: function (args) {
	var pathptr = args[0];
	if (pathptr !== undefined && pathptr != null) {
	var path = ptr(pathptr).readCString();
	console.log("load " + path);
	}
	}
	}
	);
	}

	setImmediate(hook_dlopen)

哈哈没想到是 libmsaoaidsec.so , 这个 so 我在很多的 apk 里面都看到过了，按照以前逆向的经验这个 so 里面没有任何的业务代码，在 init_proc 里面是纯的检测逻辑

我对 libmsaoaidsec.so 里面的控制流平坦化还是很感兴趣的，之后会去专门分析一下这个 so:)

现在我们就用最简单的方法去反调试好啦，就是不让 app 加载这个 so, 具体做法就是在打开这个 so 时，把要加载的 so 的字符串置空

	function hook_dlopen() {
	Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"), {
	onEnter: function (args) {
	var pathptr = args[0];
	if (pathptr !== undefined && pathptr != null) {
	var path = ptr(pathptr).readCString();
	if(path.indexOf('libmsaoaidsec.so') >= 0){
	ptr(pathptr).writeUtf8String("");
	}
	console.log("load " + path);
	}
	}
	});
	}


	setImmediate(hook_dlopen_anti)

再次注入代码之后就 hook 成功了

# webview chrome 调试

用 Device Monitor 看一下购票的页面，发现是套了一个 WebView

想要在 android 中使用 chrome 的 devtool 开启 webview debug, 需要注入下面的 frida 脚本

	function webview_debug() {
	Java.perform(function () {
	var WebView = Java.use('android.webkit.WebView');

	WebView.$init.overloads.forEach(function(init) {
	init.implementation = function() {
	// 调用原始构造方法
	var instance = init.apply(this, arguments);

	// 打开 WebView 的调试功能
	WebView.setWebContentsDebuggingEnabled(true);

	console.log('[*] WebView debug open~');

	// 返回实例
	return instance;
	};
	});
	});
	}

然后使用 USB 将电脑和手机相连

在电脑端的 chrome 打开 chrome://inspect/#devices

之后我们点击这个 Port forwarding 按钮配置端口转发

然后选一个端口点击 Done

但是这样做并没有什么网页可以 inspect

通过 device monitor 来看，这个 b 站肯定是调用了 Webview 的，那为什么这个脚本没有 hook 到 Webview 的创建呢？我觉得可能的原因就是 webview 并不是在主进程被创建的，而是在子进程被创建的，我们打印一下 bilibili 建立的进程来看看情况

的确，除了主进程之外，还多了其他的四个进程，感觉这个 web 进程很可疑呀

那写个 python 脚本让 frida 也去注入这个 tv.danmaku.bili:web 子进程好啦

	import codecs
	import frida
	import sys
	import threading

	device = frida.get_device_manager().add_remote_device("127.0.0.1:1234")
	pending = []
	sessions = []
	scripts = []
	event = threading.Event()

	jscode = open('./hook.js', 'r', encoding='utf-8').read()
	pkg = "tv.danmaku.bili" #包名


	def spawn_added(spawn):
	event.set()
	if spawn.identifier == pkg or spawn.identifier == f"{pkg}:web":
	print('spawn_added:', spawn)
	session = device.attach(spawn.pid)
	script = session.create_script(jscode)
	script.on('message', on_message)
	script.load()
	device.resume(spawn.pid)


	def spawn_removed(spawn):
	print('spawn_removed:', spawn)
	event.set()


	def on_message(spawn, message, data):
	print('on_message:', spawn, message, data)


	def on_message(message, data):
	if message['type'] == 'send':
	print("[*] {0}".format(message['payload']))
	else:
	print(message)


	device.on('spawn-added', spawn_added)
	device.on('spawn-removed', spawn_removed)

	device.enable_spawn_gating()

	event = threading.Event()
	print('Enabled spawn gating')

	pid = device.spawn([pkg])

	session = device.attach(pid)
	print("[*] Attach Application id:", pid)
	device.resume(pid)
	sys.stdin.read()

这样就 hook 到子进程啦

打开了 webview 的 debug 之后，终于可以 inspect 了！

之后的过程就很简单啦

点击漫展详情，抓个包
点击立即购票，抓个包
点击提交订单，抓个包

我写了一个小脚本还挺好用的，用这个 js 脚本可以读取剪切板里的 curl 请求并转换为 python 的 request 请求复制到剪切板上 :)

剪切板里的 curl 请求是从这里来的

记得安装一下包就好了

	npm i curlconverter
	npm i copy-paste

	import * as curlconverter from 'curlconverter';
	import ncp from 'copy-paste'
	let cmd = ncp.paste()
	var res = curlconverter.toPython(cmd);
	console.log(res)

	ncp.copy(res, function () {
	console.log("OK")
	})

分析一下接口，写一下脚本就抢票成功啦

waiting for cp30!

ollvm三种混淆模式的反混淆思路

2024-07-12T01:24:52.000Z

ollvm 算是日常逆向的过程中的一个难点，试想一下当你把程序拖进 ida 后那无穷无尽的 block 出现在面前的感受，这滋味一言难尽呐…

所以很有必要对 ollvm 的混淆与反混淆进行系统的学习，以便在未来实际生活中遇到时，不必慌忙的去 google 寻找答案.

文中的分析所用到的附件可以点这里下载哦 ollvm_bcf-fla-sub.zip

# 预备知识

llvm 是一个完整的编译器架构，作用可以理解为制作一个编译器，llvm 先将源码生成为与目标机器无关的 LLVM IR 代码，然后把 LLVMIR 代码先优化，再向目标机器的汇编语言而努力。经典编译器都可以分为前端、中层优化和后端：

从上图中可以看到 clang 是前端的一个套件，但在实际使用时，我们只可以感受到 clang，也只是在使用 clang，因为编译的时候，是调用 clang 或 clang++ 来编译源码。

而 ollvm 是基于 LLVM 的代码分支的代码混淆，在中间表示 IR 层，通过编写 pass（遍历一遍 IR，可以同时对它做一些操作）来混淆 IR，这样目标机器的汇编语言也就被混淆了

# ollvm 环境搭建

ollvm 搭建的环境为

ubuntu22.04

# 下载 ollvm 4.0 源码

git clone -b llvm-4.0 --depth=1 https://github.com/obfuscator-llvm/obfuscator.git

# 安装 docker

sudo apt install docker.io

# 安装编译 ollvm 的 docker 环境

sudo docker pull nickdiego/ollvm-build

# 编译 ollvm

# 下载编译脚本

git clone --depth=1 https://github.com/oacia/docker-ollvm.git

# 编译

ollvm-build.sh 后面跟的参数是 ollvm的源码目录

sudo docker-ollvm/ollvm-build.sh /home/oacia/Desktop/obfuscator/

# 创建硬链接

sudo ln ./obfuscator/build_release/bin/* /usr/bin/

创建完成硬链接后，使用该命令来检测 clang 是否可用

clang --version

# 使用测试代码尝试编译

使用一个简单的 RC4 加密来作为测试代码， 该代码将在后续 ollvm 的三种混淆中继续使用

	//test.c
	#include<stdio.h>

	/*
	RC4 初始化函数
	*/
	void rc4_init(unsigned char* s, unsigned char* key, unsigned long Len_k)
	{
	int i = 0, j = 0;
	char k[256] = { 0 };
	unsigned char tmp = 0;
	for (i = 0; i < 256; i++) {
	s[i] = i;
	k[i] = key[i % Len_k];
	}
	for (i = 0; i < 256; i++) {
	j = (j + s[i] + k[i]) % 256;
	tmp = s[i];
	s[i] = s[j];
	s[j] = tmp;
	}
	}

	/*
	RC4 加解密函数
	unsigned char* Data 加解密的数据
	unsigned long Len_D 加解密数据的长度
	unsigned char* key 密钥
	unsigned long Len_k 密钥长度
	*/
	void RC4(unsigned char* Data, unsigned long Len_D, unsigned char* key, unsigned long Len_k) // 加解密
	{
	unsigned char s[256];
	rc4_init(s, key, Len_k);
	int i = 0, j = 0, t = 0;
	unsigned long k = 0;
	unsigned char tmp;
	for (k = 0; k < Len_D; k++) {
	i = (i + 1) % 256;
	j = (j + s[i]) % 256;
	tmp = s[i];
	s[i] = s[j];
	s[j] = tmp;
	t = (s[i] + s[j]) % 256;
	Data[k] = Data[k] ^ s[t];
	}
	}

	void RC4encrypt(unsigned char* Data, unsigned long Len_D, unsigned char* key, unsigned long Len_k) {
	RC4(Data, Len_D, key, Len_k);
	}
	void RC4decrypt(unsigned char* Data, unsigned long Len_D, unsigned char* key, unsigned long Len_k) {
	RC4(Data, Len_D, key, Len_k);
	}
	int main()
	{
	// 字符串密钥
	unsigned char key[] = "secret";
	unsigned long key_len = sizeof(key) - 1;// 字符串最后还有一个 '/0' 所以需要 - 1
	// 数组密钥
	//unsigned char key[] = {'s','e','c','r','e','t'};
	//unsigned long key_len = sizeof(key);

	unsigned char data[] = { 116, 104, 105, 115, 32, 105, 115, 32, 82, 67, 52, 44, 111, 97, 99, 105, 97 };

	// 对明文进行加密
	RC4encrypt(data, sizeof(data), key, key_len);

	for (int i = 0; i < sizeof(data); i++)
	{
	printf("%d, ", data[i]);
	}
	printf("\n");

	// 对密文进行解密
	RC4encrypt(data, sizeof(data), key, key_len);

	for (int i = 0; i < sizeof(data); i++)
	{
	printf("%c", data[i]);
	}
	printf("\n");
	return 0;
	}
	/*
	153, 94, 187, 111, 162, 205, 165, 134, 96, 136, 143, 240, 156, 135, 150, 94, 204,
	this is RC4,oacia
	*/

运行如下命令进行编译

clang test.c -o test

如果提示 fatal error: ‘stdio.h’ file not found

尝试下载 g++ 和 gcc

	sudo apt-get install g++
	sudo apt-get install gcc

如果提示 fatal error: 'stddef.h’或者’stdarg.h’等 file not found

使用该命令复制 clang 所需的头文件到 /usr/include/ , cp -r -i 后面跟的参数为 ollvm的源码目录/build_release/lib/clang/4.0.1/include/. , 这个文件夹内包含了 clang 编译器所需的头文件

cp -r -i /home/oacia/Desktop/obfuscator/build_release/lib/clang/4.0.1/include/. /usr/include/

如果提示有重名文件的话，最好先对 /usr/include 内的重名文件作好备份，然后去掉 -i 参数重新进行复制头文件操作

# 虚假控制流 BCF (Bogus Control Flow)

# 原理

虚假控制流混淆通过加入包含不透明谓词的条件跳转（也就是跳转与否在运行之前就已经确定的跳转，但 IDA 无法分析）和不可达的基本块，来干扰 IDA 的控制流分析和 F5 反汇编。

所谓的不透明谓词，例如

	if(x>10 && x<=10){
	goto Label1;
	}

对于这类表达式，我们可以很明显的看到， x>10 && x<=10 是永假式，所以 goto Label1 这个跳转永远不会被执行，但是对于 IDA 来说可不是这个样子，在静态分析的时候，IDA 并不知道 x 的值是多少，所以说这类虚假控制流就会干扰我们的静态分析.

# ollvm 的 BCF 混淆

使用下列命令对代码进行 BCF 混淆

clang -mllvm -bcf -mllvm -bcf_loop=3 -mllvm -bcf_prob=40 test.c -o test-bcf

可用选项：

-mllvm -bcf : 激活虚假控制流
-mllvm -bcf_loop=3 : 混淆次数，这里一个函数会被混淆 3 次，默认为 1
-mllvm -bcf_prob=40 : 每个基本块被混淆的概率，这里每个基本块被混淆的概率为 40%，默认为 30 %

可以发现在 BCF 混淆之后，函数的控制流明显复杂了许多

打开 BCF 混淆之后 IDA 的伪代码，发现多了许多的 while , if 表达式，伪代码变得十分复杂，也让我们无法一眼就可以看出这是何种加密

# ollvm 的 BCF 反混淆

铺垫了这么长的时间，终于要来到本篇文章的第一个有趣的环节，BCF 的反混淆了

我们往上看 while 内的表达式 y_4 >= 10 && (((x_3 - 1) * x_3) & 1) != 0 , 在这个式子中， (x_3 - 1) * x_3) 的值永远为偶数，所以 (x_3 - 1) * x_3) & 1 永远返回 0 , 不等号左边 y_4 >= 10 && (((x_3 - 1) * x_3) & 1) , 因为是用逻辑与 && 作为连接词，所以左侧的表达式其实为永假式， y_4 >= 10 && (((x_3 - 1) * x_3) & 1) != 0 永远不成立

对于 BCF, 有 3 种思路可以帮助我们去进行反混淆

# 思路一将全局变量赋值并将 segment 设为只读

IDA 其实是有死代码消除 (DCE, Dead Code Elimination) 的，但是由于 y_4 , x_3 被定义为了全局变量，在静态分析时，IDA 不知道这个表达式的值是多少，所以 IDA 也不敢轻易的就把这段代码给消除了 (万一把重要的代码也给消除掉了那逆向人员真的要 *** 了)

但是如果我们把这个变量的值定下来，并且将变量所在的 segment 设为 只读 ，那这个变量值在没运行前也变不了，IDA 不就可以自己算出来这个表达式的值是多少了嘛，这样那些没有用的跳转 IDA 就可以自动优化了

所以我们先双击 x_3 跳转到 x_3 的地址

然后按下 Alt+S 或者 Edit->Segments->Edit segment... 来改变不透明谓词所在的 segment 的读写属性，如图将 Write 复选框取消勾选， .bss段 就设为只读了

光是这样还不够，因为 .bss段 中的变量还没有被赋过值，所以我们还需要 patch 这个段来固定 .bss段 内变量的值

一个变量一个变量去 patch 显然显得有些麻烦，所以我们可以直接编写 IDApython 脚本来实现一步到位的效果，并且对于常规的 ollvm 的 bcf 混淆来说，bcf 的不透明谓词都是处于 .bss段 中。如果不透明谓词定义在其他段中，将 IDApython 中的代码做出相对应的修改即可

	import ida_segment
	import ida_bytes

	seg = ida_segment.get_segm_by_name('.bss')

	for ea in range(seg.start_ea, seg.end_ea,4):
	ida_bytes.patch_bytes(ea, int(2).to_bytes(4,'little'))

	'''
	seg.perm: 由三位二进制数表示,例如一个segment为可读,不可写,不可执行,则seg.perm = 0b100
	(seg.perm >> 2)&1: Read
	(seg.perm >> 1)&1: Write
	(seg.perm >> 0)&1: Execute
	'''
	seg.perm = 0b100

# 思路二使用 d810 去除 BCF

d810 中内置了很多的不透明谓词表达式，它的匹配器也是非常的厉害完全可以做到去除虚假控制流

在 Edit->plugins->D-810 打开之后，选择 default_unflattening_switch_case.json 之后点击 start , 即可做到对不透明谓词的去除并还原控制流

还原后的效果如下，可以发现和原本的代码基本是一样的了

当然如果发现有一些恒定值的不透明谓词表达式 d810 没有识别到无法去除的话，我们也可以手动添加规则让 D810 进行匹配来消除 BCF

例如对于这个表达式 ((x_0>=10 && x_10<10)==false) == True , 我们可以先在 \plugins\d810\conf\xxx.json 里面添加我们自己的规则

随后来到 plugins\d810\optimizers\instructions\pattern_matching\rewrite_and.py 中加一个我们自己的类 OaciaRule0 , 这样就可以完成一个自定义规则的导入啦

# 思路三使用 idapython patch 不透明谓词

在思路一中，我们通过对不透明谓词变量进行交叉引用找到了它们所在的 segment, 并通过将全局变量赋值并将 segment 设为只读的方法消除了 BCF, 但是其实我们还可以用另外的一种方式去消除 bcf, 就是在汇编中将不透明谓词直接 patch 掉

例如对于该不透明谓词 x_9 , y_10 , 它的 c 表达式为 y_10 >= 10 && ((((_BYTE)x_9 - 1) * (_BYTE)x_9) & 1) != 0

我们要做的就是让 mov eax, ds:x_9 改成 mov eax, 0 , 这样就可以做到消除 BCF 的目的

但是这样一个一个改过去显得十分的麻烦，所以我们可以用 ida python, 通过找到不透明谓词的所有交叉引用的方式来批量修改

	# 去除虚假控制流 idapython 脚本
	import ida_xref
	import ida_idaapi
	from ida_bytes import get_bytes, patch_bytes

	# 将 mov 寄存器，不透明谓词修改为 mov 寄存器，0
	def do_patch(ea):
	if get_bytes(ea, 1) == b"\x8B": # mov eax-edi, dword
	reg = (ord(get_bytes(ea + 1, 1)) & 0b00111000) >> 3
	patch_bytes(ea, (0xB8 + reg).to_bytes(1,'little') + b'\x00\x00\x00\x00\x90\x90')
	else:
	print('error')

	# 不透明谓词在.bss 段的范围
	seg = ida_segment.get_segm_by_name('.bss')
	start = seg.start_ea
	end = seg.end_ea

	for addr in range(start,end,4):
	ref = ida_xref.get_first_dref_to(addr)
	print(hex(addr).center(20,'-'))
	# 获取所有交叉引用
	while(ref != ida_idaapi.BADADDR):
	do_patch(ref)
	print('patch at ' + hex(ref))
	ref = ida_xref.get_next_dref_to(addr, ref)
	print('-' * 20)

这样 BCF 就被去掉啦

# 指令替换（SUB）

# 原理

指令替换（Instruction Substitution）是一种代码混淆技术，用于将程序中的原始指令替换为等效但更难理解和还原的指令序列。通过指令替换，可以增加程序的复杂性和抵抗逆向工程的能力。

它的本质其实就是数学公式的简化，例如 (x + y) - 2 * (x & y) -> x ^ y (过去学离散数学感觉做的就是这种样子的…)

# ollvm 的 SUB 混淆

使用下面的命令对代码进行 SUB 混淆

clang -mllvm -sub -mllvm -sub_loop=3 test-sub.c -o test-sub

可用选项

-mllvm -sub : 激活指令替换
-mllvm -sub_loop=3 : 混淆次数，这里一个函数会被混淆 3 次，默认为 1 次

经过指令替换后，代码明显变长了很多

# ollvm 的 SUB 反混淆

# 思路一使用 d810 去除 SUB

D810 太猛了！这里又用到了 D810

还是和去除 BCF 反混淆一样，我们直接跑一下 d810, 虽然还是有一些部分没有去掉，但是看起来已经很清晰了，因为指令替换不影响程序整体的执行逻辑，所以我想剩下的一点点 SUB 应该难不倒逆向的同学吧～

# 思路二使用 GAMBA 简化复杂的 SUB 表达式

这个思路二其实就是思路一那一点点未解决的 SUB 的补充，对于一些复杂的表达式来说，github 上的开源工具 GAMBA 可以很好的帮助我们简化

具体可以参考细品 sec2023 安卓赛题中的 加密三 vm 指令分析

# 控制流平坦化（FLA）

# 原理

控制流平坦化 (control flow flattening) 的基本思想主要是通过一个主分发器来控制程序基本块的执行流程，例如下图是正常的执行流程

经过控制流平坦化后的执行流程就如下图

这样可以模糊基本块之间的前后关系

此图是一个经典的控制流平坦化 CFG

其中

序言：函数的第一个执行的基本块
主 (子) 分发器：控制程序跳转到下一个待执行的基本块
retn 块：函数出口
真实块：混淆前的基本块，程序真正执行工作的块
预处理器：跳转到主分发器

# ollvm 的 FLA 混淆

使用如下命令即可完成 fla 混淆

clang -mllvm -fla -mllvm -split -mllvm -split_num=3 test-fla.c -o test-fla

可用选项：

-mllvm -fla : 激活控制流平坦化
-mllvm -split : 激活基本块分割
-mllvm -split_num=3 : 指定基本块分割的数目

经过控制流平坦化之后，函数的逻辑已经很难看清楚了

# ollvm 的 FLA 反混淆

想要定位各个块其实很简单，对于经典的 ollvm 来说，各个块之间有如下规则 (要是魔改的话就具体情况具体分析啦)

找到序言块，这是整个函数的入口
序言块的后继是主分发器
主分发器的前驱有两个，除了序言块外，另一个块就是预处理器
预处理器的前驱是真实块
除此之外的其他块是子分发器

想要反控制流平坦化，我们只需要做 3 步

找到真实块。我们可以手动找真实块；可以用 idapython 通过各个块之间的联系通过一定的规则找真实块；可以用 unicorn 或 angr 得到函数的 CFG, 利用规则匹配出真实块… 方法多种多样，但是核心都是找到真实块，除真实块和序言块外，其余的块都是虚假块，我们需要 NOP 掉他们
得到真实块之间的联系。我们主要想知道分支跳转的另一个分支，它究竟跳到了什么地方去的呢？所以这一步我们必须得让代码运行起来，它把控制流给混淆了，我们要是不把代码跑起来咋知道控制流嘞？可以用模拟执行，也可以在真机调试打断点 trace, 核心都是为了找到真实块之间的调用关系
得到了真实块之间的联系之后，我们只需要在每个真实块的末尾，用跳转汇编指令将每个真实块像串糖葫芦一样串起来，控制流平坦化就修复好啦～

所以开始我们的第一步找到真实块和虚假块，对于标准的 ollvm 来说，观察得知预处理器的前驱都是真实块，所以我们写出如下的 idapython 脚本

	import idaapi
	import idc
	target_func = 0x401E80#需要反控制流平坦化的函数的地址
	Preprocessor_block = 0x402697#ollvm 中预处理器的地址，这个是通过观察 ida 中的 CFG 得到的，预处理器的前驱都是真实块
	True_blocks = []#真实块列表
	Fake_blocks = []#所有块的列表
	f_block = idaapi.FlowChart(idaapi.get_func(0x401E80), flags=idaapi.FC_PREDS)
	for block in f_block:
	if block.start_ea==Preprocessor_block:#预处理器块的前驱都是真实块
	#but 预处理器是虚假块
	Fake_blocks.append((block.start_ea,idc.prev_head(block.end_ea)))
	print("find ture block!")
	tbs = block.preds()
	for tb in tbs:
	#print (hex (tb.start_ea),hex (idc.prev_head (tb.end_ea)))# 获取块的开始 / 结束地址
	True_blocks.append((tb.start_ea,idc.prev_head(tb.end_ea)))
	elif not [x for x in block.succs()]:#返回块没有后继
	print("find ret block!")
	True_blocks.append((block.start_ea,idc.prev_head(block.end_ea)))
	# 序言块不作为虚假块处理
	elif block.start_ea!=target_func:
	#print(hex(block.start_ea),hex(idc.prev_head(block.end_ea)))
	Fake_blocks.append((block.start_ea,idc.prev_head(block.end_ea)))

	print('true block:')
	print('tbs =',True_blocks)
	print('fake block:')
	print('fbs =',Fake_blocks)

之后就是要得到真实块之间的联系啦，这里我使用 unicorn 来模拟执行得到真实块的调用关系，这里要注意的是因为我们只对一个函数中真实块的前后调用进行模拟执行，所以是不需要跳转到其他函数中的，遇到 call 指令直接将 pc 强制改成下一行汇编的地址，同时也要注意内存访问异常的情况直接通过 uc.hook_add(UC_HOOK_MEM_UNMAPPED|UC_HOOK_INTR, hook_mem_access) 进行忽略

通过这个 unicorn 脚本模拟执行，我们得到了分支跳转时下一个要跳转的真实块地址，以及此时的 ZF 标志位，这个标志位可是有着大用，通过这个标志位我们就可以知道究竟是 jz 跳转还是 jnz 跳转啦

	# code for test-fla.elf
	from unicorn import *
	from unicorn.x86_const import *
	from keystone import * # pip install keystone-engine
	from capstone import * # pip install capstone
	# import networkx as nx #pip install networkx
	# import matplotlib.pyplot as plt # pip install matplotlib

	BASE = 0x400000
	CODE = BASE + 0x0
	CODE_SIZE = 0x100000
	STACK = 0x7F00000000
	STACK_SIZE = 0x100000
	FS = 0x7FF0000000
	FS_SIZE = 0x100000
	ks = Ks(KS_ARCH_X86, KS_MODE_64) # 汇编引擎
	uc = Uc(UC_ARCH_X86, UC_MODE_64) # 模拟执行引擎
	cs = Cs(CS_ARCH_X86, CS_MODE_64) # 反汇编引擎
	# g=nx.Graph ()# 创建空的无向图
	# g=nx.DiGraph ()# 创建空的有向图
	tbs = [(4204176, 4204182), (4203066, 4203066), (4203071, 4203098), (4203103, 4203157), (4203162, 4203314),
	(4203319, 4203341), (4203346, 4203366), (4203371, 4203398), (4203403, 4203428), (4203433, 4203457),
	(4203462, 4203490), (4203495, 4203514), (4203519, 4203558), (4203563, 4203585), (4203590, 4203609),
	(4203614, 4203636), (4203641, 4203651), (4203656, 4203689), (4203694, 4203737), (4203742, 4203776),
	(4203781, 4203804), (4203809, 4203831), (4203836, 4203856), (4203861, 4203888), (4203893, 4203918),
	(4203923, 4203957), (4203962, 4203981), (4203986, 4204025), (4204030, 4204040), (4204045, 4204067),
	(4204072, 4204091), (4204096, 4204118), (4204123, 4204133), (4204138, 4204171)]
	tb_call = []
	main_addr = 0x00000000000401E80
	main_end = 0x0000000000040269C


	def hook_code(uc: unicorn.Uc, address, size, user_data):
	# print(hex(address))
	for i in cs.disasm(CODE_DATA[address - BASE:address - BASE + size], address):
	if i.mnemonic == "call": # 因为只是针对单个函数的控制流，所以我们并不需要跳转到其他的函数里面
	print(f"find call at {hex(address)}, jump...")
	uc.reg_write(UC_X86_REG_RIP, address + size)
	elif i.mnemonic == "ret":
	print("find ret block, emu stop~")
	uc.emu_stop()
	print("block emu path↓↓↓↓")
	print(tb_call)
	# for i in range(len(tb_call)-1):
	# g.add_edge(tb_call[i],tb_call[i+1])

	# Plot it
	# nx.draw(g, with_labels=True)
	# nx.write_gml(g,'./test-fla.gml')

	for tb in tbs:
	if address == tb[1]:
	# print (uc.reg_read (UC_X86_REG_FLAGS))#ZF 标志位在第 6 位
	ZF_flag = (uc.reg_read(UC_X86_REG_FLAGS) & 0b1000000) >> 6
	#print("ZF=", ZF_flag)
	tb_call.append((tb, ZF_flag))
	break


	def hook_mem_access(uc: unicorn.Uc, type, address, size, value, userdata):
	pc = uc.reg_read(UC_X86_REG_RSP) # UC_ARM64_REG_PC

	print('pc:%x type:%d addr:%x size:%x' % (pc, type, address, size))
	# uc.emu_stop()
	return True


	def inituc(uc):
	uc.mem_map(CODE, CODE_SIZE, UC_PROT_ALL)
	uc.mem_map(STACK, STACK_SIZE, UC_PROT_ALL)

	uc.mem_write(CODE, CODE_DATA)
	uc.reg_write(UC_X86_REG_RSP, STACK + 0x1000)

	uc.hook_add(UC_HOOK_CODE, hook_code)
	uc.hook_add(UC_HOOK_MEM_UNMAPPED \| UC_HOOK_INTR, hook_mem_access)


	def init_graph():
	for tb in tbs:
	g.add_node(tb[1])


	with open('./test-fla', 'rb') as f:
	CODE_DATA = f.read()
	inituc(uc)
	try:
	uc.emu_start(main_addr, main_end)
	except Exception as e:
	print(e)

之后再去写一个 idapython 脚本将真实块串起来就可以啦，对于无分支跳转，可以直接将前后基本块通过 jmp 进行连接，而麻烦的只是分支跳转，我们由模拟执行后已经得到了分支跳转时的 ZF 标志位，通过该标志位我们将将 jmp 改成为零跳转 (jz) 亦或是非零跳转 (jnz)

写一下 patch 脚本，修复成功～

	import idaapi
	import ida_bytes
	import idc
	from keystone import *

	ks = Ks(KS_ARCH_X86, KS_MODE_64) # 汇编引擎

	def jmp_patch(start, target, j_code="jmp"):
	global debug
	patch_byte, count = ks.asm(f"{j_code} {hex(target)}", addr=start)
	patch_byte = bytes(patch_byte) + b'\x00' * (idc.get_item_size(start) - len(patch_byte))
	print(hex(start), f"{j_code} {hex(target)}", patch_byte)
	ida_bytes.patch_bytes(start, patch_byte)


	def patch_nop(addr, endaddr):
	#print(f"Patching from {addr} to {endaddr}")
	while addr < endaddr:
	ida_bytes.patch_byte(addr, 0x90)
	addr += 1

	def patch_nop_line(addr):
	patch_nop(addr,addr+idc.get_item_size(addr))


	preamble_block = 0x401E8B # 序言块的地址
	internal_reg = '[rbp+var_B4]'#中间变量的名称，遇到这个想都不用想直接 NOP
	# 格式: ((块的起始地址，块的结束地址),ZF 标志位)
	tb_path = [((4203071, 4203098), 0), ((4203103, 4203157), 0), ((4203162, 4203314), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 0), ((4203403, 4203428), 0), ((4203433, 4203457), 1),
	((4203462, 4203490), 0), ((4203495, 4203514), 1), ((4203519, 4203558), 1), ((4203563, 4203585), 1),
	((4203590, 4203609), 0), ((4203614, 4203636), 1), ((4203641, 4203651), 1), ((4203319, 4203341), 1),
	((4203346, 4203366), 1), ((4203371, 4203398), 1), ((4203403, 4203428), 1), ((4203656, 4203689), 1),
	((4203694, 4203737), 1), ((4203742, 4203776), 1), ((4203781, 4203804), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 0), ((4203893, 4203918), 0), ((4203923, 4203957), 0),
	((4203962, 4203981), 1), ((4203986, 4204025), 1), ((4204030, 4204040), 1), ((4204045, 4204067), 1),
	((4204072, 4204091), 0), ((4204096, 4204118), 1), ((4204123, 4204133), 1), ((4203809, 4203831), 1),
	((4203836, 4203856), 1), ((4203861, 4203888), 1), ((4203893, 4203918), 1), ((4204138, 4204171), 1)]

	tbs = [(4204176, 4204182), (4203066, 4203066), (4203071, 4203098), (4203103, 4203157), (4203162, 4203314), (4203319, 4203341), (4203346, 4203366), (4203371, 4203398), (4203403, 4203428), (4203433, 4203457), (4203462, 4203490), (4203495, 4203514), (4203519, 4203558), (4203563, 4203585), (4203590, 4203609), (4203614, 4203636), (4203641, 4203651), (4203656, 4203689), (4203694, 4203737), (4203742, 4203776), (4203781, 4203804), (4203809, 4203831), (4203836, 4203856), (4203861, 4203888), (4203893, 4203918), (4203923, 4203957), (4203962, 4203981), (4203986, 4204025), (4204030, 4204040), (4204045, 4204067), (4204072, 4204091), (4204096, 4204118), (4204123, 4204133), (4204138, 4204171)]
	fbs = [(4202133, 4202159), (4202165, 4202165), (4202170, 4202187), (4202193, 4202193), (4202198, 4202215), (4202221, 4202221), (4202226, 4202243), (4202249, 4202249), (4202254, 4202271), (4202277, 4202277), (4202282, 4202299), (4202305, 4202305), (4202310, 4202327), (4202333, 4202333), (4202338, 4202355), (4202361, 4202361), (4202366, 4202383), (4202389, 4202389), (4202394, 4202411), (4202417, 4202417), (4202422, 4202439), (4202445, 4202445), (4202450, 4202467), (4202473, 4202473), (4202478, 4202495), (4202501, 4202501), (4202506, 4202523), (4202529, 4202529), (4202534, 4202551), (4202557, 4202557), (4202562, 4202579), (4202585, 4202585), (4202590, 4202607), (4202613, 4202613), (4202618, 4202635), (4202641, 4202641), (4202646, 4202663), (4202669, 4202669), (4202674, 4202691), (4202697, 4202697), (4202702, 4202719), (4202725, 4202725), (4202730, 4202747), (4202753, 4202753), (4202758, 4202775), (4202781, 4202781), (4202786, 4202803), (4202809, 4202809), (4202814, 4202831), (4202837, 4202837), (4202842, 4202859), (4202865, 4202865), (4202870, 4202887), (4202893, 4202893), (4202898, 4202915), (4202921, 4202921), (4202926, 4202943), (4202949, 4202949), (4202954, 4202971), (4202977, 4202977), (4202982, 4202999), (4203005, 4203005), (4203010, 4203027), (4203033, 4203033), (4203038, 4203055), (4203061, 4203061), (4203066, 4203066), (4203071, 4203098), (4203103, 4203157), (4203162, 4203314), (4203319, 4203341), (4203346, 4203366), (4203371, 4203398), (4203403, 4203428), (4203433, 4203457), (4203462, 4203490), (4203495, 4203514), (4203519, 4203558), (4203563, 4203585), (4203590, 4203609), (4203614, 4203636), (4203641, 4203651), (4203656, 4203689), (4203694, 4203737), (4203742, 4203776), (4203781, 4203804), (4203809, 4203831), (4203836, 4203856), (4203861, 4203888), (4203893, 4203918), (4203923, 4203957), (4203962, 4203981), (4203986, 4204025), (4204030, 4204040), (4204045, 4204067), (4204072, 4204091), (4204096, 4204118), (4204123, 4204133), (4204138, 4204171), (4204183, 4204183)]
	block_info = {} #判断有没有 patch 结束
	for i in range(len(tbs)):
	block_info[tbs[i][0]] = {'finish': 0,'ret':0}

	#nop 掉所有虚假块
	for fb in fbs:
	patch_nop(fb[1], fb[1] + idc.get_item_size(fb[1]))
	for tb in tbs:
	dont_patch = False
	current_addr = tb[0]
	while current_addr <= tb[1]:
	# print(hex(current_addr),idc.GetDisasm(current_addr))
	if "cmov" in idc.print_insn_mnem(current_addr):
	#cmov 指令会影响分支跳转，所以这里直接 patch 掉
	patch_nop_line(current_addr)
	dont_patch = True
	# print(hex(current_addr),hex(tb_path[i][0]))
	elif internal_reg in idc.print_operand(current_addr, 0):
	print('find internal_reg!')
	patch_nop_line(current_addr)
	elif 'ret' in idc.print_insn_mnem(current_addr):
	block_info[tb[0]]['ret'] = 1
	dont_patch = True
	current_addr = idc.next_head(current_addr)
	if not dont_patch:
	patch_nop_line(tb[1])
	block_info[tb[0]]['finish'] = 1
	# 序言块 -> 第一个真实块 patch
	jmp_patch(preamble_block, tb_path[0][0][0])
	for i in range(len(tb_path) - 1):
	# 不是返回块，也未完成 patch, 剩下的指令都是有分支跳转的.
	if block_info[tb_path[i][0][0]]['finish'] == 0 and not block_info[tb_path[i][0][0]]['ret']:
	ZF = tb_path[i][1]
	#当要跳转的块和当前块不连续时，这个分支跳转才修复完成
	if not idc.next_head(tb_path[i][0][1]) == tb_path[i + 1][0][0]:
	block_info[tb_path[i][0][0]]['finish'] = 1
	j_code = ('jnz', 'jz')
	jmp_patch(tb_path[i][0][1], tb_path[i + 1][0][0], j_code[ZF])

patch 完之后看一下，这个代码也太好看了吧哈哈哈！ (●'◡'●)

小小总结一下，感觉 ollvm 的控制流平坦化去混淆原来那么简单呐～去年 sec2023 安卓赛题的 CESL-BR 混淆和 CEST-BR 混淆的反混淆 idapython 脚本可真是把我写昏过去了 (倒)

# 参考资料

ollvm 快速学习
跟着铁头干混淆 3 ubuntu 下用 docker 编译 ollvm (保证成功)
OLLVM 混淆学习（0）—— 环境搭建及混淆初体验
利用 angr 符号执行去除虚假控制流
[原创] Android APP 漏洞之战（14）——Ollvm 混淆与反混淆
利用符号执行去除控制流平坦化
代码混淆与反混淆学习 - 第一弹

android binder源码分析

2024-07-06T06:25:21.000Z

Binder 是 Android 独有的一种通信机制， Activity ， Service ， Broadcast ， ContentProvider 这四大组件所涉及的多进程间的通信底层都是依赖于 Binder IPC 机制。学好底层的通信原理对掌握安卓这幢大厦有着重要的意义.

# 说明

本文所研究的安卓内核版本为 Linux version 4.9.270-g862f51bac900-ab7613625

安卓框架版本为 android-12.0.0_r34

# Binder 简介

从进程角度来看 IPC (Inter Process Communication) 机制，每个 Android 的进程，只能运行在自己进程所拥有的虚拟地址空间。对于用户空间，不同进程之间彼此是不能共享的，而内核空间却是可共享的。Client 进程向 Server 进程通信，恰恰是利用进程间可共享的内核内存空间来完成底层通信工作的，Client 端与 Server 端进程往往采用 ioctl 等方法跟内核空间的驱动进行交互。

Binder 通信采用 C/S 架构，从组件视角来说，包含 Client、Server、ServiceManager 以及 binder 驱动，其中 ServiceManager 用于管理系统中的各种服务。架构图如下所示，图中的 Client,Server,Service Manager 之间交互都是虚线表示，是由于它们彼此之间不是直接交互的，而是都通过 Binder 驱动进行交互的，从而实现 IPC 通信方式。其中 Binder 驱动位于内核空间，Client,Server,Service Manager 位于用户空间。

# Binder 设备的初始化过程

在 Linux 中，万物皆文件，那么毫无疑问，Binder 其实也是一个文件，它的初始化函数是 binder_init , 主要功能是注册 binder 设备

	//kernel\drivers\android\binder.c
	static int __init binder_init(void)
	{
	int ret;
	char device_name, device_names, *device_tmp;
	struct binder_device *device;
	struct hlist_node *tmp;

	// 初始化 lru 链表，该链表用于管理内存页；注册 shrinker 结构体
	ret = binder_alloc_shrinker_init();
	if (ret)
	return ret;

	// 原子操作赋值
	atomic_set(&binder_transaction_log.cur, ~0U);
	atomic_set(&binder_transaction_log_failed.cur, ~0U);
	/debug 相关的代码，之后 debug 相关的代码将不再出现 /

	// 在 debugfs 文件系统创建了 binder 文件夹
	binder_debugfs_dir_entry_root = debugfs_create_dir("binder", NULL);

	// 如果 binder 文件夹创建成功，则在该文件夹内继续创建 binder/proc 文件夹
	if (binder_debugfs_dir_entry_root)
	binder_debugfs_dir_entry_proc = debugfs_create_dir("proc",
	binder_debugfs_dir_entry_root);

	if (binder_debugfs_dir_entry_root) {
	// 继续在 binder 目录中创建 state,stats,transactions,transaction_log,failed_transaction_log 文件，读取 Binder 驱动程序的运行情况
	debugfs_create_file("state",
	0444,
	binder_debugfs_dir_entry_root,
	NULL,
	&binder_state_fops);
	debugfs_create_file("stats",
	0444,
	binder_debugfs_dir_entry_root,
	NULL,
	&binder_stats_fops);
	debugfs_create_file("transactions",
	0444,
	binder_debugfs_dir_entry_root,
	NULL,
	&binder_transactions_fops);
	debugfs_create_file("transaction_log",
	0444,
	binder_debugfs_dir_entry_root,
	&binder_transaction_log,
	&binder_transaction_log_fops);
	debugfs_create_file("failed_transaction_log",
	0444,
	binder_debugfs_dir_entry_root,
	&binder_transaction_log_failed,
	&binder_transaction_log_fops);
	}

	/*
	* Copy the module_parameter string, because we don't want to
	* tokenize it in-place.
	*/
	// 在内核空间中分配内存，GFP_KERNEL 表示正常分配内存
	device_names = kzalloc(strlen(binder_devices_param) + 1, GFP_KERNEL);
	if (!device_names) {
	ret = -ENOMEM;
	goto err_alloc_device_names_failed;
	}
	// 将 binder,hwbinder,vndbinder 赋值给 device_names
	strcpy(device_names, binder_devices_param);

	device_tmp = device_names;
	while ((device_name = strsep(&device_tmp, ","))) {
	// 以 "," 作为分隔符，注册 misc 设备 /dev/binder/dev/hwbinder/dev/vndbinder
	ret = init_binder_device(device_name);
	if (ret)
	goto err_init_binder_device_failed;
	}

	return ret;

	err_init_binder_device_failed:
	hlist_for_each_entry_safe(device, tmp, &binder_devices, hlist) {
	misc_deregister(&device->miscdev);
	hlist_del(&device->hlist);
	kfree(device);
	}

	kfree(device_names);

	err_alloc_device_names_failed:
	debugfs_remove_recursive(binder_debugfs_dir_entry_root);

	return ret;
	}

在 binder_init 中，调用了 init_binder_device 通过 misc_register 来注册 binder 设备

	//kernel\drivers\android\binder.c
	static const struct file_operations binder_fops = {
	.owner = THIS_MODULE,
	.poll = binder_poll,
	.unlocked_ioctl = binder_ioctl,
	.compat_ioctl = binder_ioctl,//IO 控制函数
	.mmap = binder_mmap,// 内存映射函数
	.open = binder_open,//binder 文件打开函数
	.flush = binder_flush,
	.release = binder_release,
	};

	static int __init init_binder_device(const char *name)
	{
	int ret;
	struct binder_device *binder_device;

	binder_device = kzalloc(sizeof(*binder_device), GFP_KERNEL);
	if (!binder_device)
	return -ENOMEM;

	binder_device->miscdev.fops = &binder_fops;//// 设备的文件操作结构，这是 file_operations 结构
	binder_device->miscdev.minor = MISC_DYNAMIC_MINOR;// 次设备号动态分配
	binder_device->miscdev.name = name;//// 设备名

	// 设置 binder_context，用于记录 servicemanager 的 binder_node 信息，
	// 由于 binder_device 是全局唯一的，这是 servicemanager 可以成为守护进
	// 程的关键。
	binder_device->context.binder_context_mgr_uid = INVALID_UID;
	binder_device->context.name = name;

	mutex_init(&binder_device->context.context_mgr_node_lock);

	// 注册 binder 设备
	ret = misc_register(&binder_device->miscdev);
	if (ret < 0) {
	kfree(binder_device);
	return ret;
	}

	hlist_add_head(&binder_device->hlist, &binder_devices);

	return ret;
	}

# Binder 设备文件的打开过程

一个进程在使用 binder 进行通信之前，需要使用 open 函数来打开设备文件 /dev/binder, 在这个过程中， binder_open 函数就会被调用，这个函数的作用如下

创建 binder_proc 对象
把当前进程等信息保存到 binder_proc 对象
把 binder_proc 对象保存到文件指针 filp
把 binder_proc 加入到全局链表 binder_procs 。

	//kernel\drivers\android\binder.c
	static int binder_open(struct inode nodp, struct file filp)
	{
	struct binder_proc *proc;
	struct binder_device *binder_dev;

	binder_debug(BINDER_DEBUG_OPEN_CLOSE, "%s: %d:%d\n", __func__,
	current->group_leader->pid, current->pid);

	// 创建 binder_proc 结构体遍历 proc，并为 proc 实现初始化
	proc = kzalloc(sizeof(*proc), GFP_KERNEL);
	if (proc == NULL)
	return -ENOMEM;
	spin_lock_init(&proc->inner_lock);
	spin_lock_init(&proc->outer_lock);
	atomic_set(&proc->tmp_ref, 0);
	get_task_struct(current->group_leader);

	/*
	任何一个进程，如果只有主线程，那 pid 是自己，tgid 是自己，group_leader 指向的还是自己。
	但是，如果一个进程创建了其他线程，那就会有所变化了。线程有自己的 pid，tgid 就是进程的
	主线程的 pid，group_leader 指向的就是进程的主线程。
	有了 tgid 之后，我们就可以判断一个 task 是线程还是进程了。

	pid : 每个 task 都有一个 pid，是唯一的，不管是进程还是线程。
	tgid: 指向主线程的 pid
	*/

	//group_leader: 指向进程的主线程
	proc->tsk = current->group_leader;
	mutex_init(&proc->files_lock);

	// 初始化 todo 队列
	INIT_LIST_HEAD(&proc->todo);
	// 初始化进程优先级
	if (binder_supported_policy(current->policy)) {
	proc->default_priority.sched_policy = current->policy;
	proc->default_priority.prio = current->normal_prio;
	} else {
	proc->default_priority.sched_policy = SCHED_NORMAL;
	proc->default_priority.prio = NICE_TO_PRIO(0);
	}

	// 初始化 binder_dev,proc->context,proc->alloc
	binder_dev = container_of(filp->private_data, struct binder_device,
	miscdev);
	proc->context = &binder_dev->context;
	binder_alloc_init(&proc->alloc);

	//binder_alloc 初始化
	binder_stats_created(BINDER_STAT_PROC);
	proc->pid = current->group_leader->pid;
	INIT_LIST_HEAD(&proc->delivered_death);
	INIT_LIST_HEAD(&proc->waiting_threads);

	// 将初始化完成的 binder_proc 结构体 proc 保存到 filp->private_data 中
	//filp 指向一个打开的文件结构体，它和进程调用 open 函数打开设备文件
	///dev/binder 之后内核返回给进程的文件描述符是相互关联的
	filp->private_data = proc;

	mutex_lock(&binder_procs_lock);
	// 将 binder_proc 结构体 proc 加入到一个全局哈希队列 binder_procs 中
	//binder 通过遍历这个哈希队列就可以知道有多少进程在使用 binder
	hlist_add_head(&proc->proc_node, &binder_procs);
	mutex_unlock(&binder_procs_lock);

	return 0;
	}

# Binder 设备文件的内存映射过程

在打开了设备文件 /dev/binder 之后，还需要调用 mmap 函数来把这个设备文件映射到进程的地址空间，此时 binder 驱动程序中的 binder_mmap 函数就会被调用，主要功能：在内核虚拟地址空间，申请一块与用户虚拟内存相同大小的内存；然后再申请 1 个 page 大小的物理内存，再将同一块物理内存分别映射到内核虚拟地址空间和用户虚拟内存空间，从而实现了用户空间的 Buffer 和内核空间的 Buffer 同步操作的功能。

	//kernel\drivers\android\binder.c
	static int binder_mmap(struct file filp, struct vm_area_struct vma)
	{
	int ret;
	struct binder_proc *proc = filp->private_data;
	const char *failure_string;

	// 保证请求分配内存的线程为主线程
	if (proc->tsk != current->group_leader)
	return -EINVAL;

	// 保证映射内存 <= 4MB, 说明 Binder 最多能为进程分配 4MB 的内核缓冲区来传输数据
	if ((vma->vm_end - vma->vm_start) > SZ_4M)
	vma->vm_end = vma->vm_start + SZ_4M;

	binder_debug(BINDER_DEBUG_OPEN_CLOSE,
	"%s: %d %lx-%lx (%ld K) vma %lx pagep %lx\n",
	__func__, proc->pid, vma->vm_start, vma->vm_end,
	(vma->vm_end - vma->vm_start) / SZ_1K, vma->vm_flags,
	(unsigned long)pgprot_val(vma->vm_page_prot));

	//#define FORBIDDEN_MMAP_FLAGS (VM_WRITE)
	// 检查进程要映射的地址空间是否可写
	if (vma->vm_flags & FORBIDDEN_MMAP_FLAGS) {
	ret = -EPERM;
	failure_string = "bad vm_flags";
	goto err_bad_arg;
	}

	//VM_DONTCOPY /* Do not copy this vma on fork */
	//VM_MIXEDMAP /* Can contain "struct page" and pure PFN pages */
	// 禁止拷贝
	vma->vm_flags \|= VM_DONTCOPY \| VM_MIXEDMAP;
	// 为该内存赋予 r-x 权限
	vma->vm_flags &= ~VM_MAYWRITE;

	vma->vm_ops = &binder_vm_ops;
	vma->vm_private_data = proc;

	// 为进程分配内核缓冲区，并将这块物理内存分别映射到内核虚拟地址空间和用户虚拟内存空间
	ret = binder_alloc_mmap_handler(&proc->alloc, vma);
	if (ret)
	return ret;
	mutex_lock(&proc->files_lock);
	proc->files = get_files_struct(current);
	mutex_unlock(&proc->files_lock);
	return 0;

	err_bad_arg:
	pr_err("%s: %d %lx-%lx %s failed %d\n", __func__,
	proc->pid, vma->vm_start, vma->vm_end, failure_string, ret);
	return ret;
	}

Binder 驱动程序为进程分配的内核缓冲区即为一系列物理页面，他们分别被映射到进程的用户地址空间和内核地址空间。当 Binder 驱动程序需要将一块数据传输给一个进程时，它可以先把这块数据保存在为该进程分配所分配的一块内核缓冲区中，然后再把这块内核缓冲区的用户空间地址告诉进程，最后进程就可以访问到里面的数据了。这样做的好处是不需要将内核空间拷贝到用户空间，从而提高了数据传输的效率.

# binder 设备文件的 ioctl

binder_ioctl 函数负责在两个进程间收发 IPC 数据和 IPC reply 数据。

ioctl (input/output control) 是一个专用于设备输入输出操作的系统调用，该调用传入一个跟设备有关的请求码，系统调用的功能完全取决于请求码。

ioctl 命令	数据类型	操作	使用场景
BINDER_WRITE_READ	struct binder_write_read	收发 Binder IPC 数据	Binder 读写交互场景，IPC.talkWithDriver
BINDER_SET_IDLE_TIMEOUT	__s64
BINDER_SET_MAX_THREADS	__u32	设置 Binder 线程最大个数	初始化 ProcessState 对象，open_driver () ; 主动调整参数，ProcessState.setThreadPoolMaxThreadCount ()
BINDER_SET_IDLE_PRIORITY	__s32
BINDER_SET_CONTEXT_MGR	__s32	设置 Service Manager 节点	servicemanager 进程成为上下文管理者，binder_become_context_manager ()
BINDER_THREAD_EXIT	__s32	释放 Binder 线程
BINDER_VERSION	struct binder_version	获取 Binder 版本信息	初始化 ProcessState 对象，open_driver ()
BINDER_GET_NODE_DEBUG_INFO	struct binder_node_debug_info
BINDER_GET_NODE_INFO_FOR_REF	struct binder_node_info_for_ref
BINDER_SET_CONTEXT_MGR_EXT	struct flat_binder_object

	//kernel\drivers\android\binder.c
	static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
	{
	int ret;
	struct binder_proc *proc = filp->private_data;
	struct binder_thread *thread;
	unsigned int size = _IOC_SIZE(cmd);
	void __user ubuf = (void __user )arg;

	/*pr_info("binder_ioctl: %d:%d %x %lx\n",
	proc->pid, current->pid, cmd, arg);*/

	binder_selftest_alloc(&proc->alloc);

	trace_binder_ioctl(cmd, arg);

	ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);
	if (ret)
	goto err_unlocked;

	thread = binder_get_thread(proc);
	if (thread == NULL) {
	ret = -ENOMEM;
	goto err;
	}

	switch (cmd) {
	// 进行 binder 的读写操作，这个命令使用的最为频繁
	case BINDER_WRITE_READ:
	ret = binder_ioctl_write_read(filp, cmd, arg, thread);
	if (ret)
	goto err;
	break;
	// 设置 binder 最大支持的线程数
	case BINDER_SET_MAX_THREADS: {
	int max_threads;

	if (copy_from_user(&max_threads, ubuf,
	sizeof(max_threads))) {
	ret = -EINVAL;
	goto err;
	}
	binder_inner_proc_lock(proc);
	proc->max_threads = max_threads;
	binder_inner_proc_unlock(proc);
	break;
	}
	case BINDER_SET_CONTEXT_MGR_EXT: {
	struct flat_binder_object fbo;

	if (copy_from_user(&fbo, ubuf, sizeof(fbo))) {
	ret = -EINVAL;
	goto err;
	}
	ret = binder_ioctl_set_ctx_mgr(filp, &fbo);
	if (ret)
	goto err;
	break;
	}
	// 成为 binder 的上下文管理者，也就是 ServiceManager 成为守护进程
	case BINDER_SET_CONTEXT_MGR:
	ret = binder_ioctl_set_ctx_mgr(filp, NULL);
	if (ret)
	goto err;
	break;
	// 当 binder 线程退出，释放 binder 线程
	case BINDER_THREAD_EXIT:
	binder_debug(BINDER_DEBUG_THREADS, "%d:%d exit\n",
	proc->pid, thread->pid);
	binder_thread_release(proc, thread);
	thread = NULL;
	break;
	// 获取 binder 的版本号
	case BINDER_VERSION: {
	struct binder_version __user *ver = ubuf;

	if (size != sizeof(struct binder_version)) {
	ret = -EINVAL;
	goto err;
	}
	if (put_user(BINDER_CURRENT_PROTOCOL_VERSION,
	&ver->protocol_version)) {
	ret = -EINVAL;
	goto err;
	}
	break;
	}
	case BINDER_GET_NODE_INFO_FOR_REF: {
	struct binder_node_info_for_ref info;

	if (copy_from_user(&info, ubuf, sizeof(info))) {
	ret = -EFAULT;
	goto err;
	}

	ret = binder_ioctl_get_node_info_for_ref(proc, &info);
	if (ret < 0)
	goto err;

	if (copy_to_user(ubuf, &info, sizeof(info))) {
	ret = -EFAULT;
	goto err;
	}

	break;
	}
	case BINDER_GET_NODE_DEBUG_INFO: {
	struct binder_node_debug_info info;

	if (copy_from_user(&info, ubuf, sizeof(info))) {
	ret = -EFAULT;
	goto err;
	}

	ret = binder_ioctl_get_node_debug_info(proc, &info);
	if (ret < 0)
	goto err;

	if (copy_to_user(ubuf, &info, sizeof(info))) {
	ret = -EFAULT;
	goto err;
	}
	break;
	}
	default:
	ret = -EINVAL;
	goto err;
	}
	ret = 0;
	err:
	if (thread)
	thread->looper_need_return = false;
	wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);
	if (ret && ret != -ERESTARTSYS)
	pr_info("%d:%d ioctl %x %lx returned %d\n", proc->pid, current->pid, cmd, arg, ret);
	err_unlocked:
	trace_binder_ioctl_done(ret);
	return ret;
	}

# Binder 内部通信协议

Client 进程通过 RPC (Remote Procedure Call Protocol) 与 Server 通信，可以简单地划分为三层，应用层、IPC 层、内核驱动层。 demo() 是 Client 端和 Server 共同协商好的统一方法；handle、RPC 数据、代码、协议这 4 项组成了 IPC 层的数据，通过 IPC 层进行数据传输；而真正在 Client 和 Server 两端建立通信的基础设施便是 Binder Driver。

# 通信模型

一次完整的 Binder 通信过程如下

Binder 协议包含在 IPC 数据中，分为两类:

BINDER_COMMAND_PROTOCOL ：binder 请求码，以”BC_“开头，简称 BC 码，用于从 IPC 层传递到 Binder Driver 层；
BINDER_RETURN_PROTOCOL ：binder 响应码，以”BR_“开头，简称 BR 码，用于从 Binder Driver 层传递到 IPC 层；

Binder IPC 通信至少是两个进程的交互：

client 进程执行 binder_thread_write，根据 BC_XXX 命令，生成相应的 binder_work；
server 进程执行 binder_thread_read，根据 binder_work.type 类型，生成 BR_XXX，发送到用户空间处理。

# 通信过程

一次 Client 向 Server 通信的过程如图所示

# BC_PROTOCOL

binder 请求码，是用 enum binder_driver_command_protocol 来定义的，是用于应用程序向 binder 驱动设备发送请求消息

请求码	参数类型	作用
BC_TRANSACTION	binder_transaction_data	Client 向 Binder 驱动发送请求数据
BC_REPLY	binder_transaction_data	Server 向 Binder 驱动发送请求数据
BC_FREE_BUFFER	binder_uintptr_t (指针)	释放内存
BC_INCREFS	__u32(descriptor)	binder_ref 弱引用加 1 操作
BC_DECREFS	__u32(descriptor)	binder_ref 弱引用减 1 操作
BC_ACQUIRE	__u32(descriptor)	binder_ref 强引用加 1 操作
BC_RELEASE	__u32(descriptor)	binder_ref 强引用减 1 操作
BC_ACQUIRE_DONE	binder_ptr_cookie	binder_node 强引用减 1 操作
BC_INCREFS_DONE	binder_ptr_cookie	binder_node 弱引用减 1 操作
BC_REGISTER_LOOPER	无参数	创建新的 looper 线程
BC_ENTER_LOOPER	无参数	应用线程进入 looper
BC_EXIT_LOOPER	无参数	应用线程退出 looper
BC_REQUEST_DEATH_NOTIFICATION	binder_handle_cookie	注册死亡通知
BC_CLEAR_DEATH_NOTIFICATION	binder_handle_cookie	取消注册的死亡通知
BC_DEAD_BINDER_DONE	binder_uintptr_t (指针)	已完成 binder 的死亡通知
BC_ACQUIRE_RESULT	-	-
BC_ATTEMPT_ACQUIRE	-	-

当一个进程请求另外一个进程执行一个操作时，源进程就使用 BC_TRANSACTION 来请求 Binder 驱动进程将通信数据传递到目标进程
当目标进程处理完成源进程所请求的操作之后，它就使用 BC_REPLY 来请求 Binder 驱动进程将结果数据传递给源进程
BC_FREE_BUFFER 后面跟的通信数据是一个整数，它指向了在 Binder 驱动进程内部所分配的一块内核缓冲区.Binder 驱动程序就是通过这个内核缓冲区将源进程的通信数据传递到目标进程的。当目标进程处理完成源进程的通信请求之后，它会使用 BC_FREE_BUFFER 来通知 Binder 驱动程序释放这个内核缓冲区
当一个线程将自己注册到 Binder 驱动程序之后，它会使用 BC_ENTER_LOOPER 来通知 Binder 驱动程序，它已经准备就绪处理进程间通信请求了
当 Binder 驱动程序主动请求进程注册一个新的线程到它的 Binder 线程池中来处理进程间通信请求之后，新创建的线程就会使用 BC_REGISTER_LOOPER 来通知 Binder 驱动程序，它准备就绪了
当一个线程要退出时，它使用 BC_EXIT_LOOPER 从 Binder 驱动程序中注销，这样他就不会再接收到进程间通信请求了
如果一个进程希望获得它所引用的 Service 组件的死亡接收通知，那么它需要使用 BC_REQUEST_DEATH_NOTIFICATION 来向 Binder 驱动程序注册一个死亡接收通知
如果一个进程希望注销之前所注册的一个死亡接收通知，那么它需要使用 BC_CLEAR_DEATH_NOTIFICATION 来向 Binder 驱动程序发出请求
当一个进程获得一个 Service 组件的死亡通知时，它会使用 BC_DEAD_BINDER_DONE 来通知 Binder 驱动程序，它已经处理完成该 Service 组件的死亡通知了

# binder_work

结构体 binder_work 用来描述待处理的工作项， binder_work.entry 用来将结构体嵌入到一个宿主结构中，通过 binder_work.type 的取值，Binder 就可以判断出一个 binder_work 结构体嵌入到什么类型的宿主结构中

	struct binder_work {
	struct list_head entry;

	enum binder_work_type {
	BINDER_WORK_TRANSACTION = 1,// 最常见
	BINDER_WORK_TRANSACTION_COMPLETE,
	BINDER_WORK_RETURN_ERROR,
	BINDER_WORK_NODE,
	BINDER_WORK_DEAD_BINDER,
	BINDER_WORK_DEAD_BINDER_AND_CLEAR,
	BINDER_WORK_CLEAR_DEATH_NOTIFICATION,
	} type;
	};

binder_work 类型	触发时机
BINDER_WORK_TRANSACTION	`binder_transaction()` ; `binder_release_work()` 被调用
BINDER_WORK_TRANSACTION_COMPLETE	`binder_transaction()` ; `binder_release_work()` 被调用
BINDER_WORK_NODE	`binder_new_node()` 被调用
BINDER_WORK_DEAD_BINDER	`binder_thread_write()` 收到 `BC_REQUEST_DEATH_NOTIFICATION`
BINDER_WORK_DEAD_BINDER_AND_CLEAR	`binder_thread_write()` 收到 `BC_CLEAR_DEATH_NOTIFICATION`
BINDER_WORK_CLEAR_DEATH_NOTIFICATION	`binder_thread_write()` 收到 `BC_CLEAR_DEATH_NOTIFICATION` 和 `BC_DEAD_BINDER_DONE`

# BR_PROTOCOL

binder 响应码，是用 enum binder_driver_return_protocol 来定义的，是 binder 设备向应用程序回复的消息

响应码	参数类型	作用	触发时机
BR_ERROR	__s32	操作发生错误
BR_OK	无参数	操作完成
BR_NOOP	无参数	不做任何事
BR_SPAWN_LOOPER	无参数	创建新的 Looper 线程
BR_TRANSACTION	binder_transaction_data	Binder 驱动向 Server 端发送请求数据	收到 BINDER_WORK_TRANSACTION
BR_REPLY	binder_transaction_data	Binder 驱动向 Client 端发送回复数据	收到 BINDER_WORK_TRANSACTION
BR_TRANSACTION_COMPLETE	无参数	对请求发送的成功反馈	收到 BINDER_WORK_TRANSACTION_COMPLETE
BR_DEAD_REPLY	无参数	回复失败，往往是线程或节点为空
BR_FAILED_REPLY	无参数	回复失败，往往是 transaction 出错导致
BR_INCREFS	binder_ptr_cookie	binder_ref 弱引用加 1 操作（Server 端）
BR_DECREFS	binder_ptr_cookie	binder_ref 弱引用减 1 操作（Server 端）
BR_ACQUIRE	binder_ptr_cookie	binder_ref 强引用加 1 操作（Server 端）
BR_RELEASE	binder_ptr_cookie	binder_ref 强引用减 1 操作（Server 端）
BR_DEAD_BINDER	binder_uintptr_t (指针)	Binder 驱动向 client 端发送死亡通知	收到 BINDER_WORK_DEAD_BINDER 或 BINDER_WORK_DEAD_BINDER_AND_CLEAR
BR_CLEAR_DEATH_NOTIFICATION_DONE	binder_uintptr_t (指针)	BC_CLEAR_DEATH_NOTIFICATION 命令对应的响应码	收到 BINDER_WORK_CLEAR_DEATH_NOTIFICATION
BR_ACQUIRE_RESULT	-	-
BR_ATTEMPT_ACQUIRE	-	-
BR_FINISHED	-	-

# 协议转换图

BINDER_WORK_xxx –> BW_xxx

图解：(以 BC_TRANSACTION 为例)

发起端进程：binder_transaction () 过程将 BC_TRANSACTION 转换为 BW_TRANSACTION；
接收端进程：binder_thread_read () 过程，将 BW_TRANSACTION 转换为 BR_TRANSACTION;
接收端进程：IPC.executeCommand () 过程，处理 BR_TRANSACTION 命令。

# ServiceManager 介绍

我们知道在 Android 系统中，各个进程之间都是隔离的，假如 Clinet 想和 Server 通信，那么该如何找到 Server 呢？这就需要依靠 ServiceManager 了

ServiceManager 是 Android 进程间通信机制 Binder 的守护进程，它扮演着 Binder 进程间通信机制上下文管理者 (context Manager) 的角色，同时负责管理系统中的 Service 组件，向 Client 组件提供获取 Service 代理对象的服务

我们可以将 binder 跨进程通信和 socket 网络通信类比，在网络通信中，客户端并不知道服务器的 IP 地址，但是知道服务器的域名，现在客户端想要和服务器建立 socket 连接，那么通信的第一步就是通过 DNS 服务器将域名解析为 IP 地址然后层层路由，这样客户端就可以和服务器建立网络连接了。binder 跨进程通信也不例外，ServiceManager 就相当于是 socket 网络通信中的 DNS 服务器，倘若 Server 希望有人能够和它通信，那么 Server 就先前往 Service Manager 那里 “备案” 一下（1. 注册服务），过了不久，Client 想要和 Server 去通信了，它就去询问 Service Manager：“Server 在什么地方呀，我要怎么和它通信呀”（2. 获取服务），然后 Service Manager 就告诉 Client 通信的方法，这样 Clinet 和 Server 就可以愉快的通信了～（3. 使用服务）

# ServiceManager 的启动过程

ServiceManager 是由 init 进程通过解析 init.rc 文件创建的

# platform\system\core\rootdir\init.rc
on init
	...
	# Start essential services.
    start servicemanager

具体的服务声明在 platform\frameworks\native\cmds\servicemanager\servicemanager.rc

# platform\frameworks\native\cmds\servicemanager\servicemanager.rc
service servicemanager /system/bin/servicemanager
    class core animation# 指定了服务的类别为core和animation
    user system# 指定了服务用户为system,表示该服务将以系统用户的权限来运行
    group system readproc# 指定了服务的用户组为system,并具有 readproc 权限
    critical# 标志该服务为关键服务，这表示它是系统启动的一部分，必须优先启动

    # 要求在servicemanager重新启动时重启
    # apexd服务, audioserver服务, gatekeeperd服务
    # main类别的服务, hal类别的服务, early_hal类别的服务
    onrestart restart apexd
    onrestart restart audioserver
    onrestart restart gatekeeperd
    onrestart class_restart main
    onrestart class_restart hal
    onrestart class_restart early_hal

    # 将 servicemanager 的进程 ID 写入
    # /dev/cpuset/system-background/tasks文件，这可用于CPU集合管理
    writepid /dev/cpuset/system-background/tasks

    # 声明该服务为关键服务，在系统关闭时，这个服务将被优先关闭
    shutdown critical

Service Manager 的入口函数是 main.cpp 中的 main() , 它的启动过程由以下四个步骤组成

调用 ProcessState::initWithDriver 打开并映射 binder 驱动设备
将自身作为服务 (服务名称: manager ) 注册到 ServiceManager 中
调用 ps->becomeContextManager(); 成为 binder 进程间通信机制的上下文管理者
使用 looper 无限循环阻塞处理事件

	//platform\frameworks\native\cmds\servicemanager\main.cpp
	int main(int argc, char** argv) {
	if (argc > 2) {
	LOG(FATAL) << "usage: " << argv[0] << " [binder driver]";
	}

	// 指定 driver 的名称，如果无参数，则使用默认驱动 /dev/binder
	const char* driver = argc == 2 ? argv[1] : "/dev/binder";

	/*
	每一个进程只能有一个 ProcessState 对象，service manager 通过 initWithDriver 方法
	实例化了一个 ProcessState 对象，并打开 binder 设备和进行 mmap 内存映射，这个过程中
	将会同时调用 binder 设备内部的函数 binder_open 和 binder_mmap
	*/
	sp<ProcessState> ps = ProcessState::initWithDriver(driver);
	// 设置可以同时存在的线程池的最大数量为 0, 即此时只能有 ServiceManager 这一个线程存在
	ps->setThreadPoolMaxThreadCount(0);
	// 在阻塞调用时中止进程
	//FATAL_IF_NOT_ONEWAY: ServiceManager 发起的 Binder 调用必须是单向，否则打印堆栈日志提示
	ps->setCallRestriction(ProcessState::CallRestriction::FATAL_IF_NOT_ONEWAY);

	// 实例化 ServiceManager, 初始化参数为 Access 对象的智能指针
	sp<ServiceManager> manager = sp<ServiceManager>::make(std::make_unique<Access>());
	//self register servicemanager,"manager" 将作为 servicemanager 的第一个服务被注册
	if (!manager->addService("manager", manager, false /allowIsolated/, IServiceManager::DUMP_FLAG_PRIORITY_DEFAULT).isOk()) {
	LOG(ERROR) << "Could not self register servicemanager";
	}

	// 将 "manager" 服务作为服务端 Bbinder 对象
	IPCThreadState::self()->setTheContextObject(manager);
	// 向 binder 驱动发送 ioctl BINDER_SET_CONTEXT_MGR_EXT 信号，将 servicemanager
	// 在 ProcessState::initWithDriver 中打开驱动设备 /dev/driver 所返回的文件描述符句柄
	// 作为整个 binder IPC 通信中的上下文管理者
	ps->becomeContextManager();

	// 准备 looper
	sp<Looper> looper = Looper::prepare(false /allowNonCallbacks/);

	// 监听 BC_ENTER_LOOPER 信号，收到该信号后回调处理 binder 调用
	BinderCallback::setupTo(looper);

	// 监听客户端回调
	ClientCallbackCallback::setupTo(looper, manager);

	// 阻塞等待和处理事件
	while(true) {
	looper->pollAll(-1);
	}

	// should not be reached
	return EXIT_FAILURE;
	}

# ProcessState::init

	//platform\frameworks\native\libs\binder\ProcessState.cpp
	sp<ProcessState> ProcessState::self()
	{
	return init(kDefaultDriver, false /requireDefault/);
	}

	sp<ProcessState> ProcessState::initWithDriver(const char* driver)
	{
	return init(driver, true /requireDefault/);
	}

	sp<ProcessState> ProcessState::init(const char *driver, bool requireDefault)
	{
	[[clang::no_destroy]] static sp<ProcessState> gProcess;
	[[clang::no_destroy]] static std::mutex gProcessMutex;

	if (driver == nullptr) {
	std::lock_guard<std::mutex> l(gProcessMutex);
	return gProcess;
	}
	/*
	这里使用了单例模式的设计思想，通过 std::once_flag 和 std::call_once
	来保证只有一个线程可以进入初始化代码块，
	这保证了在一个线程中只能有一个 ProcessState 实例

	它的工作方式如下
	[-] 第一次调用 std::call_once 时，它会检查与 std::once_flag 关联的标记是否已被设置。
	如果标记尚未设置，它将执行传递给 std::call_once 的可调用对象，
	并设置标记，以标记初始化已完成。

	[-] 如果其他线程尝试再次调用 std::call_once 与相同的 std::once_flag，
	它会发现标记已经设置，因此不会再次执行可调用对象。
	*/
	[[clang::no_destroy]] static std::once_flag gProcessOnce;
	std::call_once(gProcessOnce, [&](){
	// 判断 binder 驱动是否存在
	if (access(driver, R_OK) == -1) {
	ALOGE("Binder driver %s is unavailable. Using /dev/binder instead.", driver);
	driver = "/dev/binder";
	}

	std::lock_guard<std::mutex> l(gProcessMutex);
	// 将 driver 作为参数实例化 ProcessState, 并赋值给 gProcess
	gProcess = sp<ProcessState>::make(driver);
	});

	if (requireDefault) {
	// Detect if we are trying to initialize with a different driver, and
	// consider that an error. ProcessState will only be initialized once above.
	LOG_ALWAYS_FATAL_IF(gProcess->getDriverName() != driver,
	"ProcessState was already initialized with %s,"
	" can't initialize with %s.",
	gProcess->getDriverName().c_str(), driver);
	}

	return gProcess;
	}

# ProcessState 构造函数

在代码的第 26 行，通过 driver 参数实例化了 ProcessState, 它通过 open_driver() 打开了 binder 驱动设备，并使用 mmap 来进行内存映射

	//platform\frameworks\native\libs\binder\ProcessState.cpp
	ProcessState::ProcessState(const char *driver)
	: mDriverName(String8(driver))
	, mDriverFD(open_driver(driver))// 通过系统调用陷入内核，打开 /dev/binder 设备
	, mVMStart(MAP_FAILED)// 映射内存的起始地址
	, mThreadCountLock(PTHREAD_MUTEX_INITIALIZER)
	, mThreadCountDecrement(PTHREAD_COND_INITIALIZER)
	, mExecutingThreadsCount(0)
	, mWaitingForThreads(0)
	, mMaxThreads(DEFAULT_MAX_BINDER_THREADS)
	, mStarvationStartTimeMs(0)
	, mThreadPoolStarted(false)
	, mThreadPoolSeq(1)
	, mCallRestriction(CallRestriction::NONE)
	{
	if (mDriverFD >= 0) {
	// mmap the binder, providing a chunk of virtual address space to receive transactions.
	// 调用内存映射函数 mmap, 此时 binder 驱动会在内核空间执行 binder_mmap, 来将一块物理内存同时映射到
	// 用户空间和内核空间，来帮助进行跨进程通信
	// #define BINDER_VM_SIZE ((1 * 1024 * 1024) - sysconf(_SC_PAGE_SIZE) * 2) = 1016KB
	// PAGE_SIZE 被定义为 4096
	mVMStart = mmap(nullptr, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE \| MAP_NORESERVE, mDriverFD, 0);
	if (mVMStart == MAP_FAILED) {
	// sigh
	ALOGE("Using %s failed: unable to mmap transaction memory.\n", mDriverName.c_str());
	close(mDriverFD);
	mDriverFD = -1;
	mDriverName.clear();
	}
	}

	#ifdef __ANDROID__
	LOG_ALWAYS_FATAL_IF(mDriverFD < 0, "Binder driver '%s' could not be opened. Terminating.", driver);
	#endif
	}

# open_driver

	//platform\frameworks\native\libs\binder\ProcessState.cpp
	static int open_driver(const char *driver)
	{
	// 以读写方式打开，并为该文件描述符添加 close-on-exec (执行时可关闭) 的标志，
	// 来防止该文件描述符被意外泄漏给了 fork 创建出来的子进程
	int fd = open(driver, O_RDWR \| O_CLOEXEC);
	if (fd >= 0) {
	int vers = 0;
	status_t result = ioctl(fd, BINDER_VERSION, &vers);
	if (result == -1) {
	ALOGE("Binder ioctl to obtain version failed: %s", strerror(errno));
	close(fd);
	fd = -1;
	}
	if (result != 0 \|\| vers != BINDER_CURRENT_PROTOCOL_VERSION) {
	ALOGE("Binder driver protocol(%d) does not match user space protocol(%d)! ioctl() return value: %d",
	vers, BINDER_CURRENT_PROTOCOL_VERSION, result);
	close(fd);
	fd = -1;
	}
	// 设置这个打开的 binder 对象的最大线程数为 15
	size_t maxThreads = DEFAULT_MAX_BINDER_THREADS;
	result = ioctl(fd, BINDER_SET_MAX_THREADS, &maxThreads);
	if (result == -1) {
	ALOGE("Binder ioctl to set max threads failed: %s", strerror(errno));
	}
	uint32_t enable = DEFAULT_ENABLE_ONEWAY_SPAM_DETECTION;
	result = ioctl(fd, BINDER_ENABLE_ONEWAY_SPAM_DETECTION, &enable);
	if (result == -1) {
	ALOGD("Binder ioctl to enable oneway spam detection failed: %s", strerror(errno));
	}
	} else {
	ALOGW("Opening '%s' failed: %s\n", driver, strerror(errno));
	}
	return fd;
	}

# 总结

# Binder 中各个类的含义

在进行后续的学习前，我们先来了解一下 Binder 中各个类的含义

类名	说明
BpRefBase	RefBase 的子类，提供 remote () 方法获取远程 Binder
IInterface	Binder 服务接口的基类，Binder 服务通常需要同时提供本地接口和远程接口
BpInterface	远程接口的基类，远程接口是供客户端调用的接口集
BnInterface	本地接口的基类，本地接口是需要服务中真正实现的接口集
IBinder	Binder 对象的基类，BBinder 和 BpBinder 都是这个类的子类
BpBinder	远程 Binder，这个类提供 transact 方法来发送请求，BpXXX 实现中会用到
BBinder	本地 Binder，服务实现方的基类，提供了 onTransact 接口来接收请求
ProcessState	代表了使用 Binder 的进程
IPCThreadState	代表了使用 Binder 的线程，这个类中封装了与 Binder 驱动通信的逻辑
Parcel	在 Binder 上传递的数据的包装器

Binder 服务的实现类通常都会遵守下面的命名规则

服务的接口使用 I 字母作为前缀
远程接口使用 Bp 作为前缀
本地接口使用 Bn 作为前缀
p 即 proxy 的意思，是客户端用来与 Server 交互的类

IBinder 家族

BpBinder 和 BBinder 都是 Android 中与 Binder 通信相关的代表，它们都从 IBinder 类中派生而来

BpBinder 是客户端用来与 Server 交互的代理类，p 即 proxy 的意思
BBinder 则是 proxy 相对的一端，它是 proxy 交互的目的端。如果说 BpBinder 代表客户端，那么 BBinder 则代表服务端。这里的 BpBinder 和 BBinder 是一一对应的，即某个 BpBinder 只能和对应的 BBinder 交互
在注册服务和获取服务的过程中，ServiceManager 均为服务端
BpBinder 通过 handle 来标识它所对应的 BBinder 端，与其相关的函数为 sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle) ,handle 值为 0 表示 ServiceManager 所对应的 BBinder

IServiceManager 家族

IServiceManager、BpServiceManager 和 BnServiceManager 都与业务逻辑相关。
BnServiceManager 同时从 BBinder 派生，表示它可以直接参与 Binder 通信。
BpServiceManager 虽然从 BpInterface 中派生，但是这条分支似乎与 BpBinder 没有关系。
BnServiceManager 是一个虚类，它的业务函数最终需要子类来实现。

# ServiceManager 的获取过程

当一个 Server 想要注册服务，那必须要知道 "ServiceManager 在哪里才可以", 所以需要有一个方法来让 Server 找到 ServiceManager, 这是通过函数 defaultServiceManager 实现的

	// 获取 BpServiceManager 对象
	sp<IServiceManager> sm(defaultServiceManager());

defaultServiceManager 的主要作用是获取 BpServiceManager 对象，它通过 getContextObject 获取到了 ServiceManager 的 BBinder 所对应的 BpBinder 对象，随后利用 interface_cast 将 BpBinder 对象转换成了 BpServiceManager 对象

	//platform\frameworks\native\libs\binder\IServiceManager.cpp
	sp<IServiceManager> defaultServiceManager()
	{
	std::call_once(gSmOnce, []() {
	sp<AidlServiceManager> sm = nullptr;
	while (sm == nullptr) {
	// 获取 ServiceManager 的 BBinder 所对应的 BpBinder 对象，
	// 并将该对象通过 interface_cast 转换为 AidlServiceManager
	sm = interface_cast<AidlServiceManager>(ProcessState::self()->getContextObject(nullptr));
	if (sm == nullptr) {
	ALOGE("Waiting 1s on context object on %s.", ProcessState::self()->getDriverName().c_str());
	sleep(1);
	}
	}
	// 实例化 ServiceManagerShim
	gDefaultServiceManager = sp<ServiceManagerShim>::make(sm);
	});

	return gDefaultServiceManager;
	}

AidlServiceManager

AidlServiceManager 其实是 android::os::IServiceManager 的别名

using AidlServiceManager = android::os::IServiceManager;

ServiceManagerShim

之前是没有 ServiceManagerShim 的，而是直接操作 BpServiceManager，这个辅助类封装了 AIDL 自动生成的 BpServiceManager，所以现在的客户端代码流就变成如下三步：

	1. 用户代码
	2. libbinder代码 binder/IServiceManager.cpp#ServiceManagerShim
	3. AIDL 代码 android/os/IServiceManager.cpp#BpServiceManager 接口

libbinder 中的 ServiceManagerShim 起到了一个中转的作用，把请求转给 out 下 AIDL 自动生成的 BpServiceManager, 原来是在 libbinder#IServiceManager.cpp 中手写实现，现在是 AIDL 帮你实现。

	//platform\frameworks\native\libs\binder\IServiceManager.cpp
	// From the old libbinder IServiceManager interface to IServiceManager.
	class ServiceManagerShim : public IServiceManager
	{
	public:
	explicit ServiceManagerShim (const sp<AidlServiceManager>& impl);

	sp<IBinder> getService(const String16& name) const override;
	sp<IBinder> checkService(const String16& name) const override;
	status_t addService(const String16& name, const sp<IBinder>& service,
	bool allowIsolated, int dumpsysPriority) override;
	Vector<String16> listServices(int dumpsysPriority) override;
	sp<IBinder> waitForService(const String16& name16) override;
	bool isDeclared(const String16& name) override;
	Vector<String16> getDeclaredInstances(const String16& interface) override;
	std::optional<String16> updatableViaApex(const String16& name) override;

	// for legacy ABI
	const String16& getInterfaceDescriptor() const override {
	return mTheRealServiceManager->getInterfaceDescriptor();
	}
	IBinder* onAsBinder() override {
	return IInterface::asBinder(mTheRealServiceManager).get();
	}
	private:
	sp<AidlServiceManager> mTheRealServiceManager;
	};

# getContextObject

这个函数最主要的功能就是获取 ServiceManager 的 BBinder 所对应的 BpBinder 对象，它通过调用 getStrongProxyForHandle(0) 来进行获取

这里传入的 handle 的值为 0, 它表示 ServiceManager 所对应的 BBinder

	//platform\frameworks\native\libs\binder\ProcessState.cpp
	sp<IBinder> ProcessState::getContextObject(const sp<IBinder>& /caller/)
	{
	// 创建一个 BpBinder 对象，getStrongProxyForHandle 传入的参数 handle 的值为 0
	//,0 代表的就是 ServiceManager 所对应的 BBinder。
	sp<IBinder> context = getStrongProxyForHandle(0);

	if (context) {
	// The root object is special since we get it directly from the driver, it is never
	// written by Parcell::writeStrongBinder.
	internal::Stability::markCompilationUnit(context.get());
	} else {
	ALOGW("Not able to get context object on %s.", mDriverName.c_str());
	}

	return context;
	}

getStrongProxyForHandle(0)

	//platform\frameworks\native\libs\binder\ProcessState.cpp
	sp<IBinder> ProcessState::getStrongProxyForHandle(int32_t handle)
	{
	sp<IBinder> result;

	AutoMutex _l(mLock);
	// 根据索引查找对应资源。
	handle_entry* e = lookupHandleLocked(handle);
	// 如果 lookupHandleLocked 发现没有对应的资源项，则会创建一个新的项并返回。
	if (e != nullptr) {
	// We need to create a new BpBinder if there isn't currently one, OR we
	// are unable to acquire a weak reference on this current one. The
	// attemptIncWeak() is safe because we know the BpBinder destructor will always
	// call expungeHandle(), which acquires the same lock we are holding now.
	// We need to do this because there is a race condition between someone
	// releasing a reference on this BpBinder, and a new reference on its handle
	// arriving from the driver.
	IBinder* b = e->binder;
	if (b == nullptr \|\| !e->refs->attemptIncWeak(this)) {
	if (handle == 0) {
	// Special case for context manager...
	// The context manager is the only object for which we create
	// a BpBinder proxy without already holding a reference.
	// Perform a dummy transaction to ensure the context manager
	// is registered before we create the first local reference
	// to it (which will occur when creating the BpBinder).
	// If a local reference is created for the BpBinder when the
	// context manager is not present, the driver will fail to
	// provide a reference to the context manager, but the
	// driver API does not return status.
	//
	// Note that this is not race-free if the context manager
	// dies while this code runs.
	//
	// TODO: add a driver API to wait for context manager, or
	// stop special casing handle 0 for context manager and add
	// a driver API to get a handle to the context manager with
	// proper reference counting.

	IPCThreadState* ipc = IPCThreadState::self();

	CallRestriction originalCallRestriction = ipc->getCallRestriction();
	ipc->setCallRestriction(CallRestriction::NONE);

	Parcel data;
	status_t status = ipc->transact(
	0, IBinder::PING_TRANSACTION, data, nullptr, 0);

	ipc->setCallRestriction(originalCallRestriction);

	if (status == DEAD_OBJECT)
	return nullptr;
	}
	// 创建一个 BpBinder
	sp<BpBinder> b = BpBinder::create(handle);
	e->binder = b.get();
	if (b) e->refs = b->getWeakRefs();
	result = b;
	} else {
	// This little bit of nastyness is to allow us to add a primary
	// reference to the remote proxy when this team doesn't have one
	// but another team is sending the handle to us.
	result.force_set(b);
	e->refs->decWeak(this);
	}
	}

	return result;
	}

# interface_cast

	//platform\frameworks\native\libs\binder\include\binder\IInterface.h
	/**
	* If this is a local object and the descriptor matches, this will return the
	* actual local object which is implementing the interface. Otherwise, this will
	* return a proxy to the interface without checking the interface descriptor.
	* This means that subsequent calls may fail with BAD_TYPE.
	*/
	template<typename INTERFACE>
	inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
	{
	return INTERFACE::asInterface(obj);
	}

这是一个模板函数，其中的 asInterface 是在 DECLARE_META_INTERFACE 宏中定义的

asInterface

	//platform\frameworks\native\include\binder\IInterface.h
	//## 的作用是将前后两个标识符或符号连接在一起，以形成一个单独的标识符或符号。
	// 如 #define CONCATENATE (x, y) x##y
	// 如果调用 CONCATENATE (a, b)，它将被展开为 ab
	#define DECLARE_META_INTERFACE(INTERFACE) \
	public: \
	static const ::android::String16 descriptor; \
	static ::android::sp<I##INTERFACE> asInterface( \
	const ::android::sp<::android::IBinder>& obj); \
	virtual const ::android::String16& getInterfaceDescriptor() const; \
	I##INTERFACE(); \
	virtual ~I##INTERFACE(); \
	static bool setDefaultImpl(std::unique_ptr<I##INTERFACE> impl); \
	static const std::unique_ptr<I##INTERFACE>& getDefaultImpl(); \
	private: \
	static std::unique_ptr<I##INTERFACE> default_impl; \
	public: \

	#define IMPLEMENT_META_INTERFACE(INTERFACE, NAME) \
	DO_NOT_DIRECTLY_USE_ME_IMPLEMENT_META_INTERFACE(INTERFACE, NAME) \

	#define DO_NOT_DIRECTLY_USE_ME_IMPLEMENT_META_INTERFACE(INTERFACE, NAME)\
	const ::android::StaticString16 \
	I##INTERFACE##_descriptor_static_str16(__IINTF_CONCAT(u, NAME));\
	const ::android::String16 I##INTERFACE::descriptor( \
	I##INTERFACE##_descriptor_static_str16); \
	const ::android::String16& \
	I##INTERFACE::getInterfaceDescriptor() const { \
	return I##INTERFACE::descriptor; \
	} \
	::android::sp<I##INTERFACE> I##INTERFACE::asInterface( \
	const ::android::sp<::android::IBinder>& obj) \
	{ \
	::android::sp<I##INTERFACE> intr; \
	if (obj != nullptr) { \
	intr = ::android::sp<I##INTERFACE>::cast( \
	obj->queryLocalInterface(I##INTERFACE::descriptor)); \
	if (intr == nullptr) { \
	intr = ::android::sp<Bp##INTERFACE>::make(obj); \
	} \
	} \
	return intr; \
	} \
	std::unique_ptr<I##INTERFACE> I##INTERFACE::default_impl; \
	bool I##INTERFACE::setDefaultImpl(std::unique_ptr<I##INTERFACE> impl)\
	{ \
	/* Only one user of this interface can use this function */ \
	/* at a time. This is a heuristic to detect if two different */ \
	/* users in the same process use this function. */ \
	assert(!I##INTERFACE::default_impl); \
	if (impl) { \
	I##INTERFACE::default_impl = std::move(impl); \
	return true; \
	} \
	return false; \
	} \
	const std::unique_ptr<I##INTERFACE>& I##INTERFACE::getDefaultImpl() \
	{ \
	return I##INTERFACE::default_impl; \
	} \
	I##INTERFACE::I##INTERFACE() { } \
	I##INTERFACE::~I##INTERFACE() { } \

我们将 interface_cast<AidlServiceManager>(new BpBinder(0)) 通过宏定义替换一下看的会更加清楚，在这里 asInterface 将 BpBinder 转换成了 BpServiceManager , BpServiceManager 继承了 IServiceManager

	public:
	static const ::android::String16 descriptor;
	static ::android::sp<IServiceManager> asInterface(
	const ::android::sp<::android::IBinder>& obj);
	virtual const ::android::String16& getInterfaceDescriptor() const;
	IServiceManager();
	virtual ~IServiceManager();
	static bool setDefaultImpl(std::unique_ptr<IServiceManager> impl);
	static const std::unique_ptr<IServiceManager>& getDefaultImpl();
	private:
	static std::unique_ptr<IServiceManager> default_impl;
	public:
	const ::android::StaticString16
	IServiceManager_descriptor_static_str16(__IINTF_CONCAT(u, android.os.IServiceManager));
	const ::android::String16 IServiceManager::descriptor(
	IServiceManager_descriptor_static_str16);
	const ::android::String16&
	IServiceManager::getInterfaceDescriptor() const {
	return IServiceManager::descriptor;
	}

	// 在这里终于出现了 asInterface 函数的定义，我们也找到了 BpServiceManager 这个类
	::android::sp<IServiceManager> IServiceManager::asInterface(
	const ::android::sp<::android::IBinder>& obj)
	{
	::android::sp<IServiceManager> intr;
	if (obj != nullptr) {
	intr = ::android::sp<IServiceManager>::cast(
	obj->queryLocalInterface(IServiceManager::descriptor));
	if (intr == nullptr) {
	intr = ::android::sp<BpServiceManager>::make(obj);
	}
	}
	return intr;
	}
	std::unique_ptr<IServiceManager> IServiceManager::default_impl;
	bool IServiceManager::setDefaultImpl(std::unique_ptr<IServiceManager> impl)
	{
	/* Only one user of this interface can use this function */
	/* at a time. This is a heuristic to detect if two different */
	/* users in the same process use this function. */
	assert(!IServiceManager::default_impl);
	if (impl) {
	IServiceManager::default_impl = std::move(impl);
	return true;
	}
	return false;
	}
	const std::unique_ptr<IServiceManager>& IServiceManager::getDefaultImpl()
	{
	return IServiceManager::default_impl;
	}
	IServiceManager::IServiceManager() { }
	IServiceManager::~IServiceManager() { }

# 总结

# Server 向 ServiceManager 注册服务

这里以 MediaServer 为例来分析 Server 向 ServiceManager 注册服务的过程

	//platform\frameworks\av\media\mediaserver\main_mediaserver.cpp

	int main(int argc __unused, char **argv __unused)
	{
	signal(SIGPIPE, SIG_IGN);

	// 创建一个 ProcessState 实例，打开默认驱动 /dev/binder 并进行 mmap 内存映射
	// 此方法的详细分析请参见右侧目录 ServiceManager 的启动过程 ->ProcessState::init
	sp<ProcessState> proc(ProcessState::self());

	// 客户端获取 ServiceManagerShim 对象
	// 此方法的详细分析请参见右侧目录 ServiceManager 的获取过程
	sp<IServiceManager> sm(defaultServiceManager());
	ALOGI("ServiceManager: %p", sm.get());

	// 注册 media.player 服务
	MediaPlayerService::instantiate();
	ResourceManagerService::instantiate();
	registerExtensions();
	::android::hardware::configureRpcThreadpool(16, false);
	// 启动线程池
	ProcessState::self()->startThreadPool();
	// 将线程加入线程池
	IPCThreadState::self()->joinThreadPool();
	::android::hardware::joinRpcThreadpool();
	}

MediaPlayerService::instantiate

这个函数的作用就是调用 defaultServiceManager 的 addService 方法来添加向 ServiceManager 注册服务

	//platform\frameworks\av\media\libmediaplayerservice\MediaPlayerService.cpp
	void MediaPlayerService::instantiate() {
	defaultServiceManager()->addService(
	String16("media.player"), new MediaPlayerService());
	}

# defaultServiceManager()->addService

	//platform\frameworks\native\libs\binder\IServiceManager.cpp
	status_t ServiceManagerShim::addService(const String16& name, const sp<IBinder>& service,
	bool allowIsolated, int dumpsysPriority)
	{
	Status status = mTheRealServiceManager->addService(
	String8(name).c_str(), service, allowIsolated, dumpsysPriority);
	return status.exceptionCode();
	}

这里使用了 mTheRealServiceManager 中的 addService 方法，那么 mTheRealServiceManager 是从哪里来的呢？

# mTheRealServiceManager

	//platform\frameworks\native\libs\binder\IServiceManager.cpp
	using AidlServiceManager = android::os::IServiceManager;
	// From the old libbinder IServiceManager interface to IServiceManager.
	class ServiceManagerShim : public IServiceManager
	{
	public:
	...
	private:
	sp<AidlServiceManager> mTheRealServiceManager;
	};
	ServiceManagerShim::ServiceManagerShim(const sp<AidlServiceManager>& impl)
	: mTheRealServiceManager(impl)
	{}

从这段 ServiceManagerShim 类的声明中，我们可以清楚的看到 mTheRealServiceManager 是 android::os::IServiceManager 类型的实例，并且在 ServiceManagerShim 实例化时赋值

而在 ServiceManager 的获取过程 中，我们知道 ServiceManagerShim 是在 defaultServiceManager() 中实例化的

	//platform\frameworks\native\libs\binder\IServiceManager.cpp
	sp<IServiceManager> defaultServiceManager()
	{
	std::call_once(gSmOnce, []() {
	sp<AidlServiceManager> sm = nullptr;
	while (sm == nullptr) {
	// 获取 ServiceManager 的 BBinder 所对应的 BpBinder 对象，
	// 并将该对象通过 interface_cast 转换为 AidlServiceManager
	sm = interface_cast<AidlServiceManager>(ProcessState::self()->getContextObject(nullptr));
	if (sm == nullptr) {
	ALOGE("Waiting 1s on context object on %s.", ProcessState::self()->getDriverName().c_str());
	sleep(1);
	}
	}
	// 实例化 ServiceManagerShim
	gDefaultServiceManager = sp<ServiceManagerShim>::make(sm);
	});

	return gDefaultServiceManager;
	}

所以说 mTheRealServiceManager 其实是 BpServiceManager(new BpBinder(0)) , 注册服务的顺序为 BpServiceManager-->BpBinder-->IPCThreadState-->ioctl

而 BpServiceManager 现在是由 AIDL 自动生成，在框架编译完成之后的 out 目录中的

BpServiceManager::addService

	//platform/out/soong/.intermediates/frameworks/native/libs/binder/libbinder/android_arm_armv8-a_shared/gen/aidl/android/os/IServiceManager.cpp
	namespace android {
	namespace os {

	BpServiceManager::BpServiceManager(const ::android::sp<::android::IBinder>& _aidl_impl)
	: BpInterface<IServiceManager>(_aidl_impl){//_aidl_impl 就是 BpBinder (0) 实例
	}
	--------------------------------------------------
	::android::binder::Status BpServiceManager::addService(const ::std::string& name, const ::android::sp<::android::IBinder>& service, bool allowIsolated, int32_t dumpPriority) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());//0、和 Rpc Binder 有关
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	//1、写 interface
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	//2、写 name
	_aidl_ret_status = _aidl_data.writeUtf8AsUtf16(name);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	//3、写 binder 对象
	_aidl_ret_status = _aidl_data.writeStrongBinder(service);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	//4、写 allowIsolated
	_aidl_ret_status = _aidl_data.writeBool(allowIsolated);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	//5、写 dumpPriority
	_aidl_ret_status = _aidl_data.writeInt32(dumpPriority);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	//6、借助 BpBinder (0)#transact 来发起 Binder 通信
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_addService, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->addService(name, service, allowIsolated, dumpPriority);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	//7、如果有返回值就从这个 parcel 包里读
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

这个过程主要是借助 BpBinder(0)#transact 来发起 Binder 通信，Binder 驱动根据 handle == 0 找到我们的 ServiceManager 进程，唤醒他开始处理请求。

还记得在 ServiceManager 的启动过程 中的那个 while 循环函数吗？BinderCallback 就是用来处理 Binder 驱动发送的 BR_TRANSACTION 信号的

	//platform\frameworks\native\cmds\servicemanager\main.cpp
	int main(int argc, char** argv) {
	...
	// 准备 looper
	sp<Looper> looper = Looper::prepare(false /allowNonCallbacks/);

	// 监听 BC_ENTER_LOOPER 信号，收到该信号后回调处理 binder 调用
	BinderCallback::setupTo(looper);

	// 监听客户端回调
	ClientCallbackCallback::setupTo(looper, manager);

	// 阻塞等待和处理事件
	while(true) {
	looper->pollAll(-1);
	}

	// should not be reached
	return EXIT_FAILURE;
	}

# BinderCallback

BinderCallback::handleEvent 调用了 IPCThreadState::self()->handlePolledCommands() 来处理命令

	//platform\frameworks\native\cmds\servicemanager\main.cpp
	class BinderCallback : public LooperCallback {
	public:
	static sp<BinderCallback> setupTo(const sp<Looper>& looper) {
	sp<BinderCallback> cb = sp<BinderCallback>::make();

	int binder_fd = -1;
	// 监听 BC_ENTER_LOOPER 信号
	IPCThreadState::self()->setupPolling(&binder_fd);
	LOG_ALWAYS_FATAL_IF(binder_fd < 0, "Failed to setupPolling: %d", binder_fd);

	int ret = looper->addFd(binder_fd,
	Looper::POLL_CALLBACK,
	Looper::EVENT_INPUT,
	cb,
	nullptr /data/);
	LOG_ALWAYS_FATAL_IF(ret != 1, "Failed to add binder FD to Looper");

	return cb;
	}

	int handleEvent(int /* fd /, int / events /, void /* data */) override {
	IPCThreadState::self()->handlePolledCommands();
	return 1; // Continue receiving callbacks.
	}
	};

# IPCThreadState::handlePolledCommands

	//platform\frameworks\native\libs\binder\IPCThreadState.cpp
	status_t IPCThreadState::handlePolledCommands()
	{
	status_t result;

	do {
	// 获取并执行命令
	result = getAndExecuteCommand();
	} while (mIn.dataPosition() < mIn.dataSize());

	processPendingDerefs();
	flushCommands();
	return result;
	}

# IPCThreadState::getAndExecuteCommand

	//platform\frameworks\native\libs\binder\IPCThreadState.cpp
	status_t IPCThreadState::getAndExecuteCommand()
	{
	status_t result;
	int32_t cmd;

	// 和 binder 驱动通信，获取或传输数据
	result = talkWithDriver();
	if (result >= NO_ERROR) {
	size_t IN = mIn.dataAvail();
	if (IN < sizeof(int32_t)) return result;
	// 读取命令
	cmd = mIn.readInt32();
	IF_LOG_COMMANDS() {
	alog << "Processing top-level Command: "
	<< getReturnString(cmd) << endl;
	}

	pthread_mutex_lock(&mProcess->mThreadCountLock);
	mProcess->mExecutingThreadsCount++;
	if (mProcess->mExecutingThreadsCount >= mProcess->mMaxThreads &&
	mProcess->mStarvationStartTimeMs == 0) {
	mProcess->mStarvationStartTimeMs = uptimeMillis();
	}
	pthread_mutex_unlock(&mProcess->mThreadCountLock);

	// 解析并执行命令
	result = executeCommand(cmd);

	pthread_mutex_lock(&mProcess->mThreadCountLock);
	mProcess->mExecutingThreadsCount--;
	if (mProcess->mExecutingThreadsCount < mProcess->mMaxThreads &&
	mProcess->mStarvationStartTimeMs != 0) {
	int64_t starvationTimeMs = uptimeMillis() - mProcess->mStarvationStartTimeMs;
	if (starvationTimeMs > 100) {
	ALOGE("binder thread pool (%zu threads) starved for %" PRId64 " ms",
	mProcess->mMaxThreads, starvationTimeMs);
	}
	mProcess->mStarvationStartTimeMs = 0;
	}

	// Cond broadcast can be expensive, so don't send it every time a binder
	// call is processed. b/168806193
	if (mProcess->mWaitingForThreads > 0) {
	pthread_cond_broadcast(&mProcess->mThreadCountDecrement);
	}
	pthread_mutex_unlock(&mProcess->mThreadCountLock);
	}

	return result;
	}

# IPCThreadState::executeCommand

	//platform\frameworks\native\libs\binder\IPCThreadState.cpp
	status_t IPCThreadState::executeCommand(int32_t cmd)
	{
	switch ((uint32_t)cmd) {
	case BR_TRANSACTION:
	{ // 因为目的端 SM 所以 tr.target.ptr 为 0
	if (tr.target.ptr) {
	...
	}else {// 开始业务分发
	error = the_context_object->transact(tr.code, buffer, &reply, tr.flags);
	}

# IPCThreadState::setTheContextObject

在 ServiceManager 的启动过程 这节的内容中，我们让 ServiceManager 成为了整个 binder IPC 通信中的上下文管理者，并将其存储在全局变量 the_context_object 中

	//platform\frameworks\native\cmds\servicemanager\main.cpp
	sp<BBinder> the_context_object;

	void IPCThreadState::setTheContextObject(const sp<BBinder>& obj)
	{
	the_context_object = obj;
	}

	int main(int argc, char** argv) {
	...
	// 将 "manager" 服务作为服务端 Bbinder 对象
	IPCThreadState::self()->setTheContextObject(manager);
	// 向 binder 驱动发送 ioctl BINDER_SET_CONTEXT_MGR_EXT 信号，将 servicemanager
	// 在 ProcessState::initWithDriver 中打开驱动设备 /dev/driver 所返回的文件描述符句柄
	// 作为整个 binder IPC 通信中的上下文管理者
	ps->becomeContextManager();
	...
	}

# BBinder::transact

所以 the_context_object->transact() 调用就走到 BBinder 的 transact

	//platform\frameworks\native\libs\binder\Binder.cpp

	// NOLINTNEXTLINE(google-default-arguments)
	status_t BBinder::transact(
	uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
	{
	data.setDataPosition(0);

	if (reply != nullptr && (flags & FLAG_CLEAR_BUF)) {
	reply->markSensitive();
	}

	status_t err = NO_ERROR;
	switch (code) {
	case PING_TRANSACTION:
	err = pingBinder();
	break;
	case EXTENSION_TRANSACTION:
	err = reply->writeStrongBinder(getExtension());
	break;
	case DEBUG_PID_TRANSACTION:
	err = reply->writeInt32(getDebugPid());
	break;
	default:
	err = onTransact(code, data, reply, flags);
	break;
	}

	// In case this is being transacted on in the same process.
	if (reply != nullptr) {
	reply->setDataPosition(0);
	}

	return err;
	}

# BnServiceManager::onTransact

然后回到了这个 AIDL 自动生成的 IServiceManager.cpp 中 BnServiceManager 的 onTransact () 方法里

	//platform/out/soong/.intermediates/frameworks/native/libs/binder/libbinder/android_arm_armv8-a_shared/gen/aidl/android/os/IServiceManager.cpp

	::android::status_t BnServiceManager::onTransact(uint32_t _aidl_code, const ::android::Parcel& _aidl_data, ::android::Parcel* _aidl_reply, uint32_t _aidl_flags) {
	::android::status_t _aidl_ret_status = ::android::OK;
	switch (_aidl_code) {
	case BnServiceManager::TRANSACTION_addService:
	{
	::std::string in_name;
	::android::sp<::android::IBinder> in_service;
	bool in_allowIsolated;
	int32_t in_dumpPriority;
	// 检查 interface
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	// 读 name
	_aidl_ret_status = _aidl_data.readUtf8FromUtf16(&in_name);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	// 读 binder
	_aidl_ret_status = _aidl_data.readStrongBinder(&in_service);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	// 读 in_allowIsolated
	_aidl_ret_status = _aidl_data.readBool(&in_allowIsolated);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	// 读 in_dumpPriority
	_aidl_ret_status = _aidl_data.readInt32(&in_dumpPriority);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	// 调用真正的 ServiceManager.cpp 中的实现 addService
	::android::binder::Status _aidl_status(addService(in_name, in_service, in_allowIsolated, in_dumpPriority));
	// 如果有返回写返回到 _aidl_reply
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	}

# ServiceManager::addService

这里是和 Bp 端是对称的操作，下一步走到 ServiceManager.cpp::addService 方法

QUESTION? 为什么通过 ::android::binder::Status _aidl_status(addService(in_name, in_service, in_allowIsolated, in_dumpPriority)) 可以调用到 ServiceManager::addService ?

	//platform\frameworks\native\cmds\servicemanager\ServiceManager.cpp

	Status ServiceManager::addService(const std::string& name, const sp<IBinder>& binder, bool allowIsolated, int32_t dumpPriority) {
	auto ctx = mAccess->getCallingContext();

	// apps cannot add services
	if (multiuser_get_app_id(ctx.uid) >= AID_APP) {
	return Status::fromExceptionCode(Status::EX_SECURITY);
	}

	if (!mAccess->canAdd(ctx, name)) {
	return Status::fromExceptionCode(Status::EX_SECURITY);
	}

	if (binder == nullptr) {
	return Status::fromExceptionCode(Status::EX_ILLEGAL_ARGUMENT);
	}

	// 检验 Service 名称的合法性，名称长度要求大于 0 并小于等于 127
	// 字符仅包括 [a-z][A-Z][0-9]_-./
	if (!isValidServiceName(name)) {
	LOG(ERROR) << "Invalid service name: " << name;
	return Status::fromExceptionCode(Status::EX_ILLEGAL_ARGUMENT);
	}

	#ifndef VENDORSERVICEMANAGER
	if (!meetsDeclarationRequirements(binder, name)) {
	// already logged
	return Status::fromExceptionCode(Status::EX_ILLEGAL_ARGUMENT);
	}
	#endif // !VENDORSERVICEMANAGER

	// implicitly unlinked when the binder is removed
	// 为 binder 对象设置死亡代理
	/*
	在和 service 进行交互时，service 返回一个 Binder 对象。
	Binder 是工作在 service 端，如果，由于某种原因，服务端出现故障而死亡，
	那么该返回的 Binder 对象也将消失，这时，如果我们在客户端在使用 Binder 对象
	进行某些函数调用将会出现错误。为了避免该情况的发生，我们可以为
	Binder 对象设置死亡代理 (linkToDeath)。当出现和服务端连接发生故障时，
	系统将自动调用死亡代理函数 binderDied ()。
	*/
	if (binder->remoteBinder() != nullptr &&
	binder->linkToDeath(sp<ServiceManager>::fromExisting(this)) != OK) {
	LOG(ERROR) << "Could not linkToDeath when adding " << name;
	return Status::fromExceptionCode(Status::EX_ILLEGAL_STATE);
	}

	// Overwrite the old service if it exists
	// 添加服务，以 name 作为索引值，使用 binder 作为参数实例化 Service 对象
	mNameToService[name] = Service {
	.binder = binder,
	.allowIsolated = allowIsolated,
	.dumpPriority = dumpPriority,
	.debugPid = ctx.debugPid,
	};


	/* 检查服务注册的合法性，包括
	1. 服务是否存在
	2. 该服务是否是服务端注册的
	3. 是否有同名服务存在
	4. 为该服务注册的死亡代理是否成功
	*/
	auto it = mNameToRegistrationCallback.find(name);
	if (it != mNameToRegistrationCallback.end()) {
	for (const sp<IServiceCallback>& cb : it->second) {
	mNameToService[name].guaranteeClient = true;
	// permission checked in registerForNotifications
	cb->onRegistration(name, binder);
	}
	}

	return Status::ok();
	}

# 总结

Server 想要向 ServiceManager 注册服务，首先通过 defaultServiceManager 获取到一个 Service Manager 的代理对象，然后再调用它的成员函数 addService 将该 Service 组件注册到 Service Manager 中，该代理对象通过向 Binder 驱动设备发送 BC_TRANSACTION 信号和 Service Manager 通信，在 Service Manager 启动之后会进入一个阻塞的无限循环， Service Manager 通过 BinderCallback 回调函数处理 Binder 驱动设备返回的 BR_TRANSACTION , 调用 BBinder 的 transact 方法，这个方法将会把我们引到 BnServiceManager 的 onTransact () 方法，终于这个方法将我们带到了真正添加服务的方法 ServiceManager.cpp::addService, 并向 mNameToService 字典中添加 name: Service 的键值对，来为 Client 向 ServiceManager 获取服务的过程做数据准备.

# Client 向 ServiceManager 获取服务

这里以 MediaServer 为例来分析 Client 向 ServiceManager 获取服务的过程

	// android-platform\frameworks\av\media\libmedia\IMediaDeathNotifier.cpp
	// establish binder interface to MediaPlayerService
	/static/const sp<IMediaPlayerService>
	IMediaDeathNotifier::getMediaPlayerService()
	{
	ALOGV("getMediaPlayerService");
	Mutex::Autolock _l(sServiceLock);
	if (sMediaPlayerService == 0) {
	sp<IServiceManager> sm = defaultServiceManager();
	sp<IBinder> binder;
	do {
	binder = sm->getService(String16("media.player"));// 核心函数，获取名为 media.player 的服务，因为在之前 Server 已经向 ServiceManager 注册过了
	if (binder != 0) {
	break;
	}
	ALOGW("Media player service not published, waiting...");
	usleep(500000); // 0.5 s 一个无限循环每 0.5 秒就获取一次服务，知道获取到权限
	} while (true);

	if (sDeathNotifier == NULL) {
	sDeathNotifier = new DeathNotifier();//Service 死亡后创建死亡通知
	}
	binder->linkToDeath(sDeathNotifier);
	sMediaPlayerService = interface_cast<IMediaPlayerService>(binder);
	}
	ALOGE_IF(sMediaPlayerService == 0, "no media player service!?");
	return sMediaPlayerService;
	}

# ServiceManagerShim::getService

这里调用 ServiceManagerShim::checkService 来寻找以注册的服务

	//android-platform\frameworks\native\libs\binder\IServiceManager.cpp

	// This implementation could be simplified and made more efficient by delegating
	// to waitForService. However, this changes the threading structure in some
	// cases and could potentially break prebuilts. Once we have higher logistical
	// complexity, this could be attempted.
	sp<IBinder> ServiceManagerShim::getService(const String16& name) const
	{
	static bool gSystemBootCompleted = false;

	sp<IBinder> svc = checkService(name);// 检查一下指定的服务名称是否存在
	if (svc != nullptr) return svc;// 找到了直接返回


	//verder 进程服务获取逻辑，这里不做分析
	const bool isVendorService =
	strcmp(ProcessState::self()->getDriverName().c_str(), "/dev/vndbinder") == 0;
	constexpr int64_t timeout = 5000;
	int64_t startTime = uptimeMillis();
	// Vendor code can't access system properties
	if (!gSystemBootCompleted && !isVendorService) {
	#ifdef __ANDROID__
	char bootCompleted[PROPERTY_VALUE_MAX];
	property_get("sys.boot_completed", bootCompleted, "0");
	gSystemBootCompleted = strcmp(bootCompleted, "1") == 0 ? true : false;
	#else
	gSystemBootCompleted = true;
	#endif
	}
	// retry interval in millisecond; note that vendor services stay at 100ms
	const useconds_t sleepTime = gSystemBootCompleted ? 1000 : 100;

	ALOGI("Waiting for service '%s' on '%s'...", String8(name).string(),
	ProcessState::self()->getDriverName().c_str());

	int n = 0;
	while (uptimeMillis() - startTime < timeout) {
	n++;
	usleep(1000*sleepTime);

	sp<IBinder> svc = checkService(name);
	if (svc != nullptr) {
	ALOGI("Waiting for service '%s' on '%s' successful after waiting %" PRIi64 "ms",
	String8(name).string(), ProcessState::self()->getDriverName().c_str(),
	uptimeMillis() - startTime);
	return svc;
	}
	}
	ALOGW("Service %s didn't start. Returning NULL", String8(name).string());
	return nullptr;
	}

# ServiceManagerShim::checkService

这里和 Server 向 ServiceManager 注册服务一节开头中的形式一样，也是通过 mTheRealServiceManager 来执行核心的获取服务逻辑，对该变量的赋值于分析可参阅 mTheRealServiceManager

	sp<IBinder> ServiceManagerShim::checkService(const String16& name) const
	{
	sp<IBinder> ret;
	if (!mTheRealServiceManager->checkService(String8(name).c_str(), &ret).isOk()) {
	return nullptr;
	}
	return ret;
	}

# BpServiceManager::checkService

同样的，我们需要从安卓框架编译之后的输入文件中找到由模板 aidl 生成的 IServiceManager.cpp

	///android-platform/out/soong/.intermediates/frameworks/native/libs/binder/libbinder/android_arm64_armv8-a_shared/gen/aidl/android/os/IServiceManager.cpp
	::android::binder::Status BpServiceManager::checkService(const ::std::string& name, ::android::sp<::android::IBinder>* _aidl_return) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	//1. 写 interface
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	//2. 将要查询的 Service name 写入
	_aidl_ret_status = _aidl_data.writeUtf8AsUtf16(name);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	// 借助 BpBinder (0)#transact 来发起 Binder 通信
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_checkService, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->checkService(name, _aidl_return);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_ret_status = _aidl_reply.readNullableStrongBinder(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

# BnServiceManager::onTransact

与 Server向ServiceManager注册服务 中相类似， BpBinder(0)#transact 来发起 Binder 通信后，BinderCallback 处理 Binder 驱动发送的 BR_TRANSACTION 信号，并交由 IPCThreadState::self()->handlePolledCommands() 来处理命令，最终来到由 aidl 生成的 aidl/android/os/IServiceManager.cpp 的 BnServiceManager::onTransact 去执行命令，与 ServiceManager 通过 Binder 通信

	::android::status_t BnServiceManager::onTransact(uint32_t _aidl_code, const ::android::Parcel& _aidl_data, ::android::Parcel* _aidl_reply, uint32_t _aidl_flags) {
	::android::status_t _aidl_ret_status = ::android::OK;
	switch (_aidl_code) {
	...
	case BnServiceManager::TRANSACTION_checkService:
	{
	::std::string in_name;
	::android::sp<::android::IBinder> _aidl_return;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	// 写入要查询的名称
	_aidl_ret_status = _aidl_data.readUtf8FromUtf16(&in_name);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	// 调用真正的 ServiceManager.cpp 中的实现 addService
	::android::binder::Status _aidl_status(checkService(in_name, &_aidl_return));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	_aidl_ret_status = _aidl_reply->writeStrongBinder(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	}
	break;
	...
	if (_aidl_ret_status == ::android::UNEXPECTED_NULL) {
	_aidl_ret_status = ::android::binder::Status::fromExceptionCode(::android::binder::Status::EX_NULL_POINTER).writeToParcel(_aidl_reply);
	}
	return _aidl_ret_status;
	}

# ServiceManager::checkService

同样和 Bp 端是对称的操作，下一步走到 ServiceManager.cpp::checkService 方法中

	//platform\frameworks\native\cmds\servicemanager\ServiceManager.cpp
	Status ServiceManager::checkService(const std::string& name, sp<IBinder>* outBinder) {
	*outBinder = tryGetService(name, false);
	// returns ok regardless of result for legacy reasons
	return Status::ok();
	}

# ServiceManager::tryGetService

	//platform\frameworks\native\cmds\servicemanager\ServiceManager.cpp
	sp<IBinder> ServiceManager::tryGetService(const std::string& name, bool startIfNotFound) {
	auto ctx = mAccess->getCallingContext();

	sp<IBinder> out;
	Service* service = nullptr;
	// 调用 mNameToService.find 利用 id 查找 Service
	if (auto it = mNameToService.find(name); it != mNameToService.end()) {
	service = &(it->second);

	if (!service->allowIsolated) {
	uid_t appid = multiuser_get_app_id(ctx.uid);
	bool isIsolated = appid >= AID_ISOLATED_START && appid <= AID_ISOLATED_END;

	if (isIsolated) {
	return nullptr;
	}
	}
	out = service->binder;
	}

	if (!mAccess->canFind(ctx, name)) {
	return nullptr;
	}
	// 如果 Service 没有启动的话就尝试启动 Servicve
	if (!out && startIfNotFound) {
	tryStartService(name);
	}

	if (out) {
	// Setting this guarantee each time we hand out a binder ensures that the client-checking
	// loop knows about the event even if the client immediately drops the service
	service->guaranteeClient = true;
	}

	return out;
	}

而倘若我们深究 mNameToService , 它可以在 ServiceManager.h 找到定义

	//platform/frameworks/native/libs/fakeservicemanager/ServiceManager.h
	class ServiceManager : public IServiceManager {
	public:
	...

	private:
	std::map<String16, sp<IBinder>> mNameToService;
	};

	} // namespace android

这样一看原来查找的过程很简单，就是在一个 map 字典里找找是否含有这个键，如果有的话，就是查找成功了并且返回 IBinder 类型的值，添加向字典中添加键值的过程其实已经在注册服务的时候做好了

	//platform\frameworks\native\cmds\servicemanager\ServiceManager.cpp

	Status ServiceManager::addService(const std::string& name, const sp<IBinder>& binder, bool allowIsolated, int32_t dumpPriority) {
	...
	// Overwrite the old service if it exists
	// 添加服务，以 name 作为索引值，使用 binder 作为参数实例化 Service 对象
	mNameToService[name] = Service {
	.binder = binder,
	.allowIsolated = allowIsolated,
	.dumpPriority = dumpPriority,
	.debugPid = ctx.debugPid,
	};


	/* 检查服务注册的合法性，包括
	1. 服务是否存在
	2. 该服务是否是服务端注册的
	3. 是否有同名服务存在
	4. 为该服务注册的死亡代理是否成功
	*/
	auto it = mNameToRegistrationCallback.find(name);
	if (it != mNameToRegistrationCallback.end()) {
	for (const sp<IServiceCallback>& cb : it->second) {
	mNameToService[name].guaranteeClient = true;
	// permission checked in registerForNotifications
	cb->onRegistration(name, binder);
	}
	}

	return Status::ok();
	}

# 总结

Client 向 ServiceManager 获取服务的过程其实很简单，主要就是一个 map 字典查询的过程，值得注意的是，Client 与 ServiceManager 的通信也是通过 Binder 驱动进行的

# 附录

# 安卓系统编译后由 aidl 生成的 IServiceManager.cpp

编译系统版本: android-12.0.0_r34

platform/out/soong/.intermediates/frameworks/native/libs/binder/libbinder/android_arm64_armv8-a_shared/gen/aidl/android/os/IServiceManager.cpp

	#include <android/os/IServiceManager.h>
	#include <android/os/BpServiceManager.h>

	namespace android {

	namespace os {

	DO_NOT_DIRECTLY_USE_ME_IMPLEMENT_META_INTERFACE(ServiceManager, "android.os.IServiceManager")

	} // namespace os

	} // namespace android
	#include <android/os/BpServiceManager.h>
	#include <android/os/BnServiceManager.h>
	#include <binder/Parcel.h>
	#include <android-base/macros.h>

	namespace android {

	namespace os {

	BpServiceManager::BpServiceManager(const ::android::sp<::android::IBinder>& _aidl_impl)
	: BpInterface<IServiceManager>(_aidl_impl){
	}

	::android::binder::Status BpServiceManager::getService(const ::std::string& name, ::android::sp<::android::IBinder>* _aidl_return) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeUtf8AsUtf16(name);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_getService, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->getService(name, _aidl_return);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_ret_status = _aidl_reply.readNullableStrongBinder(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

	::android::binder::Status BpServiceManager::checkService(const ::std::string& name, ::android::sp<::android::IBinder>* _aidl_return) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeUtf8AsUtf16(name);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_checkService, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->checkService(name, _aidl_return);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_ret_status = _aidl_reply.readNullableStrongBinder(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

	::android::binder::Status BpServiceManager::addService(const ::std::string& name, const ::android::sp<::android::IBinder>& service, bool allowIsolated, int32_t dumpPriority) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeUtf8AsUtf16(name);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeStrongBinder(service);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeBool(allowIsolated);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeInt32(dumpPriority);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_addService, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->addService(name, service, allowIsolated, dumpPriority);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

	::android::binder::Status BpServiceManager::listServices(int32_t dumpPriority, ::std::vector<::std::string>* _aidl_return) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeInt32(dumpPriority);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_listServices, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->listServices(dumpPriority, _aidl_return);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_ret_status = _aidl_reply.readUtf8VectorFromUtf16Vector(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

	::android::binder::Status BpServiceManager::registerForNotifications(const ::std::string& name, const ::android::sp<::android::os::IServiceCallback>& callback) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeUtf8AsUtf16(name);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeStrongBinder(::android::os::IServiceCallback::asBinder(callback));
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_registerForNotifications, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->registerForNotifications(name, callback);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

	::android::binder::Status BpServiceManager::unregisterForNotifications(const ::std::string& name, const ::android::sp<::android::os::IServiceCallback>& callback) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeUtf8AsUtf16(name);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeStrongBinder(::android::os::IServiceCallback::asBinder(callback));
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_unregisterForNotifications, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->unregisterForNotifications(name, callback);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

	::android::binder::Status BpServiceManager::isDeclared(const ::std::string& name, bool* _aidl_return) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeUtf8AsUtf16(name);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_isDeclared, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->isDeclared(name, _aidl_return);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_ret_status = _aidl_reply.readBool(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

	::android::binder::Status BpServiceManager::getDeclaredInstances(const ::std::string& iface, ::std::vector<::std::string>* _aidl_return) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeUtf8AsUtf16(iface);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_getDeclaredInstances, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->getDeclaredInstances(iface, _aidl_return);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_ret_status = _aidl_reply.readUtf8VectorFromUtf16Vector(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

	::android::binder::Status BpServiceManager::updatableViaApex(const ::std::string& name, ::std::optional<::std::string>* _aidl_return) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeUtf8AsUtf16(name);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_updatableViaApex, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->updatableViaApex(name, _aidl_return);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_ret_status = _aidl_reply.readUtf8FromUtf16(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

	::android::binder::Status BpServiceManager::registerClientCallback(const ::std::string& name, const ::android::sp<::android::IBinder>& service, const ::android::sp<::android::os::IClientCallback>& callback) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeUtf8AsUtf16(name);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeStrongBinder(service);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeStrongBinder(::android::os::IClientCallback::asBinder(callback));
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_registerClientCallback, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->registerClientCallback(name, service, callback);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

	::android::binder::Status BpServiceManager::tryUnregisterService(const ::std::string& name, const ::android::sp<::android::IBinder>& service) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeUtf8AsUtf16(name);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_data.writeStrongBinder(service);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_tryUnregisterService, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->tryUnregisterService(name, service);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

	::android::binder::Status BpServiceManager::getServiceDebugInfo(::std::vector<::android::os::ServiceDebugInfo>* _aidl_return) {
	::android::Parcel _aidl_data;
	_aidl_data.markForBinder(remoteStrong());
	::android::Parcel _aidl_reply;
	::android::status_t _aidl_ret_status = ::android::OK;
	::android::binder::Status _aidl_status;
	_aidl_ret_status = _aidl_data.writeInterfaceToken(getInterfaceDescriptor());
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = remote()->transact(BnServiceManager::TRANSACTION_getServiceDebugInfo, _aidl_data, &_aidl_reply, 0);
	if (UNLIKELY(_aidl_ret_status == ::android::UNKNOWN_TRANSACTION && IServiceManager::getDefaultImpl())) {
	return IServiceManager::getDefaultImpl()->getServiceDebugInfo(_aidl_return);
	}
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_ret_status = _aidl_status.readFromParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	if (!_aidl_status.isOk()) {
	return _aidl_status;
	}
	_aidl_ret_status = _aidl_reply.readParcelableVector(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	goto _aidl_error;
	}
	_aidl_error:
	_aidl_status.setFromStatusT(_aidl_ret_status);
	return _aidl_status;
	}

	} // namespace os

	} // namespace android
	#include <android/os/BnServiceManager.h>
	#include <binder/Parcel.h>
	#include <binder/Stability.h>

	namespace android {

	namespace os {

	BnServiceManager::BnServiceManager()
	{
	::android::internal::Stability::markCompilationUnit(this);
	}

	::android::status_t BnServiceManager::onTransact(uint32_t _aidl_code, const ::android::Parcel& _aidl_data, ::android::Parcel* _aidl_reply, uint32_t _aidl_flags) {
	::android::status_t _aidl_ret_status = ::android::OK;
	switch (_aidl_code) {
	case BnServiceManager::TRANSACTION_getService:
	{
	::std::string in_name;
	::android::sp<::android::IBinder> _aidl_return;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	_aidl_ret_status = _aidl_data.readUtf8FromUtf16(&in_name);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	::android::binder::Status _aidl_status(getService(in_name, &_aidl_return));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	_aidl_ret_status = _aidl_reply->writeStrongBinder(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	}
	break;
	case BnServiceManager::TRANSACTION_checkService:
	{
	::std::string in_name;
	::android::sp<::android::IBinder> _aidl_return;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	_aidl_ret_status = _aidl_data.readUtf8FromUtf16(&in_name);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	::android::binder::Status _aidl_status(checkService(in_name, &_aidl_return));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	_aidl_ret_status = _aidl_reply->writeStrongBinder(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	}
	break;
	case BnServiceManager::TRANSACTION_addService:
	{
	::std::string in_name;
	::android::sp<::android::IBinder> in_service;
	bool in_allowIsolated;
	int32_t in_dumpPriority;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	_aidl_ret_status = _aidl_data.readUtf8FromUtf16(&in_name);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	_aidl_ret_status = _aidl_data.readStrongBinder(&in_service);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	_aidl_ret_status = _aidl_data.readBool(&in_allowIsolated);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	_aidl_ret_status = _aidl_data.readInt32(&in_dumpPriority);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	::android::binder::Status _aidl_status(addService(in_name, in_service, in_allowIsolated, in_dumpPriority));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	}
	break;
	case BnServiceManager::TRANSACTION_listServices:
	{
	int32_t in_dumpPriority;
	::std::vector<::std::string> _aidl_return;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	_aidl_ret_status = _aidl_data.readInt32(&in_dumpPriority);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	::android::binder::Status _aidl_status(listServices(in_dumpPriority, &_aidl_return));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	_aidl_ret_status = _aidl_reply->writeUtf8VectorAsUtf16Vector(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	}
	break;
	case BnServiceManager::TRANSACTION_registerForNotifications:
	{
	::std::string in_name;
	::android::sp<::android::os::IServiceCallback> in_callback;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	_aidl_ret_status = _aidl_data.readUtf8FromUtf16(&in_name);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	_aidl_ret_status = _aidl_data.readStrongBinder(&in_callback);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	::android::binder::Status _aidl_status(registerForNotifications(in_name, in_callback));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	}
	break;
	case BnServiceManager::TRANSACTION_unregisterForNotifications:
	{
	::std::string in_name;
	::android::sp<::android::os::IServiceCallback> in_callback;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	_aidl_ret_status = _aidl_data.readUtf8FromUtf16(&in_name);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	_aidl_ret_status = _aidl_data.readStrongBinder(&in_callback);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	::android::binder::Status _aidl_status(unregisterForNotifications(in_name, in_callback));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	}
	break;
	case BnServiceManager::TRANSACTION_isDeclared:
	{
	::std::string in_name;
	bool _aidl_return;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	_aidl_ret_status = _aidl_data.readUtf8FromUtf16(&in_name);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	::android::binder::Status _aidl_status(isDeclared(in_name, &_aidl_return));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	_aidl_ret_status = _aidl_reply->writeBool(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	}
	break;
	case BnServiceManager::TRANSACTION_getDeclaredInstances:
	{
	::std::string in_iface;
	::std::vector<::std::string> _aidl_return;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	_aidl_ret_status = _aidl_data.readUtf8FromUtf16(&in_iface);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	::android::binder::Status _aidl_status(getDeclaredInstances(in_iface, &_aidl_return));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	_aidl_ret_status = _aidl_reply->writeUtf8VectorAsUtf16Vector(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	}
	break;
	case BnServiceManager::TRANSACTION_updatableViaApex:
	{
	::std::string in_name;
	::std::optional<::std::string> _aidl_return;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	_aidl_ret_status = _aidl_data.readUtf8FromUtf16(&in_name);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	::android::binder::Status _aidl_status(updatableViaApex(in_name, &_aidl_return));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	_aidl_ret_status = _aidl_reply->writeUtf8AsUtf16(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	}
	break;
	case BnServiceManager::TRANSACTION_registerClientCallback:
	{
	::std::string in_name;
	::android::sp<::android::IBinder> in_service;
	::android::sp<::android::os::IClientCallback> in_callback;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	_aidl_ret_status = _aidl_data.readUtf8FromUtf16(&in_name);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	_aidl_ret_status = _aidl_data.readStrongBinder(&in_service);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	_aidl_ret_status = _aidl_data.readStrongBinder(&in_callback);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	::android::binder::Status _aidl_status(registerClientCallback(in_name, in_service, in_callback));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	}
	break;
	case BnServiceManager::TRANSACTION_tryUnregisterService:
	{
	::std::string in_name;
	::android::sp<::android::IBinder> in_service;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	_aidl_ret_status = _aidl_data.readUtf8FromUtf16(&in_name);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	_aidl_ret_status = _aidl_data.readStrongBinder(&in_service);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	::android::binder::Status _aidl_status(tryUnregisterService(in_name, in_service));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	}
	break;
	case BnServiceManager::TRANSACTION_getServiceDebugInfo:
	{
	::std::vector<::android::os::ServiceDebugInfo> _aidl_return;
	if (!(_aidl_data.checkInterface(this))) {
	_aidl_ret_status = ::android::BAD_TYPE;
	break;
	}
	::android::binder::Status _aidl_status(getServiceDebugInfo(&_aidl_return));
	_aidl_ret_status = _aidl_status.writeToParcel(_aidl_reply);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	if (!_aidl_status.isOk()) {
	break;
	}
	_aidl_ret_status = _aidl_reply->writeParcelableVector(_aidl_return);
	if (((_aidl_ret_status) != (::android::OK))) {
	break;
	}
	}
	break;
	default:
	{
	_aidl_ret_status = ::android::BBinder::onTransact(_aidl_code, _aidl_data, _aidl_reply, _aidl_flags);
	}
	break;
	}
	if (_aidl_ret_status == ::android::UNEXPECTED_NULL) {
	_aidl_ret_status = ::android::binder::Status::fromExceptionCode(::android::binder::Status::EX_NULL_POINTER).writeToParcel(_aidl_reply);
	}
	return _aidl_ret_status;
	}

	} // namespace os

	} // namespace android

# 参考资料

gityuan 大佬的 Binder 系列
第 6 章深入理解 Binder
Android 12 系统源码分析 | Native Binder 代码变迁
Android 深入浅出之 Binder 机制
理解 Android Binder 机制 (2/3)：C++ 层

pixel3安卓系统编译及刷入过程记录

2024-06-20T09:33:17.000Z

想要下载并编译安卓系统，请必须预留至少 250G 及以上的空余空间，并保持代理连接稳定，否则将导致下载失败并从头下载！

# 安卓系统编译环境配置

# 为虚拟机配置代理

# 查看虚拟机代理地址

打开 clash for windows , 并打开 Allow LAN 的开关，随后点击 network interfaces

请注意我的虚拟机使用的网络连接方式为 NAT 模式，所以需要关注 VMnet8 的地址，所以对于该虚拟机，代理地址为 192.168.27.1 , 端口就是 clash 中 Port 选项所显示的端口

# 启用虚拟机代理

依次点击如下选项进入代理配置

输入代理地址保存即可

# 配置 docker ubuntu 镜像

# 安装 docker

sudo apt install docker.io

# docker pull 代理配置

	sudo mkdir -p /etc/systemd/system/docker.service.d
	sudo gedit /etc/systemd/system/docker.service.d/proxy.conf

输入以下代理服务器内容

	[Service]
	Environment="HTTP_PROXY=http://192.168.27.1:7890/"
	Environment="HTTPS_PROXY=http://192.168.27.1:7890/"
	Environment="NO_PROXY=localhost,127.0.0.1"

# 刷新配置并重启 docker 服务

	sudo systemctl daemon-reload
	sudo systemctl restart docker

# docker 镜像代理配置

	sudo mkdir -p ~/.docker/
	sudo gedit ~/.docker/config.json

输入以下内容

	{
	"proxies":
	{
	"default":
	{
	"httpProxy": "http://192.168.27.1:7890/",
	"httpsProxy": "http://192.168.27.1:7890/",
	"noProxy": "localhost,127.0.0.1"
	}
	}
	}

# 下载 Ubuntu 镜像

docker pull ubuntu

# 运行 Ubuntu 镜像

docker run --privileged -it --net host --name aplatform ubuntu /bin/bash

# 安装 sudo,vim

	apt-get update
	apt-get install vim
	apt-get install sudo

# 修改 apt-get 的软件源为阿里源

	sudo cp /etc/apt/sources.list /etc/apt/sources.list_backup
	sudo vim /etc/apt/sources.list

替换为如下内容

	deb http://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse
	deb-src http://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse

	deb http://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse
	deb-src http://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse

	deb http://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse
	deb-src http://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse

	# deb http://mirrors.aliyun.com/ubuntu/ jammy-proposed main restricted universe multiverse
	# deb-src http://mirrors.aliyun.com/ubuntu/ jammy-proposed main restricted universe multiverse

	deb http://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse
	deb-src http://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse

随后将 apt-get 更新至最新版本

	sudo apt-get update
	sudo apt-get upgrade
	sudo apt-get install build-essential

# 安装必要的库

sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 libncurses5 x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig libssl-dev bc kmod cpio git curl rsync

# 为 git 配置基本信息

	git config --global user.email "xxx@gmail.com"
	git config --global user.name "xxx"
	git config --global http.proxy 192.168.27.1:7890

# 安装 repo

	mkdir ~/bin
	curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
	chmod a+x ~/bin/repo

# 修改 repo 的下载源为清华源，并添加 repo 至全局变量

# 打开全局变量配置文件

sudo vim ~/.bashrc

# 添加全局变量

在末尾添加这三行并保存

	# repo
	export REPO_URL='https://mirrors.tuna.tsinghua.edu.cn/git/git-repo/'
	export PATH="~/bin:$PATH"

# 使配置文件生效

source ~/.bashrc

# 安装 python

如果使用 python --version 有打印 python 版本的话，那么这一步就不需要了，如果 docker 中没有安装 python , 在 docker 内使用如下命令安装

	sudo apt-get install software-properties-common
	add-apt-repository ppa:deadsnakes/ppa
	sudo apt install python3.9
	sudo ln -s /usr/bin/python3 /usr/bin/python

# 修改交换区大小

为了防止编译源码的过程中由于交换区不足而失败，所以我们需要去修改虚拟机的交换区的大小

	# 如果提示 No such file or directory，那就直接进行下面设置交换区的操作
	sudo swapoff /swapfile
	sudo rm /swapfile

	# 设置了 32g 交换区，防止编译失败，执行下列命令需要花费一段时间，如果执行命令后没有输出，请耐心等待命令执行完毕
	sudo dd if=/dev/zero of=/swapfile bs=1GB count=32
	sudo chmod 600 /swapfile
	sudo mkswap -f /swapfile
	sudo swapon /swapfile

# 安卓系统源码下载

# 查看 android 版本

进入代号，标记和 build 号来查看安卓系统的版本

如果是预装的系统，那么 kernel 版本和系统版本是有对应关系的，例如我给 pixel3 刷入的系统为 blueline-sp1a.210812.016.c2-factory-fa981d87 , 那么在上面提到的网址内找到该安卓系统该 build ID 所对应的安卓系统版本 android-12.0.0_r34 如图所示

# 下载

输入如下命令来进行安卓系统源码下载，分支就选择我们之前查找到的那个分支

	mkdir android-platform && cd android-platform
	repo init -u https://android.googlesource.com/platform/manifest -b android-12.0.0_r34 --depth=1
	repo sync -j4

# 安卓系统编译

在源码下载完成之后，我们首先使用 envsetup.sh 设置构建环境

source build/envsetup.sh

之后使用 lunch 命令选择目标，我们可以直接输入 lunch 来查看可供编译的编译

lunch

在 google 设备代号中可以知道 pixel3 的设备代号是 blueline

所以我们可以直接使用如下命令设置好编译目标

lunch aosp_blueline-userdebug

这里出现了 Build sandboxing disabled due to nsjail error 报错，这个报错应该是不会影响后续的系统编译的

lunch自定义命令组合

lunch product_name-release-build_variant

此字符串的组成部分包括：

product_name 是我们要构建的产品的名称，例如 aosp_cf_x86_64_phone 或 aosp_husky 。特定的 product_name 可以遵循我们自己的设备格式，但 Google 为其设备采用的格式包含以下组件：
- aosp 是指 Android 开源平台。
- （可选）如果要在 Cuttlefish 模拟器中运行目标，则包含 cf 。
- 架构和硬件（代号），例如 x86_64_phone 或 husky （Pixel 8 Pro 的代号）。如需查看 Google 设备的代号列表，请参阅设备代号。
所以对于 pixel3 来说，我们可以将 product_name 配置为 aosp_blueline
将 release 设置为 trunk_staging 。

此字符串的 build_variant 部分可以是下表中的三个值之一，这里我选择 user 为目标来构建，毕竟谁知道万一编译成 debug 会不会有 app 检测到特征了嘞～

build_variant	概述	说明	ro.secure	ro.debuggable	ro.kernel.android.checkjni	adb 功能	Proguard 混淆器	DEXPREOPT 预先编译优化
`user`	release 版本	此 build 变体提供有限的安全访问权限，适用于生产环境。	设定属性 ro.secure=1，打开安全检查功能	设定属性 ro.debuggable=0，关闭应用调试功能	设定属性 ro.kernel.android.checkjni=0，关闭 JNI 调用检查	关闭	打开	打开
`userdebug`	部分 debug 版本	此 build 变体可帮助设备开发者了解开发中版本的性能和功耗。使用 `userdebug` build 进行开发时，请遵循 userdebug 指南。	设定属性 ro.secure=1，打开安全检查功能	设定属性 ro.debuggable=1，启用应用调试功能	设定属性 ro.kernel.android.checkjni=0，关闭 JNI 调用检查	打开	打开	打开
eng	debug 版本	此 build 变体的构建时间更短，如果您不在意性能和功耗，它最适合用于日常开发。	设定属性 ro.secure=0，关闭安全检查功能	设定属性 ro.debuggable=1，启用应用调试功能	设定属性 ro.kernel.android.checkjni=1，启用 JNI 调用检查	打开	关闭	关闭

所以对于我的 pixel3 来说编译命令如下

lunch aosp_blueline-trunk_staging-user

但是没想到的是竟然报错了？估计是不能以 user 作为目标编译？之后看看 userdebug 会不会被检测到再决定是否继续研究此处的报错

然后开始编译，给虚拟机分配 12 核的话第一次大概需要两个小时左右可以编译完成，后面再次编译的速度就很快了

make -j8

编译完成后会生成一个 vbmeta.img 文件，到时候我们要刷入的也是这一个文件

# 编译后的镜像刷入手机

//TODO 6.24 号周一的时候刷进去试试看功能是不是正常！

# 参考资料

构建 Android
Android 编译选项 eng、user、userdebug 的区别

EBPF android bcc初体验

2024-05-07T07:31:28.000Z

pixel6 到手的第一件事，当然是去玩玩看 ebpf 了～ebpf 的无痕 hook 听上去就感觉相当的强大，去官网看了一下 ebpf 知名度排名前几的项目，那非 bcc 莫属了，用 python 就可以运行 ebpf 代码，虽然 ebpf 的核心代码还是 C 写的，但是用 python 去执行就感觉十分的舒适

在网上也找到了三篇非常详细的 Android bcc 编译教程，前人种树，后人乘凉 ^.^ 可以试试看 ebpf 究竟是什么样子的啦

eBPF on Android 之 bcc 环境准备 ——eadb 原版
[原创] 60 秒学会用 eBPF-BCC hook 系统调用 ( 2 ) hook 安卓所有 syscall
eBPF on Android 之 bcc 编译与体验

# bcc 环境搭建

接下来进行 bcc 的环境搭建，我们将使用 eadb 在手机中配置 Debian 系统，并通过 ssh 让 Windows 上的 vscode 可以连接手机中的 Debian

想要使用 bcc 的全部功能，首先检查 linux 内核版本，我的内核版本为 5.10

uname -a

然后检查 BPF 的配置是否开启

	oriole:/ # zcat /proc/config.gz \| grep PROBE
	CONFIG_GENERIC_IRQ_PROBE=y
	CONFIG_ARCH_SUPPORTS_UPROBES=y
	CONFIG_KPROBES=y
	CONFIG_UPROBES=y
	CONFIG_KRETPROBES=y
	CONFIG_HAVE_KPROBES=y
	CONFIG_HAVE_KRETPROBES=y
	# CONFIG_TEST_ASYNC_DRIVER_PROBE is not set
	CONFIG_GENERIC_CPU_AUTOPROBE=y
	CONFIG_TIMER_PROBE=y
	CONFIG_KPROBE_EVENTS=y
	CONFIG_UPROBE_EVENTS=y
	CONFIG_PROBE_EVENTS=y
	# CONFIG_BPF_KPROBE_OVERRIDE is not set
	# CONFIG_KPROBE_EVENT_GEN_TEST is not set

随后使用 magisk root 手机，然后安装 MagiskSSH

ubuntu 中在 root 权限下安装 adb 和 fastboot

apt install adb,fastboot

随后在 ubuntu 中输入下列命令生成 rsa 密钥，一路回车

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

将公钥推送到手机中

adb push ~/.ssh/id_rsa.pub /data/local/tmp

将公钥追加写入 MagiskSSH 的配置文件中

	cat /data/local/tmp/id_rsa.pub >> /data/ssh/shell/.ssh/authorized_keys
	chmod 600 /data/ssh/shell/.ssh/authorized_keys
	cat /data/local/tmp/id_rsa.pub >> /data/ssh/root/.ssh/authorized_keys
	chmod 600 /data/ssh/root/.ssh/authorized_keys

使用 MT 管理器编辑 /data/ssh/sshd_config , 把下面的内容粘贴到文件开头并保存即可

	Port 22225
	PasswordAuthentication yes
	PermitEmptyPasswords yes
	PermitUserEnvironment yes

重启 sshd 服务

	/data/adb/modules/ssh/opensshd.init stop
	/data/adb/modules/ssh/opensshd.init start

随后在 ubuntu 中下载 eadb 和 debianfs

在手机的 WLAN 网络详情里找到手机热点的 IP 地址

配置 debian 环境

./eadb --ssh root@192.168.50.191 -p 22225 prepare -a debianfs-arm64-full.tar.gz

然后运行下面的命令就可以连接上了

./eadb --ssh root@192.168.50.191 -p 22225 shell

为 Debian 配置 ssh

	apt-get update
	apt-get install ssh

打开 /etc/ssh/sshd_config

vim /etc/ssh/sshd_config

并按下 ctrl+shift+v 粘贴下列的内容

	AuthorizedKeysFile .ssh/authorized_keys
	Port 11111
	PubkeyAuthentication yes
	PermitRootLogin yes
	PasswordAuthentication yes
	GSSAPIAuthentication no # 加速SSH
	UseDNS no # 加速SSH

在虚拟机 ubuntu 中查看生成的公钥

cat ~/.ssh/id_rsa.pub

在手机 Debian 中手动粘贴导入公钥

vim id_rsa.pub

在手机 Debian 中增加公钥并配置权限

	cat id_rsa.pub >> ~/.ssh/authorized_keys
	chmod 600 ~/.ssh/authorized_keys;chmod 700 ~/.ssh
	service ssh restart # 手机每次重启后，第一次进入 debian, 可能都需要手动启动下 ssh 服务

如果没有 ~/.ssh/authorized_keys 文件，新建一个就行了

mkdir ~/.ssh;touch ~/.ssh/authorized_keys

修改 Debian 的 root 密码

passwd root

在 ubuntu 中查看私钥，然后复制到 Windows 的一个文件 id_rsa 中

cat ~/.ssh/id_rsa

然后打开 C:\Users\admin\.ssh\config , 配置 ssh, 并在 vscode 中安装 ssh 插件

之后关闭虚拟机让手机的 USB 连上 Windows, 在 vscode 中就可以连上啦

vscode 第一次连接 Debian, 会在 Debian 中安装 vscode 服务器，如果不开代理的话速度会相当相当的慢，要想给 Debian 挂代理的话，只要在手机中把 Clash 开起来就可以啦

# bcc 编译运行

环境搭建好了之后，就可以编译 bcc 了

先把 bcc 下过来

git clone https://github.com/iovisor/bcc.git

编译 bcc

	mkdir bcc/build; cd bcc/build
	cmake ..
	make

我在编译的过程中遇到了如下的报错

先装个 pip

	wget https://bootstrap.pypa.io/get-pip.py
	python get-pip.py

然后再安装 setuptools

	wget https://files.pythonhosted.org/packages/af/e7/02db816dc88c598281bacebbb7ccf2c9f1a6164942e88f1a0fded8643659/setuptools-45.0.0-py2.py3-none-any.whl
	pip install setuptools-45.0.0-py2.py3-none-any.whl

后来又报错 zip 没安装

装一个 zip

apt-get install zip

重新 make 之后编译成功～

然后把 bcc 安装一下

make install

随后再编译一下 python 的 bcc

	cmake -DPYTHON_CMD=python3 ..
	pushd src/python/
	make
	make install
	popd

试试看官方的例子

python3 bcc/examples/hello_world.py

结果竟然没输出？

哈哈，原来是 tracing 的开关没开，开一下

echo 1 > /sys/kernel/tracing/tracing_on

Hello, World!

# 参考资料

eBPF on Android 之 bcc 环境准备 ——eadb 原版
[原创] 60 秒学会用 eBPF-BCC hook 系统调用 ( 2 ) hook 安卓所有 syscall
eBPF on Android 之 bcc 编译与体验

d3ctf2024 reverse wp

2024-04-28T16:12:07.000Z

# 前言

已经是四月底了，但是却突然发现这一整个月都没有在博客写些什么，感觉又是在不明所以中度过了，想看的 magisk , frida 源码没有看完，想做的小夏的 live2d 也迟迟没有动工，下个月努努力，多学点，多做点，加油加油

总觉得自己还是要写下点什么才好，恰好这周听闻有个 d3ctf, 于是便想来看看逆向题，去学习一下新知识开拓视野，同时也为了度过一段充实的周末时光

回想去年的 d3ctf, 感觉那时的自己有太多不了解的地方了，于是乎情理之中的也是一题都没做出来了，复现的题目的计划在我的 todolist 里面躺了很长一段时间，然而不知不觉间变成了 undo, 最后到现在的 forget do,never do

同时我也想来看看一下这一年的自己有了什么变化，感觉现在可以称自己是一位入门逆向工程师了吧哈哈哈，总共五道逆向题做好了三题，可惜周日因为要调休的缘故 (谁发明的调休？！) 便没有再继续看题了，题目挺不错的，不过要是可以有安卓题的话我应该会有百分之三百的精气神去做吧 ^.^

翻了翻自己过去写的 ctf 文章，那也仅仅是 wp 出个 flag 而已，但是 flag 不是题目的终点，二进制文件中蕴藏的技巧，手法才是真正值得总结一篇文章的地方，我可不希望自己写的文章在未来连我自己都不愿重新翻看 (●ˇ∀ˇ●)

题目附件点这里下载～

# forest

很好的一道题，将 MSVC 的 SEH 异常处理使用的十分巧妙，同时点和图的思想也在这题有了充分的体现，在做这题的时候有一个失败的解法，不过我感觉很有意思所以也在这里记录下来啦

这里你会看到地址都是 61 开头，那时因为用 od 的时候里面的基址就是 0x610000 , 所以当时为了和 ida 中对应起来我也改成了 61 开头，不过最后 od 还是没有排上用场全靠 ida 动态调试啦

这里通过主动设置 int 3 断点触发 0x80000003 断点异常进入 sub_611A00

在 sub_611A00 中，对异常码进行判断，这里可以重定义 this 参数类型为 _EXCEPTION_POINTERS , 这样看起来更方便些，感觉是一个小小的突破口哦

首次触发断点异常，解密由 VirtualProtect 分配的内存地址的值，并设置 byte_616028 标志为 0, 下一次触发断点异常将视为 flag 错误，进程退出

解密完成后设置 EIP, 并通过 this->ContextRecord->EFlags |= 0x100 设置单步调试模式，使标志寄存器第 8 位 TF 为 1

随后程序会通过调用 cli 特权指令实现 shellcode 的跳转

int 2Dh 表示 flag 错误

# [失败] frida 侧信道

说的高大上一点叫侧信道，实际上就是爆破哈哈哈，我调试的时候发现每一次输入的 flag 不一样，调用 cli 特权指令触发 0xC0000096 的次数也不一样，所以我就在想，要是我可以一位一位的爆破，通过在处理 0xC0000096 异常的地方下断点统计调用次数，然后然调用最多的那个字符作为这一位的 flag, 那不就得到最后的 flag 了嘛～

所以这回用上了我的老伙计 frida, 想要通过 frida 实现爆破，那么需要使用 frida 的 python 脚本，同时输入也不能再是 console.log , 而是需要使用 send 将结果返回到 python 中去做处理

	function my_hook() {
	var module = Process.findModuleByName(exe_name);
	Interceptor.attach(module.base.add(0x1BDE),
	{
	onEnter: function (args) {

	if(this.context.eax.compare(0xC0000096)===0){
	count=count+1
	//console.log(this.context.eax)
	//console.log(ptr(module.base.add(0xAD20).readS32()).readS32().toString(16))
	//console.log(ptr(module.base.add(0xAD24).readS32()).readS32().toString(16))
	send(count)
	}
	},
	onLeave: function (retval) {
	}
	}
	);
	}
	// d3ctf{01234567890123456}


	setImmediate(my_hook);

这个 python 的代码虽然很简单但是也巧妙，嘻嘻

	import os
	import subprocess
	import frida
	import string
	#d3ctf{0ut00431101002001}
	def on_message(message, data):
	global max_count,max_ch,current_ch
	if message['type'] == 'send':
	if not max_count:
	max_count = int(message['payload'])
	max_ch = current_ch
	elif int(message['payload'])>max_count:
	max_count = message['payload']
	max_ch = current_ch
	elif int(message['payload'])==max_count:
	print(f"NOTE! {max_ch} and {current_ch} have the same max_count {max_count}")
	elif message['type'] == "error":
	print(message["description"])
	print(message["stack"])
	print(message["fileName"], "line:", message["lineNumber"], "colum:", message["columnNumber"])

	jscode = open("trace_forest.js","rb").read().decode()

	t_flag = list("d3ctf{01234567890123456}")
	for i in range(6,23):
	max_count, max_ch = None,None
	break_flag = 0
	for c in string.printable:
	current_ch = c
	t_flag[i] = c
	process = subprocess.Popen("forest.exe",
	stdin=subprocess.PIPE,
	stdout=subprocess.PIPE,
	stderr=subprocess.PIPE,
	universal_newlines=True)
	session = frida.attach("forest.exe")
	script = session.create_script(jscode)
	script.on('message', on_message)
	script.load()
	process.stdin.write(''.join(t_flag))
	output, error = process.communicate()
	process.terminate()
	t_flag[i] = max_ch
	print(f"{''.join(t_flag)}, max: {max_count}")

但是可惜的是程序跑完出来了这个 d3ctf{0ut00431101002001} , 虽然是错的但是回显不一样了 ^.^

这何尝不是一种胜利～不过换个方法咯

# [成功] 图点路径

如果想要产生正确的回显，必须触发 0xC0000005 异常

输入的字符串将会被全部转换为二进制的形式，每执行 cli 特权指令触发 0xC0000096 异常后都会读取一位

如果为 0, 则下一次触发 0x80000004 单步调试异常且当前指令的偏移逻辑 &0x3F 等于 7 时，将会让当前的 Eip 加上 23

进入下一个块的位置由 unk_EAA720 和 unk_EA8658 进行控制，算法为 (unk_EAA720+unk_EA8658+(unk_EA8658<<4))<<6

观察后发现这明显就是一个图呀，所以可以用 idapython 找到图的所有边

	# d3ctf{0ut00431101002001}

	import idautils
	import idc
	import ida_bytes

	base = 0x616035

	pattern = ["B8 FF FF FF FF C7 00 ?? 00 00 00 B8 FF FF FF FF C7 00 ?? 00 00 00 FA"]
	pl = [] # point list
	for i in range(len(pattern)):
	cur_addr = 0x616035
	end_addr = 0x616035 + 0x483D
	while cur_addr < end_addr:
	cur_addr = idc.find_binary(cur_addr, idc.SEARCH_DOWN, pattern[i])

	if cur_addr == idc.BADADDR:
	break
	else:
	a = ida_bytes.get_byte(cur_addr + 7)
	b = ida_bytes.get_byte(cur_addr + 18)
	pl.append({
	"cur": cur_addr,
	"off": (a + b + (b << 4)) << 6,
	"s": 0
	})
	cur_addr = idc.next_head(cur_addr)

	pattern = ["8B 00"]
	for i in range(len(pattern)):
	cur_addr = 0x616035
	end_addr = 0x616035 + 0x483D
	while cur_addr < end_addr:
	cur_addr = idc.find_binary(cur_addr, idc.SEARCH_DOWN, pattern[i])
	if cur_addr == idc.BADADDR:
	break
	else:
	# if cur_addr-(base+5) &0x3F==7,eax->1, eip+23
	pl.append({
	"cur": cur_addr,
	"off": cur_addr + 23 - base,
	"s": 1
	})
	cur_addr = idc.next_head(cur_addr)

	print(pl)

然后打印一下没有对应端点的点，这里只是部分，实际上还有很多…

之后一个一个试过去，就有 flag 了 (为什么不用 for 循环尝试所有可能的点，因为用 for 循环 all_simple_paths 不出结果呜)

	base = 0x616035
	pl = [...]# ida python 的结果
	import networkx as nx

	G = nx.DiGraph()
	for p in pl:
	G.add_node(p["cur"])
	out_way = []
	for p in pl:
	if not p["s"]:
	if G.has_node(base+p["off"]):
	G.add_edge(p["cur"],base+p["off"])
	else:
	if base+p['off']>0x616035 + 0x483D:
	print(f"find a way out: {hex(p['cur'])} --> {hex(base+p['off'])}")
	G.add_node(base+p['off'])
	G.add_edge(base,base+p['off'])
	out_way.append(base+p['off'])
	else:
	print(f"no taget point: {hex(p['cur'])} --> {hex(base + p['off'])}")
	out_way.append(base + p['off'])

	else:
	if G.has_node(p["cur"]+2+23):
	G.add_edge(p["cur"],p["cur"]+2+23)
	if G.has_node(p["cur"]+2):
	G.add_edge(p["cur"], p["cur"] + 2)
	else:
	print("ERRR")


	start = 0x616035
	tem = []
	out = 0x616c0e
	for path in nx.all_simple_paths(G, source=start, target=out):
	tem.append(path)
	#print(tem)
	#print(len(tem[0]))
	pll = []
	for t in tem[0]:
	for p in pl:
	if p["cur"]==t:
	#print(p["cur"],p["s"])
	pll.append(p)
	break

	start = True
	flag=""
	for p in range(len(pll)):
	if p!=0:
	if not pll[p]["s"]:
	if pll[p]["cur"]-pll[p-1]["cur"]==2:
	flag+="0"
	else:
	flag+="1"
	for i in range(0,len(flag)//8):
	print(chr(int(flag[8i:8i+8],2)),end='')

# ezjunk

从整个程序的入口 start 函数开始分析，在执行 main 函数前，还会调用 sub_401CC0 函数

在这个函数中，会对 sub_401550 进行调用

但是却没法直接反编译，既然是栈的问题，把 sub rsp, 30h nop 掉就好啦

有个反调试，过一下就好了

main 函数的花指令也很简单，去一下就看到逻辑啦

进到 sub_401917 里面，只是一个 tea 算法

之后就是一个类似 crc 的算法

不过在调试的时候还是不能直接把花指令 nop 掉的，因为这里读取的是 loc401A1C 花指令的汇编，如果 nop 掉变成 90 的话，tea 的常数值会出错的

	from ctypes import *


	def encrypt(v, key):
	v0, v1 = c_uint32(v[0]), c_uint32(v[1])
	delta = 0xff58f981
	total = c_uint32(0xE8017300)
	for i in range(32):
	v0.value += (((v1.value << 4) ^ (v1.value >> 5)) + v1.value) ^ (total.value + key[total.value & 3]) ^ 0x44
	v1.value += (((v0.value << 5) ^ (v0.value >> 6)) + v0.value) ^ (
	total.value + key[(total.value >> 11) & 3]) ^ 0x33
	total.value -= delta
	return v0.value, v1.value


	def decrypt(v, key):
	v0, v1 = c_uint32(v[0]), c_uint32(v[1])
	delta = 0xff58f981

	total = c_uint32(0xE8017300 - 32 * delta)
	for i in range(32):
	total.value += delta
	v1.value -= (((v0.value << 5) ^ (v0.value >> 6)) + v0.value) ^ (
	total.value + key[(total.value >> 11) & 3]) ^ 0x33
	v0.value -= (((v1.value << 4) ^ (v1.value >> 5)) + v1.value) ^ (total.value + key[total.value & 3]) ^ 0x44

	return v0.value, v1.value


	# test
	if __name__ == "__main__":
	# 待加密的明文，两个 32 位整型，即 64bit 的明文数据
	# fakeflag{Is_there_anywhere_else}
	# value = [0x5406CBB1, 0xA4A41EA2, 0x34489AC5, 0x53D68797, 0xB8E0C06F, 0x0259F2DB, 0x52E38D82, 0x595D5E1D]
	value = [0xB6DDB3A9, 0x36162C23, 0x1889FABF, 0x6CE4E73B, 0x0A5AF8FC, 0x21FF8415, 0x44859557, 0x2DC227B7]
	value = [c_uint(v) for v in value]
	for i in range(len(value)):
	for _ in range(32):
	if value[i].value&1:
	value[i] = c_uint(((value[i].value ^ 0x84A6972F)//2) \| 0x80000000)#2086826726
	else:
	value[i] = c_uint((value[i].value//2))
	value = [v.value for v in value]
	#for v in value:
	#print(hex(v))

	# value = []
	# 四个 key，每个是 32bit，即密钥长度为 128bit
	key = [0x00005454, 0x00004602, 0x00004477, 0x00005E5E]
	v = [0, 0]

	for i in range(len(value) // 2):
	v[0], v[1] = value[2 * i], value[2 * i + 1]
	res = decrypt(v, key)
	print(f"{res[0].to_bytes(4, 'little').decode()}{res[1].to_bytes(4, 'little').decode()}", end='')

# RandomVM

VM 题型，不过算是比较方便的那种真正用到的指令不是很多，ida trace 在关键函数 trace 一下，不过有个 ptrace 反调试注意一下就好啦

syscall (0x65) ptrace 反调试，跳过这条指令就好了

比较重要的有这些函数

idapython trace 一下

	#xor
	import idc
	import ida_bytes
	import idaapi
	ea = ida_bytes.get_byte(idaapi.get_imagebase()+0xB072)
	ecx=idc.get_reg_value("ECX")
	eax=idc.get_reg_value("EAX")
	print(f"final[{ea}] = {hex(ecx)}^{hex(eax)} = {hex(ecx^eax)}")

	#mov
	import idc
	import ida_bytes
	import idaapi
	ea = ida_bytes.get_byte(idaapi.get_imagebase()+0xB072)
	eax=idc.get_reg_value("EAX")
	print(f"final[{ea}] = {hex(eax)}")

	#circleRmov
	import idc
	import ida_bytes
	import idaapi
	import ctypes
	ea = ida_bytes.get_byte(idaapi.get_imagebase()+0xB072)
	edx=idc.get_reg_value("EDX")
	ecx=idc.get_reg_value("ECX")%8
	res = ctypes.c_uint8(edx)
	if ecx!=0xffffffff:
	res = ctypes.c_uint8((res.value>>ecx) \| (res.value<<(8-ecx)))
	else:
	res = ctypes.c_uint8(0)
	print(f"final[{ea}] = {hex(edx)}>>{ecx} \| {hex(edx)}<<{8-ecx} = {hex(res.value)}")

输入 0123456789ab 得到输出

	final[0] = 0x0^0x30 = 0x30
	final[1] = 0x1
	final[1] = 0x30>>3 \| 0x30<<5 = 0x6
	final[1] = 0x6^0x3 = 0x5
	final[1] = 0x5^0x31 = 0x34
	final[2] = 0x2
	final[2] = 0x31>>5 \| 0x31<<3 = 0x89
	final[2] = 0x89^0x32 = 0xbb
	final[3] = 0x3
	final[3] = 0x32>>6 \| 0x32<<2 = 0xc8
	final[3] = 0xc8^0x33 = 0xfb
	final[4] = 0x4
	final[4] = 0x33>>7 \| 0x33<<1 = 0x66
	final[4] = 0x66^0x7 = 0x61
	final[4] = 0x61^0x34 = 0x55
	final[5] = 0x5
	final[5] = 0x34>>4 \| 0x34<<4 = 0x43
	final[5] = 0x43^0x4 = 0x47
	final[5] = 0x47^0x35 = 0x72
	final[6] = 0x6
	final[6] = 0x35>>4 \| 0x35<<4 = 0x53
	final[6] = 0x53^0x36 = 0x65
	final[7] = 0x7
	final[7] = 0x36>>7 \| 0x36<<1 = 0x6c
	final[7] = 0x6c^0x7 = 0x6b
	final[7] = 0x6b^0x37 = 0x5c
	final[8] = 0x8
	final[8] = 0x37>>7 \| 0x37<<1 = 0x6e
	final[8] = 0x6e^0x38 = 0x56
	final[9] = 0x9
	final[9] = 0x38>>2 \| 0x38<<6 = 0xe
	final[9] = 0xe^0x39 = 0x37
	final[10] = 0xa
	final[10] = 0x39>>4 \| 0x39<<4 = 0x93
	final[10] = 0x93^0x61 = 0xf2
	final[11] = 0xb
	final[11] = 0x61>>4 \| 0x61<<4 = 0x16
	final[11] = 0x16^0x62 = 0x74
	final[12] = 0xc
	final[12] = 0x62>>7 \| 0x62<<1 = 0xc4
	final[12] = 0xc4^0x7 = 0xc3
	final[2] = 0xbb^0x34 = 0x8f
	final[3] = 0xfb^0x8f = 0x74
	final[4] = 0x55^0x74 = 0x21
	final[5] = 0x72^0x21 = 0x53
	final[6] = 0x65^0x53 = 0x36
	final[7] = 0x5c^0x36 = 0x6a
	final[8] = 0x56^0x6a = 0x3c
	final[9] = 0x37^0x3c = 0xb
	final[10] = 0xf2^0xb = 0xf9
	final[11] = 0x74^0xf9 = 0x8d
	final[12] = 0xc3^0x8d = 0x4e

exp 如下

	import ctypes

	def circleR_rev(s, r):
	res = ctypes.c_uint8(s)
	res = ctypes.c_uint8((res.value << r) \| (res.value >> (8 - r)))
	return res.value


	key = [0x9D, 0x6B, 0xA1, 0x02, 0xD7, 0xED, 0x40, 0xF6, 0x0E, 0xAE, 0x84, 0x19]

	circle_R = [3, 5, 6, 7, 4, 4, 7, 7, 2, 4, 4, 7]
	xor = [3,0,0,7,4,0,7,0,0,0,0,7]
	flag = [0 for _ in range(12)]
	for i in range(len(key)-1,-1,-1):
	if not flag[-1]:
	flag[i] = circleR_rev(key[i]^key[i-1]^xor[i],circle_R[i])
	else:
	flag[i] = circleR_rev(key[i]^key[i-1]^xor[i]^flag[i+1],circle_R[i])
	if not i:
	flag[i] = circleR_rev(key[i]^xor[i]^flag[i + 1], circle_R[i])

	print(''.join(map(chr, flag)))

oaciaのBbBlog~

dexguard反混淆-unidbg去除BR寄存器跳转

# 前言

# unidug 环境搭建

# 寄存器跳转基本类型

# 直接跳转

# 分支跳转

# unidbg 反混淆

# 参考资料

DexGuard java字符串反混淆

# 前言

# 神奇的防 hook 手段

# frida RPC 调用

# flask 搭个本地服务器

# Jeb Script 反混淆

初探抖音六神之字符串解密算法分析

# 前言

# ssl pinning 绕过

# 定位参数位置

# libmetasec_ml.so 反混淆

# 自加载 libmetasec_ml.so

# SVC 调用

# svc 函数 hook 检测的 bug

# 字符串解密算法分析

frida inline hook原理分析及实践

# 前言

# lldb 动态调试

# IDA 动态调试分析 hook 跳板

# 一级跳板

# 二级跳板

# 三级跳板

# 保存寄存器环境

# 跳转到核心代码

# 恢复寄存器环境

# 恢复执行流

# 自实现 inline hook

# ptrace 注入

# 为字符串分配内存

# 加载 hook 功能库 so

# 在 hook 点 patch 上跳板

# 执行 hook 逻辑

# 参考资料

b站app漫展抢票

# 前言

# 基本信息

# frida 反调试

# webview chrome 调试

ollvm三种混淆模式的反混淆思路

# 预备知识

# ollvm 环境搭建

# 下载 ollvm 4.0 源码

# 安装 docker

# 安装编译 ollvm 的 docker 环境

# 编译 ollvm

# 下载编译脚本

# 编译

# 创建硬链接

# 使用测试代码尝试编译

# 虚假控制流 BCF (Bogus Control Flow)

# 原理

# ollvm 的 BCF 混淆

# ollvm 的 BCF 反混淆

# 思路一 将全局变量赋值并将 segment 设为只读

# 思路二 使用 d810 去除 BCF

# 思路三 使用 idapython patch 不透明谓词

# 指令替换（SUB）

# 原理

# ollvm 的 SUB 混淆

# ollvm 的 SUB 反混淆

# 思路一 使用 d810 去除 SUB

# 思路二 使用 GAMBA 简化复杂的 SUB 表达式

# 控制流平坦化（FLA）

# 原理

# ollvm 的 FLA 混淆

# ollvm 的 FLA 反混淆

# 参考资料

android binder源码分析

# 说明

# Binder 简介

# Binder 设备的初始化过程

# 思路一将全局变量赋值并将 segment 设为只读

# 思路二使用 d810 去除 BCF

# 思路三使用 idapython patch 不透明谓词

# 思路一使用 d810 去除 SUB

# 思路二使用 GAMBA 简化复杂的 SUB 表达式