Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filetype Adapters #69

Open
DakotaNelson opened this issue Nov 1, 2015 · 3 comments
Open

Filetype Adapters #69

DakotaNelson opened this issue Nov 1, 2015 · 3 comments

Comments

@DakotaNelson
Copy link
Owner

We have (or are developing) a lot of channels that require the same "file type" as input: images, sound, text, etc.

For text, this is easy, but - for instance - why does Soundcloud contain code to convert the incoming data into a valid WAV file? This seems like it should go in another place, so that other channels which need it can reuse the code.

This would enable channels to simply specify that they need data in the form of a WAV file, or JPG, etc., and have the framework handle the details.

It would also help encourage multiple methods of file encoding (e.g. data can be encoded directly into JPG images using stegonography, appended after the end of the JPG image data, or encoded as black and white pixels as seen in #68) and make it easier to explicitly expose options for the filetype adapters (e.g. how many bits to change in the case of stegonography) and enable more advanced techniques (e.g. downloading music to use for stegonography instead of generating white noise) to be swapped in or out as desired to trade off between simplicity (reliability) and stealth.

@davinerd
Copy link
Contributor

davinerd commented Nov 4, 2015

So are you thinking about creating a class (FileType) that should be use inside the channels, or about a class that should be use by exfil.py?

It can be tricky both ways, and we can use a different approach depending of our point of view, but the code should be redesigned a little bit anyway.

@DakotaNelson
Copy link
Owner Author

The idea is that the channels would have a parameter along the lines of requiresFileType and then the chain would go:

(optional) encoder -> (optional) encoder -> filetype adapter -> channel

with the filetype adapter being chosen by the framework automagically based on the channel's required filetype. Could then be upgraded to having several filetype adapters for a single filetype, and letting the user choose (or defaulting to a good one if no preference is specified).

@davinerd
Copy link
Contributor

I think I need a PoC for this, can't figure by myself, sorry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants