importantchoice
commented
7 years ago @D-Kern okay, I think this metadata class might work. having this multi file complexity in our program might make things difficult to understand. I created a FAT FileSlack module in the 'fileslackimpl' branch, so if you need an example how this all should work, have a look at it.
The main thing is, that we should use a wrapper class (fileSlack.py) that does the metadata handling. This way our cli stays realtively clean and our hiding technique implementation stays reusable and generic.
The key concept to use this metadata class for a hiding techniqe is the creation of a "sub-metadata" class, that holds the actual data for a hiding technique and is defined by every hiding technique.
e.g. for the fat file slack module I wrote the class FileSlackMetadata. It only contains a list, which gets filled with tuples of (cluster_id, offset, length) while we are writing a file into slack space. This write method gets called by the wrapper class (in fileSlack.py) and returns this sub-metadata object. The wrapper class, then creates a new file entry in the Metadata object by calling add_file(filename, sub_metadata).
Hope this explaines it well enough to understand the concept.
Oh, with the last merge the commit log is a little bit confusing. The only interesting thing in this pull request is the file fishy/fishy/metadata.py
Most hiding techniques probably need a way to store metadata between writing and reading data. E.g. the cluster_ids where some data was written to, or the length of the hidden data. This metadata class tries to provide a unique interface for this purpose.
Please have a look at it. Shall we use it? Or are there better ways to do this task?