2013-09-03 2 views
6

Я работаю над игрой, и одно из требований к лицензионному соглашению звуковых активов, которые я использую, заключается в том, что они распространяются таким образом, чтобы сделать их недоступными для конечного пользователя. Итак, я собираюсь объединить их в плоский файл, зашифровать их или некоторые из них. Проблема в том, что используемая звуковая библиотека (Hekkus Sound System) принимает только путь к файлу «char *» и обрабатывает внутреннее чтение файла. Поэтому, если я буду продолжать использовать его, мне придется переопределить функции файла stdio для обработки шифрования или того, что я решаю сделать. Это кажется выполнимым, но меня это беспокоит. В Интернете я вижу, как люди сталкиваются с неожиданными неприятными проблемами, которые возникают на платформах, которые меня интересуют (Win32, Android и iOS).Переопределить функции библиотеки библиотеки c?

Существует ли кросс-платформенная библиотека, которая позаботится об этом? Есть ли лучший подход, который вы бы рекомендовали?

+4

Не могли бы вы их декодировать и записать их некодированные в файл/tmp, а затем вызвать открытые и затем отменить их сразу после Открыто? Дескриптор файла внутри Хеккуса останется открытым после открытия. (Редактирование: идея дискового диска ниже кажется лучше) –

+2

Определите «недоступный». Если вы играете звук в пользовательской системе, это звучит довольно доступным для меня. В любом случае, в отношении Hekkus Sound System - авторский веб-сайт говорит, что он предлагает источники тому, кто заинтересован. Таким образом, проще всего получить исходный код и исправить его. Странно, хотя эта звуковая библиотека не абстрагирует способ получения данных. – n0rd

+2

Пожалуйста, не переопределяйте зарезервированный идентификатор в C, он будет вызывать неопределенное поведение. В проекте стандарта C99 говорится (Приложение J, раздел J.2): ** Поведение не определено в следующих случаях: [...] Программа пытается объявить библиотечную функцию самостоятельно, а не через стандартный заголовок , но декларация не имеет внешней связи (7.1.2). Программа объявляет или определяет зарезервированный идентификатор, кроме как разрешено в соответствии с 7.1.4 (7.1.3). ** –

ответ

7

