[原创]Polaris-Obfuscator中BogusControlFlow简要分析反混淆-逆向工程-看雪安全社区

[原创]Polaris-Obfuscator中BogusControlFlow简要分析反混淆

发表于: 2026-3-22 12:47 13834

[原创]Polaris-Obfuscator中BogusControlFlow简要分析反混淆

Taardisaa

2026-3-22 12:47

13834

## Introduction

这个混淆也算是从OLLVM继承下来的老玩意了；简单来说就是对于一个basic block，在它之前创建一个相同的basic block，这个新的basic block包含一个opaque predicate（一个永远为真/永远为假的条件，即new block永远也不会被真正执行到）；然后在这个新的block里面还可以相应的加入一些junk instructions，使得反编译器无法正确解析这个block。

具体可以看此篇：68eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6G2j5X3k6#2M7$3y4S2N6r3!0J5i4K6u0V1L8r3I4$3L8g2)9J5c8X3!0T1k6Y4g2K6j5$3q4@1L8%4u0Q4x3V1k6%4K9h3E0A6i4K6u0r3b7X3!0Y4N6i4y4Q4x3X3c8U0L8$3&6@1M7X3!0D9i4K6u0V1k6X3I4G2N6H3`.`.

## Implementation Details

59fK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6*7j5e0t1K6x3#2)9J5c8W2m8G2L8r3q4J5K9i4y4Q4x3X3c8a6j5X3k6#2M7$3y4S2N6r3!0J5i4K6u0r3j5X3I4G2j5W2)9J5c8X3#2S2K9h3&6Q4x3V1k6K6M7X3y4Q4x3V1k6D9L8s2k6E0i4K6u0r3L8r3W2T1i4K6u0r3g2s2u0S2L8Y4y4X3L8%4u0E0M7#2)9J5c8V1!0T1k6Y4g2K6j5$3q4@1K9h3!0F1i4K6u0r3b7X3!0Y4N6i4y4o6L8$3&6@1M7X3!0D9c8X3I4G2N6#2)9J5k6h3y4H3M7l9`.`.

我们逐个函数的来分析：

### 1. 克隆basic block（`cloneAlterBasicBlock`）

```cpp
BasicBlock *BogusControlFlow::cloneAlterBasicBlock(BasicBlock *BB) {
 ValueToValueMapTy VMap;
 BasicBlock *CBB = CloneBasicBlock(BB, VMap, "cloneBB", BB->getParent());
 BasicBlock::iterator Iter = BB->begin();
 for (Instruction &I : *CBB) {
 for (unsigned i = 0; i < I.getNumOperands(); i++) {
 Value *V = MapValue(I.getOperand(i), VMap);
 if (V) {
 I.setOperand(i, V);
 }
 }
 SmallVector<std::pair<unsigned, MDNode *>, 4> MDs;
 I.getAllMetadata(MDs);
 for (std::pair<unsigned, MDNode *> pair : MDs) {
 MDNode *MD = MapMetadata(pair.second, VMap);
 if (MD) {
 I.setMetadata(pair.first, MD);
 }
 }
 I.setDebugLoc(Iter->getDebugLoc());
 Iter++;
 }
 return CBB;
}
```

这个函数的功能就是克隆一个basic block。当然也进行了相应的变量重命名，以及metadata的克隆。但是并没有对其进行任何的修改，没有添加junk code。

### 2. 拆分basic block

```cpp
/* 将函数中的每个基本块按每 Size 条指令拆分成多个较小的块 */
void BogusControlFlow::splitBasicBlock(Function &F, unsigned Size) {
 std::vector<Instruction *> SplitPoints;
 for (BasicBlock &BB : F) {
 unsigned Idx = 0;
 for (auto Iter = BB.getFirstInsertionPt(); Iter != BB.end(); Iter++) {
 Instruction &I = *Iter;
 if (I.isTerminator()) {
 continue;
 }
 if (Idx % Size == Size - 1) {
 SplitPoints.push_back(&I);
 }
 Idx = (Idx + 1) % Size;
 }
 }
 for (Instruction *I : SplitPoints) {
 BasicBlock *BB = I->getParent();
 BB->splitBasicBlock(I);
 }
}
```

这个函数的功能就是将函数中的每个基本块按每Size条指令拆分成多个较小的块。这样做的目的是为了增加基本块的数量，后面便可以插入更多的opaque predicates。

### 3. `process`函数

首先在函数头创建两个变量，`Var`和`Var0`。

```cpp
IRBuilder<> IRB(&*F.getEntryBlock().getFirstInsertionPt());
Value *Var = IRB.CreateAlloca(IRB.getInt64Ty());
Value *Var0 = IRB.CreateAlloca(IRB.getInt64Ty());
```

紧接着，得到两个变量`Mod`和`X`：

$$
Mod = 0x100000000 - rand32()
$$

$$
X = randPrime() \mod Mod
$$

```cpp
uint64_t Mod = 0x100000000 - getRand32();
// X is just a random prime % Mod
uint64_t X =
    primes[getRandomNumber() % (sizeof(primes) / sizeof(primes[0]))] % Mod;
```

