In the past developing and compiling python software on Windows was a troubling process. Getting the python environment setup just right was quite tricky since one had to install MS Visual Studio, then get python to use it for building C code. The whole thing was fragile and hard to get right. This is why we traditionally ship Windows installers for Rekall.
These days the situation is much better. The new python setuptools integrates well with Visual Studio, and Microsoft is now shipping a free, stripped down version of Visual Studio that can be used to build python extensions (the whole thing is 85mb without any of the GUI stuff in it).
It is pretty easy to install Rekall from source on Windows and this blog post will illustrate the process. We also show how the binary distribution can be built from source using the installer.
Finally, we also cover how you could build a stand-alone version of Rekall which can be packaged on a USB drive or CD ROM in order to respond to incidents.
Starting with a clean Windows machine
I have built a fresh new virtual machine with Windows 8.1. The first step is to install python itself from http://www.python.org :
Download and install for all users. This typically stores the python installation in C:\Python27\
Next we show how to track the latest version of Rekall - download Git for Windows:
Get the clone URL from the Rekall github page:
Now clone the source to your home directory:
It is recommended that python development always use virtual env. If you are not familiar with Virtual Env it is a neat system which allows you to run a fairly isolated python installation inside a directory. This way it is possible to run several python projects with different and even conflicting dependencies. Once a virtual environment is activated, python code is run from within the environment's directory instead of from the system python installation.
A Typical procedure for setting up a development environment is:
- install virtualenv using the system's pip (This will install virtualenv in the system's python).
- Use virtualenv to create a new environment (A new directory with the necessary skeleton files to serve as the new environment). The new environment has only python and pip and so everything must be installed again in it. This helps to ensure that the environment is started with a clean slate, and all package dependencies are explicitly defined.
- The new environment is activated by running the <VirtualEnv Dir>/Scripts/activate script. Any new pip packages will be installed into this environment. (NOTE: Running a python program by association will run it with the system python. If you want to run a python script inside the virtual environment you should preceed the script name with python). eg:
- C:\> setup.py install ← Runs the system's python and installs into the system's main directory (C:\Python27\)
- C:\> python setup.py install ← Runs the virtualenv's python and installs into the virtualenv.
The Rekall source tree actually contains several packages with different setup.py files. The core of Rekall is in rekall/rekall-core/ so change to that directory and install. The installer will try to compile some C files and will probably fail at this point because it is trying to use Visual Studio to compile this but we don't have it installed yet.
In the old days this is the point where you have to mess with environment variables to get it to find the Visual Studio installation, but these days there is a special package shipped by Microsoft to make this process smoother. The installer even tells you where to get it:
Download and install it:
Now compilation should proceed without any problems:
Let's test our Rekall installation by doing some live analysis. First open an Administrator shell:
Now we need to activate our virtual environment inside this shell. The Rekall we just installed lives inside the virtual environment and therefore requires it to be activated.
We then run rekall -v live. The -v flag means to report verbose logging, while the live plugin tells Rekall to insert a driver and attach to it automatically.
We can run a simple plugin, say pslist:
Note that since the entire Rekall installation and all its dependencies are installed in the virtual environment you can simply blow it all away by removing the environment and making a new one (and activating it). This allows you to test building and installing packages from a clean system each time.
Another useful feature is to run "python setup.py develop". This sets the virtual environment up such that it will use the git repository for the python files. Therefore when you make a change in a python file, the change will be picked up immediately without needing to reinstall into the virtual environment.
Alternatively if you do not want to install the latest source, and only want to have the released version installed you may simply issue "pip install rekall" to have the latest rekall release and all its dependencies installed into the virtual environment.
Building the Windows binary installation.
Rekall is normally shipped with a nice installer which installs a pyinstaller built self contained binary package. This is a nicer way to deliver Windows applications because it does not require any special software like python to be pre-installed.
In order to build the nice windows installer, we need to install inno setup - the installer creator tool:
Finally we install pyinstaller with pip, and simply run the rekall winbuild.py script from the tools\installers\winbuild.py
Hopefully a windows installer is waiting for us:
Building a stand alone version of Rekall.
Sometimes when responding to incidents we want to have all our tools on a CDROM, file share or a USB drive and do not want to install anything on the system. In particular we sometimes do not want Rekall to go to the network by itself - e.g. to get a profile from the profile repository or the Microsoft Symbol Server.
How can we configure Rekall so it does not write on the system it is trying to analyze?
This is quite easy actually - all we need to do is to give Rekall all it needs and configure where it looks for things. Rekall needs two main things to run:
- Access to the profile repository - this can be over the web, or to a local directory.
- Access to a cache directory to store temporary files. You can either choose to provide a cache directory (e.g. on a writable USB drive) or not (in which case there will only be an in-memory cache - i.e. non persistent).
Obtaining a copy of the profile repository
If you don't want Rekall to contact the public profile repository, simply download a local copy. The profile repository is hosted on github so it can be git cloned:
git clone --depth 1 https://github.com/google/rekall-profiles
|
You can keep the repository up to date by periodically running git pull in that directory.
Let's create a new directory to store the AMD64 build of Rekall. We can copy the binaries created in the previous step (This assumes you built using the 64 bit python version).
The next step is ensuring that Rekall uses somewhere safe to write on. Normally rekall opens its configuration file in the user's home directory, but in this case we want to prevent Rekall from touching the user's home directory.
Rekall searches for its configuration file (.rekallrc) in the following locations:
- The directory of the Rekall executable.
- Current directory.
- The user's home directory. This is either taken from environment variables or can be set via the --home command line parameter.
- /etc/rekallrc for system wide configuration.
Note that if Rekall does not find a configuration file it creates a default file in the user's home directory (~/.rekallrc) and also a local cache directory in the user's home directory (~/.rekall_cache).
In our case we override the configuration by placing the .rekallrc right next to the executable itself.
The following configuration file places the home directory in the standalone directory (i.e. assuming we run from the standalone\AMD64\ directory), and then specifies the repository path and cache relative to that home directory. This configuration is suitable for a writable standalone USB drive (For example, this entire directory can be copies to a USB drive).
# This forces Rekall to assume your home directory is ../ .
home: ../
repository_path:
- $HOME/rekall-profiles/
# Do not use a persistent cache.
cache: memory
# We do not want to contact MS symbol server at all
autodetect_build_local: none
# Where Rekall will store cached files.
cache_dir: $HOME/rekall_cache/
|
When responding to an incident one has to simply mount the USB drive, change to the appropriate directory (e.g. D:\standalone\AMD64) and run rekal.
One of the first things you should do is acquire a memory image. This will acquire memory, pagefiles and any mapped files into the AFF4 image:
D:\standalone\AMD64> rekal aff4acquire my_image.aff4 --also_files
|
Building 32 bit windows binaries
The process for building x86 binaries is exactly the same as with 64 bit binaries, except one has to start with the 32 bit python distribution. I usually install the 32 bit python installation into C:\Python27.32 to keep it separate from the 64 bit installation. The binaries can be similarly copied into the standalone directory under e.g. I386.
Building OSX binaries
For OSX, one can similarly build binaries by running the script in tools/installers/darwinbuild.sh. The result is a directory containing a pyinstaller built Rekall, which can be placed into the standalone directory similarly to the Windows example above.