Занимался проверкой файлов и возник вопрос как бы сделать это быстрее?

Код:


[CODE]
bool CheckSum(string newfile, int newfilesize, int newchecksum)
{
int flenght = newfilesize; //4696403; //FSIZE
int sum = newchecksum; //858273431; //CSUM

FILE* f;
if (!(f = fopen(newfile.c_str(), "rb")))
{
return false;
}

byte b;
unsigned int Csum = 0;
unsigned int Fsize = 0;

while (fread(&b, sizeof(byte), 1, f))
{
Fsize++;

Csum += b;
}

fclose(f);

//DEBUG: для генерации (CSUM) и размера файла (FSIZE) убрать комменты
/*ofstream myfile("CheckFiles_"+ newfile +".txt");
if (myfile.is_open())
{
myfile

Только размер файлов? Может лучше md5/crc32 сверять? Не быстро, но будет надежнее

Просто есть идея сделать так чтобы сверялись все файлы по списку из System папки lineage, потом Maps.

Но то что выше работает очень долго по такому алгоритму.

Возможно есть вариант проще с проверкой не только по размеру, но и по crc или md5 и быстрее чем сейчас?

А зачем простите сверять размер файла если есть сверка CRC ?

Если у исходного файла отличается хоть 1 байт, контрольная сумма измениться, не говоря о размере.

Сверка файла по размеру не обязательно, просто если есть более быстрое и точное решение тогда можно crc32 или md5.

Вся проблема именно в том что проверяет много файлов долго если есть большие.

конечно CRC, его на все ваши запросы с головой. Все остальное это мусор.

Но подделать crc32 возможно у файла в теории?

Конечно, как и любой другой метод на процессе загрузке пропатчить место где ты вызываешь сверку. Это вопрос 10-15 минут.

Какие тогда варианты от подмены файлов?

Накрывать ВМками файл и вшивать прямо в не очевидный файл. Допустим использовать VMProtect или Themida и так далее. Но если станет вопрос и заплатят деньги что бы это отключить, ну примерно 40-80 USD цена вопроса и по времени день или пол.

Ну накрывать криптором не вариант, рано или поздно знающие снимут.

Просто если вопрос в защите от "дилетантов", кто знает чем накрыто но может только инжектить в процесс.

Ну ты то инжектишь на ините процесса, это еще проще отследить. Запускаешь отладчик и все видно сразу, это явно не тот путь. Имхо.

По сути идея вот в чем:

1. Во время запуска прочитать размер / crc32 / md5 что то 1 из этого, что будет лучше.

2. После сверки выдать результат true или false

Главная проблема в больших файлах, если много тогда проверяет все это долго.

В случае если проверять только папку System все делает быстро, если же Maps тогда намного дольше.

CRC быстрее, размер файла бессмыслен, сверка по хешу нагрузочный

Долго это сколько, какой размер файла и алгоритм?

По поводу crс32, юзаешь на свой страх и риск, во первых коллизии могут быть, а во вторых лучше уже юзай crc64,а в третьих crc не самый быстрый.

Если по клиенту lineage в папке maps: 16 мб одна из карт.

Просто много таких файлов, как бы ускорить проверку всего этого.

Все же передумал сверять по размеру файла, но вместо crc32 взял xxHash это самый быстрый алгоритм на сегодня.

Прикрепил ниже форк xxHash и всего 2 варианта, вместо зависимостей в оригинальном репозитории.

Возможно кто то использует вместо crc32.

тьфу ты.... я думал ты имеешь дело с файлами по пару гигабайт.

я тоже его уже пару лет юзаю, печалит когда юзают всякие crc или MD5

Я чет не понял, это очередная попытка "защиты от подмены файлов", или проверка нужна для других целей?

Оба варианта.

Не стоит с этим сильно заморачиваться, так как если захотят - в любом случае ломанут. Будь то вырезать проверку из клиентской части или отправлять на сервер заведомо валидные данные.

По поводу ускорения - попробуй распараллелить.

именно поэтому "прихрдкоривание" никогда не должно быть в одном месте и не должно быть таким простым

на клиент можно поставить 3-4 растяжки - нечто вроде что делает ТС, код интерфейса (как минимум md5\примитивные привязки), флажок сервер>клиент, защиты типа сг\аа и всё это переплетено друг с другом (по возможности)

такая связка не то, что бы что-то исключит подмены, но создаст хороший клубок из зависимостей

Запихай файлы в экзешник и накрой какой-нибудь колбасой чтобы анпакать задолбались.

Можно еще чекать хэши только это когда реально необходимо, т.е. когда размер или время у файла поменялись.

А данные о ранее вычисленном хэше и корректном времени хранить в потоке файла.

Ну и для большей надежности для больших файлов к примеру можно какой-то кусок/куски из всего объема проверять каждый раз на тему изменения их хэша.

Именно поэтому и говорю - зачем париться? Лучше на стороне клиента сделать базовые вещи (проверки по хэшу файлов/рандомных блоков, шифрование файлов данных нестандартным ключом и т.п.). А уже остальные вещи хэндлить на стороне сервера. Например, если задача ограничить использование интерфейсов с автозаточкой и т.п. - сетапим троттлинг для пакетов, отвечающих за это.

С таким же успехом можно сделать свой бэк подменив банально в хостах адрес и валидировать это на стороне клиента как валидную дату и потом передавать управление на реальный адрес для подключения на порты.

Т.е. данный оратор шарит о чем говорит.

Может ты не мое сообщение прочитал? Никак не могу сопоставить твой написанный текст к своему. Зачем писать свой бэк, если можно обойти все это просто переходя сразу в блок с обработкой валидного респонса? Я и вел к тому, что эту часть в любом случае можно ломануть, так чего над ней сильно заморачиваться? Просто защиту от дурачка сделать и все.

По поводу подмены бэка не понял прикола. Просвети несведущего.

Ты серьезно ? Подымаешь локально допустим тот же веб, берем в учет что верификация на веб сервере. Предварительно получаем валидные ответы с "официального сервера", пишем аналог и хостим у себя, прописываем в хосты "оф. сервак". Этот вариант вообще для дуболомов, которые не уметь в реверс.

Профит ?

Хах) я таким образом пейн тим «хакал»

А при чем здесь это к тому, что я сказал? Я ни слова не обмолвил об обработке на стороне сервера кроме троттлинга запросов.

Под базовыми вещами я имел в виду базовые проверки client only. Без какого либо бэка, уж тем более веб.

Если говорить об эффективной защите, тогда нужно контролить частоту и порядок приема определенных пакетов - это против кастомных "читерских" UI в виде автоэнчанта и типа того. Против ботов, конечно, вряд ли что-то появится, так как даже какую-то нейронку можно обойти просто задавай случайную частоту и последовательность действий.

Других кейсов, в которых могут понадобиться подобные проверки, я не знаю.

Ну а если брать самую эффективную защиту - хостить файлы с данными, кроме текстур/моделей/анимаций/звуков/роликов, и таким образом получится что-то вроде лайтвэйт "твич" стрима Ну или вообще все данные хранить на сервере, а юзеру возвращать видеопоток

Вообщем, на профессиональность и правильность не претендую, лишь расписал как я считаю и чего придерживаюсь. Поэтому буду рад почитать опровержение, если оно будет.

Написал по алгоритму пока читал книгу по шифрации и прочее, здесь crc32.

В своей версии далеко ушел и там уже все на сокетах + xxHash.

Настройка простая переключаете на true конфиг в самом верху, закидываете в папку system от игры и генерируете файл.

Далее в исходниках заменяем кусок кода в самом низу и переключаем на false в верху.

После компиляции собираем и тестим меняя байты у файлов в System или Maps, только обязательно положите в папку System.

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