Latest Tweets

Dolphin singleClick option not working in XFCE4

Preamble

On an OpenSuse Leap GNU/Linux box, Dolphin’s singleClick option to open files and folders does not work if executing the file manager within an XFCE4 session. Instead, the user is forced to double-click every item to open it. Configuring the global KDE input settings does not help. Editing the ~./config/kdeglobals file and adding the SingleClick=true option does not fix the issue either.

Behind the scenes

To fix this issue, first we need to find where the program reads the singleClick option from and when it enables it. We start trying this issue on another GNU/Linux box running Debian Stretch, and we confirm it suffers from the same problem. So we get its sources and its build dependencies too (this way we are going to be able to build our own customised version of Dolphin, if need be):

apt-get source dolphin
apt-get build-dep dolphin

After that, we look for the string “singleClick” using the grep command inside the src directory:

grep -R “singleClick” *|grep false
src/kitemviews/kitemlistcontroller.cpp: m_singleClickActivationEnforced(false),

According to the previous result, there’s an explicit call to the m_singleClickActivationEnforced() method in src/kitemviews/kitemlistcontroller.cpp. This file has its header file counterpart as well, so we start by having a look at the headers and we find this:

   /**
     * If set to true, the signals itemActivated() and itemsActivated() are emitted
     * after a single-click of the left mouse button. If set to false (the default),
     * the setting from style()->styleHint(QStyle::SH_ItemView_ActivateItemOnSingleClick) is used.
     */
    void setSingleClickActivationEnforced(bool singleClick);
    bool singleClickActivationEnforced() const;

It seems pretty obvious then. So according to the comment above, Dolphin is disabling the SingleClick option by default (it’s hard-coded in the call m_singleClickActivationEnforced(false) as we’ve seen earlier). We can change the source code and re-build dolphin to make sure it works, although this solution is far from being optimal because at the next package upgrade, this modification will be lost and the double click issue will re-appear. But we can try it anyway just for fun!

Building our own Dolphin binary with SingleClick enabled by default

We edit the src/kitemviews/kitemlistcontroller.cpp and replace the call to the method m_singleClickActivationEnforced(false) with m_singleClickActivationEnforced(true). Then, we build the binary:

fakeroot debian/rules binary

Once the building process is over, we install all the built packages:

mkdir ../debs ; mv ../*.deb ../debs; su -c “dpkg -i -R ../debs”

If we run the command “dolphin” now, we will have the SingleClick option enabled. So far so good, but … as we have previoisly stated, at the next package upgrade this customisation will be lost.

QT5 Styles without KDE integration

According to the source comment we have previously found, style()->styleHint(QStyle::SH_ItemView_ActivateItemOnSingleClick) is used in order to enable or disable the SingleClick option within Dolphin. If we google this we find that this is a QT5 Style setting (see http://doc.qt.io/qt-5/qstyle.html) , and it can be easily manipulated with the Qt5ct tool. We do not have this tool as a package for Debian stable, but we do have it for OpenSUSE Leap. So on the computer where this issue was first reported we use Yast2 to install the qt5ct package. Then, we add the following line to the .bashrc file of the affected user:

export QT_QPA_PLATFORMTHEME=qt5ct

Finally, we run the qt5ct tool and we tick the “Activate item on single-click” option on the “Interface” tab, as shown below:

After making this change, we run Dolphin again and this time we have the SingleClick option enabled all right!

 

Una al Mes: Silicon Valley Episodio 1 CTF Write-Up

1: Obtención del archivo con las credenciales.

Descargamos una imagen del disco de Gilfoyle desde cualquiera de los dos enlaces propuestos. Rápidamente pensamos en utilizar Volatilty para analizar dicha imagen. Primero descomprimimos el archivo descargado y luego pedimos a Volatility que nos dé información sobre la imagen, para poder escoger el mejor perfil a utilizar:

 

Obtención de información sobre la imagen del disco de Gilfoyle.

Según el enunciado del reto, debemos encontrar un archivo con las credenciales (encriptadas) de acceso a la web http://34.247.69.86/siliconvalley/episodio1/login.php . Como se comenta que se ha producido un corte eléctrico, podríamos pensar que tal vez ese documento estuviera en uso en el momento del corte. Así que empezamos enumerando procesos que estuvieran en ejecución para luego filtrar aquellos que puedan ser más interesantes (navegadores web, procesadores de texto, programas de anillo de claves, etc.). Para ello usamos Volatility con el primer perfil propuesto en el comando anterior:

volatility -f GILFOYLE-HELLDD.raw –profile=Win7SP1x64 pslist

Entre todos los procesos listados, observamos que LibreOffice y Firefox estaban en ejecución:

Procesos interesantes ejecutados por el usuario.

Empezamos con LibreOffice; usamos de nuevo Volatility para listar aquellos archivos abiertos por el proceso con PID 2340 que estuvieran ubicados en el directorio del usuario (Users). El primero de la lista parece muy prometedor: info.odt:

Volcamos el archivo info.odt a disco para analizarlo con mayor detenimiento:

Volcado del archivo info.odt a disco.

Abrimos el documento con LibreOffice y observamos que, efectivamente, podría muy bien ser el documento con las credenciales cifradas.

2: Descifrando las credenciales

A priori, el contenido del documento parecer utilizar el abecedario de Base-64. Intentamos decodificarlo, pero sin éxito. Lo que sorprende es que el documento parece estar segmentado en grandes bloques de texto independientes, y se puede ver claramente una repetición de dichos bloques. En una parte del documento observamos una separación de párrafo después del carácter “:”. Justo antes y después de dicho caracter observamos lo que podría ser un par de MD5s encerrados entre corchetes:

Posibles MD5s encerrados entre corchetes.

Lo que obtenemos bien podría ser el usuario y el password generado con MD5 que estamos buscando. Probamos suerte directamente pegando estos valores en la web http://md5decrypt.net:

Rompiendo el MD5 (usuario de la web).

Rompiendo el MD5 (password de la web).

Ya tenemos las credenciales; podemos validarnos en la web y proseguir con el reto.

3: Obtención del número de la casa

Tras validarnos en la web con las credenciales Gilfoyle:Satan, obtenemos una nueva URL:

Nueva URL tras validarnos con éxito en la web.

Accedemos a la misma y obtenemos una imagen JPG:

La nueva URL nos lleva hasta una imagen JPEG.

Descargamos la imagen a disco. Antes de proceder con técnicas de stego, obtenemos toda la meta-información posible sobre la imagen. Nos da por pensar: “ey, esto parece una fotografía tomada del archivo de denuncia, tal vez tengamos suerte y tengamos la geolocalización de la cámara donde se tomó la misma…”; así que nos centramos en el campo XMP/IPTC de la imagen y buscamos la localización:

Copiamos y pegamos estas coordenadas en Google Maps. En lugar de un número de casa, Google nos devuelve un código Plus (https://plus.codes/):

Casi lo tenemos; en lugar de un número, Google nos devuelve un Plus Code.

Basta con pulsar sobre la casa que está en la calle indicada por el código Google Plus para obtener su número, el 2126:

Ya tenemos el posible número de la casa, el 2126.

Generamos el MD5 de dicho número:

echo -n “2126”|md5sum
3b92d18aa7a6176dd37d372bc2f1eb71 –

La flag es, pues: UAM{3b92d18aa7a6176dd37d372bc2f1eb71}

 

@disbauxes

Toni Castillo Girona

 

 

 

 

 

Script for NUMA systems

Preamble

On modern NUMA systems, it’s always a good thing to know the total number of physical processors (nodes), the total number of real cores per processor, and if HT is enabled, the total number of virtual cores per processor (which is, of course, twice the number of real cores per socket). At the same time, it would be great to be able to disable HT for a particular physical processor on the fly. This simple BASH script does precisely that.

Using the script

Install numactl before running the script. If numactl is not found, the script will tell you so and exit:

sudo apt-get install numactl

The script can report the real and virtual cores per socket along with the total number of physical processors installed on the system. It works perfectly well for systems that only have 1 socket, of course, so no NUMA in this case.:

cores.sh -h
Usage: /usr/bin/cores.sh [-t] [-c CPU] [-h]
		 -t, reports total number of physical processors (nodes) and quits.
		 -c CPU, reports total and real cores for physical processor CPU.
		 -r CPU, reports real cores for physical processor CPU separated with commas.
		 -d CPU, disables HT on the given CPU (requires root).
		 -h, show this help message.
  Example: /usr/bin/cores.sh -t
           /usr/bin/cores.sh -c 2
           sudo /usr/bin/cores.sh -d 0

To get the total number of cores for, say, physical processor 1 on a 4-socket system, run:

cores.sh -c 1
Total physical processors on this system: 4
Total Cores for processor 1: 1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77
Virtual Cores for processor 1:  41 45 49 53 57 61 65 69 73 77 
Real Cores for processor  1:  1 5 9 13 17 21 25 29 33 37

You can disable HT for a particular socket as well. The number of cores that will be disabled are shown in the “Virtual Cores” row. Say, you want to disable HT for CPU0 on a 1-socket system; run:

 sudo cores.sh -d 0
Total physical processors on this system: 1
Total Cores for processor 0: 0 1 2 3 4 5 6 7
Virtual Cores for processor 0:  4 5 6 7 
Real Cores for processor  0:  0 1 2 3
We are about to disable HT on physical cpu: 0
CPU cores to be disabled:  4 5 6 7 
Are you sure? [yn]

If you are completely sure, type “y” and press <ENTER>. Otherwise, type any other key and press <ENTER>.

You can run the script using the “-r” flag in order to output the real cores for a particular physical processor to pass it directly to numactl. Let’s imagine you want to run a 10-core simulation using mpirun on a 4-socket NUMA system. Each physical node has 10 real cores and 10 virtual cores due to HT. You want to run this simulation on node 3 (CPU4):

cores.sh -r 3
Total physical processors on this system: 4
Real Cores for processor  3:  3,7,11,15,19,23,27,31,35,39

Now, you can pass the string of real cores to numactl and run your simulation like this:

numactl --physcpubind=3,7,11,15,19,23,27,31,35,39 mpirun -np 10 \
> --report-bindings binary arguments

Or you can do it using this one-liner instead:

numactl --physcpubind=`cores.sh -r 3|tail -1|cut -d":" -f2|tr -d " "` \
>  mpirun -np 10 --report-bindings binary arguments

To make sure your simulation is running on the chosen cores/sockets, you can run the following command (replace PID with the proper one):

cat /proc/<PID>/status |grep Cpus_allowed_list
Cpus_allowed_list:	4-7

Get the script (cores.sh)

You can download the script from HERE.