Why not support Windows?
Ideally, we should support any NT variant that can have Python -- so Windows NT4 would be great.
Realistically, getting things running under the Windows 10 emulation layer would be nice -- but the terminal stuff is broken. We should detect this.
Native support for Windows would be nice for things like popping Windbg: https://www.securifera.com/blog/2017/06/18/defcon-ctf-2017-divided-writeup/
Similar to the "Filesystem" abstraction layer, we should also extend the available operations to reflect basic tube instantiation.
For example, let's say that I have a process-like object (which may be local, remote via SSH, or via ADB).
I ma want to spawn another process on the same host (e.g.
gdbserver to attach to it), or listen on a port, or create a connection.
Currently, this is difficult and has some special-case code -- an abstraction layer would make things nice and neat.
A lot of the code is littered with conditional checks against types of objects, to see if they are e.g. a local process, SSH process, or Android process.
This code would be greatly simplified if there were an abstraction layer that provided basic file I/O. Since the bounding set on functionality is what is provided by Paramiko's SFTP object, we should just implement that interface.
For things which resemble processes, we can add a property e.g.
filesystem which is an object which exposes this functionality. An example use-case is fetching a core file, one could just