Вы не предоставили нам достаточно примеров, чтобы мы могли надежно угадать даже алфавит, использованный для его кодирования, и тем более, какую структуру он мог бы иметь.
Что я могу сказать,из трех приведенных вами выборочных значений:
В данных довольно много избыточности - сравните, например, width=<b>Iypc</b>O<b>y</b>s<b>K</b> и height=<b>Iypc</b>L<b>y</b>k<b>K</b> (и даже watermark=<b>I</b>S<b>p</b>QICA<b>K</b>хотя это может быть просто совпадением).Это говорит о том, что данные не являются ни случайными, ни надежно зашифрованными (что делает их случайными).
Алфавит содержит довольно широкий диапазон прописных и строчных букв, начиная с 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 для печати (hex 20 - 7E).В частности, самый распространенный печатный символ ASCII, пробел = hex 20, особенно распространен, особенно в строках watermark.
Строки в каждом URL-адресе больше похожи друг на друга, чемони напоминают соответствующие строки из других URL-адресов.(Но есть и сходства между URL-адресами: например, все декодированные значения watermark начинаются с ! = hex 21.)
Фактически,самый высокий пронумерованный символ, встречающийся в любой из строк, равен _ = hex 5F, а самый низкий (исключая перевод строки) - пробел = hex 20.Их разница равна шестнадцатеричной 3F = десятичной 63. Совпадение?Думаю, нет.Я предполагаю, что второй уровень кодирования похож на uuencoding : данные разбиты на 6-битные группы (как в Base64), и каждая группа отображается в символ ASCII, просто добавив hex 20 to it.
На самом деле, похоже, что второй слой может быть 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 &. ")@<`
Это выглядит хорошо:
Uudecoding и перекодирование данных (с использованием Perl unpack "u" и pack "u") создает исходную строку, за исключением того, что завершающие пробелы заменяются ` символами (что находится в пределах допустимого отклонения между кодировщиками).
Декодированные строки больше неASCII для печати, который предполагает, что мы могли бы быть ближе к реальным данным.
Строки watermark теперь представляют собой одиночные символы.В двух случаях из трех это префиксы соответствующих строк width и height.(В третьем случае, который выглядит немного по-другому, возможно, водяной знак был добавлен к другим значениям.)
Еще один фрагментзагадка - сравнивая строки идентификаторов и соответствующие числовые значения, которые вы даете в комментариях, мы видим, что:
- Все числа имеют шесть цифр.Первые две цифры каждого номера одинаковы.
- Все строки с uudecoded имеют шесть байтов.Первые два байта каждой строки совпадают.
Совпадение?Опять я думаю нет.Давайте посмотрим, что мы получим, если мы запишем числа в виде строк ASCII и XOR их с помощью строк с 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 - но XOR с помощью uudecoded ID дает соответствующий идентификатор в трех случаях из трех.
Еще подумайте: вы предоставили две разные строки идентификатора длязначение 405174: JiJQPjNfT0MtCg== и JikwPCpVXE9LCg==.Они декодируют до 0b 07 93 fe f8 cd и 25 07 0a d7 cb eb соответственно, а их XOR равно 2e 00 99 29 33 26.Два URL-адреса, с которых были получены эти строки идентификаторов, имеют декодированные водяные знаки 0e и 20 соответственно, что соответствует первому байту (и второй байт в любом случае одинаков).Откуда берутся различия в оставшихся четырех байтах, для меня все еще остается загадкой.