我有使用加密 GET 参数的基于 Web 的系统。我需要弄清楚使用了什么加密并创建一个 PHP 函数来重新创建它。有任何想法吗?
示例网址:
...&watermark=ISpQICAK&width=IypcOysK&height=IypcLykK&...
我有使用加密 GET 参数的基于 Web 的系统。我需要弄清楚使用了什么加密并创建一个 PHP 函数来重新创建它。有任何想法吗?
示例网址:
...&watermark=ISpQICAK&width=IypcOysK&height=IypcLykK&...
您没有提供几乎足够的样本数据让我们可靠地猜测用于编码它的字母表,更不用说它可能具有的结构了。
从您提供的三个示例值中,我可以看出:
数据中有很多冗余——比较例如和(甚至,尽管这可能只是巧合)。这表明数据既不是随机的,也不是安全加密的(这会使它看起来是随机的)。width=IypcOysK
height=IypcLykK
watermark=ISpQICAK
字母表包含相当广泛的大写和小写字母,从A
toS
和 from c
to y
。假设字母表由连续的字母范围组成,这意味着调色板包含 42 到 52 个可能的字母。当然,我们无法从样本中确定是否还会使用其他字符,因此我们甚至不能完全排除 Base64。
这不是PHPbase_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 列中用 a 替换了不可打印的字符。)假设所有其他参数也是 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 = hex20
尤其常见,尤其是在watermark
字符串中。
每个 URL 中的字符串彼此相似,而不是与其他 URL 中的相应字符串相似。(但 URL 之间也有相似之处:例如,所有解码的watermark
值都以!
= hex开头21
。)
事实上,出现在任何字符串中的编号最高的字符是_
= hex 5F
,而最低的(不包括换行符)是 space = hex 20
。它们的区别是十六进制3F
= 十进制 63。巧合?我想不是。我猜第二个编码层类似于uuencoding:数据被分成 6 位组(如在 Base64 中),每个组只需添加十六进制就映射到一个 ASCII 字符20
。
事实上,看起来第二层可能是uuencoding:每个字符串的第一个字节都有正确的值作为 uuencode 长度指示符。让我们看看如果我们尝试解码它们会得到什么:
_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 &. ")@<`
这看起来不错:
对数据进行解码和重新编码(使用 Perlunpack "u"
和pack "u"
)生成原始字符串,除了尾随空格被替换为`
字符(这在编码器之间可接受的变化范围内)。
解码后的字符串不再是可打印的 ASCII,这表明我们可能更接近真实数据。
watermark
字符串现在是单个字符。在三分之二的情况下,它们是对应的width
和height
字符串的前缀。(在第三种情况下,看起来有点不同,水印可能已添加到其他值中。)
另一个难题 - 比较您在评论中提供的 ID 字符串和相应的数值,我们看到:
巧合?再说一次,我认为不是。让我们看看如果我们将数字写成 ASCII 字符串,然后用 uudecoded 字符串对它们进行异或运算,我们会得到什么:
_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
这个11 37 3f e6 fc df
字符串是什么?我不知道——它大多不是可打印的 ASCII——但是用它对 uudecoded ID 进行异或会在三种情况下的三种情况下产生相应的 ID 号。
更多需要考虑:您为值405174
:JiJQPjNfT0MtCg==
和. 提供了两个不同的 ID 字符串JikwPCpVXE9LCg==
。这些分别解码为0b 07 93 fe f8 cd
和25 07 0a d7 cb eb
,它们的异或为2e 00 99 29 33 26
。这些 ID 字符串来自的两个 URL 分别解码了0e
和的水印20
,这占了第一个字节(无论如何,第二个字节在两者中都是相同的)。其余四个字节的差异来自哪里对我来说仍然是个谜。
那会很困难。即使您找到了加密方法和密钥,原始数据也可能是加盐的,并且每个记录的加盐可能会有所不同。
这就是加密的重点。