Проверка загруженного AssetBundles

Вы можете распространять AssetBundles с вашим приложением или настроить удаленные серверы для загрузки AssetBundles.

При загрузке AssetBundles необходимо принимать меры предосторожности, чтобы предотвратить повреждение данных и атаки злонамеренных субъектов. Повреждение данных в загруженной AssetBundles является распространенной причиной сбоев на устройствах пользователей. Хотя AssetBundles не может содержать исполняемый код, измененные серийные данные могут использовать уязвимости в коде приложения или времени выполнения Unity. Слой проверки может помочь предотвратить случайные сбои или плохое поведение.

Загрузка с использованием безопасного протокола

Используйте UnityWebRequestAssetBundle для загрузки AssetBundles с удаленного веб-сервера. Всегда используйте HTTPS в вашем URL, если только это не для локального веб-сервера на той же машине. HTTP небезопасен и подвержен атакам типа «человек посередине».

Циклические проверки избыточности

Чтобы проверить, что AssetBundles не поврежден, вы можете использовать циклические проверки избыточности (CRC) против 32-битной контрольной суммы, которую Unity генерирует во время процесса сборки AssetBundle. Контрольная сумма хранится в файле .manifest и доступна через BuildPipeline.GetCRCForAssetBundle. При загрузке AssetBundles через UnityWebRequestAssetBundle.GetAssetBundle, предоставьте ожидаемое значение CRC, чтобы предотвратить кэширование недействительного AssetBundles из в.

Если вы управляете AssetBundle загрузки непосредственно вне Unityкэша, выполнять проверки целостности перед использованием полученного контента. Необязательные параметры в AssetBundle нагрузка APIs позволить вам пройти CRC Если рассчитанные значения не соответствуют CRC не соответствует, AssetBundle не загружается. Для LZ4- сжатые AssetBundles, эта проверка является ресурсоемкой, поскольку она требует полной декомпрессии в RAM. LZMA- сжатые AssetBundles уже требуют полной декомпрессии для загрузки, так CRC Чтобы избежать повторных проверок во время загрузки, проверяйте работу всех компонентов, AssetBundle раз, когда он извлекается и сохраняется на устройстве. См. AssetBundle форматы сжатия для больше информации.

Ниже приводятся важные соображения, которые следует учитывать при проверке AssetBundles:

Не используйте обычные алгоритмы хеширования, такие как md5 для проверки AssetBundles, которые используют сжатие LMZA. Unity может пересжать AssetBundles без изменения их содержимого, что изменяет хэш файла, несмотря на действительное содержимое. Unity рассчитывает значения CRC из несжатого содержимого, и значения остаются последовательными после сжатия содержимого.
IncrementalBuildHash в файле .manifest не является хэшем полного содержимого файла. Он служит в качестве идентификатора версии и не подходит для обнаружения повреждений файла.
AssetFileHash в файле .manifest, доступном через BuildPipeline.GetHashForAssetBundle, является истинным хэшем содержимого.

Созданный пользователем контент

Для пользовательского контента (UGC), распространяемого другим игрокам, фильтруйте отправки, чтобы предотвратить неподходящий или вредоносный контент. Не разрешайте пользователям загружать двоичные файлы AssetBundle напрямую. Вместо этого требуйте от них загружать исходные ассеты и самостоятельно компилировать файлы AssetBundle. Этот процесс позволяет выполнять ручную и автоматическую фильтрацию и позволяет вам перекомпилировать AssetBundles для более новых версий Unity, если это необходимо.

Патч AssetBundles

При создании новой сборки AssetBundle вы можете обновить существующие установки новым или измененным AssetBundles и удалить любой нессылочный AssetBundles. Обновление существующего AssetBundles называется патчем. Unity поддерживает базовый уровень патчей через кэш AssetBundle, и вы можете заменить существующую версию AssetBundle на UnityWebRequestAssetBundle.GetAssetBundle. Однако Unity не поддерживает дифференциальное патчирование, при котором вы избирательно обновляете содержимое существующего файла, чтобы соответствовать новому файлу. Если вы хотите создать дифференциальные патчи, вы должны расширить или заменить кэш AssetBundle собственной логикой.

Использование UnityWebRequestAssetBundle.GetAssetBundle с другой версией или параметром хэша вызывает загрузку обновленного AssetBundles.

Основная задача состоит в том, чтобы определить, какие AssetBundles требуют замены. Система патчей должна управлять двумя списками:

Локальный AssetBundles: текущий загруженный AssetBundles и информация о его версии.
Сервер AssetBundles: Доступные AssetBundles на сервере и их информация о версии.

Система патчей сравнивает эти списки, повторно загружая AssetBundles, которые отсутствуют или имеют обновленную информацию о версии.

Unity не поддерживает дифференциальное патчирование по умолчанию. UnityWebRequestAssetBundle.GetAssetBundle загружает целые файлы, даже с встроенной системой кэширования. Если вам нужно дифференциальное патчирование, реализуйте собственные загрузчики. Unity детерминистически распределяет данные AssetBundle, поэтому файлы патчей для перестроенного AssetBundles могут быть намного меньше. Несжатые AssetBundles или те, которые используют сжатие LZ4, более эффективны для патчей, чем LZMA-сжатые AssetBundles.

Для индивидуальных систем используйте JSON для AssetBundle списки файлов и .NET криптография APIs для вычисления хэшей файлов. Эти хэши могут действовать как идентификаторы версий, или вы можете использовать традиционные номера версий, если ваши системы сборки их поддерживают.