Pre-post Explanation
Ok, before you hate on me for not using the official Kali image or [insert distro] here, there’s a reason I want to go with Arch Linux — to become more proficient with non-Debian-based Linux systems and have the opportunity to learn more about Linux as a whole. I could of easily grabbed an ISO for the latest Kali image and stood it up in as a VM in VMWare or VirtualBox and had all the tools readily available. If you’re an absolute beginner, that’s what you should do! However, I’ve done that many times over and it’s great for when you just need something to work (I’ll write about that process in the future). I want a bit of a challenge, the satisfaction of building a system exactly the way I want it, and all the headaches and bumpy roads that go along with it. So with that out of the way, let’s go into it!
The Journey to “I use Arch, BTW…”
I have an older (2013/2014) ASUS Q550LF laptop that had been a Windows 8/10 machine that I re-birthed as Kali around the early part of 2021. I used it a bit for going through HackTheBox retired machines and loved the fact that I had Kali on dedicated hardware. However, the OS really seemed sluggish over time despite the fact I was doing a pretty decent job keeping things up-to-date and maintained. So I started toying around with the idea of using Arch.
I first installed Arch on a super old HP laptop that only had 2 GB of RAM. That way if I screwed something up, it’s a laptop I really didn’t care about. That went reasonably well, so I tried BlackArch on another old laptop that a friend gave me, this time a Toshiba Satellite. It’s still operating quite well but there’s a few hardware issues with the track pad and keyboard. I even put ArchARM on a RaspberryPi just to get a little more experience with installation.
So I made up my mind to save down anything important from my old Kali instance, blow it away, and begin anew with Arch on the ASUS Q550LF. Here’s the specs and potential future upgrades:
- Display diagonal: 15.6 inch (touch display)
- Processor: i7-4500U 1.8 GHz
- Internal memory: 8 GB DDR3-SDRAM -> Will upgrade to 16 GB
- Graphics: NVIDIA GeForce GT 745M
- Storage: 1000 GB HDD -> Will upgrade to 1TB SSD
Still a highly decent machine for my purposes. Oh wait, other than the title, I haven’t talked about those purposes. This machine is primarily going to be for my OSCP studies. I’m going to take TJNull’s OSCP-like listing and make a post about each one to document my journey to the OSCP. I currently have a HackTheBox subscription, so I’ll be tackling the retired machines. I’ll use any and all resources at my disposal, including YouTube (looking at you IppSec) and the approved write-ups if I get stuck; however, if I use these resources, I’ll be sure to point that out. There’s no shame in looking this stuff up, especially when you’re rusty or just learning. That’s the whole point. I just want to document when I’ve referenced this material when it happens to both highlight the author/content creator (no plagiarism here) and showcase that it was a skill I needed to learn and didn’t just automagically figure out.
A quick note: I’m using both the standard Arch repository and the BlackArch repository, as there are just a ton of tools that I want to check out from BlackArch but haven’t gotten the opportunity yet. If you’re considering the same, check out the installation instructions for BlackArch.
The Path so Far
As you can tell in the screenshot, I’ve made a bit of progress towards having an aesthetically pleasing system (to me anyway). A huge shout out to Notusknot and his video for configuring bspwm (binary space partitioning window manager). I heavily used the dotfiles from his github page for inspiration and guidance. I’ll make my dotfiles available on github in case you want to similarly use my configurations. I may also write about the specific simple ricing I’ve performed thus far. For any updated configurations, check out my projects page for Arch.
Of course, there were a few things I had to RTFM and bang my head against the wall through trial and error to figure out — it’s the best way I learn, and I’d argue the best way most of us learn. One example of this was my laptop lid customization. I typically use this laptop docked to an external monitor and have the laptop lid closed. However, I wanted to be able to undock and take the laptop anywhere in the house and use it. And I wanted the ability to open the lid while docked and have an extra screen, if necessary. So that’s a total of three states of usage:
- Mobile – Just the laptop
- Docked – Both the external monitor and laptop screen
- Docked_noLid – Just the external monitor
To solve my problem, I used a combination of autorandr and acpid and took it one configuration at a time. Autorandr is an extremely simple tool that will automatically detect when your outputs have changed and will make the necessary adjustments based on the profiles you’ve saved. The acpid daemon essentially allows you to customize how acpi events are handled. Most of these events will be handled via systemd (if you’re on a systemd version of Linux), so there’s a few tweaks I had to make that I’ll get to under the Docked_noLid heading below.
Mobile
For the mobile configuration, it was as simple as saving the profile in autorandr while not being connected to my external monitor.
autorandr --save mobileDocked
Not as easy as the first, but relatively straightforward. You can use xrandr to set up your configurations as you see fit. One of the first things you must do is identify your display names. You can find this out by simply typing in:
xrandr
In my case, eDP1 is my laptop screen, while HDMI2 is my external monitor. I wanted my external monitor on the left as primary and my laptop screen on the right, so I used the following command:
xrandr --output HDMI2 --primary --output eDPI1 --right-of HDMI2Then I saved the profile:
autorandr --save dockedDocked_noLid
This part took me a couple of days to figure out for what most people would say is a silly reason — I didn’t want my mouse to be able to fly to the right of my external monitor into “nothingness;” I wanted everything smart enough to know that I’m only using the external monitor. The reason for this is that the laptop screen doesn’t ever “disconnect” on its own. I tried a few different solutions, but what eventually worked was:
- Use acpid to handle lid switches
- Disable lid switch handling in /etc/systemd/logind.conf
- Modify the /etc/acpi/events/anything file to handle only lid events (renamed to lm_lid)
- Modify the /etc/acpi/handler.sh file to handle the specifics of lid events
Here’s how my files look:
One very important element here are the two export lines. When X display begins during boot (if you’ve configured it that way), it runs as the root process, which means you as a normal user and your user-level processes do not have access to it. I used dbus-monitor a few times while opening and closing the lid during my tinkering, in which I kept getting errors relating to the acpid trying to read the events. This post helped put me on the right track to solving the problem which led to my end result above.
Once I had the configuration working, I saved it similarly:
autorandr --save docked_nolidPackages & Tools
Since a lot of programs have dependencies, I’m only going to list the major packages that I’ve installed as of this post, along with simple explanations of why (except for those under Installation):
| Installation | Main Repos | AUR | Offensive Tools |
| grub | vim: text editor | nerd-fonts-hack: awesome-enabled font I chose (glyphs/symbols) | nmap: port scanner to rule them all |
| efibootmgr | man-db: for man pages | brave: browser | burpsuite: browser proxy to rule them all |
| intel-ucode | man-info: for man pages | spotify: preferred music app | |
| base | texinfo: gnu docs | spotifyctl: for capturing ipc calls, controlling spotify, and updating polybar | |
| linux | networkmanager: you guessed it, networking | ||
| linux-firmware | which: terminal utility to identify installed programs | ||
| sudo: control privileged access | |||
| alsa-utils: control sound devices | |||
| nfs-utils: utilize file shares over the network | |||
| picom: compositor for transparency in apps | |||
| feh: background and image viewer | |||
| git: clone those repos! | |||
| base-devel: required if building AUR packages (need fakeroot) | |||
| autorandr: become lord of your output displays | |||
| lxsession: needed if you want to use lxappearance | |||
| lxappearance: modify gtk themes | |||
| cherrytree: notetaking app | |||
| neofetch: gotta be cool… | |||
| xorg: display server | |||
| xorg-xinit: manually start an xorg display server | |||
| nvidia: for nvidia graphics cards | |||
| rxvt-unicode: terminal emulator | |||
| xterm: backup terminal | |||
| lightdm-webkit2-greeter: for my themed greeter | |||
| ttf-hack: font I liked | |||
| lightdm-webkit-theme-litarvan: my themed greeter | |||
| flameshot: freaking awesome screenshot tool | |||
| firefox: browser | |||
| bspwm: tiling window manager | |||
| sxhkd: hotkeys and keybindings | |||
| polybar: nice status bars | |||
| dmenu: app chooser | |||
| nautilus: GUI file manager | |||
| xf86-video-intel: intel-based graphics drivers | |||
| mesa: open-source OpenGL | |||
| libpwquality: password security module for PAM | |||
| arch-audit: vulnerability checker | |||
| jre-runtime (Java 18): needed for burpsuite | |||
| acpid: daemon for handling acpi events | |||
| openvpn: for connecting to VPNs |
The Path Forward
I don’t have many actual pentesting tools installed yet, so that’s going to be a work in progress. I’m sure there’s going to be bumps along the way. I’ll be sure to document those bumps and any solutions I find so that if you face similar issues, perhaps it can help you through it. Also, one of my reasons for not just loading up on every pentesting tool I could find was that I want to document a sort of “tool box” as I go through TJNull’s list. This way I develop a portfolio of tools and attack techniques overtime and can definitively show what my “tool box” evolved into at the conclusion of the training.
Conclusion
I think I have the baseline system down and the aesthetics I wanted, so it’s just time to get to work on TJNull’s list! If you’ve got any suggestions on things I need to add/change, or maybe you want to share your system ricing photos, drop a comment below. I’m still an Arch newbie, so I’ll take all the help I can get and I thoroughly enjoy checking out others’ creativity.