您可能需要对进行解密的代码进行逆向工程。FindCrypt和用于PEiD的 Krypto Analyzer（“KANAL”）插件等工具可能会帮助您找到一个起点。

部分重复我在crypto.SE的评论中已经写过的内容......

您可以从该数据中了解到的一件事是已知的密文（十六进制表示中的 20 个字节）

AA969CF9657F77C597C8EAFF1594D59374E4977F

可以与（让我们称之为）OTP 异或

C2E2E8895F5058AFF8AF858C3BF9B0FC5A94E350

得到已知明文的十六进制编码的版本，http://jogos.meo.pt/这是

687474703A2F2F6A6F676F732E6D656F2E70742F

由于您一无所知，因此已经很难判断是否使用了算法或 OTP。是C2E2E8895F5058AFF8AF858C3BF9B0FC5A94E350OTP 还是 PRNG、散列或其他东西的结果？您无法通过简单地查看这条相当少的信息来判断。

因此，您唯一的机会是收集足够的样本，以便您识别特定模式。然而，这种模式很可能归结为一个不知道长度的随机 OTP 字符串。就个人而言，我无法仅通过观察就“感觉到”任何模式……但您可以检查明显的模式：基于 256 字节基础的键控 Vignere 等。

您的密文由 40 个十六进制数字组成，这些数字编码 20 个字节。您的明文长度为 20 个 ASCII 字符。因此，显而易见的假设是，密文是通过获取每个明文字符的 ASCII 码并与它相加（模 256）或异或相应的密钥字节来计算的。

此外，您的密文中的字节不是均匀分布在 0 到 255 的范围内，这表明您拥有的不是安全的流密码，而是更弱的东西。

实际上，取密文的每个字节并减去相应的明文字节产生：

42 22 28 89 2b 50 48 5b 28 61 7b 8c e7 27 70 24 46 74 23 50

或者，在 ASCII 中（\xHH用于有效 ASCII 范围之外的字符）：

B"(\x89+PH[(a{\x8C\xE7'p$Ft#P

这些额外的字符可能属于 ASCII 的一些 8 位扩展，例如Windows-1252，这将使“密钥流”看起来像这样：

B"(‰+PH[(a{Œç'p$Ft#P

这看起来很像某人可能通过在非英语键盘上混合“随机”键而产生的东西，因此“加密”可能仅包括将此键字符串逐字节添加到明文中至少是合理的。然而，没有更多的样本，就没有真正的方法来证实这一点。