Skip to content

timdiels/sysintercept

BranchesTags

Repository files navigation

If you are looking for a windows hooking library/engine, try EasyHook or detours instead. The original intent of this repo was to rewrite file system paths in system calls of a process without having to use a virtual machine and without modifying the program executable that should see the fake file system. This repo contains a proof of concept, research notes and ideas. When I last worked on this, I was changing the build system directly on the master branch but the code itself looks about right. You'd likely have to go back a number of commits to find a version that works or build it with visual studio again.

The idea/goal: sysintercept allows you to intercept and modify win32 system calls done by a process. sysintercept provides a CLI. Aim is to allow rewriting paths, translating keyboard input, ...

Usage

At the command line:

sysintercept c:\full\path\to\config.xml relative\or\abs\path\to\something.exe

For config.xml syntax see this example to get an idea and sysintercept_config.xsd for full details.

This runs something.exe and applies rules of config.xml to it.

Shortcomings:

  • Does not pass on arguments to something.exe
  • Verbose logging that cannot be turned off.
  • Does not handle relative path
  • Catches only a couple of functions for path rewriting but misses many other ones.
  • Supports barely any rules currently.

How to compile

Apparently this requires zero install, you might be able to avoid that by looking for a build command in the zero install feed file, an xml file. You might also get visual studio to compile it as that's how I started out. These are the original instructions:

  • Setting up the environment:

    • Download and run Zero Install setup for windows

    • Open a command line and run:

      0alias 0compile http://0install.net/2006/interfaces/0compile.xml

    • Download and unpack the sysintercept source

    • In the root of the source, open a command prompt and run:

      0compile setup

  • Actual building (incremental build):

    0compile build

TODO get rid of these steps:

  • 0install
  • Install windows SDK (for VC++ toolchain)
  • boost and friends:

    • Install boost: Dowload and unpack this to C:\boost.

    • Install boost-log: Download and unpack boost-log files from sourceforge, to C:\boost.

    • Compile all boost libs, open "windows SDK 7.1 command prompt" (via start menu) and execute:

      cd C:\boost
bootstrap
PATH=%PATH%;C:\boost\bin
.\b2 --build-type=complete stage

    • Download and install codesynthesis msi.

Other notes

Performance

There is no emulation or virtualization involved. It injects a dll into the target process. The dll wraps all system calls necessary for the given config and only those, the hooking can be done dynamically without recompiling the dll.

Todo: python or lua would be more flexible than an xml config file, but would the overhead of python be acceptable for system calls? We could offer multiple mechanisms, e.g. for some cases python is fast enough. Rust might be a faster alternative. Either way it needs to be implemented first in c++ or rust.

Defeating the hook

The current implementation intercepts syscalls with user space techniques, by hooking into certain api calls. While programs can't avoid the hook on those api calls, they can still make system calls on their own without those api calls although it would be a fragile way of doing it and no sane program would do this unless specifically trying to thwart api hooking. Point being, this tool will never be a perfect sandbox and it certainly isn't in it's current state; so don't use it on malware. (See 2d, 2f, 2g of http://www.stanford.edu/~stinson/paper_notes/win_dev/hooks/defeating_hooks.txt.)

License

Project is covered by the GPLv3 license.

Libraries used in project:

  • distorm: Modified BSD license -> GPL compatible
  • ncodehook, ninjectlib: no license?
  • boost: boost license -> GPL compatible
  • CodeSynthesis: GPLv2

The original use case

This was the original use case for the tool but I no longer have a need for this.

  • Allow path redirects in ZI (http://0install.net) feed file.
    • redirect hardcoded file paths to correct location (location where binaries will be placed is impossible to know at compile time)
    • could be used to work with simplified view of environment's filesystem
      • /home: current user's homedir
      • /app/cache
      • /app/config
      • /media/...
      • and no more than those dirs. This way devs don't have to make a call to resolve a relative to an absolute path, the sandbox does it for them.

Design overview

sysintercept.dll: This dll intercepts win32 calls of whatever process it is loaded by.

sysintercept.exe: a cli interface, that starts a program and injects the dll into that program's process.

When sysintercept.exe runs:

  • it starts the child process in a suspended state,
  • makes the path to config.xml available in shared memory
  • modifies the IAT of the child process in memory, so it will load sysintercept.dll when started
  • resumes the child process and waits for it to finish

When the child process runs (i.e. when it is resumed):

  • it will load the dll,
  • during DllMain, the dll patches all relevant win32 calls (inline patching) so that they are intercepted
  • upon first win32 call, the dll will access shared memory, load and parse the xml file so that it knows what to do with intercepted calls. Note we couldn't do this in DllMain as many libs aren't loaded yet (e.g. IPC for shared memory), Dll main is very limited.

System call interposition methods

I.e. how to intercept syscalls?

For now process-level emulation, later I may also check for kmview/utrace support in the kernel and use process-level as a fallback. Well, should do another comparison perhaps, will we go for max security from the start etc?

Related projects (a fairly dated list)

API hooking:

App virtualization:

Sandboxes:

Process-level emulation:

System calls

A system consists of kernel-space and user-space. CPU has a mechanism for privileges. Kernel has privilege to access hardware directly, user-space has no such privilege and must ask the kernel to do so via a syscall. Syscalls can usually be done by CPU interrupts (x86 also has SYSCALL/SYSENTER (or call gates)); which to use depends on choices of the kernel. Most OSs provide a library to do this syscall interrupting.

Any well-behaved application will use that library. Though when wanting to offer security one should take into account the possibility of a syscall by manual interrupt without that library (or are the details of the interrupt so unstable that it'd be very hard to get this working?? and would that justify ignoring it? Also take into account, it may be statically linked into apps and libs)

PE executable format

Definitions

Virtualization vs sandboxing

  • application virtualization solutions:
    • a server from which software can be retrieved by clients,
    • something to record installed files into a single app file which can be uploaded to server
    • applications are ran by a virtualization component which modifies and passes syscalls (compatibility layer)
    • goal: easier to run app without installing, configging, ...
  • sandbox solutions:
    • applications are ran by a virtualization component which modifies and passes syscalls
    • or the kernel/libs are modified
    • goal: much greater focus on security/privacy than app virtualization

About

System call interceptor for windows

Resources

Readme

License

GPL-3.0 license
Activity

Stars

39 stars

Watchers

8 watching

Forks

14 forks
Report repository

Releases

No releases published

Packages

No packages published

Languages