J’ai donc ajouté le support WebP à SDL_image qui est la bibliothèque dédiée aux divers format d’images, le tout dans un temps très court.

Que retenir de WebP ? une API simple : deux fonctions pour décoder une image et encore, car je voulais savoir si je devais prévoir un canal alpha ou non ! De plus, il y a aussi une API où l’on peut indiquer la taille de l’image en sortie tout en supportant un mode de décompression incrémentiel. Les développeurs de l’embarqué apprécieront quand on voit la taille d’une photo avec les appareils numériques

Le patch se trouve ici (et devrait s’appliquer sans problème sur le trunk de SDL_image ) : webp_for_SDL_image.diff

Vais-je avoir le temps de m’attaquer à un lecteur CBZ en SDL ?

La playlist est constituée de musique de jeux, dont la plupart sont des RPGs. Pourquoi ? car pendant mes sessions de développement, de surf sauvage ou d’administration, j’aime ce genre de musique.

Une mise à jour aura lieu pour permettre l’utilisation du tag html5 audio sous Firefox & Chrome (ogg/vorbis) mais j’ai eu quelques problèmes. Pour l’occassion j’ai créée la page WebradioWidget où j’ai mis la plupart de mes configurations, scripts & sources.

Suite à mon petit utilitaire Yubikey, j’ai continué à approfondir l’interface proposée par Linux sur les périphériques entrée/sortie.

J’ai donc repris mon code pour capturer les événements d’un périphérique de type clavier. Comme on récupère ceux-ci directement du kernel, toute la phase de traduction côté userland n’est pas faite : les événements font référence à un clavier Américain. Le programme gère le support des touches spéciales ( Control, Alt, Shift, …) pour essayer de savoir si on a fait C ou Ctrl-C. Le code est disponible à l’adresse http://www.murlock.org/code/keylogger-0.1.tar.bz2

Bien sûr, je décline toute responsabilité pour toute utilisation frauduleuse de cet outil.

Pour lancer l’utilitaire (en tant que root), les logs sont disponible dans le fichier trace.log.

# keylogger path_to_dev_entry

Comment détecter l’outil ?

# lsof /dev/input/event1
 Output information may be incomplete.
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
acpid     1615 root    4r   CHR  13,65      0t0 3043 /dev/input/event1
hald-addo 2290 root    4r   CHR  13,65      0t0 3043 /dev/input/event1
Xorg      2378 root   28u   CHR  13,65      0t0 3043 /dev/input/event1
keylogger 8338 root    3r   CHR  13,65      0t0 3043 /dev/input/event1

Exemple: avec changement d’onglet dans un Terminal et exemple de texte capturé

# ./keylogger /dev/input/event1 &
BusType : 17
Vendor  : 1
Product : 1
Version : 43841
Name : AT Translated Set 2 keyboard
Physical Location : isa0060/serio0/input0
# tail -f trace.log
Detected default keyboard layout :
XKBLAYOUT="fr"

<RIGHTCTRL=1><PAGEDOWN><RIGHTCTRL=0>ceci est un exe;ple de keylogger
<UP><HOME><DELETE><RIGHTSHIFT=1>c<RIGHTSHIFT=0>

Autre outil disponible : http://code.google.com/p/logkeys/

J’ai commencé l’installation d’U-boot comme indiqué dans le numéro d’open silicium, mais comme je travaille à coup de bootp / tftp / nfs, je n’ai pas finalisé avec l’initialisation correcte de la NAND.

Je construit maintenant une toolchain en utilisant buildroot 2010-10, pas de souci particulier, mon fichier de configuration est disponible ici : buildroot-2010-11.config (installation par défaut dans /opt/arm-mini2440). Busybox se fait sans souci.

Pour le kernel, pas de souci mais je reste avec la version patché (2.6.32.2) fourni par FriendlyArm.

J’ai bien avancé sur la compilation de qt 4.6.2 pour embarqué mais j’ai un souci pour lancer un programme, pas de plantage mais pas d’affichage non plus, en cours d’investigation en comparant mon rootfs et celui fourni.

Côté Android, j’ai commencé à fouiller vers la version 2.2 ( Froyo ) car il utilise la même version de kernel, j’ai réussi à trouver un kernel sur le dépôt GIT d’Android. Dans un monde idéal, il ne resterait plus qu’à reporter les modifications du premier sur le second. Malheureusement, la documentation d’Android est plutôt légère (ou obsolète) à ce stade…

A suivre…