然后`Var`和`Var0`都初始化成了`X`：

```cpp
// Both Var and Var0 are set to X at the beginning of the function.
IRB.CreateStore(IRB.getInt64(X), Var);
IRB.CreateStore(IRB.getInt64(X), Var0);
```

接下来的就是比较tricky的部分了。我先把代码贴上来，然后再进行分析：

```cpp
 std::vector<BasicBlock *> BBs;
 for (BasicBlock &BB : F) {
 // At the end of each basic block
 IRB.SetInsertPoint(BB.getTerminator());
 // a*x - b = x (mod m)
 // (a - 1) * x = b (mod m)
 uint64_t B = getRand32() % Mod;
 uint64_t Inv = getInverse(X, Mod);
 uint64_t A = ((B * Inv) % Mod + 1) % Mod;

Value *V = IRB.CreateLoad(IRB.getInt64Ty(), Var0);
    IRB.CreateStore(
        IRB.CreateURem(
            IRB.CreateSub(IRB.CreateURem(IRB.CreateMul(IRB.getInt64(A), V),
                                         IRB.getInt64(Mod)),
                          IRB.getInt64(B)),
            IRB.getInt64(Mod)),
        Var0);
    BBs.push_back(&BB);
  }
```

首先来说说下面的这个IR到底是啥玩意：

```llvm
%v = load i64, ptr %Var0
%mul  = mul i64 A, %v
%rem1 = urem i64 %mul, Mod
%sub  = sub i64 %rem1, B
%rem2 = urem i64 %sub, Mod
store i64 %rem2, ptr %Var
```

转化成high level code的话就是：

```cpp
Var0 = ((A * Var0) % Mod - B) % Mod
```

那么这个公式到底算了啥玩意？从上面的计算公式可知：

$$
B = rand32() \bmod Mod
$$

$$
A = ((B * Inv(X, Mod)) \bmod Mod + 1) \bmod Mod
$$

这两个刻意构造的变量`A`和`B`满足如下的关系：

$$
(A - 1) * X = B \bmod Mod
$$

其中，`X`可以是任何一个小于`Mod`的数。这个公式只需要将上面的`A`和`B`代入进去就可以轻松验证。

下面，只需要稍微变形一下上面的公式就可以得到：

$$
A * X = (X + B) \bmod Mod
$$

将这个玩意带入到上面用于变换`Var0`的公式中就可以得到：

![bcf](upload/attach/202603/1070326_WT53SNFFMEM6H73.webp)

所以实际上`Var0`的值是永远不会改变的，一直和`Var`的值相等的。上面花里胡哨的计算其实只是为了让编译器和反编译器无法进行优化。

> **注意：这里的实现实际上有一个bug。** 上面的推导在数学模运算下是正确的，但IR中使用的是`sub i64`（无符号64位减法）+ `urem i64`。当`(A * X) % Mod < B`时，`sub`会发生unsigned underflow，wrap到$2^{64}$附近的大数，后续的`urem`就不再等价于数学模运算了。例如取`Mod=11, X=3, B=8`，数学上$(-8) \bmod 11 = 3$，但uint64下`0 - 8 = 2^{64} - 8`，$(2^{64} - 8) \bmod 11 = 8 \neq 3$。这会导致opaque predicate不再恒真，进而使程序陷入死循环。

接下来就是注入blocks和opaque predicates了：

```cpp 
for (BasicBlock *BB : BBs) {
 if (isa<InvokeInst>(BB->getTerminator()) || BB->isEHPad() ||
 BB->isEntryBlock()) {
 continue;
 }
 BasicBlock *BodyBB =
 BB->splitBasicBlock(BB->getFirstNonPHIOrDbgOrLifetime(), "bodyBB");
 BasicBlock *TailBB =
 BodyBB->splitBasicBlock(BodyBB->getTerminator(), "endBB");
 BasicBlock *CloneBB = cloneAlterBasicBlock(BodyBB);
 BB->getTerminator()->eraseFromParent();
 BodyBB->getTerminator()->eraseFromParent();
 CloneBB->getTerminator()->eraseFromParent();
 IRB.SetInsertPoint(BB);
 if (getRandomNumber() % 2) {
 Value *Cond = IRB.CreateICmpEQ(IRB.CreateLoad(IRB.getInt64Ty(), Var),
 IRB.CreateLoad(IRB.getInt64Ty(), Var0));
 IRB.CreateCondBr(Cond, BodyBB, CloneBB);
 } else {
 Value *Cond = IRB.CreateICmpNE(IRB.CreateLoad(IRB.getInt64Ty(), Var),
 IRB.CreateLoad(IRB.getInt64Ty(), Var0));
 IRB.CreateCondBr(Cond, CloneBB, BodyBB);
 }

IRB.SetInsertPoint(BodyBB);
    if (getRandomNumber() % 2) {
      Value *Cond = IRB.CreateICmpEQ(IRB.CreateLoad(IRB.getInt64Ty(), Var),
                                     IRB.CreateLoad(IRB.getInt64Ty(), Var0));
      IRB.CreateCondBr(Cond, TailBB, CloneBB);
    } else {
      Value *Cond = IRB.CreateICmpNE(IRB.CreateLoad(IRB.getInt64Ty(), Var),
                                     IRB.CreateLoad(IRB.getInt64Ty(), Var0));
      IRB.CreateCondBr(Cond, CloneBB, TailBB);
    }

IRB.SetInsertPoint(CloneBB);
    IRB.CreateBr(BodyBB);
  }
```

