bug: AssetRipper cannot read asset bundles written by AssetsTools.NET with BlockInfoNeedPaddingAtStart flag#161
Open
loukylor wants to merge 1 commit intonesrak1:mainfrom
Open
bug: AssetRipper cannot read asset bundles written by AssetsTools.NET with BlockInfoNeedPaddingAtStart flag#161loukylor wants to merge 1 commit intonesrak1:mainfrom
BlockInfoNeedPaddingAtStart flag#161loukylor wants to merge 1 commit intonesrak1:mainfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I noticed that AssetRipper will fail to read AssetsTools.NET asset bundles created with the
BlockInfoNeedPaddingAtStartflag because AssetRipper expects the blocks info length to not be aligned to the next multiple of 16 bytes.You can see that in these lines:
AssetRipper will not attempt to increase the blocks info length to the next multiple of 16 before validating that the number of bytes read is correct. This contrasts with AssetsTools.NET which does align to the next multiple of 16 before calculating length. I'm not sure which tool's behavior is correct, but I figured I'd just open a PR for whichever fix was easier.
Here's the minimum reproducible code:
The bundle this generates will fail to load in AssetRipper, but if you change the uncompressed blocks info length to 59 (0x3B) using a hex editor, it will load in AssetRipper just fine.