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.
The current, simple YAFFS signature has several flaws, and a regression in not being able to detect yaffs2 images (read: images created with mkyaffs2image tool) since 46d8a32.
Therefore, the current signature failed to find valid YAFFS images during tests, both with generated test images and in a real world scientific use-case examining an Android device NAND dump.
Unfortunately, the YAFFS on-disk format is poorly documented and mainly defined by the memory layout of the reference implementation found here: http://www.aleph1.co.uk/gitweb/?p=yaffs2.git;a=blob;f=yaffs_guts.h;h=74ded0be526f1f44c91ce90a6d54cc52bb338cf0;hb=HEAD#l329
I propose the signatures in the attached commit, where we recognize the start of an object header defined by yaffs_obj_hdr, with the values being encoded depending on platform endianess:
Notes:
From a test set of 9 images generated with different contents and versions of the reference implementation, the old signature recognized 5, while the improved signature recognized all images and displayed additional data where appropriate (root file name). Attached for reference are the test images, as well as the old and new logs generated when executing binwalk directly on these files.
Various remaining parameters (NAND layout, ECC, etc.) do not seem to have an effect on the object header examined here.
Correct execution could also be verified with the device dump in question.
binwalk_old.log
binwalk_new.log
testimages.tar.gz