Petit tour rapide pour tomber sur l’article détaillant la Mini2440 de FriendlyARM, je reste bluffé par le matos détaillé dans l’article, surtout proposer à ce prix. Alors que je pensais investir à terme pour une Beaggle Board, avoir un PDA like (OS Supporté Linux / WinCE 5 / Android) avec écran tactile pour un prix dérisoire ( env. 100€ / 150$ ). Ca reste moins puissant qu’une Beaggle Board mais un usage complètement différent ! Pour revenir au magazine, l’article aborde la chaîne de compil, un classique, et le changement du bootloader. Un bon départ, il faudrait faire le tour des différents projets pour voir les capacités de la bête…

Pour revenir au magazine, tout les articles parlent de l’embarqué mais aussi de simulation de circuits, de FPGA. Beaucoup de domaine sont donc abordés et pour un premier numéro, c’est plutôt réussi, à conseiller à tout les barbus qui s’intéressent à l’embarqué

J’ai décidé de jouer avec FUSE. Car FUSE me rappelle un peu Ubik, ça permet de tout faire

Voici donc WikkaFS (LGPL 2.1.) : il nécessite mysql & fuse pour se connecter au wiki (distant ou local). Le code n’est très propre et utilisable de manière sécurisé qu’en mono utilisateur. Seul bémol, sur la version stable (1.2) de WikkaWiki, l’UTF8 n’est pas géré alors attention à vos charsets .

http://www.murlock.org/code/wikkafs-0.9.tar.bz2

Fonera 2.0n, Alix 2c3 et Dingoo A320

Donc voici la Fonera 2.0n, basé sur la distribution OpenWrt. Fonera fourni un firmware avec ssh ouvert pour permettre une administration ou des développements directement en situation, et le lien nécessaire pour le développeur.

Fonera 2.0n

Ensuite, voici une Alix 2c3 de PcEngines. Un certain nombre de distribution Linux/OpenBSD est possible, j’ai opté pour une OpenWrt, étant l’une des plus actives et supportant bon nombre de matériels. En étant basé sur une carte Compact Flash, l’installation se passe sans souci (avec dd sur votre PC par exemple) et de plus, comme c’est une architecture x86, OpenWrt permet de générer une image disque pour VirtualBox, permettant de tester très rapidement (en plus de la solution standard du NFS).

Alix 2c3

Et enfin, une A320 de Dingoo, une console chinoise de bonne qualité, avec une distribution nommée Dingux. L’installation est un peu plus douloureuse mais on arrive à s’en sortir sans trop de souci. Voici quelques liens : Dingux Intégrale v2 (comprenant tout ce qu’il faut pour installer et préparer sa miniSD) et la toolchain.

Dingoo A320

]]> http://www.murlock.org/blog/linux-embarque/feed/ 0 http://www.murlock.org/blog/cle-yubikey/ http://www.murlock.org/blog/cle-yubikey/#comments Sun, 28 Feb 2010 15:07:22 +0000 admin http://www.murlock.org/blog/?p=53 Pour ce premier post qui parle d’informatique, je vais vous presenter la YubiKey : c’est une cle d’authentification forte a base d’One-Time Password (ou mot de passe jetable), empechant les attaques par rejout. On peut utiliser cette cle avec une double authentification : le possesseur doit egalement saisir un autre mot de passe traditionnel, permettant une securite encore plus forte.

Malheureusement, il y a un defaut, cette cle est vu comme un peripherique de saisie standart ( HID ), ce qui ne cadrait pas avec mon utilisation de la cle : je voulais pouvoir modifier l’etat d’un service (le wifi ou surveillance video par exemple) sans avoir a ouvrir une session, ou dans le cas d’un routeur a base de firmware nihiliste extremiste libre, sans avoir a se connecter a une interface web).

Apres un peu de recherche, lors de l’insertion de la cle, grace a une regle udev, je lance mon programme :

ACTION=="add", SUBSYSTEM=="input", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0010", KERNEL=="event*", RUN+="/bin/yubico"

Je reclame ensuite le peripherique indique par la variable d’environnement DEVNAME:

fd = open( getenv("DEVNAME"), O_RDONLY );

A ce stade, j’obtiens copie de tout les evenenements claviers de la cle, mais cette derniere reste attache a l’entree standart du PC. Il faut alors reclamer le peripherique (un plongeon dans /usr/include/linux/input.h a ete necessaire).

ioctl( fd, EVIOCGRAB, 1 );

A ce stade, il suffit d’attendre une structure input_event (toujours le meme fichier input.h ainsi que Documentation/input/input.h). Une gestion de tampon et de timeout et me voila pret a verifier l’OTP.

