Я новичок в методах декодирования и вчера только что узнал о base64, sha-1, md5 и некоторых других.
Я пытался выяснить, что на самом деле содержат черви orkut.
За последние несколько дней на меня напали многие спамеры и хакеры orkut, и в URL-адресах, которые они нам отправляют, есть сходство.
Я не знаю, какую информацию он содержит, но мне нужно разобраться.
Проблема заключается в следующих текстах:
Foo+bZGMiDsstRKVgpjhlfxMVpM=
lmKpr4+L6caaXii9iokloJ1A4xQ=
Приведенная выше кодировка выглядит как base64, но это не так, потому что всякий раз, когда я пытаюсь декодировать ее с помощью онлайн-декодеров base64, я получаю необработанный вывод, и он не декодируется точно.
Возможно, какой-то другой код был смешан с base64.
Может ли кто-нибудь помочь мне его расшифровать?





Ха-ха, если бы это было так просто, не стоило бы взламывать! Вы должны постараться намного больше, чем просто расшифровать его один раз.
Это могут быть просто хеши.
Если они являются хешами, их «реверсирование» алгоритмически невозможно, если исходный контент превышает определенный размер, потому что после определенного размера исходных данных хеширование становится функцией сжатия с потерями.
The encoding above appears to be base64 but it is not, because when-ever I try to decode it using online base64 decoders I get raw output and it doesn't decode accurately.
С чего вы взяли, что расшифровка неправильная? Обычно двоичный контент кодируется в формате base64 или hex, чтобы его можно было транспортировать как текст. Вы бы не стали кодировать текст base64, поэтому неудивительно, что декодирование строк, которые вы предоставили выше, приводит к бреду ASCII.
Это часть червя orkut. Эта страница имеет некоторые подробности. Обратите внимание, что здесь упоминается переменная JSHDF["Page.signature.raw"], в которой вы находите эти строки.
Это SHA1-хеш страницы, на которой он был найден. Эта страница показывает его декодированную форму.
Часто Foo + то, что является результатом соленого хеша. Обычно хеш-результаты хранят с солью, и соль можно хранить в открытом виде. Чтобы отделить соль от фактического хеш-значения, обычно используется знак +.
Используется Base64, чтобы двоичный результат хеширования можно было сохранить в текстовом виде. Вы можете сказать, что последняя часть этих строк может быть допустимой Base64, потому что содержимое Base64 всегда будет кратным 4. Он выводит 4 действительных символа ASCII на каждые 3 байта ввода. Он дополняет конец знаком "=".
Итак, для Foo+bZGMiDsstRKVgpjhlfxMVpM= это может быть результатом ввода некоторого ввода, будь то какое-то сообщение или что-то еще, и применения соль «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. Кто знает? Я не знаю, почему вы получаете спам или почему к этим спам-сообщениям прикреплены эти строки, но это может быть некоторым пониманием природы структуры строк.
Н-Д - напишите свои ответы как комментарии к тем ответам, на которые вы отвечали.