具体的插入稍微有点复杂，涉及在graph上的变换。不过整体变化后的图像可以直接参考：

![BogusControlFlow](upload/attach/202603/1070326_JPJYRM3434F3PTH.webp)

来源：552K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2S2M7s2u0A6L8%4u0A6N6q4)9J5k6h3y4G2L8g2)9J5c8X3c8W2N6W2)9J5k6r3u0D9L8$3N6Q4x3V1k6G2j5X3k6#2M7$3y4S2N6r3W2F1k6#2)9J5k6r3y4G2k6r3g2Q4x3X3c8@1L8#2)9J5k6s2y4W2j5%4g2J5k6g2)9J5k6r3q4F1k6s2u0G2K9h3c8Q4x3X3c8S2M7s2m8K6

不过核心点其实还是在于opaque predicate的构造上。只要能够把opaque predicate给优化掉，那么具体的插入方式实际上并不重要；反编译器会自动把dead block给剪枝掉。

## BogusControlFlow2分析

刚刚快速看了一下源码，发现里面有两个都是BogusControlFlow的pass，分别是`BogusControlFlow`和`BogusControlFlow2`。前者就是我们上面分析的那个，而后者则是一个更为简单的版本？我没记错的话，以前OLLVM用的就是这个：

```cpp
Value *createBogusCmp(BasicBlock *insertAfter) {
 // if((y < 10 || x * (x + 1) % 2 == 0))
 Module *M = insertAfter->getModule();
 LLVMContext &context = M->getContext();
 GlobalVariable *xptr = new GlobalVariable(
 *M, Type::getInt32Ty(context), false, GlobalValue::CommonLinkage,
 ConstantInt::get(Type::getInt32Ty(context), 0), "x");
 GlobalVariable *yptr = new GlobalVariable(
 *M, Type::getInt32Ty(context), false, GlobalValue::CommonLinkage,
 ConstantInt::get(Type::getInt32Ty(context), 0), "y");

IRBuilder<> builder(context);
 builder.SetInsertPoint(insertAfter);
 LoadInst *x = builder.CreateLoad(Type::getInt32Ty(context), xptr);
 LoadInst *y = builder.CreateLoad(Type::getInt32Ty(context), yptr);
 Value *cond1 =
 builder.CreateICmpSLT(y, ConstantInt::get(Type::getInt32Ty(context), 10));
 Value *op1 =
 builder.CreateAdd(x, ConstantInt::get(Type::getInt32Ty(context), 1));
 Value *op2 = builder.CreateMul(op1, x);
 Value *op3 =
 builder.CreateURem(op2, ConstantInt::get(Type::getInt32Ty(context), 2));
 Value *cond2 =
 builder.CreateICmpEQ(op3, ConstantInt::get(Type::getInt32Ty(context), 0));
 return BinaryOperator::CreateOr(cond1, cond2, "", insertAfter);
}
```

这里面生成的opaque predicate明显要简单很多，并没有涉及mod+invserse的计算。

在Pipeline.cpp里面，`BogusControlFlow2`才是那个被注册成pass的，而那个看上去更复杂的`BogusControlFlow`反而完全没有被使用上。

```cpp
else if (pass == "bcf") {
      FunctionPassManager FPM;
      FPM.addPass(BogusControlFlow2());
      MPM.addPass(createModuleToFunctionPassAdaptor(std::move(FPM)));
    }
```

## Example

对一个csmith生成的测试样本进行bcf混淆后，得到的混淆片段如下：

```c
 if (iVar4 == 0) {
 if (y.12 < 10 || ((x.11 + 1) * x.11 & 1U) == 0) goto LAB_001012af;
 do {
 local_28->f0 = 1;
LAB_001012af:
 local_28->f0 = 1;
 } while (9 < y.14 && ((x.13 + 1) * x.13 & 1U) != 0);
 }
 }
 if (y.16 < 10 || ((x.15 + 1) * x.15 & 1U) == 0) goto LAB_0010132a;
```

注意，这里由于还是使用的旧的`BogusControlFlow2`, 所以生成的opaque predicate比较简单。

## Deobfuscation Prototype

核心点在于对opaque predicate的判断。我认为可以分成如下流程：

1. collect. 使用基于DDG的backward slicing收集影响branch guard的所有指令。
2. merge(optional). 有的时候，一个opaque predicate可能会在编译后被拆分成独立的多个条件进行判断；因此需要对这些条件进行合并，得到一个完整的predicate。**在测试的样本里面并没有遇到过这种情况，暂时跳过这层的考虑。**
3. solve. 使用符号执行对收集到的predicate进行求解，得到一个优化后的判断条件。在这个BogusControlFlow的例子中，得到的条件应该就是要么True，要么False。
4. patch. 对binary进行patch，消除opaque predicates对反编译器的影响。

