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 << "!CheckSum(\"" << newfile.c_str() << "\", " << Fsize << ", " << Csum << ") || \n";
myfile.close();
}*/
//DEBUG: для генерации (CSUM) и размера файла (FSIZE) убрать комменты
//INFO: убрать в комменты когда нужна генерация, можно сделать и boolean потом
if (Csum != sum || flenght != Fsize)
{
return false;
}
//INFO: убрать в комменты когда нужна генерация, можно сделать и boolean потом
return true;
}
//Здесь если поставить в if (CheckSum("ALAudio.dll", 150548, 13108215)) {} даст true или false в сравнении файла
//Когда включен режим генерации, это просто передает только путь до файла
CheckSum("ALAudio.dll", 150548, 13108215)
Просто есть идея сделать так чтобы сверялись все файлы по списку из System папки lineage, потом Maps.Только размер файлов? Может лучше md5/crc32 сверять? Не быстро, но будет надежнее
Сверка файла по размеру не обязательно, просто если есть более быстрое и точное решение тогда можно crc32 или md5.А зачем простите сверять размер файла если есть сверка CRC ?
Но подделать crc32 возможно у файла в теории?конечно CRC, его на все ваши запросы с головой. Все остальное это мусор.
Конечно, как и любой другой метод на процессе загрузке пропатчить место где ты вызываешь сверку. Это вопрос 10-15 минут.Но подделать crc32 возможно у файла в теории?
Какие тогда варианты от подмены файлов?Конечно, как и любой другой метод на процессе загрузке пропатчить место где ты вызываешь сверку. Это вопрос 10-15 минут.
Накрывать ВМками файл и вшивать прямо в не очевидный файл. Допустим использовать VMProtect или Themida и так далее. Но если станет вопрос и заплатят деньги что бы это отключить, ну примерно 40-80 USD цена вопроса и по времени день или пол.Какие тогда варианты от подмены файлов?
Ну накрывать криптором не вариант, рано или поздно знающие снимут.Накрывать ВМками файл и вшивать прямо в не очевидный файл. Допустим использовать VMProtect или Themida и так далее. Но если станет вопрос и заплатят деньги что бы это отключить, ну примерно 40-80 USD цена вопроса и по времени день и или пол.
По сути идея вот в чем:Ну ты то инжектишь на ините процесса, это еще проще отследить. Запускаешь отладчик и все видно сразу, это явно не тот путь. Имхо.
Долго это сколько, какой размер файла и алгоритм?По сути идея вот в чем:
1. Во время запуска прочитать размер / crc32 / md5 что то 1 из этого, что будет лучше.
2. После сверки выдать результат true или false
Главная проблема в больших файлах, если много тогда проверяет все это долго.
В случае если проверять только папку System все делает быстро, если же Maps тогда намного дольше.
Если по клиенту lineage в папке maps: 16 мб одна из карт.Долго это сколько, какой размер файла и алгоритм?
По поводу crс32, юзаешь на свой страх и риск, во первых коллизии могут быть, а во вторых лучше уже юзай crc64,а в третьих crc не самый быстрый.
тьфу ты.... я думал ты имеешь дело с файлами по пару гигабайт.Если по клиенту lineage в папке maps: 16 мб одна из карт.
Просто много таких файлов, как бы ускорить проверку всего этого.
я тоже его уже пару лет юзаю, печалит когда юзают всякие crc или MD5Все же передумал сверять по размеру файла, но вместо crc32 взял xxHash это самый быстрый алгоритм на сегодня.
Оба варианта.Я чет не понял, это очередная попытка "защиты от подмены файлов", или проверка нужна для других целей?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?