Brim desktop and ArchLinux


I have previously written about Brim on here, as I used it to solve a PCAP challenge from ISC. I hang out in the slack communnity for the project and like to give feedback and test drive betas. There are some really nice upgrades coming with the newest GA release 0.25. I have usually used Brim on a Debian based box but decided that I wanted to run the main tasks from my main workstation and delegate analysis to the remote box, seeing as remote workspaces is now a thing (and has been for quite sometime) more on this coming soon! My main workstation is a 8th gen 6-core i7 w/ 32gb of RAM running off a 1tb NVMe SSD. My choice of distribution is ArchLinux. The AUR has a Brim package that currently points to the latest release (which is 0.24). Before even installing you will notice in the comments that there is an issue with the bundled version of suricata. It is not able to use the libmagic version included with ArchLinux’s file command. These comments lead me to an issue filed under Brimcap repo on GitHub.

Currently the project provides images for .deb and .rpm based distributions. Which handles a huge portion of the linux user-base, since most easy/popular distros are derivatives of .deb/rpm such as Ubuntu and Fedora. There has been some chatter regarding potentially providing an AppImage as well, but the team is busy and most serious linux users should be able to manage. There are several routes we can take here, we can choose to build our own package that will track this latest prerelease-8d26e6e4 or Brim being electron based, git clone and build ourselves. I choose to create a PKGBUILD since I had never gone through the process.

The PKGBUILD article on ArchLinux’s wiki provided everything to complete this task. Granted this is a more generic pkg and I am sure things can get complicated quickly. From the article:

A PKGBUILD is a shell script containing the build information required by Arch Linux packages. Packages in Arch Linux are built using the makepkg utility. When makepkg is run, it searches for a PKGBUILD file in the current directory and follows the instructions therein to either compile or otherwise acquire the files to build a package archive (pkgname.pkg.tar.zst). The resulting package contains binary files and installation instructions, readily installable with pacman.

Every available package was created using the same process. All PKGBUILD scripts must contain the following:

  4. ARCH

The first 4 are REQUIRED for the PKGBUILD to run (and install) and a LICENSE.txt is not. But I choose to include this here to illustrate the importance of including this with your package, that way the end user knows how to use the software accordingly, depending upon which open source license the code is distributed under. While you can (and most do) deeclare those variables in that order, it is not a requirement. Let’s break down our what these mean:

  • PKGNAME: Package name or an array of names for split packages.
  • PKGVER: same version number as the upstream package as provided by the author. This should only contain underscores, but if the author distributes with hyphens, you can use $pkgname-${pkgver//_/-} for conversion each time you need to reference the version number.
  • PKGREL: Positive integer used to differiate between consecutive package builds of the same PKGVER.
  • ARCH: Architecture (e.g. x86_64)
  • LICENSE: License.txt of the open source license associated with the package.

A PKGBUILD is essentially just a shell script providing the instructions for makepkg to create our final archive (aka package) that pacman understands to be able to install it onto our Arch system. Let’s go!


I went ahead and downloaded the corresponding .deb package from the post to the #beta channel on slack. While the PKGBUILD script will actually retrieve the sources, I needed to generate a sha256sum to include in my PKGBUILD for both the .deb and License.txt for integrity checking. Having this sha256sum, am able to create the PKGBUILD.

# Created by Albert "electr0n" Gonzalez <> 

pkgdesc="Desktop application to efficiently search large packet captures and Zeek logs."
depends=('gtk3' 'libnotify' 'nss' 'libxss' 'libxtst' 'xdg-utils' 'at-spi2-core' 'glib2')
optdepends=('lsb-release' 'libgnome-keyring' 'pulseaudio')
sha256sums=('530d95c2f5dbba0a474012d75f920316516e032f9b298a4a973d0bc15df8d2b2' 'ebc2978c53b0f92bc5e5

package() {
    # extract to pkgdir
    bsdtar -O -xf "$pkgname-${pkgver//_/-}.deb" data.tar.xz | bsdtar -C "${pkgdir}" -xJf -

    # remove debian-specific files
    rm -rf "${pkgdir}/usr/share/lintian"

    # install LICENSE.txt
    install -dm755 "${pkgdir}/usr/share/licenses/${pkgname}"
    install "LICENSE.txt" "${pkgdir}/usr/share/licenses/${pkgname}"

We can now run makepkg -si which will install Brim for us.


I obviously already had the package made and installed, so your output will differ slightly, but ultimately will end up with the same results.


A fully functional Brim installation on ArchLinux. Now you are ready to take advantage of Brim’s integration of both zeek and suricata alert data. For the next steps, I will discuss leveraging our previous entry on packetStrider by integrating into the Brim workflow by creating a custom configuration for our zeek/suricata runners. Stay tuned.

You can find the built package and build scripts shown here on my github: