Open vlaci opened 2 years ago
On the subject of OO wrapping of chunks, I think this could facilitate the work on #274 . An UnknownChunk object could have a dedicated function to do some "introspection" on its content (i.e. file content encompassing that unknown chunk) and report on it by mutating its class into one of Chunk
's subclasses.
Example: we have an UnknownChunk
with only null padding in it, the introspection function runs and the object mutates into a NullPadChunk
.
Just some ideas, please don't hit me if I broke every design pattern in the book :)
This issue is about a refactor idea that came up while review-ing #357. The below steps are in decreasing order of details as the outcome of further steps can be significantly altered by new ideas coming up during execution of the first ones.
search_chunks
should return all the chunksCurrently chunks are identified in two distinct places during processing of a file: in
finder.search_chunks
which returns a list of only known chunks, then inprocessing._FileTask.process
we fill in the gaps between chunks and beginning and end of the input file.The basic idea is that search_chunks could do this preprocessing and in addition to that return an unknown chunk covering the whole file. Essentially, the following test change needs to pass:
This requires a separate change so that
carve_unknown_chunk
should be guarded the same way ascarve_valid_chunk
is: https://github.com/IoT-Inspector/unblob/blob/dbc104ffd3cbebd584af60e8f4fea548824b2a64/unblob/processing.py#L249-L256Given, that chunks are also ordered, it will also make the chunks in metadata ordered as an added bonus.
OO wrapping of chunks with operations to do on them
After the above changes, there are different possibilities to go forward, I'll just outline one possible way here.
_FileTask
to these objects.Adjust metadata creation
The primary goal of these changes is that chunk metadata handling can be encapsulated entiirely in the scope of of the
processing
module. E.g. chunk related information can be added to the new wrapping object created in the above steps. The new chunk abstractions also have access to the file path and arbitrary extra information we may add to them, so that we could also generate predictable id-s given the input path and offset-length pairs.