这个 Base64 Look-alike 是什么？
我是解码技术的新手，昨天刚刚了解了 base64、sha-1、md5 和其他一些技术。
我一直在试图找出“orkut”蠕虫病毒到底包含什么。
在过去的几天里，我受到了许多 orkut 垃圾邮件发送者和黑客的攻击，他们发送给我们的 URL 很相似。
我不知道它包含什么信息，但我需要弄清楚。
问题在于以下文本：
Foo+bZGMiDsstRKVgpjhlfxMVpM=
lmKpr4+L6caaXii9iokloJ1A4xQ=
上面的编码似乎是 base64，但事实并非如此，因为每当我尝试使用在线 base64 解码器对其进行解码时，我都会得到原始输出，但它无法准确解码。
也许其他一些代码已与 Base64 混合。
有人可以帮我解码吗？
I am new to decoding techniques and have just learnt about base64, sha-1, md5 and a few others yesterday.
I have been trying to figure out what "orkut" worms actually contain.
I was attacked by many orkut spammers and hackers in the past few days, and there is a similarity in the URLs that they send to us.
I don't know what information it contains but I need to figure it out.
The problem lies in the following texts:
Foo+bZGMiDsstRKVgpjhlfxMVpM=
lmKpr4+L6caaXii9iokloJ1A4xQ=
The encoding above appears to be base64 but it is not, because whenever I try to decode it using online base64 decoders, I get raw output and it doesn't decode accurately.
Maybe some other code has been mixed with base64.
Can anyone please help me to decode it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
它是 orkut 蠕虫病毒的一部分。 此页面包含一些详细信息。 请注意，它提到了您在其中找到这些字符串的
JSHDF["Page.signature.raw"]变量。它是找到该字符串的页面的 SHA1 哈希值。 此页面显示了它的解码形式。
It's part of an orkut worm. This page has some details. Notice it mentions the
JSHDF["Page.signature.raw"]variable you're finding these strings in.It's a SHA1-hash of the page it was found on. This page shows the decoded form of it.
是什么让您认为解码不正确？ 通常，您会对二进制内容进行 Base64 或十六进制编码，以便可以将其作为文本进行传输。 您不会对文本进行 Base64 编码，因此对上面提供的字符串进行解码会得到 ASCII 官方文档，这并不奇怪。
What makes you think that the decoding is incorrect? Typically you'd base64 or hex encode binary content so that it can be transported as text. You wouldn't base64 encode text so it isn't surprising that decoding the strings you've provided above results in ASCII gobbledygook.
哈哈，如果这么简单的话，那就不值得破解了！ 你必须更加努力地尝试，而不仅仅是简单地解码一次。
Haha, if it was that easy, it would not be worth a hack! You have to try a lot harder than just simply decoding it once.
它们可能只是哈希值。
如果它们是散列，并且原始内容超过一定大小，则在算法上“反转”它们是不可能的，因为在达到一定的源数据大小之后，散列变成有损压缩函数。
They could be merely hashes.
If they are hashes, "reversing" them is algorithmically impossible if the original content is over a certian size, because after a certain source data size, hashing becomes a lossy compression function.
通常 Foo+whatever 是加盐哈希的结果。 用盐存储哈希结果是很常见的，并且盐可以以明文形式存储。 为了将盐与实际哈希值分开，通常使用+号。
使用Base64，使得哈希的二进制结果可以以文本形式存储。 您可以看出这些字符串的最后一部分可能是有效的 Base64，因为 Base64 内容始终是 4 的倍数。它为每 3 个字节的输入输出 4 个有效的 ASCII 字符。 它用“=”符号填充末尾。
因此，对于 Foo+bZGMiDsstRKVgpjhlfxMVpM=，这可能是接受某些输入（无论是某种消息还是其他什么）并应用 salt "Foo"，然后对结果进行哈希处理。 字符串值 bZGMiDsstRKVgpjhlfxMVpM= 可能是某些哈希函数的二进制结果。 在线 Base64 解码器 显示该值采用十六进制而不是 Base64，是
{ 6D 91 8C 88 3B 2C B5 12 95 82 98 E1 95 FC 4C 56 93 }。 是的，这不是 ASCII 文本。Base64、二进制、十六进制、十进制都是表示值的方式。 将
+之后的部分视为一个数字。 上述 136 位数字可能是 128 位哈希和 8 位 CRC< /a>，例如。 谁知道？ 我不知道为什么您会收到垃圾邮件，也不知道为什么这些垃圾邮件会附加这些字符串，但这可能是对字符串结构本质的一些了解。Often times Foo+whatever is the result of a salted hash. It is common to store hash results with salt, and the salt can be stored in the clear. To separate the salt from the actual hash value, a + sign is commonly used.
Base64 is used, so that the binary result of the hash can be stored in text. You can tell that the last part of those strings might be valid Base64 because Base64 content will always be a multiple of 4. It outputs 4 valid ASCII characters for every 3 bytes of input. It pads the end with "=" signs.
So, for
Foo+bZGMiDsstRKVgpjhlfxMVpM=, this may be the result of taking some input, be it a message of some sort, or whatever, and applying the salt "Foo", and then hashing the result. The string valuebZGMiDsstRKVgpjhlfxMVpM=likely is the binary result of some hash function. An online Base64 decoder shows that the value, in Hex, instead of Base64, is{ 6D 91 8C 88 3B 2C B5 12 95 82 98 E1 95 FC 4C 56 93 }. Yes, this is not ASCII text.Base64, binary, hexadecimal, decimal, are all ways of representing values. Think of the part after the
+as just a number. The above 136-bit number may be the result of a 128-bit hash, and an 8-bit CRC, for example. Who knows? I don't know why you're getting spammed, or why these spam messages have these strings attached to them, but this may be some insight into the nature of the structure of the strings.