今天在CTF交流群里看到一道题有人贴了串字符xooooxxoooxxx说这是加密后的flag求大佬看看。底下有人说是base64有人说是凯撒还有人说这是摩斯码但都没有下文最后不了了之。我盯着这串字符看了一会儿第一反应是只含x和o不是哈希也不是Base64更像是一种双符号编码。如果把它映射成二进制再考虑补位或者干脆当成一个密钥种子情况立马就不同了。这篇文章就从这串字符出发梳理一下在密码学里遇到这类“人畜无害”的符号串时应该怎么分析、怎么解码、怎么把它用在真正的加密流程里以及在软考和CTF里常见的变形考法。1. 为什么第一眼就该怀疑它是双符号编码1.1 字符集和长度暴露了真身密码分析的第一步永远是“看长相”。xooooxxoooxxx这串字符有两个非常明显的特征第一只由x和o组成第二总长度是13位。把这两个信息放在一起基本可以排除一堆常见编码。MD5、SHA1这类哈希值输出的是十六进制字符也就是0-9加a-f里面会出现数字和其他字母Base64的字符集更是包含大小写字母、数字、、/而且长度一定是4的倍数URL编码、十六进制转义也会有%或\x这样的标记。xooooxxoooxxx全部落在小写字母x和o上没有数字也没有其他标点这种二元字符集在密码学里其实非常常见——本质上它就是一个只有两个符号的编码系统可以映射成二进制里的0和1也可以映射成摩斯码里的点和划还可以映射成培根密码里的a和b。所以当看到这种串的时候第一反应就应该是这不是普通文本而是一个“二元符号串”。接下来要做的不是瞎猜算法而是先确定它的编码空间。1.2 为什么不是Base64、MD5或凯撒很多新手看到一串字符就急吼吼地往在线工具里塞结果什么也解不出来。原因很简单xooooxxoooxxx这种字符集和Base64的标准字符集完全对不上。Base64编码后的字符串长度一定是4的倍数13不是4的倍数哈希值如果是16进制里面必然会出现0-9的数字这里没有。凯撒密码只对字母移位但一个纯x/o的串就算移多少位也仍然是由两个字母组成的文本语义上不会有任何变化。有人会想到摩斯码的确摩斯码就是由点和划组成的二元符号如果把x当点、o当划可能会是一个摩斯码消息。但是摩斯码在编码时一定要有分隔符——字符之间要有空隙单词之间要有长空隙否则连续的x和o根本没法切分。xooooxxoooxxx没有提供任何分隔信息所以它更大概率不是完整的摩斯码而是某种丢失了分隔符的编码或者根本就是一段二进制数据的另一种表示。1.3 双符号编码在密码学里的经典地位双符号编码不是冷门玩法它在密码学历史上非常常见。培根密码就是用a和b两个符号每5个一组表示一个英文字母标准摩斯码是点和划计算机里的二进制本身就是0和1两个符号。现代密码学里很多协议在传输密钥或密文时也会先把数据转成可打印字符比如十六进制或Base64但为了规避检测或满足某些受限信道的要求还会出现自定义的双符号编码。理解这一点有什么意义它告诉我们遇到xooooxxoooxxx这类字符串思路要分成两条线。一条线是“它可能是编码后的数据”需要把它还原成二进制、再还原成明文另一条线是“它本身就是一个密钥或口令”不需要解码只需要提取它的熵然后通过密钥派生函数把它变成标准算法的输入。这两条线在密码学实战里都站得住脚具体先走哪条取决于上下文。这也是xooooxxoooxxx作为一个教学案例最迷人的地方。2. 从13位怪串到可读信息手工拆解与脚本解码2.1 最直接的映射x1o0先用最简单的办法试一下定义映射x - 1o - 0把xooooxxoooxxx转成二进制。手动拆一下字符xooooxxoooxxx值1000011000111得到的二进制串是1000011000111一共13位。把它转成十进制1*2^12 1*2^7 1*2^6 1*2^2 1*2^1 1*2^0 4096 128 64 4 2 1 4295所以如果x1, o0这串字符表达的数字是4295。如果反过来映射x0, o1得到二进制0111100111000十进制是0*4096 1*2048 1*1024 1*512 1*256 0*128 0*64 1*32 1*16 1*8 0*4 0*2 0*1 3896。两种映射给出了两个不同的整数到底哪个对需要结合后面的分组和上下文来判断。2.2 八位一组的补位实验为什么会出现半个乱码我们自然想把二进制还原成ASCII字符这一步通常按8位一组。但1000011000111只有13位没法直接分组成整字节必须先补位。补位方式有两种左边补0右边补0。右侧补三个0变成16位1000011000111000。按8位分组10000110和00111000。前者是十进制的134对应扩展ASCII中的某些图形字符不一定能在常规终端里显示后者是十进制的56对应ASCII字符8。左侧补三个0变成16位0100001100011100。按8位分组01000011是十进制的67对应大写字母C00011100是十进制的28对应一个控制字符类似文件分隔符也不是可读文本。也就是说无论怎么补结果都是“一半可读、一半乱码”。这其实是很多新手解码失败的直接原因——他们按8位硬分得到乱码后就认为思路不对直接放弃了。但仔细观察会发现左侧补位后出现了C说明这种编码方向可能接近正确答案只是分组方式或者补位规则不对。更有可能的是这串字符本身就不是用来编码可读文本的而是另一种用途。2.3 换一种思路把它当成密钥种子而不是密文如果尝试了补位、分组、反向映射都得不到完整可读文本就应该立刻调整思路xooooxxoooxxx未必是“密文”很可能是“密钥”。在密码学的实际应用中密钥可以是任意字节序列为了记忆和传输方便人们会把密钥表示成字符串。比如有些题目会用key xooooxxoooxxx然后用这个key直接参与异或运算或者作为随机数生成器的种子。这里有一个很实在的经验拿到一段模糊的数据先别急着“解密”先判断它的角色。角色不同处理方式完全不同。它可能是密文也可能是密钥、IV、nonce、盐值甚至只是一个辅助参数。xooooxxoooxxx有13个字符放进一个异或算法里当密钥完全没有问题。在后文我会展示如何把它真正用到现代加密算法中让它变成一把合格的、可以用来加密真实文件的密钥。3. 把它变成AES-GCM的密钥KDF派生全流程3.1 直接拿字符串当密钥会踩到什么雷有人可能会想直接把bxooooxxoooxxx当成AES的密钥不就行了吗不行问题很大。长度不够AES-128需要16字节密钥AES-256需要32字节而xooooxxoooxxx只有13个字节。字符集太窄如果补齐到16字节比如重复填充密钥就只有x和o两种字符反复出现。这种密钥的熵非常低暴力破解只需要尝试所有可能的填充方式复杂度极低。没有防彩虹表手段真实系统中密钥通常由口令派生而来如果不对口令加盐、不迭代攻击者可以预先计算大量口令对应的密钥。所以正确的姿势是先通过密钥派生函数KDF把任意长度的口令变成固定长度的、高熵的密钥。这背后有严谨的密码学原理KDF通过一个不可逆的伪随机函数把口令的熵“摊开并放大”同时加入盐salt和迭代次数来抵抗预计算攻击。3.2 用PBKDF2从xooooxxoooxxx派生32字节密钥下面用Python演示一个可复现的流程。这里选用PBKDF2-HMAC-SHA256它是目前最广泛支持的KDF之一。import hashlib password bxooooxxoooxxx salt bctf-demo-salt-2024 iterations 600_000 key hashlib.pbkdf2_hmac( sha256, password, salt, iterations, dklen32 ) print(key.hex())运行后你会得到一串32字节的十六进制密钥。注意几个参数为什么这么定salt的作用是防止彩虹表和相同口令衍生出相同密钥。在真实系统里盐应该是随机生成的且每个用户、每个用途都不同。iterations是迭代次数越大攻击者暴力破解的代价越高。OWASP建议对PBKDF2-HMAC-SHA256至少使用60万次迭代。dklen32表示输出32字节正好对应AES-256。在实际项目中盐会随密文一起存储解密时从密文头部取出盐用相同的口令和盐重新派生密钥。不要每次都用同一个固定盐否则攻击者可以跨用户进行预计算。3.3 AES-GCM加密解密完整代码与运行效果有了合格密钥下一步就可以做真正的加密了。AES-GCM是目前最推荐的对称加密模式之一因为它同时提供机密性和完整性认证加密。如果只用AES-CBC还需要额外搭配HMAC比较麻烦GCM一个算法全部解决。下面是一个完整的加密解密函数import os from cryptography.hazmat.primitives.ciphers.aead import AESGCM def encrypt_aes_gcm(password: bytes, plaintext: bytes): salt os.urandom(16) key hashlib.pbkdf2_hmac( sha256, password, salt, 600_000, 32 ) aesgcm AESGCM(key) nonce os.urandom(12) ciphertext aesgcm.encrypt(nonce, plaintext, None) return salt nonce ciphertext def decrypt_aes_gcm(password: bytes, token: bytes): salt token[:16] nonce token[16:28] ciphertext token[28:] key hashlib.pbkdf2_hmac( sha256, password, salt, 600_000, 32 ) aesgcm AESGCM(key) plaintext aesgcm.decrypt(nonce, ciphertext, None) return plaintext # 演示 password bxooooxxoooxxx cipher encrypt_aes_gcm(password, bHello, this is a secret!) plain decrypt_aes_gcm(password, cipher) print(plain.decode())注意几个工程细节nonce是12字节随机数每次加密必须不同否则同一个密钥下两条密文的nonce重复攻击者可以直接还原明文。这里的associated_data我传了None。如果消息头里包含协议版本、时间戳等需要防篡改的字段应该把它们作为associated_data传进去GCM会额外校验这些字段。输出结构是“盐nonce密文”一起保存解密时先拆包。这种打包方式在真实文件加密工具里很常见。运行这段代码最终会打印原始的明文。这个完整流程说明一串毫无语义的xooooxxoooxxx经过KDF和AES-GCM之后完全能承担真实加密场景中的密钥职责。4. 软考和CTF里更常见的变体从双符号串到RSA数字4.1 软考RSA计算题二进制、十进制转换不能含糊热搜词里高频出现的“软考信息安全工程师密码学RSA计算题”实际上很多考生在第一步就栽跟头。RSA题目大多会给出p、q、e、c其中c有时以十进制形式给有时以十六进制形式给。如果题目改为二进制甚至用x/o这样的符号来代替0/1本质上考的还是进制转换和RSA公式。举个例子假设题目告诉你密文c的二进制表示是1000011000111那么c 4295。接下来如果私钥d和模数n都是已知的就直接算m c^d mod n。这个过程没有任何高深数学考的就是你能不能从各种编码形式里提取出正确的数字。xooooxxoooxxx在这里就是“二进制密文的伪装版”。顺手算一个小的RSA验证题。取两个小质数p67, q73那么n 4891。取e5计算d使得d*e ≡ 1 mod φ(n)φ(n) 66*72 4752。求d需要解5d ≡ 1 mod 4752即d 5^{-1} mod 4752 1901因为5*190195059505 mod 4752 1。现在假设明文m123加密c 123^5 mod 4891算出来是某个数。题目如果给的密文正是4295那么m 4295^1901 mod 4891应该还原出原来的明文。这类题在软考中反复出现关键就是别在进制转换上出错。4.2 CTF中的培根密码与摩斯码如何快速识别CTF密码学入门题里培根密码和摩斯码是双符号串的常客。培根密码固定用5个符号表示一个字母比如aaaaa表示Aaaaab表示Baaaba表示C以此类推。如果题目给你一个由x和o组成的长串且长度是5的倍数那就基本是培根密码直接把o映射成a、x映射成b5个一组查表即可。摩斯码的问题在于分隔符。如果题目保留了分隔符比如用空格区分字符、用斜杠区分单词那还是很好解的。怕就怕像xooooxxoooxxx这样的紧凑串分隔符被去掉了。这时只能尝试不同的切分方式比如“3个符号一组”或“按可见的分组边界”。一个技巧是如果串里有连续多个x或o先统计连续区段的长度往往能看出摩斯码的节奏。用xooooxxoooxxx举例可以切分为xooooxxoooxxx对应摩斯码就是.----..---...。参考国际摩斯码表.表示E----不是标准字符..是I---是O...是S。这种结果虽然没有形成完整句子但说明它确实可以沿这个方向继续挖只是可能要结合题目提示来切分。4.3 一道综合小练习把符号串变成RSA的c再解密把上面的知识串起来做一个综合练习。假设题目给出了这样一段信息公私钥参数n 4891e 5d 1901。收到密文c加密后的值用两个符号表示x表示1o表示0密文为xooooxxoooxxx。请解密。第一步把xooooxxoooxxx还原成二进制1000011000111。第二步转成十进制4295。第三步用RSA私钥解密m 4295^1901 mod 4891。由于直接算大数次幂比较费劲这里用Python验证c 4295 d 1901 n 4891 m pow(c, d, n) print(m)pow(c, d, n)是模幂运算结果就是明文。你会发现整个过程并不复杂但每一环都不能错。这个综合练习在CTF中非常典型外层是双符号编码内层是RSA计算。这种多层嵌套的题目如果不会拆层就会卡死在xooooxxoooxxx这一层。5. 踩过三次坑之后总结出的双符号串识别清单5.1 坑一拿到符号串就按8位补零出了乱码就放弃这是我见过最多的情况。很多人把xooooxxoooxxx映射成二进制后直接右补三个0然后按8位分组得到0x86 0x38看到0x86不是可读字符就断定“这思路不对”转而去试别的算法。实际上一开始就失败很正常因为13位本来就不是字节对齐的补零方向又要试几种分组方式也要试7位、4位甚至还有可能在后面有隐藏的字符没有包含进来。正确做法是写一个脚本把所有组合全部跑一遍。比如左右补0、补1、不补按4位、5位、7位、8位分组两种x/o映射方向总共也没多少种组合。下面是一个简单的枚举脚本骨架s xooooxxoooxxx for xv, ov in [(1, 0), (0, 1)]: bits .join(1 if ch x else 0 for ch in s) # 对应xv/ov映射这里以 x1,o0 为例 for pad_char in [0, 1]: for pad_len in range(1, 5): tmp bits pad_char * pad_len # 按8位分组转ascii ... # 输出可读ascii字符数找出得分最高的这种“枚举评分”的思路在CTF里特别实用。可读ascii字符数越多说明补位越可能正确。5.2 坑二分不清这串字符是密文、密钥还是辅助参数在收到一串异常数据时必须先问一个问题它在整个加密流程中扮演什么角色是密文是密钥是初始化向量还是盐值xooooxxoooxxx这个长度当密钥用太短但当口令用正合适当密文解不出可读文本但当种子用却很有潜力。很多CTF题故意把密钥伪装成密文把密文伪装成随机串就是为了考察这种辨别能力。判断依据主要看上下文提示。如果题目说“加密后的结果如下”那多半是密文如果题目说“密钥/种子如下”那就是密钥材料如果没有任何提示就把两条路都试一遍。我的习惯是先把它当成二进制编码尝试还原ASCII如果失败就立刻换到KDF路线把它当作口令。两条路都走过才能说对这个字符串有了基本判断。5.3 坑三滥用KDF或者干脆不派生就直接补字节有些人在实际代码里偷懒用password.ljust(32, b0)来凑AES密钥长度。这种做法的危险性在于xooooxxoooxxx的熵极低补一堆0也不会增加多少熵攻击者完全可以枚举所有可能的填充方式。而且ljust的补位方式是有规律的这种规律会被一些自动化密码分析工具直接识别。正确做法就是前面演示的KDF流程盐值随机、迭代次数达标。如果是在高安全场景直接上Argon2id会更稳妥。记住一句话别自己发明密钥扩展方案用标准KDF。5.4 可以复制到笔记里的检查清单现在我整理一份可以直接抄到笔记里的清单以后遇到双符号串就能按顺序排查字符集是否只有两种如果是进入第2步。长度是否为5的倍数是试培根密码。是否有分隔符是试摩斯码。将两种字符映射为0/1转十进制、十六进制、ASCII尝试左右补位和不同分组。如果明文不可读把它当成密钥种子用PBKDF2/HKDF派生密钥。如果出现RSA相关参数先转数字再走RSA运算。这张清单帮我解开了不少CTF题也帮朋友通过了软考下午的计算题值得收藏。6. 更进一步设计带认证的加密传输时要注意什么6.1 从xooooxxoooxxx到实际安全通信的四个设计要点如果你不只是做题而是要在实际系统里用xooooxxoooxxx这样的口令来加密网络传输数据那需要额外关注四个设计要点。第一密钥派生必须使用随机盐并且盐要随密文一起发送或存储。固定盐会让相同口令永远生成相同密钥攻击者可以预先计算并实施跨用户攻击。第二加密必须使用带认证的算法比如AES-GCM或ChaCha20-Poly1305。GCM本身内置认证不需要额外写HMAC。这里强调“认证”是因为攻击者如果只修改密文不触发解密失败协议就无法感知篡改。GCM的解密会直接抛异常这样应用层就能及时捕获。第三每个加密操作必须使用唯一的随机nonce。GCM的安全性严重依赖nonce的唯一性一旦nonce重复认证密钥和明文都可能被恢复。工程上通常用计数器或随机数但计数器需要持久化随机数生成要真随机。第四必须使用AAD附加认证数据绑定上下文信息。比如把协议版本、发送方ID、时间戳放进AAD这样即使密文被完整地从另一个会话中重放也能通过AAD校验失败识别出来。不过这只能检测重放不能阻止重放真正防重放还需要配合序列号机制。6.2 一个包含盐值、nonce和AAD的完整Python模块把上面的设计要点落成代码就是一个可以用于个人项目的最小安全模块。它和你输入的原始点无关直接生成可复用的代码import os import hashlib from cryptography.hazmat.primitives.ciphers.aead import AESGCM def derive_key(password: bytes, salt: bytes) - bytes: return hashlib.pbkdf2_hmac(sha256, password, salt, 600_000, 32) def secure_pack(password: bytes, plaintext: bytes, aad: bytes bv1): salt os.urandom(16) nonce os.urandom(12) key derive_key(password, salt) ciphertext AESGCM(key).encrypt(nonce, plaintext, aad) return salt nonce ciphertext def secure_unpack(password: bytes, token: bytes, aad: bytes bv1): salt, nonce, ciphertext token[:16], token[16:28], token[28:] key derive_key(password, salt) return AESGCM(key).decrypt(nonce, ciphertext, aad) # 使用示例 token secure_pack(bxooooxxoooxxx, bimportant data) print(token.hex())这个模块最大的优点是简单不依赖复杂的密钥管理系统适合个人脚本和中小工具。但它有两个注意点第一没有做nonce的严格唯一性管理如果并发量高需要引入计数器或UUID第二盐值没有做持久化策略每次加密都会重新生成盐所以同一明文加密两次会得到完全不同的密文这是正常的。6.3 为什么自己发明编码在密码学里是红线看到xooooxxoooxxx之后很容易让人产生“我也能发明一种自己的符号加密法”的冲动。把明文转成二进制再映射成x/o看起来很有创意但这在密码学上是绝对的禁区。现代密码学的安全性建立在“算法公开、密钥保密”的基础上也就是Kerckhoffs原则。如果算法本身依赖秘密的映射关系一旦攻击者猜到映射方式整个加密就崩塌了。xooooxxoooxxx这种二元符号只是编码层不是加密层。编码和加密的区别在于编码是为了数据表示方便没有密钥也能还原加密则是用密钥保护信息没有密钥无法恢复。把两者混为一谈是很多新手设计“自创密文”的根源。真正安全的做法是用标准的AES-GCM、ChaCha20等算法做加密用KDF做密钥扩展至于“xooooxxoooxxx”这种字符串最多是口令而不应该成为算法的一部分。明白了这一点才算真正理解这个案例的价值。我个人在实际操作中比较喜欢的做法是把这类奇怪符号串的解法固定成一个小工具脚本每当遇到类似题目先自动枚举所有分组和补位再输出可读性评分。这套思路帮我快速解决了不止一次CTF比赛里的双符号编码题。最后再分享一个小技巧当映射方向不确定时把x1,o0和x0,o1分别转成十进制记下来通常其中一个会落在常见ASCII或常见RSA参数范围里也就是32-126之间——那个数字往往就是突破口。