Base64魔改逆向实战：从标准编码表到Ezbase索引变换解密-北京尧图网络

想靠背原版Base64表就去通杀逆向题的人遇到魔改基本会卡住。Base64魔改在逆向题目里非常常见从入门赛到进阶赛都爱出Ezbase就是一道非常适合练手的题。它把人人都知道的编码表换掉再悄悄动一下索引值不仔细看就是找不到规律。这篇文章不废话直接带你走一遍标准Base64到魔改的原理拆掉Ezbase的核心逻辑最后给出可以直接照着抄的C和Python解密脚本。无论你是刚接触逆向的新手还是刷题遇到同类题目卡住的选手都可以把这篇当分析模板来用。1. 从标准Base64到魔改先搞懂变在哪1.1 标准Base64怎么工作编码表和索引值的真正含义标准Base64本质上是最朴素的“查表编码”。它把每3个原始字节拆成4个6位的小组每一组6位能表示0到63之间的整数这个整数就是索引值然后拿着索引值去一张64字符的表里找对应的字符最终产出4个可见字符。比如原始字节是ABC也就是十六进制的0x41 0x42 0x43二进制展开是01000001 01000010 01000011。从最高位开始每6位切分得到010000 010100 001001 000011对应的索引值分别是16、20、9、3。标准Base64表是ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789/第16个字符是Q第20个字符是U第9个字符是J第3个字符是D所以ABC编码出来就是QUJD。如果最后只剩1个或2个字节就用补齐。因为Base64编码要求输出长度必须是4的倍数缺多少补多少。解码方向正好反过来先把字符在表中找到索引值再把索引值按6位拼成8位字节流。这里的核心就是两个东西编码表长什么样索引值怎么算出来。编码表决定“看起来像什么”索引值决定“字节到底是什么”。标准版本里索引值就是字符在表中的下标不需要额外的处理。但魔改题恰恰喜欢在这两个地方动手脚。1.2 魔改的几种常见套路打乱编码表、更换索引规则、加入额外混淆魔改Base64的常见方式可以归纳成下面几类Ezbase这道题就同时出现了其中两种。魔改类型典型表现还原难度编码表替换字符串窗口里找不到标准表或有一个长得像但顺序完全不同的64字节表低拿到表就能解索引值变换编码函数里有异或、加减、查另一个数组的额外操作中需要反推索引逆变换分组规则修改不再是3字节一组或者补齐字符不是高已经不是标准Base64流程了叠加其他编码先进行魔改Base64再异或一串密钥中高需要逐层逆推初学者最容易栽在第二种上。很多人以为把表dump出来就万事大吉结果脚本解出来全是乱码就是因为没有处理索引变换。索引变换隐藏在编码函数内部表面看起来还是四字符一组的Base64输出但内部在取到字符对应的下标之后多了一步运算。还有一种比较阴的改法是把表改成运行时动态生成。程序里不直接出现完整的64字节表而是先用一段初始化代码对标准表进行异或、旋转、逐字节打乱。这种情况下静态搜字符串找表是找不到的必须动态调试等表生成完之后再从内存里复制出来。1.3 为什么逆向练习里特别关心这两个点因为只要确定了编码表和索引变换规则剩下的解码工作完全机械化。反过来说如果这两个点没确认任何解密脚本都是瞎猜。编码表的作用相当于一套“字符到数字的字典”。标准Base64里字符Q的字典序是16U是20换了一张表之后同一个字符对应的数字完全可能变成别的。你不拿到这张表就没法把密文还原成字节。索引值的作用更隐蔽。编码表定义的是“字符和数字的对应关系”索引变换定义的是“这个数字要经过什么运算之后才真正作为Base64的6位值”。很多题目用异或来做这一步因为异或的逆运算还是异或新手容易发现但写脚本时又经常忘记把它加进去。用一个生活化的类比编码表是字典索引变换就是给页码加了一把锁。拿到字典只能让你知道字在哪一页但还得解开页码上的锁才能真的翻到那一页。2. 拿到Ezbase后的静态分析思路2.1 先搜标准表字符串别急着上线拿到一个Base64魔改题我习惯性第一步在IDA的字符串窗口按一次CtrlShiftF12先搜ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789/这串标准字符。如果这个字符串在程序里出现它一般有三种用途标准Base64库的常量、初始化自定义表时的原始素材、或者单纯用来干扰你。Ezbase这道题里并没有直接出现完整标准表但出现了一些看起来像是字母表碎片的字符串。这说明表很可能不是直接写在静态区而是程序运行到一个初始化函数时动态生成的。遇到这种情况不要急着跳进去对着汇编硬啃可以先找到引用这些碎片的函数看它生成表的循环逻辑。还有一个细节值得注意自定义表通常还是64个字符并且不会出现重复字符。如果找到的是一个看起来像乱码但长度正好是64的字符串那大概率就是魔改后的表。用脚本判断一下长度和重复度比肉眼看快得多。2.2 顺着交叉引用定位Base64编解码函数找到可疑的表数组之后在IDA里对这个数组按X查看交叉引用通常能跳到编码函数或解码函数。真正的Base64编码函数有几个明显特征会调用strchr或类似函数在表里逐个查找当前输入字符的位置会有移位和掩码操作比如 6、 4、 0x3F会用一个临时变量把6位索引累积成24位整数循环次数和输入长度成比例一般是4字符一组输出。用F5看伪代码会更直观。Ezbase的主函数被还原出来大概是这个样子char g_table[65]; char g_cipher[128]; void init_table(void) { for (int i 0; i 64; i) g_table[i] ... } int main(void) { char input[64]; char output[128]; init_table(); scanf(%s, input); base64_encode_mut(input, output, g_table); if (strcmp(output, g_cipher) 0) puts(right); else puts(wrong); return 0; }看到这种结构就能确定程序对你输入的flag先做了一次魔改Base64编码再和写死在内存里的密文比较。那答案就是对这个密文做魔改Base64解码得到原始输入。2.3 记录编码表长度和padding逻辑不要只盯着编码表还要确认填充逻辑是否被改过。标准Base64用表示末尾补齐有些题目会把补齐字符改成别的也有一些会去掉直接按不完整字符组处理。Ezbase保留了标准这一点让分析省了很多事。如果程序比较的是编码后的字符串通常g_cipher的长度会是4的倍数。用Ghidra或者IDA打开数据段看一下g_cipher的字节如果末尾有或说明原始输入长度对应的余数信息保留在了密文里解码时可以直接依赖填充字符的数量。有一个坑需要提前说程序里的比较函数可能是memcmp而不是strcmp。如果比较长度不是按照字符串长度来的那么密文末尾也许还带有额外字节。这种情况要把密文先按16进制dump出来确认到底比较了多少字节别只看成ASCII字符串。3. Ezbase核心逻辑拆解魔改点在哪里3.1 从反汇编还原主流程Ezbase的流程不复杂核心就是初始化表然后用这个表编码输入再比较结果。表初始化函数很短但里面有大量异或和交换操作所以静态看会有点绕。我在调试器里下了一个断点跑完初始化函数之后直接把g_table所在的内存导出得到了一张非常规整的64字节表ZYXWVUTSRQPONMLKJIHGFEDCBAzyxwvutsrqponmlkjihgfedcba9876543210/我把这张表和标准表对比了一下发现标准表是按大写字母、小写字母、数字、加号、斜杠排列的这张表是完全倒序。也就是说Ezbase做的第一层魔改就是把标准表整个反转字符A不再是索引0而是变成了索引63。如果只看表层这就是“表替换”。但对这种倒序表如果只做替换输出的密文会很好认本来标准编码出的QUJD在这张表下会变成完全不同的字符。我当时先试着用倒序表直接解码一段已知的测试向量发现结果还是不对于是马上意识到还有第二层魔改。3.2 从内存中切割出编码表动态dump表的时候有个人人会踩的坑表数组不是以0结尾的C字符串不能用字符串窗口直接看全部内容。要按字节看选中64个字节手动复制。Ezbase的g_table在内存里的样子就是连续64个ASCII字符末尾没有0后面的内存可能还跟着其他数据。拿到表之后我习惯先做一次“字符到下标”的映射。把上面的倒序表按位置编号可以这样看位置0 1 2 3 4 5 6 7 8 9 字符 Z Y X W V U T S R Q 位置10 11 12 13 14 15 16 17 18 19 字符 P O N M L K J I H G 位置20 21 22 23 24 25 26 27 28 29 字符 F E D C B A z y x w 位置30 31 32 33 34 35 36 37 38 39 字符 v u t s r q p o n m 位置40 41 42 43 44 45 46 47 48 49 字符 l k j i h g f e d c 位置50 51 52 53 54 55 56 57 58 59 字符 b a 9 8 7 6 5 4 3 2 位置60 61 62 63 字符 1 0 /这张倒序表本来不算难真正让题目升级的是在编码函数里多了一行索引异或操作。3.3 识别索引值变换的痕迹我重新跟了一遍base64_encode_mut的代码在伪代码里看到了这句话idx (int)(strchr(g_table, cur_char) - g_table); idx ^ 0x25;这就是Ezbase的第二层魔改。标准的编码流程是拿到字符在表中的下标之后直接当作6位值用而这题在拿了下标之后先异或了0x25才把结果拼进输出字节流。0x25是十进制的37正好还是一个不超过63的数所以异或之后不会产生超出6位范围的值程序也不会报错只会输出一堆看起来毫无规律的字符串。从逆向角度发现这一步特别重要。解码时我们不能直接把密文字符在倒序表中的下标当作索引值必须先把下标异或0x25再进入Base64的6位拼接流程。因为异或操作是对合运算decode时同样执行idx idx ^ 0x25即可不需要额外写减法或者取模。如果你在别的题目里遇到的是idx (idx 7) % 64这类线性变换解码时就要反过来做idx (idx - 7 64) % 64。核心思路不是死记这一个异或而是先找到编码函数里“得到下标之后”的所有额外运算然后一一逆掉。4. 手写解密脚本C与Python双版本4.1 Python解密脚本实现与逐段说明Python脚本适合快速验证思路我这里把完整的脚本贴出来你只需要修改TABLE和CIPHER常量就能用于自己的题目。TABLE ZYXWVUTSRQPONMLKJIHGFEDCBAzyxwvutsrqponmlkjihgfedcba9876543210/ CIPHER oo IDX_XOR 0x25 def decode_base64_mut(s): char_map {c: i for i, c in enumerate(TABLE)} bits for ch in s: if ch : break if ch not in char_map: raise ValueError(finvalid char: {ch}) idx char_map[ch] idx ^ IDX_XOR bits f{idx:06b} pad s.count() if pad: bits bits[:-pad * 2] result bytes( int(bits[i:i 8], 2) for i in range(0, len(bits), 8) if len(bits[i:i 8]) 8 ) return result if __name__ __main__: print(decode_base64_mut(CIPHER))这段脚本的核心在idx ^ IDX_XOR这一行。它先通过char_map把密文字符转成它在魔改表里的下标再异或回去还原成真正的6位索引。如果你分析的题没有索引变换把这行改成pass或者把IDX_XOR设为0即可。pad的处理也很关键。标准Base64的表示原始数据只有1个字节8位有效信息填进两个6位组末尾会有4个多余的填充位需要丢掉。脚本里通过去掉pad * 2位来清除这些填充位然后再按8位切片。如果不做这一步解出来的第一个字节可能是对的后面就会全部错位。上面例子里的CIPHER oo是一个自测向量。倒序表下o的下标是37异或0x25后变成0两个0拼出的6位组是000000 000000去掉末尾4位填充位后得到00000000也就是单字节b\x00。运行脚本应该输出一个空字节这样可以确认脚本逻辑没有写歪。4.2 C解密脚本实现与编译注意事项有些场景必须用C写比如最终要集成进自己的模拟器、调试器插件或者你手头环境没有Python。C版本的重点是维护一个位累加器每来一个6位索引就往累加器里塞够8位就输出一个字节。#include stdio.h #include string.h static const char g_table[] ZYXWVUTSRQPONMLKJIHGFEDCBAzyxwvutsrqponmlkjihgfedcba9876543210/; static int index_transform(int idx) { return idx ^ 0x25; } static int decode_base64_mut(const char *in, const char *table, unsigned char *out, size_t out_cap) { size_t len strlen(in); size_t out_len 0; unsigned int acc 0; int bitcnt 0; for (size_t i 0; i len; i) { char ch in[i]; if (ch ) break; const char *pos strchr(table, ch); if (pos NULL) return -1; int idx (int)(pos - table); idx index_transform(idx); if (idx 0 || idx 64) return -1; acc (acc 6) | (unsigned int)idx; bitcnt 6; if (bitcnt 8) { bitcnt - 8; if (out_len out_cap) return -1; out[out_len] (unsigned char)((acc bitcnt) 0xFF); acc (1u bitcnt) - 1; } } return (int)out_len; } int main(void) { unsigned char out[64]; int n decode_base64_mut(oo, g_table, out, sizeof(out)); if (n 0) { for (int i 0; i n; i) printf(%02x , out[i]); putchar(\n); } return 0; }编译命令很简单gcc -o solve solve.c ./solve这里我有几个建议。第一g_table必须作为字符数组保存strchr依靠\0结尾来查找如果你从IDA里复制的表后面还带着乱七八糟的内存数据记得手动补一个字符串结束符。第二acc (1u bitcnt) - 1这一步不是可选项它能把已经输出过的位清掉避免累加器在下一次移位时把无关的残留位带进来。第三如果输入密文长度比较长注意out_cap要开得足够大一般密文长度的四分之三再加几个字节就够了。4.3 脚本测试与常见坑脚本写完不能直接跑题目密文先用自测向量确认。我常用的自测方式是构造一个已知字节用目标魔改规则编码然后看脚本能不能还原。Ezbase这个题里最容易被坑的地方有这么几个一是忘了处理索引变换。只找到表、没看函数里那句idx ^ 0x25结果解码出来的内容要么是乱码要么是差几个字节。这种情况下回IDA重新看编码函数把所有对idx的运算都记下来。二是填充位的处理。有些脚本没有去掉末尾多余位直接按8位切片虽然最后一个字节可能因为位数不足被丢弃但前面的字节不受影响。如果题目末尾有去掉填充位后正好是8的整数倍如果题目去掉了编码函数可能把末尾的无效位也保留在字符串里这时候需要根据原始输入长度判断需要保留多少有效位。三是表字符中包含或/时在命令行、URL、编程语言的字符串里都容易出转义问题。Python里最好用原始字符串或者直接复制内存里的字节不要手打手打特别容易漏字符。四是脚本里的IDX_XOR不是万能的。如果题目用的是加法、乘法或者查表映射你要在解码脚本里写出对应的逆变换。例如编码时是idx (idx 3) 0x3F解码时就要idx (idx - 3) 0x3F编码时是idx table2[idx]解码时就要先建立table2的反向映射。5. 从Ezbase延伸Base64魔改逆向的实战经验5.1 识别魔改的高效套路拿到任何疑似Base64魔改题我建议按照以下顺序排查不容易漏先找和标准Base64相关的字符串或常量。搜标准表、base64、b64之类的关键字。找到了就顺藤摸瓜。搜不到就用动态调试跑起来在可疑函数入口下断点运行完直接dum内存里的表。再找对表的引用。表一般在初始化函数和编码/解码函数里出现。编码函数里一定有从表里取字符的语句解码函数里一定有在表里找字符的语句。顺着交叉引用把这些函数一网打尽。然后根据已知输入输出确认索引变换。如果你有办法运行程序输入一个已知字符串比如flag观察密文前几个字符再和标准Base64结果对比。差异能直接体现表替换和索引变换。最后确定比较逻辑。题目通常是base64_mut(input) cipher也可能反过来是base64_mut(cipher) input要看清比较方向。5.2 常见魔改模型速查表我在实战里总结了一个速查表遇到类似题目可以直接套思路魔改点还原方式表被打乱但索引没有变换dump表后直接用新表做标准Base64解码表被打乱并附加^ key查表下标后逆异或再拼6位表被打乱并附加 key或- key按下标加/减后取模再拼6位表是运行时生成下断点等初始化结束内存中提取64字节作为表编码后还有一层异或先解异或再解码Base64比较的不是字符串而是字节码密文按十六进制处理避免ASCII截断这个表本质是把问题拆成“表”“索引变换”“后续操作”三层。每层单独逆推最后合并成一条完整解密链。5.3 遇到更复杂魔改时的思路和调试技巧Ezbase还算温柔至少表的生成逻辑和异或都能一眼看到。现实里你会遇到表是两张、索引变换依赖字符位置、或者编码前还有一层字节反转的情况。这种时候我建议:第一不要一开始就写完整脚本。先用调试器在单步执行里把前几个字符的完整处理流程记下来搞清楚“输入字符 - 表下标 - 中间运算 - 输出”的每一步。第二把每一步抽象成一个小函数最后用数据流串起来。第三如果运算比较复杂比如有多轮查表和异或可以考虑用Z3这种约束求解器直接求解而不是手推公式。调试时还有一个非常实用的技巧如果程序使用的是Windows用x64dbg在g_table初始化完成后的地址下断点然后在内存窗口复制64字节。在Linux上用GDB时用x/64bx g_table导出。这样拿到的表最干净不会因为源码里的字符转义出问题。我个人在实际操作中体会最深的一点是遇到魔改题不要急着爆破也不要急着乱试。只要你把编码表和索引变换拎清楚剩下的就是体力活。这道Ezbase的整个解题过程从dump表到写完整版脚本其实不超过二十分钟。真正花时间的不是在脚本上而是在IDA里找到那句“多余的”异或。那一行小小的idx ^ 0x25就是整道题最核心的分水岭。

Base64魔改逆向实战：从标准编码表到Ezbase索引变换解密

相关推荐

OpenHarmony上React Native表单状态管理：用useReducer替代useState的完整实践

从OpenClaw到Moltbook：让纸质书变身AI可调用的个人知识库

Spring单例注入多例Bean失效？四种方案彻底搞懂Bean作用域

更多资讯

手写Tool Use：从OpenAI规范到生产级可观测实现

AI面试官评分机制拆解：秋招中如何避免无声挂掉

ROS话题通信实战：rostopic工具与msg消息类型详解

OpenCV视频虚拟键盘：纯传统CV实时手势交互实现

AI写代码半年实践：能力边界、翻车案例与高效工作流

LangChain vs LangGraph框架选型决策指南

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？