Помогите Защита ресурспака

Тоже нужно

 

Недостатки слишком большие

Как такое можно сделать?

 

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

 

Мне не нужна очень сильная защиты

Не все могут так легко снять архив

 

Всем и не нужно, один снимет и на весь интернет сольет) Ты этим только интерес к ресурспаку повысишь, так бы просто мимо прошли и все.

 

Это значит что я хочу повысить интерес к ресурспаку? Окей!

Не уверен что будет на столько известный сервер, что кто-то захочет снимать защиту с ресурспака и тем более ещё делиться с другими. Я уже писал что мне не нужна сильная защита. Мне достаточна минимальная
Что-бы нельзя было просто так сразу всё взломать

То есть что бы время взлома с одной минуты стало, как пример, один час

 

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

1. В первую очередь ресурспак - zip файл. У zip файла есть последние 4 байт указывающие на его конец - 0x06054b50 (EOCD - End of central directory record). В java (и майнкрафт думаю очевидно) есть стандартный парсер zip файлов - класс ZipFile, который ищет эту сигнутуру С КОНЦА, а не с начала файла. К сожалению 7zip и другие архиваторы посчитали иначе. В исходнике класса ZipFile:

Код:

// Now scan the block backwards for END header signature
                for (int i = buf.length - ENDHDR; i >= 0; i--) {
                    if (buf[i+0] == (byte)'P'    &&
                        buf[i+1] == (byte)'K'    &&
                        buf[i+2] == (byte)'\005' &&
                        buf[i+3] == (byte)'\006') {
                        // Found ENDSIG header
                        byte[] endbuf = Arrays.copyOfRange(buf, i, i + ENDHDR);

Исходя из этого, можно в начало файла вставить байты 0x50, 0x4b, 0x05, 0x06 и ничего страшного не произойдёт:



Оригинальный исходник: https://github.com/erxson/PackProtect/tree/master

2. Есть ещё один прикол, он уже много где использовался и давно публичный: к концу названия каждого файла добавлять слеш / в конце. Тем самым архиватор будет думать, что файл это папка и не давать её содержимое:


Также майнкрафт нормальное воспринимает. Оригинальный исходник: https://yougame.biz/threads/331152 (noad, не реклама)
3. Сжатие архива. Как я вижу вы это уже здесь обсуждали, так что объяснять не буду

 

Спасибо, есть готовые программы для добавления данной защиты в ресурспак?

Этот способ тоже очень любопытный

 

Это лишь малая часть, там ещё много всего можно сделать

Держи
https://workupload.com/file/X9Y4fvK9DS8
Запускать используя Java 17, использование:

Код:

java -jar rp_packer.jar "C:\game\resourcepack.zip" folders_meme,eocd

folders_meme - та штука, что превращает файлы в "папки"
eocd - ломает архив

 

Большое спасибо, попробую

А какие ещё есть способы?

 

Да на самом деле дофига ещё способов. Готовая программа в самом конце сообщения


ZIP файл состоит из трех частей:

1. Описание и данные файлов (структура LocalFileHeader)
2. Центральный каталог (структура CentralDirectoryFileHeader)
3. Конец центрального каталога (End of central directory record (EOCD))

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

Код:

struct LocalFileHeader
{
    // Обязательная сигнатура, равна 0x04034b50
    uint32_t signature;
    // Минимальная версия для распаковки
    uint16_t versionToExtract;
    // Битовый флаг
    uint16_t generalPurposeBitFlag;
    // Метод сжатия (0 - без сжатия, 8 - deflate)
    uint16_t compressionMethod;
    // Время модификации файла
    uint16_t modificationTime;
    // Дата модификации файла
    uint16_t modificationDate;
    // Контрольная сумма
    uint32_t crc32;
    // Сжатый размер
    uint32_t compressedSize;
    // Несжатый размер
    uint32_t uncompressedSize;
    // Длина название файла
    uint16_t filenameLength;
    // Длина поля с дополнительными данными
    uint16_t extraFieldLength;
    // Название файла (размером filenameLength)
    uint8_t *filename;
    // Дополнительные данные (размером extraFieldLength)
    uint8_t *extraField;
};

Вот ты заполнил её данными и записал. А теперь смотри прикол, видишь странное число 0x04034b50 - сигнатура. Это число нужно для чтения.
Оригинал: https://blog2k.ru/archives/3391

Давай теперь мыслить как читалка zip архивов. Вот ты начинаешь читать файл с начала: увидел 0x04034b50. Понял, что это LocalFileHeader и прочитал данные о файле. Теперь у тебя есть его размер, имя и т.д.

Так вот к чему я. Для того, чтобы проверять сломан архив или нет придумали CRC32 или же Контрольная сумма. Когда архив создавался он высчитал эту контрольную сумму для файла и записал в эту структуру. Теперь читалка будет проверять: она самостоятельно высчитает CRC32 файла и сравнит с тем, что ты ей записал в структуре. Если они совпадают - файл не поломан.

Понял к чему я клоню? Что будет, если после того, как архив создался, я найду по сигнатуре 0x04034b50 каждую структуру LocalFileHeader и в crc32 запишу 0? То есть читалка будет сравнивать 0 с настоящим crc32 и будет тебе писать, что файл поломан.

Предлагаю так и сделать. Для этого в джаве есть класс ByteBuffer. Проходимся по каждому байту:

Код:

ByteBuffer buf = ByteBuffer.wrap(result);
buf.order(ByteOrder.LITTLE_ENDIAN);

int i = 0;
while (i < result.length - 4) {
    i++;
}

Считываем int (в той структуре что ты видел ранее было написано uint32_t , это в c++ альтернативное имя для unsigned int, unsigned означает, что число всегда > 0), чтобы определить сигнатуру:

Код:

int sig = buf.getInt(i);

Сравниваем с сигнатурой LocalFileHeader:

Код:

if (sig == 0x04034b50) { // LOC_SIG

}

Если нашли - записываем рандомный crc32 в структуру:

Код:

buf.putInt(i + 14, fakeCRC);

затем пропускаем эту структуру и идём дальше:

Код:

i += 30;

Спойлер: Откуда я взял числа 14 и 30

Я тебе дал структуру LocalFileHeader из языка C++. Сейчас проще забыть о ней и посмотреть на тоже самое, только в виде таблицы:

Оригинал: https://en.wikipedia.org/wiki/ZIP_(file_format)

Оффсет - это сколько байтов нужно пропустить от начала структуры. То есть мы нашли сигнатуру и её начало хранится у нас в переменной i. (Можно называть эту переменную курсором, просто мне было легче i)
Видишь CRC32 - оффсет 14. То есть 14 байт с начала структуры. Далее bytes - 4 - это int

Надеюсь объяснил понятно


Кароче результат:

Майнкрафт всё также читает правильно

Готовая программа: https://workupload.com/file/Z9Fhny9Zwcn
Запуск такой же, только теперь вместо folders_meme,eocd напиши fakecrc и сам попробуй архиватором достать файл из защищённого архива. Ну и для максимальной защиты ставь: folders_meme,eocd,fakecrc

 

Можно "растянуть" музыку
Для запуска этой музыки нужно запускать её с pitch "2" То есть в два раза быстрее. Или сжать её и запускать с pitch "0,1"

 

Спасибо, буду смотреть

Я понял как это работает. Очень необычный способ

В этом случае будут потери исходного качества

 

Способ прикольный. Жаль что сработает только на абсолютного дурачка. Так же просто написать мод, который перепакует распарсеный ресурспак назад в целостный архив.

 

Да

Не все могут создать мод. Те, кто не могут, попадают под понятие "абсолютного дурачка" ?

 

А не нужно всех. Достаточно одного чувачка, который напишет такое и зальет на modrinch/curseforge. И вся такая защита ресурспака пойдет прахом.

 

Спасибо, спасибо!

 

Почему "один чувак" должен что-то писать и ещё заливать?
Вы предлагаете не создавать какую либо защиту?

 

По самым разным причинам. Кто-то может захотеть выкачать ваш ресурспак во что бы то ни стало и как итог - поделиться и им, и инструментом для его скачивания. Поделиться успехами труда - естественно для человека.

Важно понимать устойчивости защиты вместо того чтобы жить в иллюзии абсолютной защищённости:
1) Все что уходит конечному рользователю может быть взломано и будет взломано при желании
2) Т.к. от ресурс паков часто требуется совместимость с ванильными клиентами (без модлоадеров), то рксурс пак по определению должен быть распарсен ванильным клиентом. Т.е. у взломщика уже на руках весь контракт парсинга ресурспаков и тривиально реализовать его сохранение назад в архив.
3) Даже если вы реализуете собственный формат паков и модифицирует клиент для его парсинга - все ещё способно обратить алгоритм вспять и получить желанный архив. Это сложнее, но тем не менее возможно

Я думаю что вложения защиту ресурс пака не оправдывают себя и дешевле вовсе отказаться от нее т.к. надёжно реализовать ее для ванильных клиентов невозможно.

 

Я не спорю что любая защита может быть сломана. Мне было интересно как реализуется защита ресурс пака. К примеру я знаю как защитить текстуры и модели. Было интересно кто что знает и какие способы защиты доступны. Видел что один разработчик продавал программу для защиты ресурспака. так что решил спросить на сколько это оправданно и реально ли защитить к примеру .ogg (звуковой) файл

Вы предлагаете отказаться от защиты, это интересное мнение
Но мне было интересно возможно ли без модов как-то защитить или это не имеет целесообразности