不过在涉及到细节的时候，对这三个步骤的实现会复杂不少。具体而言：

1. collect. 我们需要确定到底是哪种code construct需要进行collect。对于IndirectCall，我们只需要遍历，对所有的indirect call site进行collect即可；但是对于BogusControlFlow这种就比较tricky；理论上我们需要对所有的branch predicates进行收集。这显然增加了不少工作量。
2. solve. 使用符号执行沿slice路径执行到branch处，然后检查guard是否只能取一个值。由于opaque predicate永远为真或者永远为假，因此我们可以从这个入手。
3. patch. 只需要patch成直接跳转即可，难度不大.

下面简单post一下实现的代码：

### Step 1: 找到所有branch

首先，我们需要找到目标函数中所有的conditional branch指令。在VEX IR中，一个conditional branch对应的block会有`Ijk_Boring`类型的jumpkind，同时block内部会有一个`Exit`语句（也是`Ijk_Boring`类型）。

```python
def find_branches(proj, func):
    result = []
    for block_addr in func.block_addrs:
        block = proj.factory.block(block_addr)
        irsb = block.vex
        if irsb.jumpkind == 'Ijk_Boring' and any(
            isinstance(s, pyvex.stmt.Exit) and s.jumpkind == 'Ijk_Boring'
            for s in irsb.statements
        ):
            branch_insn = block.capstone.insns[-1]
            result.append(branch_insn.address)
    return result
```

这里的逻辑很简单：遍历函数中的所有basic block，找到那些包含conditional branch的block（block的default exit是`Ijk_Boring`，且内部有一个`Exit`语句也是`Ijk_Boring`），然后把branch指令的地址记录下来。

### Step 2: Backward Slicing

对于每个branch，我们需要进行backward slicing来收集所有影响这个branch guard的指令。这里使用了angr的DDG（Data Dependency Graph）来进行backward slicing。

```python
def backward_slice_from(proj, cfg, ddg, target_insn_addr):
    block_node = cfg.model.get_any_node(target_insn_addr, anyaddr=True)
    if block_node is None:
        raise RuntimeError(f"No CFG node found containing 0x{target_insn_addr:x}")

irsb = proj.factory.block(block_node.addr).vex
    exit_indices = {
        i for i, s in enumerate(irsb.statements)
        if isinstance(s, pyvex.stmt.Exit)
    } or {-2}

seed_nodes = [
        n for n in ddg.graph.nodes()
        if getattr(n, 'block_addr', None) == block_node.addr
        and getattr(n, 'stmt_idx', None) in exit_indices
    ]
    if not seed_nodes:
        raise RuntimeError(f"No DDG nodes found for ins_addr=0x{target_insn_addr:x}")

# BFS backward through the DDG
    visited = set()
    queue = deque(seed_nodes)
    slice_cls = set()
    while queue:
        cl = queue.popleft()
        if cl in visited:
            continue
        visited.add(cl)
        slice_cls.add(cl)
        for pred in ddg.graph.predecessors(cl):
            queue.append(pred)
    return slice_cls
```

具体流程如下：

1. 首先通过CFG找到包含目标指令的block node。
2. 然后在VEX IR中找到所有的`Exit`语句——这些就是conditional branch的guard所在的位置。
3. 在DDG中找到对应的节点作为seed。
4. 从seed节点开始，沿DDG的反向边进行BFS，收集所有能够到达seed的节点——这就是backward slice。

最终得到的`slice_cls`就是所有影响这个branch guard值的指令集合。

### Step 3: 符号执行求解

拿到backward slice之后，接下来就是通过符号执行来判断这个branch guard是不是一个opaque predicate。

```python
def analyze_branch_guard(proj, slice_cls, branch_block_addr):
    block_addrs = sorted(set(
        cl.block_addr for cl in slice_cls if cl.block_addr is not None
    ))
    if branch_block_addr not in block_addrs:
        block_addrs.append(branch_block_addr)

state = proj.factory.blank_state(addr=block_addrs[0])
    simgr = proj.factory.simgr(state)

for next_addr in block_addrs[1:]:
        simgr.step()
        simgr.move('active', 'deadended', lambda s, na=next_addr: s.addr != na)
        if not simgr.active:
            break
```

首先，我们收集backward slice中涉及到的所有block地址并排序。然后从第一个block开始进行符号执行，逐步step到下一个block。在每次step之后，我们把那些跑到了"错误"地址的state移到`deadended` stash里——这样就保证我们只沿着slice中的路径执行。

