You can choose to either distribute your AssetBundles with your game or app, or they can be downloaded from remote servers by your game or app. In the latter case, when you download AssetBundles, it’s important to take precautions to prevent AssetBundle data corruption as well as attacks by malicious actors. A common cause of mysterious crashes on user devices comes from data corruption in downloaded AssetBundles. Such situations can cost a large amount of effort and time to diagnose and resolve. And, even though AssetBundles cannot contain executable code, changing serialized data could allow an attacker to exploit a vulnerability in the game code or the Unity runtime.
UnityWebRequestAssetBundle can be used to download and cache AssetBundles from the internet. When using this API you should use the HTTPS protocol in your URL, unless your URL refers to a local web server that runs on the same machine. The HTTP protocol is not secure and is vulnerable to a malicious man in the middle attack.
Unity provides the tools for you to use a checksum to determine that an AssetBundle is not corrupted or modified when downloading it. A 32-bit checksum is generated during the AssetBundle build process and recorded in the .manifest file and exposed by BuildPipeline.GetCRCForAssetBundle. When you use a CRC check, it ensures the AssetBundle data was not corrupted or tampered with after it was built. You must provide this CRC when downloading AssetBundles through UnityWebRequestAssetBundle.GetAssetBundle so that invalid AssetBundles content cannot make it into the cache. See AssetBundle compression and caching for additional details.
If you download or distribute AssetBundles yourself, and do not use the built-in AssetBundle Cache, then you should be sure to perform integrity checks prior to using any content that you have retrieved. One way to do that is to use the optional parameters on the AssetBundle Load APIs to pass in the expected CRC value. When provided, the loading system calculates the checksum of the uncompressed content of the AssetBundle before loading it. If the CRC of the AssetBundle does not match the provided CRC, the AssetBundle will not load. For AssetBundles compressed with LZ4 this can be costly because it forces the file to be fully decompressed into RAM. For LZMA compressed AssetBundles the load already forces a full content decompression, so performing the CRC check is not a significant additional cost. Overall it can be practical to avoid the cost of CRC calculations by performing the integrity check once, as the file is retrieved and stored on the device, rather than repeating it at each load.
Note: If you are using AssetBundle compression then you shouldn’t use other common hash algorithms (such as md5) to validate your AssetBundle files. This is because Unity sometimes recompresses your AssetBundles even if their contents didn’t change, which means the file content hash may change in cases when the contents of the file are actually still valid. In contrast, the CRC value for an AssetBundle is calculated from its uncompressed content, which remains constant even when the bundle is recompressed.
Note: the AssetBundle hash that a Unity build calculates and stores inside the .manifest is not a hash of the AssetBundle’s full file content. It can be used as a version value for the AssetBundle but is not suitable to use for file corruption detection.
사용자가 다른 플레이어에게 배포된 콘텐츠(사용자 생성 콘텐츠)를 업로드할 수 있게 한다면 이 데이터가 적절한 콘텐츠를 가지고 있는지 아니면 악의적인 콘텐츠를 가지고 있는지 책임감을 가지고 필터링을 해야 합니다. 사용자가 바이너리 에셋 번들 파일을 빌드하여 업로드하게 허용하지 않는 것이 좋습니다. 사용자가 소스 에셋을 직접 업로드하고 개발자가 사용자를 위해 에셋 번들 바이너리 파일을 빌드하도록 허용하는 것이 좋습니다. 이렇게 하면 개발자가 매뉴얼과 자동화 프로세스를 통해 악의적이거나 적절하지 않은 콘텐츠를 더 쉽게 필터링할 수 있습니다. 또한 Unity 이후 버전으로 업그레이드한다면 필요에 따라 개발자가 에셋 번들을 다시 빌드할 수도 있습니다.