Desktop trickery with Xfce4’s terminal and wmctrl

Screenshot_2017-05-03_19-51-54Here’s a nice and simple way to embed Xfce4’s Terminal onto your desktop wallpaper.  This works across all virtual workspaces that are present, and removes it from the window list on your taskbar.

Copy this small shell script and save the file somewhere; Adjusting the configuration section to suit your own preferences., then making it executable;


# configuration

# end configuration

xfce4-terminal \
 --hide-scrollbar \
 --hide-borders \
 --hide-toolbar \
 --hide-menubar \
 --title=desktopterm \
 --geometry=${COLS}x${ROWS}+${XPOS}+${YPOS} &

sleep 1
wmctrl -r desktopterm -b add,below,sticky
wmctrl -r desktopterm -b add,skip_taskbar,skip_pager

Before running this, you may want to check if you have wmctrl installed. It’s important because Xfce4 does not have any window management tools for the placement of windowed applications. You then might want to add this script to your session startup programs, which you can find in the Xfce4 Settings menu. Then either logout/back in, or run the script manually. You should now have an Xfce4 terminal which is embedded onto your desktop wallpaper.

You could even right click the terminal, set the transparency to maximum, so that it fully blends into your wallpaper.

To go a step further, you could have it automatically run a program instead of just the terminal prompt; adding a section like this:

Posted in Desktop, Linux, Uncategorized | Tagged , , , , , , , , | Leave a comment

Using proxychains to become (mostly) anonymous

If you’ve ever wanted to mask your IP address (whatever the reason) you’ll be aware that using a proxy is the first thing to do.

Possible motivations might include:

  • Geoblocking
  • State Censorship
  • Local Network Firewall
  • Privacy
  • Illicit activity

Using one proxy is standard for most uses, let’s say your network administer restricted a certain IP address/domain and you wanted to get around it, one proxy will suffice.

In other scenarios, you’d want to think of using multiple proxies which are chained together to further enhance privacy. This is called a proxy chain. It’s a series of proxies linked together to further obfuscate a users source IP address.


The Tor network works in a similar fashion, which consists of multiple nodes being chained together with several hops as a means to hide the origin of any connection. However, many Tor exit nodes are known to be run by rogue entities such as the NSA. Treat any kind of proxy (or Tor node) as compromised by default, unless you are the one who is running it.

Whilst Tor has the benefit of encrypting traffic passing between nodes, this becomes irrelevant if every node within the connection is compromised.

Using a series of chained proxies alongside Tor can further enhance privacy. When considering that many rogue nodes exist. Whilst rogue socks proxies are also a thing, there are so many of them available that it would be much harder to directly control a vast amount of them. You can however, utilise Tor within a proxy chain for added obfuscation. The important thing would be to make sure that Tor is not the last hop within the proxy chain. It’s wise not to use a Tor exit node as your actual endpoint address in some scenarios.

In some cases, many websites will block known Tor exit nodes from accessing any content. Using a socks proxy chained onto Tor can help avoid that.

If you plan on accessing a service which is only available through the Tor network (the darkweb) then you will probably have to use Tor as the last proxy within the chain for obvious reasons when resolving an onion TLD.

To get started on Linux (i’m using Slackware here), you’ll want to get hold of an application called proxychains.

On Slackware you can find it in the repository. Most other distributions should probably have it included in the network category of your package manager.

Once you’ve built/installed the application you’ll want to edit the file /etc/proxychains.conf, The default configuration should be fine as it is, but you’ll want to provide a list of proxies for the software to use. At the bottom of this file is the section where you enter the proxies to be used:


As you can see the software is setup by default to use the Tor network, assuming you have the daemon/service up and running on your system. This will work by using Tor alone.

To get around the problem i hi-lighted above relating to Tor exit nodes, we can supply an additional socks proxy, creating a proxy chain.

Grab a bunch of socks proxies from your favourite proxy lists,  for example here are some open socks proxy websites that list some:

I’d recommend checking a whole bunch at once using a script. But there are plenty of proxy checker tools out there that are easy to find.

Once you’ve managed to find several working socks proxies, we can now add these to our proxy chain. So get the IP address and the port number of a working socks proxy, and place it into the proxychain config file:

socks4 9050
socks5 YY.YY.YY.YY 3041
socks5 ZZ.ZZ.ZZ.ZZ 1337

We can use Tor (socks4 9050) within the proxy chain somewhere if required. After saving the file, you should now be able to connect to a service where your endpoint is the last proxy in the chain.

Connect to a website such as using curl to confirm the proxy chain is working correctly.

$ proxychains4 curl

If all of the proxies in the chain connected, then you should see something like this:


Noticing that the website detects your IP address as the last one configured in the proxychain. You can now use this command in front of any other to force all connections through the proxy chain. It’s worth remembering that the more proxies you have chained together, the longer it takes to connect to a service and timeouts WILL happen frequently.

$ proxychains4 firefox
$ proxychains4 hexchat
$ proxychains4 nmap XX.XX.XX.XX

If that’s not enough, you can also change the type of chain used in the proxychain configuration file, to randomise the order in which the proxies are chained together.

It’s always important to remember than many open socks proxies could potentially be harvesting user data and acting as honeypots for user credentials. So be careful of any information leakage, such as entering login/password forms for personal accounts.  Socks proxies are not always safe, you will from time to time find a rogue proxy designed to replace certain content (such as injecting javascript into a webpage) and this can be rather dangerous when combined with browser exploits, and one of these could just turn you into a bot!

Whilst using any kind of proxy, you are never fully anonymous. Privacy is really just an illusion, but it can make things harder to track. Using a combination of Tor, socks(4/a)(5) and randomisation of the proxy chain can help obfuscate the source of a connection.

UPDATE: It turns out you cannot establish a connection to the Tor network using proxychains unless Tor is the first proxy in the chain.

Posted in Desktop, Linux, Network, Privacy | Tagged , , , , , , , | Leave a comment

Using the Linux -pf kernel on Slackware

The pf kernel is a fork of the Linux kernel containing several patches to help with desktop responsiveness. You can read more about it here at the official website:

In brief it contains these patches:

-ck patchset with MuQSS
The -ck patches are designed to increase responsiveness and interactivity on desktop systems. Multiple Queue Skiplist scheduler is a desktop orientated CPU scheduler, with extremely low latencies. A variant of the BFS Brainfuck CPU Scheduler.

BFQ I/O scheduler
BFQ (Budget Fair Queuing scheduler) is a proportional-share storage-I/O scheduler that also supports hierarchical scheduling with a cgroups interface.

graysky’s kernel GCC patch
Adds a kernel option for CPU type that will allow you to compile a kernel optimized to your CPU. There is also a native option which is not unlike using “-march=native” via CFLAGS.

Here’s how to get this kernel up and running on Slackware Linux;

Head to the -pf patch homepage at and obtain the latest patch, along with the latest Linux kernel sources from

At the time of writing, the latest patchset is 4.10-pf2, so you would want to download the 4.10 version of the Linux kernel.

Open up a root terminal, and place the downloaded archives into /usr/src on your system.

  • linux.4.10.tar.xz
  • patch-4.10-pf2.xz

Decompress the Linux tarball;

# tar -xvf linux-4.10.tar.xz

Decompress the -pf patches using:

# xzcat patch-4.10-pf2.xz > linux-4.10/patch-4.10-pf2

Now head into the kernel source directory:

# cd linux-4.10

Apply the patchset to the kernel:

# patch -Np1 < patch-4.10-pf2

If everything went fine (no error messages) you can now start to configure the -pf kernel.

The first thing to do is get your kernel config and copy it to “.config” in the kernel source directory. If you do not have an existing config, you can copy Slackware’s generic kernel config from the /boot directory.

# cp /boot/config-generic-4.4.38 .config

The next step is to configure the kernel, i’d recommend using the ncurses display, as i feel it’s the easiest to use.

# make nconfig

Head to “Processor type and Features” and change the “Processor Family” to Native Optimizations.

This will enable the kernel to use CPU instructions optimized for your exact CPU model. Similar to the behaviour of “-march=native” when used with CFLAGS for compiling any other software. Be warned that this setting will mean that the kernel can only run on the exact CPU model it was compiled on. So if you plan to compile this kernel for another system, you may not want this option included in the patches. You can skip this if that is the case.

Enable the rest of the -pf features provided by the patch like so;

General Setup -> “MuQSS cpu scheduler” (set to “Y”)

Enable the block layer -> IO Schedulers -> “BFQ I/O scheduler” (set to “Y”)

If you want BFQ as the default IO scheduler:
Enable the block layer -> IO Schedulers -> “Default I/O scheduler” (set to “BFQ”)

If not, you can enable it per disk after booting into the new kernel, for example:

# echo bfq > /sys/block/sdX/queue/scheduler

Where X is the allocated letter for your disk that should use bfq. For example; if your root disk was allocated as /dev/sda, you would write sda here.

Once you’ve finished making any additional changes save the config, and exit the configuration menu, you can now build the kernel.

# make bzImage

This may take a while depending on your CPU. You can speed it up a little by adding “-jN”, where N is the number of “cpu cores”+1, so if you have a cpu with 4 cores you would run “make -j5 bzImage”.

When that’s finished, start building the kernel modules:

# make modules

Then install the kernel modules to the system:

# make modules_install

Copy the kernel image into your /boot directory:

# cat arch/$(uname -m)/boot/bzImage > /boot/vmlinuz-pf

Copy the file:

# cp /boot/

Then rebuild initrd, using the mkinitrd helper provided in /usr/share/mkinitrd:

# /usr/share/mkinitrd/  -k 4.10.0-pf2

The output will suggest something similar to this:

# mkinitrd -c -k 4.10.0-pf2 -f ext4 -r /dev/sda1 -m usbhid:hid_generic:xhci-hcd:ext4 -u -o /boot/initrd.gz

However, we don’t want to overwrite Slackware’s “generic” initrd, so we have to modify the last part to write to /boot/initrd-pf.gz.

Simply, adjusting it like so:

# mkinitrd -c -k 4.10.0-pf2 -f ext4 -r /dev/sda1 -m usbhid:hid_generic:xhci-hcd:ext4 -u -o /boot/initrd-pf.gz

The final step is to add this kernel to the bootloader, so that we can actually boot into it.

Assuming your new kernel compiled successfully, you’ll want to add a section to LILO’s bootloader config.

Open up /etc/lilo.conf and insert a bootloader section for this new kernel:

image = /boot/vmlinuz-pf
  initrd = /boot/initrd-pf.gz
  root = /dev/sda1
  label = "4.10.0-pf2"

One thing to make sure of, is that “root” is set to the correct disk, depending on how you partitioned your system originally.

Update LILO:

# /sbin/lilo

Hopefully everything went well, and you will see the kernel appended to the list of bootable options as “Added 4.10.0-pf2 + *

You should now be able to reboot the machine and boot into the new -pf kernel on Slackware Linux.

Additionally, you should also rebuild any out of kernel modules required for your system, such as the nVidia driver being one example. In the case of Slackware, assuming you are using the build scripts for, You can build a kernel module for this kernel quite simply:

# KERNEL=4.10.0-pf2 ./nvidia-kernel.SlackBuild

That’s all there is to it!

Posted in Desktop, Kernel, Linux, Slackware | Tagged , , , , , , , , | Leave a comment

Revisiting conky

Conky is a great application for system monitoring in real time. It’s been a while since i’ve last used it on my desktop regularly, mostly because i had been running the KDE desktop for a long period and found the system monitor widgets fitted into KDE more. Since i’ve started using the XFCE desktop again lately, i recently started tweaking together a conkyrc file for my own use.

Here’s what i came up with;


Admittedly it’s not perfect, and could do with some background shading for more readability, but i like this how it is. It blends well with this desktop wallpaper i’m currently using.

You can get the conkyrc here:

If you want the wallpaper to go with it, i uploaded it here (can’t attribute the author, as i found it via google images a long time ago)

(You’ll probably want to adjust the RSS information if you do use it!)

Posted in Desktop | Tagged , , , | Leave a comment

Reverse Engineering a USB mouse (Updated 3rd May 2017)