У вас есть возможность использовать именованный канал вместо обычного файла? Если это так, вы можете представить канал в звуковую библиотеку в качестве файла для чтения, и вы можете расшифровать свои данные и записать их в трубу, без проблем. (См. Beej's Guide для объяснения названных каналов.)

+0

Нет, только char * ... – Vigabrand

+2

Не понимаю. Вы, кажется, говорите, что вместо передачи звуковых данных в библиотеку вы должны передать ему имя файла. Если это так, именованным каналом, также называемым FIFO, может быть решение. Именованный канал представляет собой файл в файловой системе, так что все, что открывает файл для чтения, находит на приемном конце вашего канала вместо чтения на диске. Таким образом, ваша программа может создать именованный канал, передать _filename pipe_ в звуковую библиотеку и записать дешифрованные аудиоданные для записи конца трубы. –

+1

Именованный канал в Unix - это файл, который можно открыть как обычный файл, поэтому его имя является регулярным «char *», и у библиотеки аудио не должно быть проблем с чтением. Тем не менее, он должен быть создан с использованием функции mkfifo, например, в другом потоке вашей программы и записано в, иначе fopen будет блокироваться (см. Http://stackoverflow.com/questions/580013/how-do-i-perform- a-non-blocking-fopen-on-a-named-pipe-mkfifo) – SirDarius

0

Решение проблемы будет ramdisk. http://en.wikipedia.org/wiki/RAM_drive Использование части памяти в плунжере, как если бы это был диск. Для этого есть программное обеспечение. Кэширование баз данных в барах становится популярным.

И он не позволяет файлу находиться на диске, что облегчит доступ пользователю.

+0

На Android? IPad? –

+0

Мне бы не понравилось, если игра или приложение добавили новый диск в систему во время работы. Кроме того, я не знаю, есть ли переносное решение, и, вероятно, потребуются права root/adminstrator. – interjay

+0

Это намного лучше, чем переопределение функций чтения файлов. –

5

Переопределите stdio таким образом, чтобы lib, который не знал, как он работает, работает точно так, как разработчик не имеет в виду не похоже на правильный подход для меня , поскольку это не очень легко. Для реализации ramdrive требуется столько усилий, что я рекомендую искать другую аудио-библиотеку.

Hekkus Sound System Я нашел, был создан одним человеком и обновлен в последний раз 2012. Я бы не стал полагаться на lib только с одним человеком, работающим над ним, без обмена источниками.

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

+0

Я тебя слышу. Но было бы к сожалению, если бы это было так, поскольку, помимо этой проблемы, Hekkus зарекомендовал себя как очень качественная функция, полная и удобная в использовании библиотека, несмотря на то, что это работа одного человека, и является перекрестной платформой для платформ I заботиться. Почему вы говорите, что переоценить stdio сложно? Кажется, что добавление тонкого слоя, который выполняет простое дешифрование, не должно быть слишком сложным, пока я получаю фактическую функцию, отменяющую работу. – Vigabrand

+0

Это может быть, и это, безусловно, ваше решение. Честно говоря, я не знаю, как переопределить stdio на платформе независимо. Напр. решение для Windows - создать именованный канал, вы можете создать путь к именованному каналу, который может быть открыт любой файловой функцией stdio. Аналогичный механизм для Linux существует, но я не знаю, одинаково ли это для любой другой платформы, такой как iPhone или Android. Для Windows, создающего именованный канал, вы можете использовать CreateFile API окон. Насколько я знаю, нет никакой независимой от платформы именованной библиотеки каналов (пока). –

+0

«overriding stdio» то, что я имел в виду, было переоценкой fopen/fread/etc через dlsym on * nix и эквивалент (hmm есть один?) На окнах – Vigabrand

2

Одна из возможностей - использовать encrypted loopback filesystem (для получения дополнительных ресурсов).

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

+0

Это кажется, единственной концепцией Linux? – Vigabrand

+0

Большинство * nix OS (включая MacOS), похоже, имеют его http://en.wikipedia.org/wiki/Loop_device. Кроме того, поскольку Android является производным от Linux, он также должен иметь его. – Ziffusion

+0

Я также буду выпускать на windows. – Vigabrand

1

Это зависит от компилятора и не является гарантией, но многие позволяют вставлять файлы/ресурсы непосредственно в exe и читать их в коде, как с диска. Вы могли бы встроить ваши звуковые файлы таким образом. Тем не менее, это значительно увеличит размер вашего exe.

+0

Это не работает прозрачно, поэтому библиотека не сможет открыть эти «файлы». – Vigabrand

+0

@Vigabrand Почему бы и нет? Просто загрузите их в массив байтов. –

+0

char * ссылается на имя файла в API Hekkus – Vigabrand

1

Другой UNIX-ориентированный подход:

Переменная среды LD_PRELOAD может быть использован, чтобы переопределить любую совместно используемую библиотеку исполняемый файл был связан с. Все символы, экспортируемые библиотекой, указанной в LD_PRELOAD, разрешаются для этой библиотеки, включая вызовы функций libc, такие как open, read и close. Используя libdl, библиотека обтекания также может обратиться к исходной реализации.

Итак, все, что вам нужно сделать, - это запустить процесс, который использует звуковую систему Hekkus в среде, где LD_PRELOAD установлен соответствующим образом, и вы можете делать все, что вам нравится, в файл, который он читает.

Обратите внимание, однако, что вы не можете сохранить данные недоступными для пользователя: сам факт, что он должен иметь возможность слышать, означает, что он должен иметь доступ. Даже если все программное обеспечение в цепочке будет использовать шифрование, а ваш пользователь не хочет взломать аппаратное обеспечение, было бы не совсем сложно подключить аудиовыход с гнездом аудиовхода, не так ли? И вы не можете запретить пользователю использовать наушники, не так ли? И, конечно, ядро ​​может видеть все аудиовыход незашифрованным и может отправлять копию где-то еще ...

+0

Похож на интересный вариант, хотя мне тоже нужно поддерживать окна. Что касается вашего второго пункта, звуки не воспроизводятся индивидуально, есть музыка и несколько звуков, поэтому это не очень полезно. – Vigabrand

+0

Даже несмотря на то, что я никогда не делал подобного, я могу придумать методы, позволяющие перепроектировать оригинальные звуки, и они не совсем сложны ... Но, конечно, если ваш источник музыки доволен оригинальными зашифрованными файлами и также доволен возможностью извлечения музыки в любом случае, казалось бы, нет проблем. Просто убедитесь, что он не может подать в суд на вас, когда музыкальные файлы появляются в Интернете ... – cmaster

Смежные вопросы