Hardening consulting

C'est le début de l'année et pourtant déjà des conférences sympas. La dernière en date Linux.conf.au. J'ai une tendresse particulière pour celle-ci car c'est une des interventions donnée là-bas qui m'a donné envie de m'intéresser à wayland.

Lire la suite…

J'ai vu quelques conférences intéressantes du CCC (c'était comme toujours entre noël et le premier de l'an):

  • il y a celle cité dans cet article sur la sécurité de xorg ;
  • j'ai aimé celle-ci sur l'exploitation avancée sur processeurs ARM. Le mélange de fils, de montage électronique, de fer à souder et de logiciel était très sympa. La quête du bon affichage via le port Jtag, génial !
  • La conférence sur le hacking de la télécommande de la WII était aussi très rigolo. On y apprend que le protocole d'association entre la télecommande et la box est simplement du WPS avec un renforcement cryptographique avancé rajouté par Nintendo: deux ROT3. Comme disent les intervenants: "come on Nintendo guys". Au final cette télécommande est quand même un super gadget avec plein de capteurs, et des CPUs relativement puissants ;
  • et encore du hacking physique avec un chercheur autrichien qui s'essaye à hacker les nouveaux systèmes de serrures électroniques par RFID. Il fini par ouvrir plus de 90% des portes avec un système coûtant une vingtaine d'euros à base de pass de ski modifié. Respect ;
  • il y aussi la conférence qui a fait plein de buzz sur le malware pour les distributeurs de billets. Techniquement ça ne casse pas trois pattes à un canard: un pauvre malware avec rien de bien compliqué dedans. Ce qui m'a fait rire, c'est plutôt que les truands avaient cherché à garder le contrôle pour eux des DAB en utilisant un code d'activation qui active un menu pirate, plus la réponse à un challenge pour pouvoir vider le DAB. Ils voulaient garder des DAB vaches à lait qu'ils seraient les seuls à pouvoir vider.

Note: j'alimenterais cet article au gré de mes découvertes intéressantes.

J'ai posté récemment une première version d'un backend FreeRds pour weston, le compositeur de référence de wayland.

Dans cette article, je vais détailler un peu le fonctionnement de ce nouveau compositeur. Ceux qui ont déjà lu mon article sur le compositeur FreeRdp ne seront pas perdu.

FreeRds et weston

FreeRds est un projet en cours, son but est de fournir un serveur RDP en se servant de la librairie FreeRdp. Xrdp était basé sur le code de rdesktop, on peut voir FreeRds est son successeur mais basé sur FreeRdp.

Voilà un schéma simplifié d'architecture de couplage FreeRds / weston, avec weston qui crée le contenu à afficher:

FreeRDS compositor

Lire la suite…

Dans le cadre du projet FreeRDS, j'ai eu à créer un petit programme bouchon faisant office de SessionManager pour tester des développements. La communication entre FreeRDS et le SessionManager se fait en protocol buffer, j'ai donc regardé du coté du binding python.

Protobuf

Rien de magique dans protobuf, il s'agit juste d'une (nième?) manière standardisée de sérializer des données. Je vais faire mon vieux de la vieille mais ça ressemble quand même furieusement à du CORBA sans la partie réseau (ce qui est d'ailleurs un peu embêtant, nous verrons ça plus tard). On décrit des messages dans un fichier .proto, on passe un compilateur dessus qui va générer du code pour lire et écrire les messages. Le truc bien c'est que le compilateur propose plein de langages de sortie.

En pratique

C'est bien beau de pouvoir écrire des messages mais si vous êtes sur ce blog, vous vous doutez bien que c'est pour transporter des paquets sur le réseau. Voici donc quelques extraits de code python

Lire la suite…

J'ai été récemment confronté à un problème qui m'a occupé un peu. J'avais une classe abstraite pure qui servait d'interface. Elle devait servir à faire le lien entre une application et l'implémentation qui resterait cachée (et qui évite aussi de linker avec l'implémentation). Jusque là rien de méchant, c'est du C++ avec Qt5.

L'implémentation fait des choses et je voulais qu'elle puisse émettre des signaux et que le code externe puisse s'abonner aux signaux.

Donc quelque chose dans le genre:

// myinterface.h

#include <QObject>

class MyInterface : public QObject {
   Q_OBJECT
public:
   virtual void myfunction() = 0;
signals:
    void onSomethingHappened();
};
// myimplementation.cpp

#include <QObject>

class MyImplementation : public MyInterface {
   Q_OBJECT
public:
    virtual void myfunction();
};

Ce serait bien si ça marchait, mais le moc (Meta Object Compiler) ne veut pas compiler ça et dés qu'on veut faire un connect() sur le signal ça coince.

Lire la suite…