Skip to content

Windows Support

Updated Oct 9, 2017

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/

Host Abstraction Layer: Tubes

Updated Jan 12, 2017

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.

Host Abstraction Layer: File IO

Updated Jan 12, 2017

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. hal or filesystem which is an object which exposes this functionality. An example use-case is fetching a core file, one could just process.filesystem.open('core').read().

You can’t perform that action at this time.