Понятно, спасибо, мы перебором жахнули login:randstr, про восстановление не подумали.

Эххх

ORIGINAL: 0xc84e20e52e25e5e8 COLLISION: 0xc84e20e52e25e5e8 STRING: W1<lmH2n

ORIGINAL: 0xc84e20e52e25e5e8 COLLISION: 0xc84e20e52e25e5e8 STRING: j1<lmH2n

ORIGINAL: 0xc84e20e52e25e5e8 COLLISION: 0xc84e20e52e25e5e8 STRING: X}<lmH2n

ORIGINAL: 0xc84e20e52e25e5e8 COLLISION: 0xc84e20e52e25e5e8 STRING: e}<lmH2n

ORIGINAL: 0xc84e20e52e25e5e8 COLLISION: 0xc84e20e52e25e5e8 STRING: XOplmH2n

ORIGINAL: 0xc84e20e52e25e5e8 COLLISION: 0xc84e20e52e25e5e8 STRING: eOplmH2n

там коллизий много) собственно, тут уже видно какие последние несколько символов у пароля ))

а тут передавались 8 файлов, в основном картинки. все были зашифрованы одной и той же RC4 гаммой (просто xor с рандомным потоком).

был файл key.dat и COPYING.txt.

COPYING.txt это стандартный файл типа README.txt или LICENSE.txt. он весил что-то около 35 кб. я его нашел в инете по размеру и имени, проксорил
encrypted_COPYTING.txt ^ plain_COPYTING.txt ^ key.dat и получил флаг, который был в key.dat

Не одной что-то не нашлось у нас, наверно где-то накосячили в коде.

Ааааа

Блин

Зачёт!

на веб и крипту за 400 хотелось бы почитать решение)

То, что мне сказали, там было просто переполнение буфера при чтения из файла (либо где-то еще)
функция хэша немного отличается вот от этого: www.stmc.edu.hk/~vincent/mplayer/libmpdemux/realrtsp/real.c

Не совсем понятно про переполнение. Что дает? Т.е. если в файле валидный ключ, то программа не отработает как нужно и нужно отдельно генерить данные из file.key и сдать на сервер для проверки?

там после функции хэша выполняется сравнение хэша с 0x010203..0e0f

О да, видел.

как я понял можно оверфловом поменять ее

тк она на стеке

но сам не тестил

Так там дальше на сервер отправка идёт, наверно для сравнения...

там мб та же переполняха

Вад взломали 😁

Это прикольно