Что это за похожий Base64?

Question

Я новичок в методах декодирования и только что узнал о base64, sha-1, md5 и нескольких других вчера.

Я пытался выяснить, что на самом деле содержат черви "orkut".

В последние несколько дней на меня напали многие спаммеры и хакеры orkut, и есть сходство в URL-адресах, которые они нам присылают.

Я не знаю, какую информацию она содержит, но мне нужно ее выяснить.

Проблема заключается в следующих текстах:

Foo+bZGMiDsstRKVgpjhlfxMVpM=
lmKpr4+L6caaXii9iokloJ1A4xQ=

Вышеприведенная кодировка выглядит как base64, но это не так, потому что всякий раз, когда я пытаюсь декодировать ее с помощью онлайн-декодеров base64, я получаю необработанный вывод, и он не декодируется точно.

Возможно, какой-то другой код был смешан с base64.

Может кто-нибудь помочь мне расшифровать его?

Answer 1

Это часть червя orkut. Эта страница содержит некоторые детали. Обратите внимание, что упоминается переменная JSHDF["Page.signature.raw"], в которой вы находите эти строки.

Это SHA1-хэш страницы, на которой он был найден. Эта страница показывает его расшифрованную форму.

Answer 2

Вышеприведенная кодировка выглядит как base64, но это не так, потому что когда-либо я пытаюсь декодировать при использовании онлайн-декодеров base64 я получаю необработанный вывод, и он точно не декодируется.

С чего вы взяли, что декодирование неверно? Обычно вы используете base64 или hex кодирование двоичного содержимого, чтобы его можно было транспортировать как текст. Вы не будете кодировать текст с помощью base64, поэтому неудивительно, что декодирование указанных выше строк приводит к ASCII gobbledygook.

Answer 3

Это могут быть просто хеши.

Если они являются хешами, то их «обратное» преобразование алгоритмически невозможно, если исходный контент превышает определенный размер, потому что после определенного размера исходных данных хеширование становится функцией сжатия с потерями.

Answer 4

Ха-ха, если бы это было так просто, это не стоило бы взломать! Вы должны попробовать намного больше, чем просто один раз расшифровать его.

Answer 5

Часто Foo + независимо от результата соленого хэша. Обычно результат хеширования хранится в соли, а соль может храниться в открытом виде. Чтобы отделить соль от фактического значения хеша, обычно используется знак +.

Base64 используется, так что двоичный результат хеша может быть сохранен в тексте. Вы можете сказать, что последняя часть этих строк может быть допустимой Base64, потому что содержимое Base64 всегда будет кратно 4. Он выводит 4 действительных символа ASCII на каждые 3 байта ввода. Он дополняет конец знаками "=".

Итак, для 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 , например. Кто знает? Я не знаю, почему вы получаете спам, или почему к этим спам-сообщениям прикреплены эти строки, но это может быть некоторым пониманием природы структуры строк.