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

[tnt15x15]

Защита от школьников

Тоже нужно

 

[minecraft 1.8.10]

Преимущества метода: Сильно усложняет анализ содержания ресурс пака
Недостатки: Если высокий пинг будут подлагивания как в случае с использованием нотных блоков

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

Я как-то игрался с получением пака. Он разбивает на разные тома и условный винрар говорит о недостающем томе.

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

 

[alexandrage]

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

 

[minecraft 1.8.10]

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

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

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

 

[alexandrage]

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

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

 

[minecraft 1.8.10]

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

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

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

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

 

[SparkDev]

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

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

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. Сжатие архива. Как я вижу вы это уже здесь обсуждали, так что объяснять не буду

 

[minecraft 1.8.10]

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

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

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

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

 

[SparkDev]

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

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

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

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

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

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

 

[minecraft 1.8.10]

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

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

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

 

[SparkDev]

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

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


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

 

[tnt15x15]

Это может работать с .Ogg файлами и есть ли эффективные способы?

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

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

 

[minecraft 1.8.10]

Да на самом деле дофига ещё способов.

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

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

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

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

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

 

[RareScrap]

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

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

 

[tnt15x15]

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

Да

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

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

 

[RareScrap]

Не все могут создать мод

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

 

[minecraft 1.8.10]

Готовая программа в самом конце сообщения

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

 

[tnt15x15]

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

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

 

[RareScrap]

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

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

Вы предлагаете не создавать какую либо защиту?

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

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

 

[minecraft 1.8.10]

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

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

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

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