unblob icon indicating copy to clipboard operation
unblob copied to clipboard

Test that handlers tolerate a non-empty unknown chunk prefix/suffix

Open e3krisztian opened this issue 2 years ago • 3 comments

e3krisztian avatar May 11 '22 10:05 e3krisztian

Given the current test output, we should investigate and open tickets for miscalculation on unaligned chunks in the following handlers:

  • [ ] compression.compress
  • [ ] compression.lzh
  • [ ] executable.elf.elf32
  • [x] filesystem.romfs
  • [ ] filesystem.yaffs.yaffs
  • [ ] filesystem.yaffs.yaffs2
  • [ ] filesystem.jffs2.jffs2_new
  • [ ] filesystem.jffs2.jffs2_old

qkaiser avatar May 11 '22 10:05 qkaiser

There are a couple of problems with this PR:

The real stuff is here e.g.:

  • https://github.com/IoT-Inspector/unblob/runs/6386032887?check_suite_focus=true

Some newer test runs fail due to timeout after 4m (more tests, and they are also of the slower kind).

e3krisztian avatar May 11 '22 10:05 e3krisztian

The chunk calculation errors on filesystem handlers is due to calls to read_until_past, which is unbounded. We should read the exact padding size whenever possible.

  • romfs: padding alignment is 1024 bytes, fixed in e872387
  • JFFS2: padding size is the erase block size by default, but can be increased by setting it explicitly
  • YAFFS: padding size is the page size by default, but can be increased by setting it explicitly

The chunk calculation error on compress and LZH comes from the fact that a random byte at the end of the compressed stream may be considered valid by the decompressor. Not sure if there is a way to overcome this.

qkaiser avatar Jun 13 '22 08:06 qkaiser