Как запаковать в exe файл
Обновлено: 02.07.2024
Давным-давном, когда Windows XP еще не было, в поисках информации о пакерах мы с Волком забирались в самые дебри исходников тогда еще молодого UPX. Но то ли ацетилхолина у нас в мозгах синтезировалось меньше нужного, то ли UPX уже тогда был очень занудным — в общем, мы почти ничего из тех сорцов не извлекли. Мэтт Питрек, и тот помог больше. Сейчас с инфой значительно проще стало. Почти всё есть. Даже сорцы вполне себе нормального банковского троя можно скачать (Zeus 2.0.8.9, bit.ly/v3EiYP). Да чего уж там, сорцы винды уже давно в паблике (Windows 2000, bit.ly/rBZlCy).
Об упаковщиках информация тоже есть, но в основном исследовательская, непосредственно разработки касающаяся не с той стороны, с которой нам бы хотелось. Отличным примером тому является статья »Об упаковщиках в последний раз» (bit.ly/vRPCxZ, bit.ly/tSUxT7) в двух частях, написанная небезызвестными гуру Volodya и NEOx.
Мы, в свою очередь, постараемся максимально конкретно и последовательно дать информацию именно о разработке простейшего, но легко модифицируемого под любые свои нужды PE-пакера.
Алгоритм
Вот есть у нас, например, notepad.exe. В обычном своем 32-битном виде он весит где-нибудь 60 Кб. Мы хотим его существенно уменьшить, сохранив при этом всю его функциональность. Какими должны быть наши действия? Ну, для начала мы наш файлик от первого до последнего байтика прочтем в массив. Теперь мы можем делать с ним всё что угодно. А нам угодно его сжать. Берем его и отдаем какому-нибудь простому компрессору, в результате чего получаем массив уже не в 60 Кб, а, например, в 20 Кб. Это круто, но в сжатом виде образ нашего «Блокнота» — это просто набор байтов с высокой энтропией, это не экзешник, и его нельзя запустить, записав в файл и кликнув. Для массива со сжатым образом нам нужен носитель (загрузчик), очень маленький исполняемый файл, к которому мы прицепим наш массив и который его разожмет и запустит. Пишем носитель, компилируем, а затем дописываем к нему в конец наш сжатый «Блокнот». Соответственно, если полученный в результате всех действий файл (размер которого немного больше, чем у просто сжатого «Блокнота») запустить, он найдет в себе упакованный образ, распакует, распарсит его структуру и запустит.
Как видишь, нам предстоит автоматизировать не слишком сложный процесс. Нужно будет просто написать две программы, загрузчик и, собственно, упаковщик.
Алгоритм работы упаковщика:
- считать PE-файл в массив;
- сжать массив каким-нибудь алгоритмом сжатия без потерь;
- в соответствии с форматом PE дописать сжатый массив к шаблону-загрузчику.
Алгоритм работы загрузчика:
- найти в конце себя массив со сжатым PE-файлом;
- разжать его;
- распарсить заголовки PE-файла, расставить все права, выделить память и в итоге запустить.
Начнем разработку с загрузчика, так как именно им впоследствии будет манипулировать упаковщик.
Загрузчик
Итак, первое, что должен сделать наш загрузчик, — это найти в своем теле адрес массива со сжатым образом PE-файла. Способы поиска зависят от того, как упаковщик имплантировал этот массив в загрузчик.
Например, если бы он просто добавил новую секцию с данными, то поиск выглядел бы так:
Но, на наш с Волком взгляд, этим кодом в загрузчике можно пожертвовать. Вообще, всё, что может сделать упаковщик, пусть он и только он и делает. Адрес образа в адресном пространстве загрузчика можно вычислить заранее, при упаковке, а потом просто вписать в нужное место. Для этого оставляем в нашей программе две метки:
Когда упаковщик будет имплантировать в загрузчик массив со сжатым образом, он пройдется сигнатурным поиском по телу загрузчика и заменит 0xDEADBEEF на адрес массива, а 0xBEEFCACE — на его размер.
Теперь, когда мы определились, как искать адрес, можно выбрать готовую реализацию алгоритма сжатия для использования в нашем упаковщике.
Неплохой вариант — использовать aplib, маленькую библиотеку с аккуратным и очень компактным кодом, реализующую сжатие на базе алгоритма Лемпеля-Зива (LZ). И мы обязательно его выбрали бы в любой другой день, однако сегодня у нас настроение для еще более простого и компактного решения — встроенных в Windows функций!
Начиная с XP, наша любимая ntdll.dll начала экспортировать две прекрасные функции:
Названия их говорят сами за себя — одна функция для компрессии, другая для декомпрессии. Конечно, если бы мы разрабатывали действительно серьезный продукт, мы бы эти функции не трогали, ведь остались еще компьютеры и с Windows 2000, и даже с NT 4.0, 😉 но для наших скромных целей RtlCompressBuffer\RtlDecompressBuffer вполне подойдут.
В хедерах Platform SDK этих функций нет, статически мы их прилинковать не сможем, поэтому придется воспользоваться GetProcAddress:
Когда есть чем распаковать и есть что распаковать, можно уже, наконец, это сделать. Для этого мы выделим память с запасом (так как не знаем объем распакованного файла) и запустим определенную выше функцию:
Параметр COMPRESSION_FORMAT_LZNT1 означает, что мы хотим использовать классическое LZ-сжатие. Функция умеет сжимать и другими алгоритмами, но нам хватит и этого.
Теперь у нас в памяти (pbImage) есть сырой образ PE-файла. Чтобы его запустить, нужно провести ряд манипуляций, которые обычно делает нативный PE-загрузчик Windows. Мы сократим список до самых-самых необходимых:
- Разместить начало образа (хедеры) по адресу, указанному в поле Image Base опционального заголовка (OPTIONAL_HEADER).
- Разместить секции PE-файла по адресам, указанным в таблице секций.
- Распарсить таблицу импорта, найти все адреса функций и вписать в соответствующие им ячейки.
Естественно, стандартный PE-загрузчик выполняет целую кучу других действий, и тем, что мы их отметаем, мы ограничиваем совместимость нашего упаковщика с некоторыми PE-файлами. Но для абсолютного большинства хватит и этих действий — можно не фиксить релоки, фиксапы и прочую редкую и противную фигню.
Если вдруг тебе захочется серьезной совместимости, ты или сам напишешь крутой PE-лоадер, или найдешь в Сети наиболее полную его реализацию — нам с Волком было лень писать свою, и мы воспользовались трудами gr8 из hellknights выкинув из нее всё, что не поняли. 😉 Даже в урезанном виде функция PE-лоадера — это строчек сто, не меньше, поэтому здесь мы приведем только ее прототип (полный код лежит на диске):
Она принимает указатель на наш распакованный образ и возвращает дескриптор загруженного модуля (эквивалент адреса, по которому загружен PE-файл) и адрес точки входа (по указателю AddressOfEntryPoint). Эта функция делает всё, чтобы правильно разместить образ в памяти, но не всё, чтобы можно было, наконец, передать туда управление.
После выполнения функции LoadExecutable в загрузчике неплохо было бы освободить память, выделенную для распаковки, — она нам больше не пригодится.
Дело в том, что система по-прежнему ничего не знает о загруженном нами модуле. Если мы прямо сейчас вызовем точку входа, с которой сжатая программа начнет выполнение, то может возникнуть ряд проблем. Работать программа будет, но криво.
Например, GetModuleHandle(NULL) будет возвращать Image Base модуля загрузчика, а не распакованной программы. Функции FindResource и LoadResource будут рыться в нашем загрузчике, в котором никаких ресурсов нет и в помине. Могут быть и более специфические глюки. Чтобы всего этого не происходило, нужно в системных структурах процесса по возможности везде обновить информацию, заменив адреса модуля загрузчика на адреса загруженного модуля.
В первую очередь нужно пофиксить PEB (Process Enviroment Block), в котором указан старый Image Base. Адрес PEB очень легко получить, в юзермоде он всегда лежит по смещению 0x30 в сегменте FS.
Также не помешает пофиксить списки модулей в структуре LDR_DATA, на которую ссылается PEB. Всего там три списка:
- InLoadOrderModuleList — cписок модулей в порядке загрузки;
- InMemoryOrderModuleList — cписок модулей в порядке расположения в памяти;
- InInitializationOrderModuleList — cписок модулей в порядке инициализации.
Нам надо найти в каждом списке адрес нашего загрузчика и заменить его на адрес загруженного модуля. Как-нибудь так:
Вот теперь можно смело вызывать точку входа загруженного модуля. Он будет функционировать так, словно был вызван самым обычным образом.
AddressOfEntryPoint — это относительный виртуальный адрес (RVA, Relative Virtual Address) точки входа, взятый из optional header в функции LoadExecutable. Для получения абсолютного адреса мы просто прибавили к RVA адрес базы (то есть свежезагруженного модуля).
Процесс отладки бажного файла в OllyDbg
Уменьшение размера загрузчика
Если наш загрузчик скомпилировать и собрать в VS 2010 с флагами по умолчанию, то мы получим не двухкилобайтную программку-носитель, а монстра размером более 10 Кб. Студия встроит туда целую кучу лишнего, а нам надо всё это оттуда выгрести.
Поэтому в свойствах компиляции проекта загрузчика (вкладка С/C++) мы делаем следующее:
- В разделе «Оптимизация» выбираем «Минимальный размер (/O1)», чтобы компилятор старался сделать все функции более компактными.
- Там же указываем приоритет размера над скоростью (флаг /Os).
- В разделе «Создание кода» выключаем исключения С++, мы их не используем.
- Проверка переполнения буфера нам тоже не нужна (/GS-). Это штука хорошая, но не в нашем случае.
В свойствах линкера (компоновщика):
- Отключаем к чертям «Манифест». Он большой, и из-за него в загрузчике создается секция .rsrc, которая нам совершенно не нужна. Вообще, каждая лишняя секция в PE-файле — это минимум 512 совершенно ненужных байт, спасибо выравниванию.
- Отключаем создание отладочной информации.
- Лезем во вкладку «Дополнительно». Выключаем «Внесение случайности в базовый адрес» (/DYNAMICBASE:NO), иначе линкер создаст секцию релоков (.reloc).
- Указываем базовый адрес. Выберем какой-нибудь нестандартный повыше, например 0x02000000. Именно это значение будет возвращать GetModuleHandle(NULL) в загрузчике. Можно его даже захардкодить.
- Указываем нашу точку входа, а не CRT-шную: /ENTRY:WinMain. Вообще, мы привыкли это делать директивой pragma прямо из кода, но раз уж залезли в свойства, то можно и тут.
Остальные настройки для линкера задаем непосредственно из кода:
Здесь мы объединили секцию .rdata, в которой содержатся данные, доступные только для чтения (строки, таблица импорта и т. п.), с секцией кода .text. Если бы мы использовали глобальные переменные, то нам также надо было бы объединить с кодом секцию .data.
Всего перечисленного хватит, чтобы получить лоадер размером в 1,5 Кб.
Переделываем в криптор
Собственно, от криптора наш пакет отличает совсем немногое: отсутствие функции шифрования и противоэмуляционных приемов. Самое простое, что можно с ходу сделать, — это добавить xor всего образа сразу после распаковки в загрузчике. Но, чтобы эмуляторы антивирусов подавились, этого недостаточно. Нужно как-то усложнить задачу. Например, не прописывать ключ xor’а в теле загрузчика. То есть загрузчик не будет знать, каким ключом ему надо расшифровывать код, он будет его перебирать в определенных нами рамках. Это может занять какое-то время, которое есть у пользователя, в отличие от антивируса.
Также ключ можно сделать зависимым от какой-нибудь неэмулируемой функции или структуры. Только их еще найти надо.
Чтобы код загрузчика не палился сигнатурно, можно прикрутить к упаковщику какие-нибудь продвинутые вирусные движки для генерации мусора и всяческого видоизменения кода, благо их в Сети навалом.
Упаковщик
Нам остается разработать консольную утилиту, которая будет сжимать отданные ей файлы и прицеплять к лоадеру. Первое, что она должна делать по описанному в начале статьи алгоритму, — это считывать файл в массив. Задача, с которой справится и школьник:
Далее наш пакер должен сжать полученный файл. Мы не будем проверять, действительно ли это PE-файл, корректные ли у него заголовки и т. п., — всё оставляем на совести пользователя, сразу сжимаем. Для этого воспользуемся функциями RtlCompressBuffer и RtlGetCompressionWorkSpaceSize. Первую мы уже описали выше — она сжимает буфер, вторая же нужна, чтобы вычислить объем памяти, необходимой для работы сжимающего движка. Будем считать, что обе функции мы уже динамически подключили (как и в загрузчике), остается только их запустить:
В результате у нас есть сжатый буфер и его размер, можно прикрутить их к загрузчику. Чтобы это сделать, нужно для начала скомпилированный код нашего загрузчика встроить в упаковщик. Самый удобный способ засунуть его в программу — это воспользоваться утилитой bin2h. Она конвертнет любой бинарник в удобный сишный хедер, все данные в нем будут выглядеть как-то так:
Скармливаем ей файл с нашим лоадером и получаем всё необходимое для дальнейших извращений. Теперь, если придерживаться алгоритма, описанного в начале статьи, мы должны прицепить к загрузчику сжатый образ. Здесь нам с Волком придется вспомнить 90-е и свое вирмейкерское прошлое. Дело в том, что внедрение данных или кода в сторонний PE-файл — это чисто вирусная тема. Организуется внедрение большим количеством разных способов, но наиболее тривиальные и популярные — это расширение последней секции или добавление своей собственной. Добавление, на наш взгляд, чревато потерями при выравнивании, поэтому, чтобы встроить сжатый образ в наш загрузчик, мы расширим ему (загрузчику) последнюю секцию. Вернее, единственную секцию — мы же избавились от всего лишнего. 😉
Создание хедера с помощью bin2h можно автоматизировать
Алгоритм действий будет такой:
- Находим единственную секцию (.text) в загрузчике.
- Изменяем ее физический размер, то есть размер на диске (SizeOfRawData). Он должен быть равен сумме старого размера и размера сжатого образа и при этом выравнен в соответствии с файловым выравниванием (FileAlignment).
- Изменяем виртуальный размер памяти (Misc.VirtualSize), прибавляя к нему размер сжатого образа.
- Изменяем размер всего образа загрузчика (OptionalHeader.SizeOfImage) по древней формуле [виртуальный размер последней секции] + [виртуальный адрес последней секции], не забывая выравнивать значение по FileAlignment.
- Копируем сжатый образ в конец секции.
Тут есть небольшая хитрость. Дело в том, что наша студия делает виртуальный размер (Misc.VirtualSize) секции с кодом (.text) равным реальному невыравненному размеру кода, то есть указывает размер меньше физического. А значит, есть шанс сэкономить до 511 байт.
То есть так бы мы записали данные после кучи выравнивающих нулей, а зная фишку, можно записаться поверх этих нулей.
Кусок кода парсера таблицы импорта
Вот как все наши мысли будут выглядеть в коде:
О, мы едва не забыли заменить метки 0xDEADBEEF и 0xBEEFCACE, оставленные в загрузчике, на реальные значения! 0xBEEFCACE у нас меняется на размер сжатого образа, а 0xDEADBEEF — на его абсолютный адрес. Адрес образа вычисляется по формуле [адрес образа] + [виртуальный адрес секции] + [смещение образа относительно начала секции]. Следует отметить, что замену надо производить еще до обновления значения Misc.VirtualSize, иначе полученный в результате файл не заработает.
Ищем и заменяем метки с помощью очень простого цикла:
Вот, собственно, и всё. Теперь в памяти у нас есть упакованный и готовый к работе файл, достаточно сохранить его на диске с помощью функций CreateFile/WriteFile.
Наш упаковщик сжал notepad.exe лучше, чем UPX!
Каждый новичок, изучающий пайтон сталкивается с проблемой упаковки своей программы в единый исполняемый файл.
Поскольку пайтон интерпретируемый язык программирования скомпилировать его в единый файл проблематично. Но не невозможно.
Для решения этой проблемы пайтон-разработчики идут на хитрость: в пакет программы "копируют" интерпретатор пайтон. Однако сделать это нужно правильно. И для этой цели обычно используют либо библиотеку pyinstaller , либо cx_freeze.
Pyinstaller позволяет упаковать программу чуть ли не в 2 клика. Однако если у вас есть дополнительные файлы, либо вы импортировали дополнительные библиотеки, скорее всего, pyinstaller не сможет их найти и у вас ничего не получится.
Поэтому я советую для сложных приложений использовать cx_freeze. И сразу скажу, все не так страшно, как может показаться. Мне удавалось запаковать игры с музыкой, картинками и все работало. Работаю я в Windows, а документацию библиотеки смотри здесь .
Шаг 1.Установка библиотеки cx_Freeze
Устанавливаем библиотеку cx_Freeze с помощью pip.
Вводим в командной строке:
Если появляется ошибка, то попробуйте добавить флаг --user.
Шаг 2. Напишем код, который запакует нашу программу.
В пакете нашей программы создаем файл с названием setup.py, в которую вписываем код, который запакует нашу программу. У меня была игра, и код компилятора выглядел так:
from cx_Freeze import setup, Executable
Шаг 3. Корректируем код
В третьей строке вписываем название файла, запускающего программу и название итогового файла exe.
Конвертировать иконку можно здесь .
В includes и zip_include_packages мы указываем те модули, которые мы использовали, чтобы python не забыл их запаковать.
В include_files мы указываем путь ко всем дополнительным файлам, которое использует наше приложение. Если у вас иерархия папок, а не все файлы скопом лежат в одной, то не забудьте в пути это указать.
В функции options ничего не исправляем.
В setup исправляем name - указываем имя главного файла, в version - версию приложения, а в description - описание приложения.
Ошибка с шрифтами
Шаг 3. Запаковываем.
Выполним запаковку, вбив в командную строку следующее:
У вас должен появиться файл build_windows. Это и есть наш итоговый пакет программы, который мы сможем распространять. Здесь же мы найдем файл .exe, запускающий нашу программу. Для него, например, можно создать ярлык и закинуть его на рабочий стол.
Возможные ошибки.
Если .exe файл выдает ошибку, то скорее всего, вы не указали, либо указали неправильно путь до одного из используемых файлов и программа не может его найти. Этот файл будет указан в ошибке.
Надеюсь у вас все получилось, а если нет, обязательно напишите об этом. И я постараюсь вам помочь.
Запаковка музыки в exe файл при компиляции
Погуглив, разобрался с упаковкой картинок в exe файл после компиляции. Но никак не могу решить.
Запаковка файлов с данными
Здравствуйте! У меня есть проект, он подгружает некоторые текстовики, картинки и прочее.
Запаковка файлов в один пакет
Доброго дня всем! Прошу прощения за возможно ламерский вопрос Дело такое. Я запаковую некоторое.
сейчас в личку дам
, а ты мне даёшь в формате *.zip; давай в *.exe, как сам и написал. файл лежит в архиве про который я писал, а название его cfPro.exe Вообщем скачал файл он в формате .exe и распаковал его с помощью 7z опиши действия. Я насколько знаю, экзешник можно удалить, переместить, скопировать, удалить, загрузить в отладчик, в hex-редактор. Запустить на исполнение в конце концов. Запаковать ещё (упаковщиком), сжать. Но распаковать с помощью 7z- это что-то новенькое для меня.Я почему сам с ним не эксперементирую- у меня антивирус орёт на него благим матом.
да что тут описывать, скачал, правой кнопкой по икзешнику 7-Zip далее Extract files и всё, после появилась папка с файлами, а вот как запаковать обратно я не знаю, весь день в гугле провел и не нашел чем запаковать.
Добавлено через 3 минуты
кстати по поводу антивируса, можешь не беспокоиться, файл не навредит тебе.
Ладно. А кто тебя вообще научил, что его надо распаковывать, а не запускать? Ты ведь наверное, где-то прочёл это? Типа инструкции. На мой взгляд такое употребление экзешника очень нестандартно, угадать, что его надо распаковывать, а не запускать, да ещё 7z ты сам не мог. Наверное, где-то это почёл. Где? Это может помочь!
Добавлено через 23 секунды
да я не где не читал, почему 7-z? Ну наверно потому что это первый архиватор который мне в голову пришел
Добавлено через 2 минуты
этот икзешник пакован не винраром, а вот чем? Я уже кучу программ перепробовал и не выходит.
Не почему 7z, а почему РАСПАКОВЫВАТЬ. Я уже говорил и повторюсь- распаковка экзешника крайне нестандартная ситуация. У меня на компе перебывало немеряно экзешников и собственных и чужих и ни один не подлежал распаковке, а только запуску.
И вдруг я узнаю, что экзешники можно распаковывать. Откуда ты это узнал? Я вот от тебя узнал, а ты откуда?
Вам уже сказал Мотороллер - WinRar'ом. Ваш файл именно им и запакован (+ накрыт сверху Enigma Protector v3.70 Build 2015/02/27 - Protected with a Company license). запаковываю винраром, пытаюсь запустить и не запускается, открывается окно разархивирование.это я знаю.. Винрар делает только самораспаковывающие архивы. Но не как не .exe запускаторы.
Добавлено через 1 минуту
Ну возьмите тот файл я ссылку дал на него и посмотрите
Теперь ваша очередь смотреть.
Откройте в любом вьювере (FAR, например), и загляните в конец вашего "запускатора". Строка ";Расположенный ниже комментарий содержит команды SFX-сценария" принадлежит SFX-скрипту WinRar (русская версия). + кто-то, не имеющий понятия о защитах, навесил на этот SFX-скрипт протектор (это, примерно, как поставить бронированную дверь в брезентовую палатку).
Запаковка файлов в архив с расширением pack
Есть игровой архив pack и скрипт для его распаковки в проге quickbms. Распаковав его и.
Распаковка и запаковка файлов в архивы - нужен графический вид
Добрый день! Подскажите пожалуйста, есть два Bat файла @echo off "C:\Program Files\7-Zip\7z" x.
Вместо запуска EXE файлов открывается сайт браузер с предложением скачать файл с названием EXE
Логи отсутствуют, т.к. не могу запустить автологер. Вместо запуска EXE файлов открывается сайт.
Запаковка
Лимит времени 2000/4000/4000/4000 мс. Лимит памяти 65000/65000/65000/65000 Кб. Сложность Гамма .
Этим способом можно создавать небольшие портабельные программы состоящие из одного файла.
Для примера буду делать exe файл CClener.
И так приступим создаем папку CClener копируем в неё файлы от программы. Далее правой клавишей мыши на папку "Добавить в архив".
На вкладке "Общие". Выставите rar формат и сжатие.
Также нужно установить галочку "Создать SFX архив".
Далее переходим на вкладку "Дополнительно" и нажимаем параметры SFX.
В открывшейся вкладки переходим на вкладку "Режимы"
Ставим галку "Распаковать во временную папку" это значит что во время запуска файлы распакуются во временную папку TEMP.
Ниже выставляем вид распаковки "Режим вывода информации.
1 вариант будет весь процес распаковки виден.
2 Не будет указываться только начальный диалог.
3 Режим скрытный не какой информации о действии не будет выведено на экран.
Так вот его и ставим.
После переходим во вкладку "Общие" ввести в "выполнить после распаковки" путь Папка программы/Файл который нужно запустить.
В примере с CClener я указал "CClener/CClener.exe".
Для того чтобы у данного архива была другая иконка а не стандартная от winrar.
Переходим во вкладку "Текст и значок".
Внизу "Загрузить значок SFX из файла" нажимаем обзор выбираем значок нажимаем открыть.
Я ничего не понимаю. как скопировать в Visual Studio файлы (шейдеры, картинки) в exe файл?
Мне нужно чтобы как можно меньше торчало файлов в открытом виде.
Таких файлов разумеется очень много и разложены по директориям.
viennahd
> Я ничего не понимаю. как скопировать в Visual Studio файлы (шейдеры, картинки) в exe файл?
Shift+Alt+A. Когда добавишь, нажми правой кнопкой мыши на файле и выбери Свойства. А там уже укажи тип.
Но это добавляет в сам проект (sln), но никак не решает проблему самого exe и скрытия файлов.
То есть мне нужно укомплектовать и утрамбовать.
viennahd
Те файлы, которые ты добавил как я писал выше, зайди в их свойства. У них там может стоять в пункте Тип элемента значение Не участвовать в сборке. Поменяй его)
И еще проблему усложняет то что шейдеры создаются сторонней утилой, и ее тоже нужно трамбовать.
И да, я не знаю кем являются dll, glsl и т.д.
Оказывается нужно знать какого типа, и не определенность не допускается.
Получается что любой файл из папки bin никак не может быть файлом dll.
И выходит шейдеры могут быть только в открытом виде?!
Хреновый Windows.
Можно спрятать файлы данных. Но для этого надо пользоваться альтернативными файловыми системами, реализуемыми в некоторых библиотеках или делать свою такую. С альтернативной файловой системой должны уметь работать все используемые инструменты. Если движок твой, самописный, это не проблема. В чужом движке надо смотреть, может у него есть своя файловая система.
Практически все игры так и реализуются, если они не хранят свои данные в открытом виде, в сотнях тысяч мелких файлов.
Некоторые типы файлов нельзя прятать, потому как API может работать только с файлом, а не с поставляемыми программой данными. Пример такого формата - avi.
У меня проект-самопал, разве что sfml.
если самопал, бери какой-нибудь boost-file-system. Впрочем, не обязательно именно его, аналоги гуляют буквально повсюду, в том числе и написанные для одного-двух проектов.
Один большой файл данных скорее всего все равно будет. Можешь сделать его сколь угодно зашифрованным, но часто его содержимое делают просто zip-архивом.
Теоретически можно прилепить данные внутрь экзешника, но это очень неудобно и непопулярно. Захочешь так сделать - не факт что найдешь готовый инструмент, придется возиться самому.
sfml поддерживает чтение из памяти, просто вместо имени файла скармливаешь ему этот указатель (ну и там функция будет по-другому называться).
Написать конвертер в такой вид из обычных файлов - ну дело дня максимум.
Правда экзешник вырастет на размер всех этих файлов, но я так понимаю ты к этому готов.
viennahd
Файл ресурсов гугли res\rc. В студии с этим добром есть интеграция, так что все сможешь добавить мышкой. Если же ты фанат автоматизации - просто сгенерируй этот файл своей тулзой.
А можно ли запаковать шейдеры, картинки и т.д. в ZIP или еще какой-нибудь архив, и уже оттуда грузить?
Но что делать с dll, которых не мало?
viennahd
> А можно ли запаковать шейдеры, картинки и т.д. в ZIP или еще какой-нибудь архив, и уже оттуда грузить?
Куда угодно можно, хоть в архив, хоть в ресурсы экзешника, хоть в константный массив. Что хочешь - то и делаешь, в зависимости от того, что тебе нужно.
> Но что делать с dll, которых не мало?
Не делай dll, закажи статическую компоновку при компиляции.
У меня статики жалуются на не разрешенные символы. от SFML.
Этот SFML все равно понужает на DLL, особенно жадничиет на libjpeg, и boost.
Есть ли способ выкинуть нахрен этот SFML не причиняя ущерб png и текстурам?
Читайте также: