For those of you who didn't get the memo, Google announced the immediate availability of Google Rapid Response server 3.1 RC at yesterdays meetup. The client was updated to

It all looks quite similar when it comes to the UI, but there are some pretty neat improvements behind the scenes. As was a focus in the announcement, the GRR team mentioned the following noteworthy points:

  • Improved build-system with deployment through pypi (packages, install scripts and docker updates coming)
  • Streaming results to a BigQuery output plugin
  • Support for more artifacts
  • As mentioned in their brief roadmap, GRR now does delivery of dependencies separately from the client. They call these "components":
    • Rekall (now works faster, and has more Linux profiles).
    • Chipsec (new, does firmware verification)
  • As GRR provides the keys to the kingdom, ACLs have been much discussed. This is beginning to get quite advanced, so have a look at their previous meetups if you are looking for more information on this point. Anyways, in this release the ACL support is becoming more granular with ACLs for approvals - based on client labels
  • There is now conditional support in the Hunt UI (they added OR to the label selections)

The separation of the dependencies (Rekall and Chipsec in the first place) is a good move. This simplifies the development cycle. In addition it will be much easier to customize Rekall et al. I noticed that the separated packages are located at their Google drive. I had to dig a bit deeper to figure out how this is actually implemented, but /grr/client/ describes the essence. More on that later.

Further, for Rekall - there are now better profile coverage for Ubuntu kernels. It will also have much faster on acquisitions, due to applying compression on the client (the Google-developed Snappy-codec).

Now, while Google says to run this stuff successfully on Ubuntu - I had some minor challenges installing on Debian Jessie.


For the review I set up a clean Debian 8.0 development environment. I would recommend everyone to do that, due to the many changes in structure of GRR in version 3.1.

I needed to install the following packages to get everything working:

apt-get install libfreetype6-dev libxft-dev libssl-dev alien dh-make

In addition pyasn1 needed an upgrade: pip --upgrade pyasn1.

pip install grr-response-server --pre
pip install grr-response-client --pre

After installing I needed to install the configuration file manually from the package.

mkdir /etc/grr
cp /usr/local/lib/python2.7/dist-packages/grr/config/grr-server.yaml /etc/grr/

Now, the standard binaries and templates are needed. First create the directory structure:

mkdir -p /usr/share/grr/binaries
mkdir -p /usr/share/grr/executables/{windows/templates/unzipsfx/,linux/templates,darwin/templates}
cd /usr/share/grr/executables

Download memory drivers for OSX and Windows.


Note that pmem needs to be manually setup for Debian, as kcore seems to be disabled.

Now get all the new client templates:


Move the templates to their directories:

mv *.exe.* windows/templates
mv *.exe windows/templates/unzipsfx/
mv *{deb,rpm}* linux/templates
mv *pkg* darwin/templates
mv *.{sys,tar.gz} ../binaries/

You can follow the manual setup guide from the GitHub pages of GRR. Basically for a dev setup:

grr_config_updater initialize
grr_config_updater add_user joe
grr_config_updater update_user joe --add_labels admin,user
grr_config_updater repack_clients
grr_config_updater upload_memory_driver --platform darwin --arch amd64 --file OSXPMem-ng-signed.tar.gz
grr_config_updater upload_memory_driver --platform darwin --arch amd64 --file OSXPMem-ng-signed.tar.gz
grr_config_updater upload_memory_driver --platform windows --arch amd64 --file winpmem_amd64_1.6.1.sys 
grr_config_updater upload_memory_driver --platform windows --arch i386 --file winpmem_i386_1.6.1.sys 

Start the server components:

grr_server --start_http_server --config=/etc/grr/grr-server.yaml &
grr_server --start_ui --config=/etc/grr/grr-server.yaml &
grr_server --start_worker --config=/etc/grr/grr-server.yaml &

Note: In this release it seems like the enroller disappeared and became part of the server itself.

For this test, just install the deb-package on the server itself.

dpkg -i linux/installers/grr_3.1.0.0_amd64.deb


As mentioned previously, the current components binaries can be found on the GRR Google Drive. To illustrate the concept we'll grab the binaries for Debian. Note that the uploaded binaries is tied to specific versions glibc. You can find the version by executing ldd --version in the target environment.


grr_config_updater upload_component grr-rekall_0.3_Linux_debian_glibc_2.2.5_amd64.bin
grr_config_updater upload_component grr-chipsec_0.1_Linux_debian_glibc_2.2.5_amd64.bin

Components can be found the "Manage Binaries"

The docs states:

Now, flows that use the component can simply tell the client to load it if required.


Now to the really cool stuff, firmware verification.

An example of a flow using Chipsec is the Collectors/DumpFlashImage.

In my case, I had Debian running in a Virtual machine - so that was a platform/hardware support no-go.

ERROR: Unsupported Platform: VID = 0x8086, DID = 0x7190

If you're interested in more, follow the GRR team blog - they said that they'll be coming with more information there.