This week my Zalman optical computer mouse died on me, I’ve had it for almost 4 years, so it did last a good while. The scroll wheel started to slip causing a very annoying issue of documents rolling about by themselves, so i threw it in the bin and went out and purchased a new one.

I ended up getting a new mouse from the local ASDA supermarket, sold under the name of ‘BlackWeb AYA gaming mouse’. Mostly because i thought it looked rather cool with it’s LED colour changing feature, as well as the fact that it was only £21.

(If you’re just looking for the software to control the BlackWeb AYA mouse LED from Linux, scroll to the bottom of the article and you’ll find the links to my github repository.)


The packaging of the BlackWeb AYA mouse

The device features are advertised as;

  • 16.8 million colours
  • 12,800 dpi optical sensor
  • on the fly dpi switching
  • 1,000Hz polling rate
  • breathing light effect
  • macro manager
  • 6 programmable buttons
  • software included

What interested me is that the box didn’t mention any specific OS support (not even a mention of Windows), so i took a gamble hoping it might just have full Linux support. I was obviously wrong.

Upon first connecting it to the computer, the mouse immediately lit up red as the default colour, and it worked like any other generic HID device, requiring no special drivers to function. This is what appears in `dmesg

[    5.912200] usb 9-1: New USB device found, idVendor=3938, idProduct=1101
[    5.912202] usb 9-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    5.912203] usb 9-1: Product: Blackweb  Optical Gaming Mouse
[    5.912204] usb 9-1: Manufacturer: Gaming Mouse
[    5.919435] input: Gaming Mouse Blackweb  Optical Gaming Mouse as /devices/pci0000:00/0000:00:13.0/usb9/9-1/9-1:1.0/0003:3938:1101.0002/input/input3
[    5.956392] hid-generic 0003:3938:1101.0002: input,hidraw1: USB HID v1.11 Mouse [Gaming Mouse Blackweb  Optical Gaming Mouse] on usb-0000:00:13.0-1/input0
[    5.961789] input: Gaming Mouse Blackweb  Optical Gaming Mouse as /devices/pci0000:00/0000:00:13.0/usb9/9-1/9-1:1.1/0003:3938:1101.0003/input/input4
[    6.013350] hid-generic 0003:3938:1101.0003: input,hiddev0,hidraw2: USB HID v1.11 Keyboard [Gaming Mouse Blackweb  Optical Gaming Mouse] on usb-0000:00:13.0-1/input1

The device listed under `lsusb

$ lsusb | grep 3938:1101
Bus 009 Device 002: ID 3938:1101

As you can see it is using the generic HID driver. The first thing i wondered, was how to change the LED colour, because the mouse only came with a CD containing software for a windows driver.

I searched through /sys and /dev for a while trying to find something representative of the colour red, hoping i may just be able to “echo” an RGB colour value to the mouse, but had no success.

I ended up finding a solution to manually set the mouse polling speed through the usbhid module,


options usbhid mousepoll=1

Where 0=default, 1=1000Hz, 2=750Hz, 4=500Hz, 8=250Hz

So that was that out of the way.

Next i went ahead and had a look at the Windows software by setting up a Windows 10 virtual machine. After enabling USB pass through for the mouse, i installed the driver and opened the driver software, setting the mouse LED to a custom colour, and this set the LED as expected. The interesting thing was that after closing the virtual machine (and even powering off the host system), the mouse continued to stick to the same colour. So the mouse stored the colour value on the hardware itself as a persistent setting.


The Windows driver software running in the virtual machine

I left it at that for a day, being a simple solution, until i came across a forum post mentioning Wireshark has USB sniffing capabilities. After alot of searching i realised it might be possible to reverse engineer the device to control it from Linux natively. Despite having never done anything like this before.

