逆向工程 base64 变体
我正在处理一个奇怪的 base64 变体。我需要为其编写解码器，但我一直坚持逆向工程。它与原始的 Base64 区别不大。看起来好像有一些填充或其他东西。
以下是一些已知的编码字符串：
- YQ== - a
- YQA= - aa
- YQBh - aaa
- YQBhAA== - aaaa
- YQBhAGE= - aaaaa
- YQBhAGEA - aaaaaa
- YQBhAGEAYQ== - aaaaaaa
- YQBhAGEAYQA= - aaaaaaaa
- YQBhAGEAYQBh - aaaaaaaaa
I'm dealing with a strange base64 variation. I need to write decoder for it but I've stuck with reverse engineering. It differs not so much from original base64. It looks like there's something with bit padding or smth.
Here are some known encoded strings:
- YQ== - a
- YQA= - aa
- YQBh - aaa
- YQBhAA== - aaaa
- YQBhAGE= - aaaaa
- YQBhAGEA - aaaaaa
- YQBhAGEAYQ== - aaaaaaa
- YQBhAGEAYQA= - aaaaaaaa
- YQBhAGEAYQBh - aaaaaaaaa
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
冒着听起来很愚蠢的风险，我敢打赌上面的编码是一个有缺陷的实现，它将 chars 和 wchar_ts 混合在一起。
使用“常规”base64，字符串“YQA=”解码为“a\x00”并且
'YQBhAGEAYQA=' 解码为 'a\x00a\x00a\x00a\x00'。
您能否再提供一些例子，以便我们取消这个理论？
At the risk of sounding stupid, my bet would be that the encoding above is a buggy implementation that is mixing chars and wchar_ts together.
Using "regular" base64, the string 'YQA=' decodes to 'a\x00' and
the 'YQBhAGEAYQA=' decodes to 'a\x00a\x00a\x00a\x00'.
Any chance you could supply a few more examples so we can cancel this theory?