```python
    # 从VEX IR中获取conditional exit语句
    irsb = proj.factory.block(branch_block_addr).vex
    cond_exit = next(
        (s for s in irsb.statements if isinstance(s, pyvex.stmt.Exit)),
        None,
    )
    if cond_exit is None:
        return 'unconditional', None

# 在branch block再step一次，观察产生的successor数量
    succs = simgr.active[0].step()

if len(succs.successors) == 1:
        taken_addr = cond_exit.dst.value
        resolved_addr = succs.successors[0].addr
        if resolved_addr == taken_addr:
            return 'always_true', None
        else:
            return 'always_false', None

# 有两个successor，用solver检查guard的可满足性
    guard = succs.successors[0].history.jump_guard
    solver = simgr.active[0].solver

can_be_true  = solver.satisfiable(extra_constraints=[guard])
    can_be_false = solver.satisfiable(extra_constraints=[claripy.Not(guard)])

if can_be_true and not can_be_false:
        return 'always_true', guard
    elif can_be_false and not can_be_true:
        return 'always_false', guard
    else:
        return 'symbolic', guard
```

到达branch block之后，我们再step一次，检查产生了多少个successor：

- **只有1个successor**：说明angr已经具体化了guard的值，直接判定为opaque predicate。通过比较resolved地址和`Exit`语句的目标地址来判断是`always_true`还是`always_false`。
- **有2个successor**：说明guard是符号化的。这时候我们用solver分别检查guard能否为true和能否为false：
  - 只能为true → `always_true`（opaque predicate）
  - 只能为false → `always_false`（opaque predicate）
  - 两者皆可 → `symbolic`（真正的branch，不是opaque predicate）

### Step 4: Patch

一旦确定了一个branch是opaque predicate，接下来就需要对binary进行patch。

```python
def build_slice_patch(proj, slice_cls, target_addr, insn="jmp"):
    # 收集slice中所有指令的地址和大小
    seen = {}
    for cl in slice_cls:
        addr = cl.ins_addr
        if addr is None or addr in seen:
            continue
        for i in proj.factory.block(addr).capstone.insns:
            if i.address == addr:
                seen[addr] = i.size
                break
    insns = sorted(seen.items())

# 找到第一个连续区域 >= 5 bytes（jmp指令需要5字节）
    patch_start = patch_total = None
    for i, (addr, size) in enumerate(insns):
        run_size = size
        for j in range(i + 1, len(insns)):
            if insns[j-1][0] + insns[j-1][1] != insns[j][0]:
                break
            run_size += insns[j][1]
            if run_size >= INSN_SIZE:
                break
        if run_size >= INSN_SIZE:
            patch_start, patch_total = addr, run_size
            break

# 在找到的区域放置jmp指令，其余全部NOP
 asm_bytes, _ = ks.asm(f"{insn} 0x{target_addr:x}", addr=patch_start)
 patches = {}
 patches[patch_start - file_base] = bytes(asm_bytes) + b'\x90' * (patch_total - len(asm_bytes))
 for addr, size in insns:
 if patch_start <= addr < patch_start + patch_total:
 continue
 patches[addr - file_base] = b'\x90' * size
 return patches
```

Patch的策略：

1. 收集backward slice中所有指令的地址和大小。
2. 找到一段连续的、至少5字节的区域——因为x86-64的`jmp rel32`指令正好需要5字节。
3. 在这个区域放置一条无条件跳转指令`jmp target`，跳转目标是opaque predicate恒真/恒假所对应的那个分支。
4. 把slice中其余所有指令全部NOP掉——因为这些指令都只是用来计算opaque predicate的，去掉它们不会影响程序的正确性。

### 主流程

最后，把上面的步骤串起来：

```python
proj, main_func, cfg, ddg = load_everything(
    TARGET_BINARY, target_func_name=TARGET_FUNC_NAME,
    cfg_type="Emulated", auto_load_libs=False
)

branches = find_branches(proj, main_func)
print(f"Found {len(branches)} branches in {TARGET_FUNC_NAME}.")

all_patches = []
for branch_addr in branches:
    block_node = cfg.model.get_any_node(branch_addr, anyaddr=True)
    block_addr = block_node.addr

slice_cls = backward_slice_from(proj, cfg, ddg, branch_addr)

kind, guard = analyze_branch_guard(proj, slice_cls, block_addr)
    print(f"  Guard: {kind}")

if kind in ('always_true', 'always_false'):
        irsb = proj.factory.block(block_addr).vex
        cond_exit = next(s for s in irsb.statements if isinstance(s, pyvex.stmt.Exit))
        taken_addr = cond_exit.dst.value
        fall_addr = irsb.next.con.value
        patch_target = taken_addr if kind == 'always_true' else fall_addr
        all_patches.append(build_slice_patch(proj, slice_cls, patch_target, insn='jmp'))

if all_patches:
    apply_patches(all_patches, TARGET_BINARY, OUTPUT_BINARY)
    print(f"\nWrote {len(all_patches)} patches -> {OUTPUT_BINARY}")
```

对于每个branch：
1. 做backward slicing
2. 符号执行判断是否为opaque predicate
3. 如果是，确定正确的跳转目标（`always_true`取taken分支，`always_false`取fallthrough分支），生成patch
4. 最后一次性把所有patch写入到输出文件

## 评测效果

这是原来混淆的：

![bcf](upload/attach/202603/1070326_X9PR8ZGHVQH3F34.webp)

去混淆后：

![bcf_patched](upload/attach/202603/1070326_43FWJ5HV78A6A7Z.webp)

## Limitations

当前的实现存在一些限制：

