Expose samples on filesystem
geekscrapy opened this issue · comments
Ever thought of exposing the samples to the filesystem?
This way other tools can be utilised where a scale has not been made or can't be. I'm thinking use of IDA and then storing the db with the sample?
Or even storing a config file with the sample?
Apologies in advanced if I have miss interpreted the question, but I currently see it as follows. From a pure filesystem point of view this is exposed in the sense that it can be set to wherever you like using the config file. The samples are then stored under their SHA256 and nested down folders (that split based on the hash). So while accessible this is not very usable due to the folder nesting and use of hashes for identifiers.
Now from a more practical point of view we could see this more as the ability to store attachments/additional data for a sample stored in Snake. This could be implemented in a number of ways but the one that comes to mind would be to create a generic attachment scale and extend the Snake scale API to support an attachments component. This approach would then allow scales to store additional data that can be uploaded and downloaded (and maybe edited) while also tying it to a sample. Is this the sort of thing you were thinking? If so I can add this to the feature list and i'll try and work on it when I get some time, currently I am a bit swamped :S
First point - I didn't actually get round to looking at this before pressing submit :| my bad. I was actually dockerising the app and didn't check the filesystem!! Apologies for that! On the docker note, I've got a working container and hopefully a docker compose in the works, do you have one, or shall I make a pull request?
Second point, yes, this is half what I was thinking. The idea to add additional files would be great, hopefully, they would be subject to the same facilities etc. that a normal upload would have.
The second point, in a nutshell, yes - I've yet to test, but how does snake react to additional files being placed in the same dir as the sample? I'm thinking with the likes of IDA creating db files or general analyst notes (could the notes tab be exposed via the filesystem?!). You don't really need to allow the additional files in the hash dir to be subject to scales interrogation (although that would be nice!) - maybe as download links? Or an option to add the additional files to the db as an attachment to the main file (as you describe above) - for example an extracted config file, dumped shellcode, or injected proc etc.?
Any clearer? Probably just added confusion :)
I'll have a look at if I could add that kind of feature, see if I can get my head around the snake ecosystem.
We do not have one but I know that is definitely something that would be appreciated. A pull request for that would not be frowned upon, thanks :)
So I am not sure how well placing them in the same directory as the sample would work as multiple samples can end up in the same directories depending on their hashes. As such there are a number of solutions:
- when uploading a sample Snake will put it in its own directory based on the samples hash (then additional data can be stored in there too)
- create a separate directory structure that is used to store additional files (seems a bit cumbersome)
- store the additional files in the mongodb
- probably a few more good alternatives, but none spring to mind right now!
Snake is not 'filesystem aware' it uses the mongodb as its brain, thus additional files will be ignored. Currently I am thinking the first is probably the best solution, as it makes clean up and management easy, the negative point is that it would be a breaking change so a migration script would be required. Notes are stored in the Mongodb but extracting these to the filesystem using the chosen method above would be beneficial for the reasons you highlight and as image support could be easily added, etc. Exposing the additional files to scales would probably not work and I would argue that these should be submitted as new samples that are linked to the original.
With carved or extracted files from samples, if done from within Snake, these will be linked together producing a 'chain of custody', the binwalk scale currently supports this. Currently ties between samples cannot be manually added but this is on the list as it just needs exposing in the API.
There are also plans to create a project feature so that samples and notes can be grouped together, along with other projecty features. I have started to populate the issue tracker on snake-core with enhancements: https://github.com/countercept/snake-core/issues
Yeah much clearer, definitely features that should be added to Snake :)
That would be awesome, if any of the code is unclear just shout and I will try to clarify.