The first thing to do was check which USB Bus the mouse was connected on, `lsusb‘ provides that information, and in my case it was Bus 009. So heading into Wireshark, i set the sniffer interface to usbmon9.

To avoid getting alot of spam information in the packet capture from other devices, i used a second connected mouse to perform any clicking whilst the packet capture was running, and also setting a filter rule within Wireshark like so:

usb.bus_id == 9 && usb.device_address == 2

The first step was to open the driver software, set a new colour for the LED, and then stop the packet capture. To my surprise i spotted the RGB colour value of the newly set colour in a datastream heading from the host to the USB mouse.


The colour i had set (as hexadecimal RGB) was FF8041

0000   c0 63 e4 97 01 88 ff ff 53 02 00 02 09 00 00 00  .c......S.......
0010   52 38 d5 58 00 00 00 00 9b 0c 01 00 8d ff ff ff  R8.X............
0020   08 00 00 00 08 00 00 00 21 09 07 03 01 00 08 00  ........!.......
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0040   07 0a 01 00 ff 80 41 00                          ......A.

The relevant part of this datastream is:

0000   07 0a 01 00 ff 80 41 00

The next step is to understand what the other information does. The colour value is surrounded by 00’s, assuming these are separators/padding. We then have 3 bytes left at the beginning, which i could only assume is a command to set the LED to the colour that follows.

I managed to whip up a small python script using PyUSB to interface with the mouse, that allowed this command to be sent to the mouse from within Linux natively.

Here’s an example showing how the request/command can be replayed, to tell the mouse to turn the LED blue:

import usb.core
import usb.util

# find the device
dev = usb.core.find(idVendor=0x3938, idProduct=0x1101)

# detach the kernel driver

# set a hardcoded colour
colors = [0x00, 0x00, 0xFF]

# concatenate the colours into the expected 8 bytes
data = [0x07, 0x0a, 0x01, 0x00] + colors + [0x00]

# send the data to the mouse
dev.ctrl_transfer(bmRequestType=0x21, bRequest=0x09, wValue=0x0307, wIndex=0x0001, data_or_wLength=data,timeout=1000)

# reclaim the device

The values for bmRequestType, bRequest, wValue and wIndex were all present in Wireshark for the captured frame. So simply filling them in the same here appeared to work.

To my amazement the mouse LED instantly turned blue! But there was a small issue. Upon rebooting / powering off the machine, or simply hotplugging the device, meant the mouse would reset to its default colour each time (or the last colour that was set from within the virtual machine).

I realised there must be another command which tells the mouse to store a persistent colour. So going through the packet capture log once again, trying anything that contained a datastream seemed like a logical approach.

Under Windows when setting the LED colour, the mouse flashes 5 times momentarily, and i hadn’t seen this from setting the LED colour through a PyUSB script.

I’d almost given up, after several hours of trying absolutely everything in the packet capture, but eventually found it:


0000   40 38 f6 a8 01 88 ff ff 53 02 00 02 09 00 00 00  @8......S.......
0010   52 38 d5 58 00 00 00 00 a6 ef 03 00 8d ff ff ff  R8.X............
0020   08 00 00 00 08 00 00 00 21 09 07 03 01 00 08 00  ........!.......
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0040   07 04 01 28 00 00 00 00                          ...(....

Sending these 8 bytes to the mouse, triggered the LED to flash 5 times!

0000   07 04 01 28 00 00 00 00

Hotplugging the mouse, now kept the colour persistent. Simply adjusting the ‘data’ variable to contain these 8 bytes worked flawlessly to store the colour onto the hardware as a persistent setting. I suppose it is like a “save” command.

data = [0x07, 0x04, 0x01, 0x28, 0x00, 0x00, 0x00, 0x00]

The mouse set to a custom LED colour!


I ended up putting together a slightly better script to set and store the LED colour of the mouse. You can get the code from my github repository here:

Or by cloning the repository directly from a terminal:

$ git clone

It’s as simple as running the below command, where each argument is the RGB value to set.

# ./ 50 100 255


I have since started working on a PyQt based interface to control more features easily, which includes a colorpicker widget, after cloning the git repository you can launch this by running:

# ./

It still needs some improvements, but should be useful for changing the settings more easily (including profile slots and polling rate!).


If this helped you with the BlackWeb AYA mouse on Linux (or helped with you reversing a different USB mouse) I’d love to hear about it! Cheers.

Posted in Hardware, Linux, Reverse Engineering, Uncategorized | Tagged , , , , , , , , | Leave a comment