1. 目前的实现对于`x*(x+1) % 2 == 0`这类简单的opaque predicate效果很好；但对于更复杂的构造（如前面分析的基于modular inverse的方案），可能需要更强的约束求解能力。
2. **Backward slice的连续性假设**。Patch阶段假设slice中存在一段至少5字节的连续指令区域来放置`jmp`指令。虽然在实际中这个假设基本成立，但理论上可能存在slice中指令极度碎片化的极端情况。

## 代码地址

6bcK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6f1j5h3q4J5k6r3W2K6j5h3q4Q4x3V1k6p5k6g2m8G2L8r3q4J5K9i4x3`.

登录后可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

#软件保护

收藏・4

点赞・16

打赏

赞赏记录

参与人

雪币

留言

时间

wx_Q道长

感谢你分享这么好的资源！

2026-9-10 16:12

孤独的街

你的帖子非常有用，感谢分享！

2026-9-7 08:45

mb_vrcwxcxq

你的分享对大家帮助很大，非常感谢！

2026-9-5 00:08

mb_zevpopif

你的分享对大家帮助很大，非常感谢！

2026-9-1 00:08

mb_hjnyfmfs

你的分享对大家帮助很大，非常感谢！

2026-8-24 00:43

mb_adshwshz

你的分享对大家帮助很大，非常感谢！

2026-8-22 01:40

mb_qzedasmm

你的分享对大家帮助很大，非常感谢！

2026-8-21 00:25

mb_bcgfbzfy

你的分享对大家帮助很大，非常感谢！

2026-8-18 00:21

mb_mqghaxkv

你的分享对大家帮助很大，非常感谢！

2026-8-17 00:56

mb_mwogblyz

你的分享对大家帮助很大，非常感谢！

2026-8-13 00:26

mb_zkfkmxet

你的分享对大家帮助很大，非常感谢！

2026-8-10 01:02

mb_fnhnpexj

你的分享对大家帮助很大，非常感谢！

2026-8-10 00:59

wx_晨梦

你的帖子非常有用，感谢分享！

2026-7-16 05:44

周旋久

感谢你的贡献，论坛因你而更加精彩！

2026-3-24 11:22

Loopher

感谢你的积极参与，期待更多精彩内容！

2026-3-24 10:15

我的小拇指啊

感谢你的积极参与，期待更多精彩内容！

2026-3-22 16:39

最新回复 (17)
mb_bnjbcdzy 雪币： 24 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 55 粉丝 0 关注私信	mb_bnjbcdzy 2 楼 Sophos的研究揭示了AI在威胁开发中的潜在风险，尤其是针对EDR的规避技术。这种工具包的出现不仅展示了技术的进步，更提醒我们网络安全的挑战正在升级。Sophos的发现为企业敲响了警钟，需警惕AI 2026-7-25 16:02 0
mb_vrcwxcxq 雪币： 26 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 53 粉丝 0 关注私信	mb_vrcwxcxq 3 楼作为一名开发者，这篇技术分析非常深入，详细解读了BogusControlFlow的实现细节及其对反编译的影响。通过代码层面的剖析，展示了如何构造opaque predicates以混淆控制流，同时提 2026-8-6 16:00 0
mb_kvvvwhmo 雪币： 21 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 30 粉丝 0 关注私信	mb_kvvvwhmo 4 楼这篇技术分析非常详细，深入探讨了BogusControlFlow混淆技术的实现原理和潜在问题。作者对代码的逐行分析和数学推导令人印象深刻，特别是对opaque predicate构造中bug的发现， 2026-8-10 12:20 0
mb_mwogblyz 雪币： 25 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 32 粉丝 0 关注私信	mb_mwogblyz 5 楼作为一名开发者，最近在学习主流编程语言的过程中，发现Python真的太强大了！从简单的脚本到复杂的后端开发，Python几乎无所不能。它的语法简洁清晰，学习曲线友好，特别适合新手入门。更让我惊喜的是 2026-8-10 12:21 0
mb_bcgfbzfy 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 31 粉丝 0 关注私信	mb_bcgfbzfy 6 楼这篇技术帖详细讲解了BogusControlFlow的实现细节，特别是通过克隆和拆分基本块来增加反编译器的解析难度。这种混淆方法通过注入opaque predicates来干扰反编译过程，为保护代码 2026-8-18 12:08 0
mb_zkfkmxet 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 30 粉丝 0 关注私信	mb_zkfkmxet 7 楼这个混淆技术确实挺有意思的，通过克隆basic block和注入opaque predicate，确实能让反编译器难以解析。特别是利用模运算和逆元构造的变换，虽然有点复杂，但确实达到了混淆的目的。不 2026-8-21 12:02 0
mb_adshwshz 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 30 粉丝 0 关注私信	mb_adshwshz 8 楼这篇文章详细介绍了BogusControlFlow混淆技术的实现细节和反混淆方法，内容深入浅出。通过分析关键函数和代码逻辑，可以看出该技术在增加代码复杂度和混淆分析难度方面确实有其独特之处。尤其是对 2026-8-26 12:04 0
mb_nuomemmo 雪币： 29 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 51 粉丝 0 关注私信	mb_nuomemmo 9 楼作者对BogusControlFlow技术的分析非常透彻，揭示了其工作原理和潜在问题。这种混淆方法虽然复杂，但在反编译时确实增加了难度。值得深入研究！ 2026-8-27 16:01 0
mb_whehifsr 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 32 粉丝 0 关注私信	mb_whehifsr 10 楼这篇文章详细讲解了BogusControlFlow混淆技术的实现细节，代码分析透彻，对混淆原理和反混淆方法都有深入探讨。文章结构清晰，逻辑严谨，对理解LLVM混淆技术有很大帮助，值得推荐给相关领域的 2026-8-29 12:17 0
mb_bcgfbzfy 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 31 粉丝 0 关注私信	mb_bcgfbzfy 11 楼这个混淆技术的实现挺有意思的，特别是通过克隆和插入opaque predicates来增加反编译的难度。Python在处理这类代码分析和生成任务时确实很强大，能够快速实现复杂的逻辑，简化很多开发步骤 2026-9-1 12:03 0
mb_whehifsr 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 32 粉丝 0 关注私信	mb_whehifsr 12 楼这篇技术分析非常深入，详细讲解了BogusControlFlow的实现原理和潜在问题。通过分析代码和混淆效果，可以看出这种技术确实能够显著增加反编译的难度。特别是通过克隆基本块和注入不透明谓词的方式 2026-9-2 12:15 0
mb_phossfny 雪币： 26 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 29 粉丝 0 关注私信	mb_phossfny 13 楼这篇文章详细分析了BogusControlFlow的实现细节，特别是克隆和拆分基本块的过程，以及注入opaque predicates的机制。通过这种方式，可以有效地混淆控制流，使得反编译器难以正确 2026-9-3 12:15 0
mb_qzedasmm 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 31 粉丝 0 关注私信	mb_qzedasmm 14 楼这个混淆技术的实现非常巧妙，通过克隆和拆分basic block来增加控制流的复杂性，确实能有效阻碍反编译器的分析。作者的详细分析和代码示例让我对BogusControlFlow的工作原理有了更深入 2026-9-5 12:10 0
mb_nuomemmo 雪币： 29 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 51 粉丝 0 关注私信	mb_nuomemmo 15 楼这篇帖子深入分析了LLVM混淆技术的实现细节，尤其是BogusControlFlow的复杂构造，展现了开发者在代码保护领域的技术深度。作为一名开发者，我非常欣赏这种对技术原理的深入挖掘，同时也能感受 2026-9-6 16:04 0
mb_xultgqpf 雪币： 22 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 57 粉丝 0 关注私信	mb_xultgqpf 16 楼这篇文章详细分析了LLVM混淆技术中的BogusControlFlow实现，特别是其在Opaque Predicate构造上的巧妙设计。文中通过代码逐行解析，展现了开发者对LLVM IR操作的深刻理 2026-9-7 08:02 0
mb_nuomemmo 雪币： 29 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 51 粉丝 0 关注私信	mb_nuomemmo 17 楼这篇技术分析非常详细，深入探讨了LLVM混淆技术的实现细节，尤其是BogusControlFlow的复杂性和潜在问题。这种混淆方法通过巧妙的代码变换增加了反编译的难度，虽然存在一些实现上的缺陷，但无 2026-9-10 16:00 0
mb_zevpopif 雪币： 30 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 33 粉丝 0 关注私信	mb_zevpopif 18 楼这个LLVM混淆的实现挺有意思的，特别是用DAG结构处理basic block，能明显看出反编译的难度增加了。 2天前 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

Taardisaa

发帖

回帖

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (17)
mb_bnjbcdzy 雪币： 24 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 55 粉丝 0 关注私信	mb_bnjbcdzy 2 楼 Sophos的研究揭示了AI在威胁开发中的潜在风险，尤其是针对EDR的规避技术。这种工具包的出现不仅展示了技术的进步，更提醒我们网络安全的挑战正在升级。Sophos的发现为企业敲响了警钟，需警惕AI 2026-7-25 16:02 0
mb_vrcwxcxq 雪币： 26 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 53 粉丝 0 关注私信	mb_vrcwxcxq 3 楼作为一名开发者，这篇技术分析非常深入，详细解读了BogusControlFlow的实现细节及其对反编译的影响。通过代码层面的剖析，展示了如何构造opaque predicates以混淆控制流，同时提 2026-8-6 16:00 0
mb_kvvvwhmo 雪币： 21 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 30 粉丝 0 关注私信	mb_kvvvwhmo 4 楼这篇技术分析非常详细，深入探讨了BogusControlFlow混淆技术的实现原理和潜在问题。作者对代码的逐行分析和数学推导令人印象深刻，特别是对opaque predicate构造中bug的发现， 2026-8-10 12:20 0
mb_mwogblyz 雪币： 25 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 32 粉丝 0 关注私信	mb_mwogblyz 5 楼作为一名开发者，最近在学习主流编程语言的过程中，发现Python真的太强大了！从简单的脚本到复杂的后端开发，Python几乎无所不能。它的语法简洁清晰，学习曲线友好，特别适合新手入门。更让我惊喜的是 2026-8-10 12:21 0
mb_bcgfbzfy 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 31 粉丝 0 关注私信	mb_bcgfbzfy 6 楼这篇技术帖详细讲解了BogusControlFlow的实现细节，特别是通过克隆和拆分基本块来增加反编译器的解析难度。这种混淆方法通过注入opaque predicates来干扰反编译过程，为保护代码 2026-8-18 12:08 0
mb_zkfkmxet 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 30 粉丝 0 关注私信	mb_zkfkmxet 7 楼这个混淆技术确实挺有意思的，通过克隆basic block和注入opaque predicate，确实能让反编译器难以解析。特别是利用模运算和逆元构造的变换，虽然有点复杂，但确实达到了混淆的目的。不 2026-8-21 12:02 0
mb_adshwshz 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 30 粉丝 0 关注私信	mb_adshwshz 8 楼这篇文章详细介绍了BogusControlFlow混淆技术的实现细节和反混淆方法，内容深入浅出。通过分析关键函数和代码逻辑，可以看出该技术在增加代码复杂度和混淆分析难度方面确实有其独特之处。尤其是对 2026-8-26 12:04 0
mb_nuomemmo 雪币： 29 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 51 粉丝 0 关注私信	mb_nuomemmo 9 楼作者对BogusControlFlow技术的分析非常透彻，揭示了其工作原理和潜在问题。这种混淆方法虽然复杂，但在反编译时确实增加了难度。值得深入研究！ 2026-8-27 16:01 0
mb_whehifsr 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 32 粉丝 0 关注私信	mb_whehifsr 10 楼这篇文章详细讲解了BogusControlFlow混淆技术的实现细节，代码分析透彻，对混淆原理和反混淆方法都有深入探讨。文章结构清晰，逻辑严谨，对理解LLVM混淆技术有很大帮助，值得推荐给相关领域的 2026-8-29 12:17 0
mb_bcgfbzfy 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 31 粉丝 0 关注私信	mb_bcgfbzfy 11 楼这个混淆技术的实现挺有意思的，特别是通过克隆和插入opaque predicates来增加反编译的难度。Python在处理这类代码分析和生成任务时确实很强大，能够快速实现复杂的逻辑，简化很多开发步骤 2026-9-1 12:03 0
mb_whehifsr 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 32 粉丝 0 关注私信	mb_whehifsr 12 楼这篇技术分析非常深入，详细讲解了BogusControlFlow的实现原理和潜在问题。通过分析代码和混淆效果，可以看出这种技术确实能够显著增加反编译的难度。特别是通过克隆基本块和注入不透明谓词的方式 2026-9-2 12:15 0
mb_phossfny 雪币： 26 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 29 粉丝 0 关注私信	mb_phossfny 13 楼这篇文章详细分析了BogusControlFlow的实现细节，特别是克隆和拆分基本块的过程，以及注入opaque predicates的机制。通过这种方式，可以有效地混淆控制流，使得反编译器难以正确 2026-9-3 12:15 0
mb_qzedasmm 雪币： 27 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 31 粉丝 0 关注私信	mb_qzedasmm 14 楼这个混淆技术的实现非常巧妙，通过克隆和拆分basic block来增加控制流的复杂性，确实能有效阻碍反编译器的分析。作者的详细分析和代码示例让我对BogusControlFlow的工作原理有了更深入 2026-9-5 12:10 0
mb_nuomemmo 雪币： 29 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 51 粉丝 0 关注私信	mb_nuomemmo 15 楼这篇帖子深入分析了LLVM混淆技术的实现细节，尤其是BogusControlFlow的复杂构造，展现了开发者在代码保护领域的技术深度。作为一名开发者，我非常欣赏这种对技术原理的深入挖掘，同时也能感受 2026-9-6 16:04 0
mb_xultgqpf 雪币： 22 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 57 粉丝 0 关注私信	mb_xultgqpf 16 楼这篇文章详细分析了LLVM混淆技术中的BogusControlFlow实现，特别是其在Opaque Predicate构造上的巧妙设计。文中通过代码逐行解析，展现了开发者对LLVM IR操作的深刻理 2026-9-7 08:02 0
mb_nuomemmo 雪币： 29 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 51 粉丝 0 关注私信	mb_nuomemmo 17 楼这篇技术分析非常详细，深入探讨了LLVM混淆技术的实现细节，尤其是BogusControlFlow的复杂性和潜在问题。这种混淆方法通过巧妙的代码变换增加了反编译的难度，虽然存在一些实现上的缺陷，但无 2026-9-10 16:00 0
mb_zevpopif 雪币： 30 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 33 粉丝 0 关注私信	mb_zevpopif 18 楼这个LLVM混淆的实现挺有意思的，特别是用DAG结构处理basic block，能明显看出反编译的难度增加了。 2天前 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

[原创]Polaris-Obfuscator中BogusControlFlow简要分析 反混淆

[原创]Polaris-Obfuscator中BogusControlFlow简要分析反混淆