Bytefreaks.net – a place for hacks

fedora

Recently we wanted to process some media on a Fedora 26 running under a Qubes OS 4.0 installation, we decided to use ffmpeg which is not part of the default repositories but it can be found in the RPM Fusion repositories. To do so, first we updated our system and enabled the RPM Fusion repositories as follows:

Then, we updated the system once more so that the information from the new repositories would get downloaded to our system and then we performed the installation of ffmpeg. While installing ffmpeg, since it was the first time that we were using the new repositories we were asked to verify the keys that were imported. We were able to manually verify the keys from this page.

Recently we wanted to process some media on a Fedora 28, we decided to use ffmpeg which is not part of the default repositories but it can be found in the RPM Fusion repositories. To do so, first we updated our system and enabled the RPM Fusion repositories as follows:

Then, we updated the system once more so that the information from the new repositories would get downloaded to our system and then we performed the installation of ffmpeg. While installing ffmpeg, since it was the first time that we were using the new repositories we were asked to verify the keys that were imported. We were able to manually verify the keys from this page.

YARA is a tool aimed at (but not limited to) helping malware researchers to identify and classify malware samples. With YARA you can create descriptions of malware families (or whatever you want to describe) based on textual or binary patterns. Each description, a.k.a rule, consists of a set of strings and a boolean expression which determine its logic.

Recently, we tried to compile YARA on a Fedora 23 GNU/Linux (running through a qubes-os version 3).
As the installation guide is directed towards Ubuntu/Debian users, we soon found out that the installation had some missing dependencies. Below, you will find all the steps we followed to download YARA / install its dependencies and build it enabling as all optional features.

There is this machine that runs Fedora GNU/Linux, for which its owners asked us to block all USB Storage Devices without affecting other peripheral devices like keyboards and mice. The reason for that was to prevent unlawful data leakage that the users of that machine could do.

On Linux there is a kernel module named usb_storage that can be found at /lib/modules/$KERNEL_VERSION/kernel/drivers/usb/storage/usb-storage.ko.xz (to get the kernel version, execute uname -r;) which operates as the USB Mass Storage driver for Linux.

Apparently, we just needed to block the usb_storage module. Initially, we tried to block the module by using the /etc/modprobe.d/blacklist.conf file but with no success. We failed to blacklist the module using the following commands (we were not sure which of the two names are correct, so we tried both, one at a time. It appears that both can be correct..):echo -e "usb_storage\n" | sudo tee -a /etc/modprobe.d/blacklist.conf;
echo -e "usb-storage\n" | sudo tee -a /etc/modprobe.d/blacklist.conf;
After creating/updating the blacklist.conf file we restarted the machine as the module does not get loaded on boot automatically, it only gets loaded when needed. Unfortunately, as we mentioned before, these attempts led to no solution as we were still able to use USB storage devices even after creating the blacklist.conf file.
Since this method failed, we had to turn our heads towards a different solution, that due to its nature, it can be considered a hack.

Solution

What we did was to create a new configuration file in /etc/modprobe.d/ that would prevent usb_storage from being loaded by redirecting any requests to load the specific module to the /bin/true application.

Then, we had to make sure that the module was not already loaded. To see if the usb_storage module was already loaded we executed:

lsmod | grep -i usb_storage;

When lsmod | grep -i usb_storage; did not return any results, then it meant we were done! Since it was not in the list, it meant that the module was not loaded and so the next time someone tried to use a USB mass storage device they would not be able to load the module.

In cases were we got a line back (and thus the module was already loaded), then we needed to unload it manually or restart the machine. To avoid rebooting the machine we used modprobe to unload the usb_storage module.

modprobe -r usb_storage;

Some times, we would get the following error: modprobe: FATAL: Module usb_storage is in use.. This error meant that some other kernel module was using usb_storage and would not allow us to unload it. Using lsmod | grep -i usb_storage; we would get back a line like the following: usb_storage 73728 1 uas. The last column is a comma separated list of kernel modules that use usb_storage and we would need to unload them as well (replacing commas with space characters). Since we had only one dependency, our command became like the one below:

modprobe -r uas usb_storage;

And we were done!

To Re-enable USB mass storage devices (revert)

That is the easy part, to re-enable access to the USB mass storage devices, all we had to do was delete the configuration file:

rm /etc/modprobe.d/disable-usb-storage.conf;

Of course, to block them again, the we would have to follow the steps in the above solution.

There was this Fedora box for which we were asked to disable most of the methods it had available for communicating with the outside world.
One of the features of the box that we decided to block was its Bluetooth device.
To make our life easy, and since the users would not have admin rights, we decided to simply stop and disable the Bluetooth service on the box and be over with it!

The way we stopped and disabled the Bluetooth service was with the following two devices.

#Stop Bluetooth service that is currently executing
systemctl stop bluetooth;
#Prevent Bluetooth service from starting after a reboot
systemctl disable bluetooth;

Once you disable the service and stop it, you will notice that on the GUI of the Gnome settings application it still shows the basic menu for the Bluetooth device.
That should not worry you though because if you enter the Bluetooth configuration tab you will notice that the user will not be able to turn the device on and make use of it.

Revert changes and re-enable / re-start the Bluetooth service:

In order to restore the Bluetooth service back to normal (to enable it and start it), just execute the following two commands:

#Start the Bluetooth service right now
systemctl start bluetooth;
#Make sure that Bluetooth service will start after each system restart
systemctl enable bluetooth;

Recently we were working on a Fedora 27 GNU/Linux box where we needed to completely disable the Network Manager.
Initially, we just stopped the NetworkManager service and then disabled it thinking that it would be enough.
To our surprise after we rebooted the box, we noticed that the Network Manager was active again!

After some research we found out that another service called NetworkManager-wait-online was starting the NetworkManager as some sort of recovery mechanism.
So, in order to permanently block NetworkManager from starting on boot, we disabled NetworkManager-wait-online as well.

In the end our solution to disable the NetworkManager service came down to executing the following commands as root (or using sudo):

To resolve this, we added to the file Onboard-SDK/osdk-core/platform/linux/inc/linux_serial_device.hpp the following include directive right after line 37 (which contained #define LINUXSERIALDEVICE_H):

As mentioned in a previous post, we installed OBS studio on our machine in order to make some desktop recordings.
What that post did not mention are two issues that we had:

when recording using the Screen Capture (XSHM) source, the recording would only show a black screen and it would actually record the mouse only!

when trying to record a LibreOffice application like Calc through the Window Capture (XComposite) source, Calc would not show in the properties dialog under the Window dropdown menu

The way we fixed these issues is not something that is always guaranteed to work but it is worth a try!
Initially we thought it would be a good idea to install the NVidia driver since we had a GeForce GTX 660M on the machine.
We hoped that the OBS studio black screen issue was a driver issue so we decided to follow the RPM Fusion guide on installing NVidia drivers.

We installed the NVidia driver, added the CUDA support and updated the system using these two commands:

After the machine booted and the graphical interface came up, we noticed that the machine was too slow and there was 100% CPU utilization for over 15 minutes.
After some very efficient Google-Fu, we realised that this was some bug that we were not willing to deal with and so we had to remove the newly installed NVidia driver.
Again following the RPM Fusion guide, we executed the following command to remove the driver from our system:

dnf remove xorg-x11-drv-nvidia\*

Please note that we DID NOT execute the last step of the guide on how to Recover from NVIDIA installer.
As it is mentioned in the guide: the NVidia binary driver installer overwrites some configuration and libraries.
Since having a clean state did not work for us, we decided to give a go of this hybrid setup that we had.
Following another full restart we were able to see that OBS Studio was working as expected and it the black screen issue was no more!!
Also, we could choose LibreOffice from the Window dropdown and we could record that as well!

As implied, this guide is a hack, it could work for you as well or not.
Our opinion is that, it is worth to give it a go!
As a synopsis, what we did was to install the NVidia driver and uninstall it, the libraries that got overwritten by this process fixed the black screen issue of OBS studio.

In order to record a few desktop sessions on our Fedora GNU/Linux machine, we decided to use the OBS Studio as it appeared to be a very powerful tool.
Unfortunately, this software does not ship with the official repositories so we had to install it from the rpmfusion.org repository using the following commands.

#Enable access to both the free and the nonfree repository
#free repository: for Open Source Software (as defined by the Fedora Licensing Guidelines) which the Fedora project cannot ship due to other reasons
#nonfree repository: for redistributable software that is not Open Source Software (as defined by the Fedora Licensing Guidelines); this includes software with publicly available source-code that has "no commercial use"-like restrictions
sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm;
#Perform the installation
sudo dnf install obs-studio;

Background:

RPM Fusion provides software that the Fedora Project or Red Hat don’t want to ship. That software is provided as precompiled RPMs.

Codecs in Fedora

By default Fedora does not ship with several codecs whose license is not free.
So we had to install a few packages manually and be able to playback or process sever multimedia formats.

Specifically we installed the following plugins and libraries for GStreamer (needed for the Totem Movie Player):

gstreamer1-libav: This package provides libav-basedGStreamer plug-ins.Libav is a free software project, forked from FFmpeg in 2011, that produces libraries and programs for handling multimedia data.

gstreamer1-plugins-good: GStreamer Good Plugins is a collection of well-supported plugins of good quality and under the LGPL license.

GStreamer is a streaming media framework, based on graphs of filters which operate on media data. Applications using this library can do anything from real-time sound processing to playing videos, and just about anything else media-related. Its plugin-based architecture means that new data types or processing capabilities can be added simply by installing new plugins.

Additional h264 – h.264 Codec – Optional

Following, we decided to install the OpenH264 codec implementation and its extensions for Firefox and gstreamer.

Cisco provides an OpenH264 codec (as a source and a binary), which is their of implementation H.264 codec, and they cover all licensing fees for all parties using their binary. This codec allows you to use H.264 in WebRTC with gstreamer and Firefox.It does not enable generic H.264 playback, only WebRTC.

While setting up Android Studio on a Fedora 27x64, we got the following message from the Android Studio Setup Wizard:

We have detected that your system can run the Android emulator in an accelerated performance mode.
Linux-based systems support virtual machine acceleration through the KVM (Kernel-mode Virtual Machine) software package.

After going through the website mentioned in the message we noticed that there were no instructions for Fedora so we decided to write our own.

Below are the steps we followed to enable hardware acceleration for the Android emulator.

Step 1: Verify that your CPU has virtualization extensions.

Execute the following in a terminal:

egrep '^flags.*(vmx|svm)' /proc/cpuinfo;

if you get ANY output then it would mean that your CPU supports either VMX or SVM which is good.
If it does not print anything then the emulator will fall back to software virtualization, which is extremely slow.

Step 2: Install the virtualization packages

sudo dnf group install --with-optional virtualization;

Step 3: Start the service

sudo systemctl start libvirtd;

Step 4: Automatically start the service on boot:

sudo systemctl enable libvirtd;

Step 5: Verify that the kvm kernel modules were loaded

lsmod | grep kvm

If the above command does not print kvm_intel or kvm_amd, it would mean that KVM is not properly configured.