fjqisba 这种方式效果有限，遇到复杂的就处理不鸟了

fjqisba 这种方式效果有限，遇到复杂的就处理不鸟了

IIImmmyyy 恰恰相反，我写这个的目的就是处理复杂情况，无论是何种情况下 块和块的链接只有2个结果 真实块或者分发块。满足条件即可遍历出结果

IIImmmyyy 恰恰相反，我写这个的目的就是处理复杂情况，无论是何种情况下 块和块的链接只有2个结果 真实块或者分发块。满足条件即可遍历出结果

mb_ldbucrik 请问大佬，arm32 thumb适用吗

大帅锅 可曾遇到共用块

for循环就是标准的共用块情况。 查找过程中会对正在查找的block进行标记，如果递归发现是已经正在查找的则返回，同时链接已经存在的block。此处理就可完成for循环的处理

```

if (block.isFind)
{
    Logger.WarnNewline("block is Finding  " + block.start_address);
    return block.RealChilds;
}

```

IIImmmyyy 不适用 暂未有arm32 和x86的支持计划。 如果要做多架构的话 需要抽出一个中间语言作为桥接。 我闲麻烦没有做了

mb_ldbucrik 好的，retdec优化貌似支持所有的架构

首先关于

1. 因为会按照非常规进入的某段逻辑，所以有时可能会出现错误，导致未遍历完整
2. 要遍历很多，所以速度比较慢 

这个我并没有办法回答你，可能是因为样本的原因。我目前没有碰到。

我的设计理念是块只有2种情况，真实块或者分发块。 真实块无论是以什么样的形式存在 只要不是分发器它都是真实块。

当然这种就需要特殊处理真实块，比如情况 

```loc_17F750

STR             XZR, [SP,#0xF0+var_C8]

```

这个也是公共块 它的后继块 要么是分发器 要么是真实块。甚至他的后继块可能是它自己。 但是无论如何是什么块，都会进入循环进行标记。我的设计理念就是找到所有的分支。排除分发器。

另外一个问题关于patch指令的 不知道我理解的对不对 我附上一个情况

```

//loc_15E604
// LDR             X9, [SP,#0x2D0+var_2B0]
// ADRP            X8, #qword_7289B8@PAGE
// LDR             X8, [X8,#qword_7289B8@PAGEOFF]
// STR             X9, [SP,#0x2D0+var_260]
// LDR             X9, [SP,#0x2D0+var_2A8]
// STR             X8, [SP,#0x2D0+var_238]
// MOV             W8, #0x561D9EF8
// STP             X19, X9, [SP,#0x2D0+var_270]

// loc_15E628
// CMP             W8, W23
// B.GT            loc_15E6C0

```

loc_15e628 是在下一个连接块中。 此时对15e604进行patch修复的 我选择删除掉MOV W8  这个分发指令 然后调整STP X19 X9 的位置 让跳转指令下沉。这样分发块就可以正常的NOP掉。 如果没有MOV 指令， 其实这个块就不是分发块 也不需要进行NOP 修复 因为下个连接块大概率是一个中转指令 就一个 B locXXXX 这个可能连接到分发块 也有可能是真实块。 但是不重要 因为块与块之间是单独修复的 只要管好自己就行。

Patch 的原则就是不要动到真实块的位置。可以删减 但是不能对原块的指令进行扩充。 因为扩充在复杂的情况下我觉的会有分支错误的问题

IIImmmyyy 其实这个也支持，也不难。 你可以仿造arm64的写法进行逻辑的剥离。 代码量很少 并不多的。不想支持的原因主要还是目前工作中需要单独去分析arm32 的情况实在是太少了。 arm64已经是主流了