cin wrote:...теперь ссылки на фильм получаются, но декодирование их из uppod2 происходит с ошибкой. То в случайное место ссылки на фильм последовательность 172 вставит (но это хорошо если так, можно руками вырезать), а то последовательность каких-то знаков вставляет вместо какого-либо символа. Пожалуйста, помогите победить декодирование uppod2.
Поправил подкаст в первом сообщении. Спасибо большое. Обычно, для затруднения получения ссылок, действительно, вносят косяки в зашифрованные ссылки. Именно в зашифрованные. Которые, при раскодировании тоже получаются неправильными.
Вот там, если заметили, есть функция EncodeUppod2(char sData). Она нужна для ЗАкодирования. Т.е. только для отладки.
Я делал так.
Через браузер с запущенным
Charles смотрим в нём полученную ссылку при просмотре видео. Потом в HMS при отладке скрипта видим, что у нас получается битая ссылка. Как вы заметили, в основном это цифры "172" в любом месте.
В отладчике останавливаемся, где мы получаем закодированную ссылку и смотрим:
Например, у нас закодированная ссылка такая, записываем её где-нибудь в комментариях:
//2iob3gRLvaUMkjnMtgEM0c9VkHm=2xmLkasB05wbv13lkgD1tQ3VtxyZyjAVydkHOgZbygDNtQENtQ3Wtgw4vc9h0SJ52xWM3NJR3QnLUah435wVUfyR2aZM054Bki7mtQ3NUSbNtgEbv5k8GDrr
Из неё у нас получилась нерабочая ссылка:
http://f-f2-01-orpf.kinogo.net/78d83170 ... a-2014.flv
в начале - разное имя домена получается, это, скорее всего, dns балансер. Это нормально. Но в Charles мы получаем почти такую-же ссылку, только без этих 172 в конце.
Пробуем в нашей полученной в скрипте подкаста ссылке изменить её только часть, и проверить на доступность файла. Т.е. убрать эти "172". Ссылка получается рабочей.
Получается вот такой:
http://f-f2-01-orpf.kinogo.net/78d83170 ... a-2014.flv
В отладчике скрипта запускаем функцию обратного
закодирования правильной ссылки и смотрим что получается, записываем под уже комментом ранее закодированной ссылки.
У нас получается такой код:
//2iob3gRLvaUMkjnMtgEM0c9VkHm=2xmLkasB05wbv13lkgD1tQ3VtxyZyjAVydkHOgZbygDNtQENtQ3Wtgw4vc9h0SJ52xWM3NJR3QnLUah435wVUfyR2aZM054Bki7m USbNtgEbv5k8GDrr
просто сравниваем их и видим, что в кодированной ссылке есть четыре лишних символа "tQ3N"
Убеждаемся, для надежности, ещё на паре примеров ссылок и видим, что четыре лишних символа всегда одни и те же, но в разных местах.
Теперь действительно, достаточно эти символы удалять перед раскодировкой и всё будет норм.
Как-раз из-за того, что в раскодировке есть base64, лишние символы могут давать не только значение "172", но и другие - в зависимости от места, где они торчат (смещения).
Подобная фигня используется и на других сайтах.