A ce stade, j’ai joue la solution de facilite et j’attaque le WebService de Yubico pour verifier la cle OTP fourni par la cle. J’ai prevu trois hooks : en cas de succes, en cas d’echec et lorsque la cle est retire, le programme quitte automatiquement.

La suite du travail se passera sur une Alix PC-Engines avec OpenWRT pour verifier si tout marche correctement avec mdev, le remplacement d’udev fourni par BusyBox. Il reste aussi plusieurs bricoles comme indique dans l’archive.

Le progamme est telechargeable a http://www.murlock.org/utils/yubikey.tar.bz2. Ma machine, un Aspire One, tourne sur une Debian (mi testing / mi stable) avec le noyau 2.6.32.

PS: ce billet est entierement realise sur un clavier qwerty, donc pas d’accent dans un premier temps.

Il est possible d’utiliser une connexion SSH pour se connecter une machine distante et de s’en servir comme relais via OpenVPN.

Préparons d’abord notre serveur (testé sur Debian) :

En premier, notre serveur VPN avec le fichier de configuration script d’init ( /etc/openvpn-server.conf par exemple )
remote localhost
dev tun
ping 30
ifconfig 192.168.5.1 192.168.5.2
proto tcp-server
port 6124
On lance le daemon avec sudo openvpn --conf /etc/openvpn-server.conf

Puis le proxy ( squid 3 dans mon cas)

Il faut juste ajouter dans les règles acl l’ip du client (192.168.5.2), rechercher la chaine acl localhost src 127.0.0.1/32 & insérer à la suite :
acl localhost src 192.168.5.2

Un petit /etc/init.d/squid3 restart pour prendre en compte les modifications.

Depuis notre portable / poste de travail, on se connecte à notre serveur  :

ssh -L 6124:localhost:6124 utilisateur@monserveur

(L’option -L 6124:localhost:6124 permet que le port 6124 en écoute qui se trouve sur le serveur sera également en écoute sur l’interface localhost:6124 sur la machine cliente)

Lançons maintenant la connexion VPN qui passera via le tunnel SSH

openvpn --config /etc/openvpn-client.conf

Contenu du fichier openvpn-client.conf
remote localhost
dev tun
ping 30
ifconfig 192.168.5.2 192.168.5.1
proto tcp-client
port 6124

Si tout va bien, on devrait voir pousser une nouvelle interface réseau (tun0 dans la plupart des cas).

Ensuite, dans notre navigateur, on paramètre le proxy sur HTTP / IP: 192.168.5.1 / port: 3128.

Dans la plupart des cas, je paramètre une nouvelle session de navigateur utilisant le proxy, me permettant de ‘choisir’ où va sortir le traffic.

Sur mon Linux Debian Lenny, pas grand chose à faire :

1. Installation des paquets iscsitarget & iscsitarget-modules-2.6.26-2-686
2. Création d’un fichier avec dd(dd if=/dev/zero of=/mnt/data/iscsi bs=4k count=2000)
3. Modification de la configuration /etc/ietd.conf :
   Target iqn.2001-04.com.example:storage.disk2.sys1.xyz
Lun 0 Path=/mnt/data/iscsi,Type=fileio
4. Par défaut, le démon iscsitarget est désactivé dans /etc/default/iscsitarget :
   ISCSITARGET_ENABLE=true
5. On relance /etc/init.d/iscsitarget

Côté OpenSolaris, testé avec snv_111a (le futur OpenSolaris 2009.06) :

1. il faut installer le paquet SUNWiscsi (un redémarrage est sans doute nécessaire, à confirmer)
2. on activate le démon : svcadm enable iscsi_initiator
3. maintenant, on configure le iscsi-initiator :
# iscsiadm modify initiator-node -A opensolaris-vm
# iscsiadm add discovery-address linux-amd64
# iscsiadm modify discovery -t enable
4. on force une réactulisation des périphériques iscsi # devfsadm -c iscsi
5. le périphérique iscsi devrait maintenant apparaître lors de le commande format:
   AVAILABLE DISK SELECTIONS:
0. c3d0 /pci@0,0/pci-ide@1,1/ide@0/cmdk@0,0
1. c3d1 /pci@0,0/pci-ide@1,1/ide@0/cmdk@1,0
2. c5t1d0 /iscsi/disk@0000iqn.2001-04.com.example%3Astorage.disk2.sys1.xyz0001,0
Specify disk (enter its number):^C

6. à ce stade, vous êtes désormais capable d’utiliser zpool pour utiliser ce nouveau disque :
   # zpool create zfsiscsi c5t1d0


source : http://www.c0t0d0s0.org/4220-Less-known-Solaris-Features-iSCSI-Part-2-Basic-iSCSI.html