我有基于网络的系统,它使用加密的GET参数。我需要弄清楚使用什么加密并创建一个PHP函数来重新创建它。有什么想法吗?
示例网址:
...&watermark=ISpQICAK&width=IypcOysK&height=IypcLykK&...
答案 0 :(得分:5)
您还没有为我们提供足够的样本数据来可靠地猜测用于编码的字母表,更不用说它可能具有的结构。
我可以告诉您,您提供的三个样本值是:
数据中存在大量冗余 - 比较例如width=IypcOysK
和height=IypcLykK
(甚至watermark=ISpQICAK
,尽管这可能只是巧合)。这表明数据既不是随机加密也不是安全加密(这会使其看起来随机)。
字母表包含相当广泛的大写和小写字母,从A
到S
以及从c
到y
。假设字母表由连续的字母范围组成,这意味着42到52个可能的字母之间的调色板。当然,我们无法从样本中确定是否也可以使用其他字符,因此我们甚至无法完全排除Base64。
这是不 PHP的base_convert
函数的输出,因为我首先猜测它可能是:该函数只处理最多36个的基数,并且不输出大写字母。
然而,这几乎就是全部。这将有助于查看更多的数据样本,最好是与它们对应的明文值。
修改:您在评论中提供的id
参数在Base64中肯定是。除了独特的尾随=
符号外,它们都会解码为九个可打印ASCII字符的简单字符串,后跟换行符(十六进制0A
):
_Base64___________Hex____________________________ASCII_____
JiJQPjNfT0MtCg== 26 22 50 3e 33 5f 4f 43 2d 0a &"P>3_OC-.
JikwPClUPENICg== 26 29 30 3c 29 54 3c 43 48 0a &)0<)T<CH.
(我已在上面的ASCII列中用.
替换了不可打印的字符。)假设所有其他参数也是Base64,让我们看看它们解码的内容:
_Base64___Hex________________ASCII_
ISpQICAK 21 2a 50 20 20 0a !*P .
IypcOysK 23 2a 5c 3b 2b 0a #*\;+.
IypcLykK 23 2a 5c 2f 29 0a #*\/).
ISNAICAK 21 23 40 20 20 0a !#@ .
IyNAPjIK 23 23 40 3e 32 0a ##@>2.
IyNAKjAK 23 23 40 2a 30 0a ##@*0.
ISggICAK 21 28 20 20 20 0a !( .
IikwICAK 22 29 30 20 20 0a ")0 .
IilAPCAK 22 29 40 3c 20 0a ")@< .
因此肯定会涉及另一个编码层,但我们已经可以看到一些模式:
所有解码值都包含一定数量的可打印ASCII字符,后跟一个尾随换行符。这不是巧合。
大多数字符位于可打印ASCII范围的低端(十六进制20
- 7E
)。特别是,最低的可打印ASCII字符space = hex 20
特别常见,特别是在watermark
字符串中。
每个网址中的字符串彼此相似,而不是类似于其他网址的相应字符串。 (但URL之间也存在相似之处:例如,所有已解码的watermark
值都以!
= hex 21
开头。)
实际上,任何字符串中出现的编号最高的字符是_
= hex 5F
,而最低(不包括换行符)是space = hex 20
。它们的区别是十六进制3F
=十进制63.巧合?我想不是。我猜第二个编码层类似于uuencoding:数据被分成6位组(如Base64中所示),每个组只需添加十六进制{{1}即可映射到ASCII字符对它来说。
实际上,看起来第二层可能是 uuencoding:每个字符串的第一个字节都有正确的值为uuencode长度指示符。如果我们尝试解码它们,让我们看看我们得到了什么:
20
这看起来不错:
对数据进行Uudecoding和重新编码(使用Perl的_Base64___________UUEnc______Hex________________ASCII___re-UUE____
JiJQPjNfT0MtCg== &"P>3_OC- 0b 07 93 fe f8 cd ...... &"P>3_OC-
JikwPClUPENICg== &)0<)T<CH 25 07 09 d1 c8 e8 %..... &)0<)T<CH
_Base64___UUEnc__Hex_______ASC__re-UUE____
ISpQICAK !*P 2b + !*P``
IypcOysK #*\;+ 2b c6 cb +.. #*\;+
IypcLykK #*\/) 2b c3 c9 +.. #*\/)
ISNAICAK !#@ 0e . !#@``
IyNAPjIK ##@>2 0e 07 92 ... ##@>2
IyNAKjAK ##@*0 0e 02 90 ... ##@*0
ISggICAK !( 20 !(```
IikwICAK ")0 25 00 %. ")0``
IilAPCAK ")@< 26 07 &. ")@<`
和unpack "u"
)会产生原始字符串,但尾随空格被替换为pack "u"
个字符(属于编码器之间可接受的差异)。
解码后的字符串不再是可打印的ASCII,这表示我们可能更接近真实数据。
`
字符串现在是单个字符。在三种情况中的两种情况下,它们是相应的watermark
和width
字符串的前缀。 (在第三种情况下,水印可能已经添加到其他值。)
另一个难题 - 比较您在评论中提供的ID字符串和相应的数值,我们看到:
重合?再说一次,我想不是。让我们看看如果我们把数字写成ASCII字符串,并用uudecoded字符串对它们进行异或,我们得到了什么:
height
这个_Num_____ASCII_hex___________UUDecoded_ID________XOR______________
406747 34 30 36 37 34 37 25 07 09 d1 c8 e8 11 37 3f e6 fc df
405174 34 30 35 31 37 34 25 07 0a d7 cb eb 11 37 3f e6 fc df
405273 34 30 35 32 37 33 25 07 0a d4 cb ec 11 37 3f e6 fc df
字符串是什么?我不知道 - 它几乎不是可打印的ASCII - 但是用它对Xudeing uudecoded ID产生三个中的三个中相应的ID号。
更多要考虑:您为值11 37 3f e6 fc df
提供了两个不同的ID字符串:405174
和JiJQPjNfT0MtCg==
。这些分别解码为JikwPCpVXE9LCg==
和0b 07 93 fe f8 cd
,其XOR为25 07 0a d7 cb eb
。这些ID字符串来自的两个URL分别具有2e 00 99 29 33 26
和0e
的解码水印,它们占第一个字节(并且两个中的第二个字节相同)。其余四个字节的差异来自于我仍然是个谜。
答案 1 :(得分:0)
那将是困难的。即使您找到加密方法和密钥,原始数据也可能会被盐析,并且每条记录的盐可能会有所不同。
这就是加密的重点。