Perte du wifi récurrent sur Netgear N750

J’ai chez moi un router wifi faisant uniquement office de borne d’accès wifi. C’est un Netgear N750 (ou DGND4000 pour les intimes) et on ne peut pas dire qu’il soit génial. Sur la porteuse à 2.4GHz, il fait son taff mais sur la porteuse à 5GHz, à moins d’être le nez en face, on a un signal aussi faible qu’inutile. Mais on pourrait dire que c’est du détail tant ça marche, non ?

En effet cette bouse ne fonctionne tout simplement plus au bout d’un moment. Ce moment est assez variable mais l’on peut considérer que c’est une fois par semaine environ. Les symptômes sont qu’on est bien identifié sur l’un des deux réseaux Wifi (celui à 2.4GHz ou l’autre à 5GHz), mais qu’on a rien sur la couche IP. Ayant analysé un peu ce qu’il se passait, je devine que la box, pour une raison qui m’échappe, a sa table d’adresses MAC pleine, ce qui empêche les nouveaux arrivant d’avoir une connectivité IP.

La box Wifi qui lave plus blanc que blanc

Juste pour bien recadrer, c’est le genre de box qui sait tout faire: DHCP, DNS, point d’accès Wifi, firewall, modem ADSL, Wifi « invité », contrôle parental, VPN et même NAS en lui collant un disque en USB.
Sur toute cette panoplie de fonctionnalités, il n’y en a qu’une seule qui m’intéresse et que j’ai donc activé, c’est le point d’accès Wifi. Tu achètes une box spécialisée Wifi, qui ne fait que ça, et elle n’est même pas fichu de faire le taff correctement, c’est vraiment gonflant. D’autant plus que le problème n’est pas matériel, mais bien logiciel, donc solvable par une simple mise à jour du firmware, que j’attends toujours.

A côté, mon routeur/firewall/proxy/dhcp/dns/dpi full open-source (oui, même le BIOS est open-source) Linux se porte comme un charme, lui…

Fuck you Netgear !

Le plombier à la rescousse

Pour restaurer le wifi, il y a deux solutions :

  • le reset (éteindre/allumer, pas une remise en usine avec clear de la mémoire hein)
  • la reconfiguration du wifi via les pages d’admin que j’ai trouvé un peu par hasard

La première solution étant un peu difficile à automatiser, je me suis concentré sur la seconde pour cracher un script que je ferais exécuter par cron par mon routeur disons… toutes les heures.

Pour se faire, rien de plus simple. J’ai analysé un peu comment était foutu le formulaire HTML.
C’est un formulaire tout bidon, sur lequel on a cependant un petit token servant de anti-forgery sur l’action du formulaire.

Pour rappel, un anti-forgery token sert à empêcher de rejouer un formulaire, et donc de pouvoir modifier la configuration du routeur au travers d’une attaque de type XSS par exemple. Cela force à faire la manipulation de manière interactive (du moins en théorie XD…)

Le script devra donc envoyer non pas un appel au routeur mais deux :

  • le premier appel sert à afficher la page et ainsi pouvoir récupérer le token (lequel dépend du temps)
  • le second appel est le POST pour reconfigurer le wifi, et il incorporera le token obtenu précédemment

Le navigateur du moment est Chrome, et celui-ci permet de récupérer tous les appels effectués sous la forme de commande curl, ce qui est bien pratique pour notre cas et ce qui explique pourquoi il y a tout un tas d’en-têtes HTTP totalement inutiles. J’ai donc fait générer ces commandes par Chrome puis adapté légèrement là où il fallait.

Note: ce script ne peut pas marcher chez vous tel quel, car il appliquera ma configuration. Vous devez modifier l’argument –data  dans le script.

Note 2: il faudra vous arranger pour que ce script s’exécute régulièrement. Tout le monde n’a pas de routeur custom comme moi, mais il existe plein d’autre solutions, les tâches planifiées de Windows par exemple.

#!/bin/bash

ip=192.168.3.3
user=admin
pass=password
auth=$( echo -n "${user}:${pass}" | base64 )

TOKEN=$( curl "http://$ip/setup.cgi?next_file=WLG_wireless_2.htm" \
        -H "Authorization: Basic $auth" \
        -H 'DNT: 1' -H 'Accept-Encoding: gzip, deflate, sdch' \
        -H 'Accept-Language: en,en-US;q=0.8,fr-FR;q=0.6,fr;q=0.4' \
        -H 'Upgrade-Insecure-Requests: 1' \
        -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36' \
        -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' \
        -H 'Cache-Control: max-age=0' \
        -H "Referer: http://$ip/WLG_wireless_2.htm&todo=cfg_init" \
        -H 'Connection: keep-alive' \
        --compressed 2> /dev/null | grep action= | gawk 'match($0, /setup\.cgi\?id\=([0-9a-f]{8})"/, ary) { print ary[1] }' )

curl "http://$ip/setup.cgi?id=$TOKEN" \
        -H "Origin: http://$ip" \
        -H 'Accept-Encoding: gzip, deflate' \
        -H 'Accept-Language: en,en-US;q=0.8,fr-FR;q=0.6,fr;q=0.4' \
        -H 'Upgrade-Insecure-Requests: 1' \
        -H "Authorization: Basic $auth" \
        -H 'Content-Type: application/x-www-form-urlencoded' \
        -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' \
        -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36' \
        -H 'Cache-Control: max-age=0' \
        -H "Referer: http://$ip/WLG_wireless_2.htm&todo=cfg_init" \
        -H 'Connection: keep-alive' \
        -H 'DNT: 1' \
        --data 'h_WRegion=Europe&h_ssid_class=primary&tempSetting=0&tempRegion=11&setRegion=11&h_wds_enable=disable&h_wds_enable_an=disable&only_mode=0&show_wps_alert=0&h_enable_ap=enable&h_enable_ap_an=enable&h_ssid_bc=&h_ssid_bc_an=&h_allow_access=disable&h_allow_access_an=disable&h_wire_iso=&h_wire_iso_an=&ssid=Kveer-2G&ssid_an=Kveer-5G&h_w_channel=8&h_w_channel_an=36&h_opmode=300&h_opmode_an=300&h_security_type=WPA2-PSK&h_security_type_an=WPA2-PSK&h_wepenc=0&h_wepenc_an=0&h_wpae_mode=3&h_wpae_mode_an=3&radius_rekey_secs=3600&radius_rekey_secs_an=3600&radiusServer=&radiusServer_an=&textWpaeRadiusPort=1812&textWpaeRadiusPort_an=1812&textWpaeRadiusSecret=&textWpaeRadiusSecret_an=&KEY1=&KEY1_an=&KEY2=&KEY2_an=&KEY3=&KEY3_an=&KEY4=&KEY4_an=&h_wep_key_no=1&h_wep_key_no_an=1&h_authAlgm=3&h_authAlgm_an=3&passphrase=tralala&passphrase_an=tralala&h_ssidSelect=1&h_ssidSelect_an=1&todo=save&load_2g_frame=WLG_2g_wireless2.htm&load_5g_frame=WLG_5g_wireless2.htm&this_file=WLG_wireless_2.htm&next_file=WLG_wireless_2.htm&SID=&Apply=Apply&WRegion=Europe' \
        --compressed

Récupérer son –data

Je suis gentil, je vais vous montrer comment adapter ce script à votre sauce. Mais vous vous démerdez pour le faire exécuter.

  • On commence donc avec Chrome et l’on va sur la page d’accueil du routeur.
  • On ouvre ensuite les outils de développements avec la touche F12, puis on se rend sur l’onglet Network.
  • Dans l’onglet Network des Developer Tools, on clique sur Network, puis on coche Preserve log et All.
  • Sur la page web, on clique sur Apply.
  • De retour dans l’onglet Network, il doit y avoir une ligne, la première normalement, intitulée setup.cgi?id=… et ça doit être le seul de type x-www-form-urlencoded.
  • On fait alors un clic droit puis Copy as cURL (bash) et voilà comment obtenir le second curl du script avec les –data de votre wifi.

Accès nvFlash sur l’Asus Transformer Prime TF700T

Avertissement : cette bidouille a le pouvoir de transformer votre tablette en brique technologique complètement inerte sans moyen de récupération. Ce tutoriel n’est pas destiné aux apprentis sorciers sans le sou et je ne pourrais pas être tenu pour responsable des conneries qui pourraient arriver à votre téléphone.

Description

Ce billet détaille la procédure permettant d’avoir un accès nvFlash à la tablette Asus Transformer Prime TF700T. La procédure a été testée avec succès sur ma tablette en Jelly Bean, plus précisément avec le firmware 10.6.1.14.10, le dernier mis à disposition à l’heure où j’écris. Jusqu’à récemment, il n’était possible de bénéficier de cet accès qu’avec la tablette en version ICS (Ice Cream Sandwich).

L’accès nvFlash, est un accès très bas-level, dont le principal intérêt est de pouvoir récupérer sa tablette quelque soit son état, notamment et surtout suite à un flash moisi. En d’autre terme, on bénéficie ainsi d’une tablette « brick-safe ».

Vu qu’ASUS permet de déverrouiller suffisamment le bootloader pour installer des roms customs, mais pas suffisamment pour éviter de la transformer en brique, l’accès nvFlash est donc plutôt recommandé, bien que la procédure soit risqué.

Pré-requis

Vous avez besoin :

  • des pilotes Windows. Ceux-ci sont signés afin de pouvoir les utiliser simplement sous Windows 8. Il s’agit des pilotes fournit par Google, auxquels j’ai ajouté les identifications de l’ASUS Transformer Prime TF700T et du Nexus 4, que j’ai signé avec mon propre certificat. Etant donné la nature de mon certificat, ces pilotes expireront en 2015.
  • de nvFlash (à télécharger sur le site de AndroidRoot)
  • un recovery spécialement modifié (à télécharger sur le site de AndroidRoot)
  • une tablette déverouillée

Déverrouiller la tablette

Installez et exécutez l’application Unlock_v8. Elle n’est officiellement compatible qu’avec Jelly Bean. Pour Ice Cream Sandwich, il vous faut la version v7, disponible sur les serveurs d’Asus.

Obtention de l’accès APX

La procédure n’est à faire que la première fois. Elle permet de construire un blob permettant de déverrouiller les commandes en mode APX. Ce blob est nécessaire à chaque fois qu’on désire accéder au mode APX.

  1. Sauvegardez tout ce dont vous avez besoin sur la tablette, y compris la mémoire interne ; on n’est jamais trop prudent
  2. Branchez la tablette au PC si ce n’est déjà fait
  3. Démarrez la tablette en bootloader.
    • A partir de la tablette éteinte, appuyez sur Power, puis sur Volume-Down jusqu’à voir trois icônes au milieu : RCK (pour accéder au recovery), Android (pour démarrer Android), et la dernière icône pour une réinitialisation de la tablette
    • A partir de la tablette allumée, envoyez la commande adb reboot-bootloader , c’est le plus simple
  4. Flashez le recovery spécial: fastboot flash boot flatline_tf700.img . Si le transfert dure plus de 5 min, vérifier les points suivants :
    1. la tablette est bien reconnue sous Windows. Si ce n’est pas le cas, le câble USB est peut-être mal enfichée, ou il faut tester avec une autre prise USB, ou bien tentez de passer dans le bootloader avec la commande adb.
    2. sinon tentez de renommer le fichier en tf700.img  (sans underscore) et réessayez
  5. Redémarrez la tablette complètement dans le bootloader (c’est à dire, n’accédez pas directement au recovery // normalement (avec Volume-Up pour sélectionnez l’item du milieu, puis Volume-Down pour valider) , sous Android, puis repassez dans le bootloader
  6. Accédez au recovery en validant l’item RCK
  7. Sélectionnez dans les menus : Advanced > Wheelie
  8. Acceptez l’avertissement, puis sélectionnez l’étape 1 : « Step 1: Flash AndroidRoot BL »
  9. La tablette devrait s’éteindre. Allumez-la normalement sous Android, puis repassez dans le recovery (via le bootloader ou bien avec la comande @@adb reboot recovery@@)
  10. Dans le recovery, sélectionnez Advanced > Wheelie
  11. Acceptez à nouveau l’avertissement, puis sélectionnez l’étape 2 : « Step 2: Generate wheelie blobs ». L’opération va prendre un certain temps…
  12. Une fois terminez, récupérez les blobs avec la commande indiqué dans la console. Gardez les au moins en double exemplaire, ils sont indispensable pour accéder au mode APX, et ce dernier est le seul moyen permettant de récupérer sa tablette sans l’envoyer en SAV.
  13. Vérifiez que vous avez bien accès au mode APX en passant à la section suivante

Accès au mode APX

Le mode APX n’est accessible qu’à partir de la tablette à l’état éteint. La combinaison de touche est la suivante : Power suivit de Volume-Up.
Si la combinaison a bien été réalisée, l’écran de la tablette devrait s’éteindre, et le PC devrait reconnaître un nouveau périphérique intitulé APX.

Le déverrouillage des commandes APX se fait à ce moment là en tapant la commande suivante : wheelie –blob blob.bin  où blob.bin  correspond à l’un des fichiers récupérés avec le recovery modifié. Si le blob est reconnu et accepté par la tablette, wheelie  devrait afficher l’id de la tablette et l’écran devrait afficher le bootloader.

Si c’est la première fois que vous accédez au mode APX, il est vivement conseillé de sauvegarder également certaines partitions :

  • une image utile dans la récupération de sa tablette : nvflash -r –rawdeviceread 0 2944 bricksafe.img
  • la configuration d’usine avec la commande nvflash -r –read 14 14_factory-config.img
  • le token de déverrouillage du bootloader nvflash -r –read 7 07_unlock-token.img
  • d’autres partitions peuvent être sauvegardées avec le paramètre read, en spécifiant le numéro de la partition. La liste des partitions est décrite ci-dessous.

On quitte le mode APX avec la commande nvflash -r –go .

Table de partitions

La tablette TF700T contient au moins 18 partitions :

  • Partition 02 : BCT, le Boot Configuration Table.
  • Partition 03 : PT, le Partition Table
  • Partition 04 : EBT, le Encrypted Bootloader
  • Partition 05 : SOS, le recovery kernel
  • Partition 06 : LNX, le kernel linux
  • Partition 07 : CER, le bootloader unlock token
  • Partition 08 : IMG
  • Partition 09 : GP1, espace libre pour une table de partition GP1
  • Partition 10 : APP, partition /system, ext4
  • Partition 11 : CAC, partition /cache, ext4
  • Partition 12: MSC, partition /misc, ext4
  • Partition 13 : USP, Upgrade Staging Partition, monté sur /stating et au format ext3. Utilisé durant les mises à jour du firmware
  • Partition 14 : PER, partition /btmac monté durant le boot, au format fat32. Contient des données système spécifique au périphérique
  • Partition 15 : YTU, contient peut-être des données de chiffrage pour les DRM.
  • Partition 16 : CRA, usage inconnu
  • Partition 17 : UDA, /data, ext4.

Ces partitions peuvent être sauvegardées

Le Bootloader

Le bootloader est accessible en appuyant sur Power puis Volume-Down lorsque la tablette est éteinte. Il est également possible d’y accéder depuis Android en tapant adb reboot-recovery .
Une fois dedans, 4 options sont disponibles :

  • la commande fastboot, à condition que la tablette soit déverrouillée
  • le recovery (la première icône RCK)
  • la continuation du démarrage normal sous Android (la seconde icône Android)
  • la réinitialisation de la tablette (wipe data/cache, c’est la dernière icône)

On navigue entre les différentes icônes avec Volume-Down, et on valide l’item sélectionné avec Volume-Up.
A partir d’un certain temps, le bootloader peut sembler être planté ou super long, mais tant qu’on n’a pas bidouillé avec fastboot, c’est juste qu’il est très long.

Voir aussi

Backup par mail

Le pipe (|), opérateur exclusivement Unix, et trop rarement utilisé (tout du moins par moi), m’a permis de réaliser en une seule ligne, une sauvegarde de base de données, compressée, et envoyé par mail.

Voyons la commande finale :

mysqldump --hex-blob --opt -pyourVerySecretPassword -u backup -B my_database | bzip2 -9 | uuencode bdd_mabase_prod_`date +%Y%m%d-%H%M%S`.sql.bz2 | mail -s "Backup BDD" storage_mail@gmail.com

Détaillons cette chaîne :

  1. on dump la ou les bases de données, pour se faire, je conseille fortement l’utilisation d’un utilisateur dédié qui n’aura qu’un accès limité à la lecture et éventuellement à l’utilisation des verrous pour assurer l’intégrité de la sauvegarde
  2. le flux de sortie, un script SQL, est envoyé à bzip pour être compressé
  3. le flux compressé est envoyé à uuencode. Cette opération va encoder avec des caractères ASCII afin d’être pouvoir transmis en pièce jointe et en lui donnant un nom
  4. enfin on expédie le mail avec un sujet et un destinataire

Et si on chiffrait la sauvegarde ?

Il y a plusieurs intérêt à chiffrer la sauvegarde :

  • la sauvegarde peut être placé dans un endroit non sécurisé ou faiblement
  • toute altération sur la sauvegarde sera impossible ou visible

Encore faut-il s’y prendre convenablement. En effet, on a immédiatement 2 façons naïves de chiffrer :

  • soit en utilisant un chiffrage symétrique
  • soit en utilisant un chiffrage asymétrique

Il se trouve que ces deux approches sont après coup débiles. En effet prenons d’abord le chiffrage symétrique ; que se passe-t-il si le serveur qu’on sauvegarde est compromis ? On peut estimer que le contenu des sauvegardes, y compris celles faites AVANT le piratage du serveur ne sont plus sûres, puisque le serveur compromis a non seulement un accès en écriture au site de sauvegarde, mais également la clé de déchiffrage des sauvegardes.

Examinons maintenant le chiffrage asymétrique, qui corrige bien le problème précédent mais présente deux problèmes :

  • le premier est un problème purement pratique : openssl, le couteau suisse du chiffrage pète en rsa lorsque le flux dépasse une certaine taille (très inférieure à 1Mo)
  • le second est d’ordre plus général : les chiffrages asymétriques coûtent très cher en temps processeur (autrement dit un chiffrage asymétrique prendre beaucoup plus de temps qu’un chiffrage symétrique sur le même flux), pour peu que la quantité de données soit « assez » conséquente, le chiffrage pourrait dégrader de façon significative et pendant un temps estimé trop long le serveur sur lequel les calculs s’effectuent.

La méthode que je qualifierais de bonne, (merci à Denis Altudov pour l’astuce), consiste à utiliser se qui se fait déjà dans les mails avec S/MIME : le contenu à protéger est chiffré avec un algorithme symétrique, dont la clé, générée à la demande et donc unique, est chiffrée par un algorithme asymétrique en utilisant la clé privée du destinataire ; ainsi seul le destinataire du mail est capable de lire le contenu protégé.

C’est exactement ce qu’on va faire, en utilisant openssl, et plus spécifiquement la sous-commande smime de openssl.
Il faudra au préalable un certificat (avec sa clé privée), au format PEM pour simplifier l’exemple. Reprenons l’exemple initial en ajoutant du chiffrage :

mysqldump --hex-blob --opt -pyourVerySecretPassword -u backup -B my_database | bzip2 -9 | openssl smime -encrypt -binary -aes128 -outform DER yourPrivateKey.crt | uuencode bdd_mabase_prod_`date +%Y%m%d-%H%M%S`.sql.bz2.ssl | mail -s "Backup BDD" storage_mail@gmail.com

# version openssl smime autonome (ou presque)
mysqldump --hex-blob --opt -pyourVerySecretPassword -u backup -B my_database | bzip2 -9 | openssl smime -encrypt -binary -aes128 -from sender@kveer.com -to storage_mail@gmail.com -subject "Bacup BDD" yourPrivateKey.crt | sendmail storage_mail@gmail.com

Note : openssl smime est capable de générer un mail lui-même comme on peut le voir dans la seconde commande, mais cela aurait donné un mail avec une pièce jointe nommée smime.p7m, ce qui n’est pas terrible pour identifier ce qui était chiffré, en particulier le type de fichier, c’est pourquoi j’ai préféré rester à utiliser uuencode.

Et voilà, plus besoin d’un script dédié pour des plans de sauvegarde simple, il n’y a plus qu’à cronifier.

Déchiffrage

Par rapport à l’exemple donné, voici la commande miroir pour déchiffrer les pièces jointes :

openssl smime -decrypt -binary -aes128 -inform DER yourPrivateKey.crt -in your_encrypted_file.sql.bz2.ssl -out your_decrypted_file.sql.bz2

Les arguments -aes128  et -binary  sont peut-être superflus, je n’ai pas testé précisément ces points là.

Plusieurs pièces jointes dans un mail

Toujours avec le même exemple, voici comment on peut joindre plusieurs pièces jointes, et même un corps de message à son mail :

(
echo -e $YOUR_MESSAGE;
mysqldump --hex-blob --opt -pyourVerySecretPassword -u backup -B my_database | bzip2 -9 | openssl smime -encrypt -binary -aes128 -outform DER yourPrivateKey.crt | uuencode bdd_mabase_prod_`date +%Y%m%d-%H%M%S`.sql.bz2.ssl;
mysqldump --hex-blob --opt -pyourVerySecretPassword -u backup -B another_database | bzip2 -9 | openssl smime -encrypt -binary -aes128 -outform DER yourPrivateKey.crt | uuencode bdd_another_base_prod_`date +%Y%m%d-%H%M%S`.sql.bz2.ssl
)
| mail -s "Backup BDD" storage_mail@gmail.com

Où sauvegarder

Où vous le souhaitez. Pour ma part, j’ai choisi Google, car il propose 8Go par boîte mail gratuitement et accepte des pièces jointes allant jusqu’à 25Mo et parce que je suis pauvre. Pour une sauvegarde à pas chère, les mails via Google constituent une excellente opportunité.

Les paquets à installer

  • uuencode se trouve dans le paquet app-arch/sharutils
  • mail se trouve dans le paquet mail-client/mailx

Exemple de script

A peu de chose près, voici ce que j’utilise comme script de sauvegarde. Ce script se trouve dans @@/etc/cron.daily@@, ce qui lui permet d’être automatiquement exécuté avec les bons privilèges tous les jours.

#!/bin/bash
MYSQL_PASS=verySecretPassword
MYSQL_USER=backup_user
DATE=`date +%Y%m%d-%H%M%S`
HOSTNAME=`hostname`
RECIPIENT=backup@gmail.com
CERT=/root/backup.gmail.com.crt
WWW_WEB1='/var/www/web1/htdocs/ /var/www/web1/reset_acl.sh'
WWW_WEB2=/var/www/web2/htdocs
WWW_WEB3='/var/www/web3/forum /var/www/web3/www'

MYSQL_CMD="mysqldump --hex-blob --opt -u ${MYSQL_USER} -p${MYSQL_PASS} -B"
OPENSSL_CMD="openssl smime -encrypt -binary -aes128 -outform DER $CERT"

CONF='/etc/bash/bashrc
/etc/ahbot.conf
/etc/bind
/etc/clam*.conf
/etc/conf.d
/etc/courier*
/etc/cron*
/etc/dhcp
/etc/env.d
/etc/fail2ban
/etc/freshclam.conf
/etc/group
/etc/passwd
/etc/shadow
/etc/hosts
/etc/init.d
/etc/ipsec*
/etc/kernels
/etc/layman
/etc/locale.gen
/etc/make.conf
/etc/munin
/etc/mysql
/etc/nginx
/etc/ntp.conf
/etc/opendkim
/etc/openvpn
/etc/pam.d
/etc/php
/etc/postfix
/etc/pureftpd.*
/etc/realmd.conf
/etc/revdep-rebuild
/etc/screenrc
/etc/scriptdev2.conf
/etc/security
/etc/selinux
/etc/sysctl.conf
/etc/syslog-ng
/etc/teamspeak3-server
/etc/unrealircd'

T=$( cat <<EOF
Type your texte here\n
with \n if you want your mail to be readable.
EOF
)

( echo -e $T;
uuencode $CERT my_cert.crt;
$MYSQL_CMD base1 | bzip2 -9 | $OPENSSL_CMD | uuencode ${HOSTNAME}_bdd_base1_${DATE}.sql.bz2.ssl;
$MYSQL_CMD base2 | bzip2 -9 | $OPENSSL_CMD | uuencode ${HOSTNAME}_bdd_base2_${DATE}.sql.bz2.ssl;
$MYSQL_CMD base3 | bzip2 -9 | $OPENSSL_CMD | uuencode ${HOSTNAME}_bdd_base3_${DATE}.sql.bz2.ssl;
tar cj ${WWW_WEB1} | $OPENSSL_CMD | uuencode ${HOSTNAME}_www_web1_${DATE}.tar.bz2.ssl;
tar cj ${WWW_WEB2} | $OPENSSL_CMD | uuencode ${HOSTNAME}_www_web2_${DATE}.tar.bz2.ssl;
tar cj ${WWW_WEB3} | $OPENSSL_CMD | uuencode ${HOSTNAME}_www_web3_${DATE}.tar.bz2.ssl;
tar cj ${CONF} | $OPENSSL_CMD | uuencode ${HOSTNAME}_etc_${DATE}.tar.bz2.ssl
) | mail -s "Backup $HOSTNAME bdd $DATE" $RECIPIENT

Voir aussi

Réparer un ventilateur bruyant

Voici une petite astuce simple et peu chère pour donner une seconde vie aux ventilateurs asthmatiques. Il se peut même qu’il soit encore plus silencieux qu’à son tout premier ronronnement.

L’astuce n’est pas de moi, mais ça marche diablement bien ! Avant de devoir claquer 40€ dans un nouveau couple ventirad (et me retrouver avec un autre radiateur dans le placard), autant chercher au préalable si on peut le réparer, surtout si la taille du ventilateur est du genre exotique (12mm en hauteur, 100mm en largeur et longueur), donc le genre qu’on ne peut trouver en boutique, même chez le chinois.

Voici deux sources qui expliquent la manipulation :

Matériel requis

  • un ou plusieurs tournevis cruciformes pour ouvrir le PC et démonter le ventilateur
  • un tournevis plat
  • une bombe à huile ou lubrifiante, de préférence avec un prolongateur souple pour ne pas asperger tout le ventilateur, mais ce n’est pas obligatoire
  • 20 minutes maximum

ManipulationS

  1. Éteindre le PC (optionnel, mais recommandé, un court-circuit est si vite arrivé)
  2. Débrancher et démonter le ventilateur. Cela peut prendre plus ou moins de temps en fonction du ventilateur (ventilateur standard, de CPU ou de GPU). Je ne détaillerai pas ce point, ce n’est pas l’objet du billet.
  3. Prendre le ventilateur, en ayant le côté creux des pales, face à soit. On peut voir qu’un autocollant recouvre le centre du ventilateur (si ce n’est pas le cas, c’est que vous vous êtes trompé de côté)
  4. Enlever délicatement l’autocollant car il faudra le remettre, avec l’aide éventuelle d’un tournevis plat.
  5. Si le centre du ventilateur sous l’autocollant est barbouillé de colle, essayer de gratter avec le tournevis plat, ou utiliser de l’acétone en évitant d’arroser les circuits électroniques s’il y en a.
  6. Enlever le capuchon au centre du ventilateur (le capuchon peut être en caoutchouc ou transparent).
  7. Injecter au centre un peu d’huile.
  8. Nettoyer la surface qui est au contact de l’autocollant si elle a été aspergée d’huile (un jet suffit, il n’est pas nécessaire de noyer le moteur), sinon plus rien ne collera dessus.
  9. Remettre le capuchon, puis l’autocollant.
  10. Remonter puis rebrancher le ventilateur.
  11. done 😉

Retour d’expérience

L’astuce a bien fonctionné, j’ai retrouvé mes ventilateurs silencieux, en revanche cela n’a pas duré très longtemps, pas plus de 2 mois :/

Débugger un flux SSL

Aujourd’hui, ça fera quelques jours que je m’arrache les cheveux à connecter Outlook à Exchange, mais uniquement en ouvrant le port HTTP/HTTPS. Pas le port RPC (tcp 135) car il s’agit de l’interface publique du serveur Exchange, et qu’en plus d’éviter des tentatives de hack par ce port, je n’ai pas eu envie d’ouvrir non plus la tripoté de ports dynamiques qui va avec.

J’ai résolu enfin mon problème, mais durant ma recherche, je suis tombé sur une perle, vraiment, incluse dans Wireshark.
Pour rappel, Wireshark est un outil d’analyse de paquets ; ça capte tout packet réseau et l’affiche sous une forme intelligible, pourvu que le protocole soit dans sa liste, qui est très bien fournie.

L’un de ces protocols, c’est le SSL. Et en regardant sa configuration, on peut observer une boite de dialogue permettant de stocker une liste… de clés privés. Qui n’a jamais eu besoin, au moins une fois dans sa vie, de débugger un flux SSL ? Et bien c’est possible avec Wireshark, si l’on possède la clé privée du serveur SSL.

Typiquement débugger un flux SSL entre un client qu’on a pas développé, disons Outlook, et un serveur qu’on a pas développé non plus, disons Exchange, donc dans le cas  »très improbable » où il est impossible de logguer le flux avant qu’il soit crypté ou après qu’il soit décrypté.

rsa1 rsa2

 

Voir aussi

Importer des certificats d’autorité racine dans Android 2.x

Comme d’habitude comme tout ce qui concerne une manip sous Android nécéssitant l’accès root, je fourni ce tutoriel sans aucune garantie contre la casse ni la bêtise. A vos risques et périls donc.

Il peut arriver de se monter sa propre PKI (pourquoi pas), et de l’utiliser à tout va pour crypter les échanges entre son mobile et ses sites web (les urls qui commencent par https://), ou son serveur de mails perso (pour utiliser pleinement TLS ou le SSL implicite). Bref, pour tous ceux qui voudraient ajouter un certificat d’autorité racine dans leur téléphone Android pour valider tout ce qu’il y a à valider, voici la marche à suivre.

Tout d’abord le matériel requis pour la manipulation :

# on récupère le magasin de certificats depuis son téléphone vers son PC, c’est là que l’ADB devient utile :

adb root
# extract certificates store on the computer
adb pull /system/etc/security/cacerts.bks cacerts.bks
# import mon-ca.crt to the store
keytool -keystore cacerts.bks -storetype BKS -provider org.bouncycastle.jce.provider.BouncyCastleProvider -storepass changeit -importcert -trustcacerts -alias MON-CA -file mon-ca.crt
# type "yes" to confirm the import of the new ca cert
# remount android /system as read-write
adb shell mount -o remount,rw /system
# push the new store
adb push cacerts.bks /system/etc/security
# remoube android /system as read-only
adb shell mount -o remount,ro /system
# done ;)

Plus qu’à redémarrer le téléphone pour qu’il prenne le nouveau CA en compte.

Mettre à jour le Milestone en version 2.0.1 avec le root

Avertissement : cette bidouille a le pouvoir de transformer votre téléphone en brique technologique complètement inerte sans moyen de récupération. Ce tutoriel n’est pas destiné aux apprentis sorciers et je ne pourrais pas être tenu pour responsable des conneries qui pourraient arriver à votre téléphone.

La technique décrite ci-après est dédiée au Motorola Milestone (la déclinaison européenne du Droid), en version 2.0 (la version d’origine). Elle fonctionne, je l’ai testé sur mon propre Milestone.

Remarque: officielle ou pas, la mise à jour 2.0.1 est une mise à jour différentielle, c’est à dire que tous les fichiers systèmes doivent être d’origine. Si vous avez enlevé des apk systèmes par exemple, il faudra les remettre avant d’effectuer la mise à jour, sinon celle-ci échouera lamentablement.

Instructions

  1. Primo, on récupère la mise à jour trafiquée, permettant l’ajout et l’accès au programme su. Ce fichier met à jour le Milestone de la version 2.0 à la version 2.0.1 et ajoute l’accès au root. Il n’est donc pas nécessaire de rooter le téléphone avant d’appliquer cette mise à jour. Télécharger update-2.0.1-no-recovery
  2. Placez cette mise à jour à la racine de la sdcard sous le nom update.zip
  3. Deuxio, passez en mode recovery. Deux techniques pour cela :
    1. Si vous avez un pc avec l’adb pas loin, branchez le téléphone et taper la commande adb reboot recovery . Le redémarrage est instantané et simple. Vous voilà en recovery.
    2. Sinon éteignez le portable complètement puis pressez la combinaison de touche suivante : pressez le bouton doré puis sans relâcher, le bouton on/off. Dès que l’écran s’allume, vous pouvez relâcher les boutons. Vous voilà en recovery.
  4. Affichez le menu du recovery en pressant la touche ‘volume up’ puis sans relâcher le bouton dorée. Un menu s’affiche, vous pouvez relâcher la combinaison de touches.
  5. Sélectionnez ensuite l’entrée ‘apply sdcard:update.zip’ avec les touches directionnelles puis validez.

Quelques informations sur cette mise à jour.

Le zip donné ici est basé sur la mise à jour officielle pour la version Européenne, il ne s’agit donc pas d’un hybride venu d’Hong-Kong, mais bien de la mise à jour qui vous est proposée par le téléphone lui-même.
Le script d’installation de cette mise à jour a été modifié sur le même principe utilisé pour avoir le root avec le Milestone 2.0.
Ce nouveau script d’installation effectue la même chose que le script initial, mais ne flash pas le recovery pour conserver la faille des mises à jour non signées, et push su avec les bons droits pour avoir l’accès root.

Je remercie caohung et poseidon pour les modifications apportées à la mise à jour officielle.

Enjoy

SHA-1 du fichier update-2.0.1-no-recovery.zip : 62E13F64F44AE56C53EE7BDE249717E7402365B4

Rooter le Motorola Milestone

Avertissement : cette bidouille a le pouvoir de transformer votre téléphone en brique technologique complètement inerte sans moyen de récupération. Ce tutoriel n’est pas destiné aux apprentis sorciers et je ne pourrais pas être tenu pour responsable des conneries qui pourraient arriver à votre téléphone.

La technique décrite ci-après est dédiée uniquement au Motorola Milestone (la déclinaison européenne du Droid), en version 2.0 (la version d’origine). Elle fonctionne, je l’ai testé sur mon propre smartphone.

Instructions

  1. Primo, on récupère la mise à jour trafiquée, permettant l’ajout et l’accès au programme su. Ce fichier ne met rien à jour, il ne fait qu’ajouter l’accès au root. Télécharger update-root.
  2. Placez cette mise à jour à la racine de la sdcard sous le nom update.zip
  3. Deuxio, passez en mode recovery. Deux techniques pour cela :
    1. Si vous avez un pc avec l’adb pas loin, branchez le téléphone et taper la commande adb reboot recovery . Le redémarrage est instantané et simple. Vous voilà en recovery.
    2. Sinon éteignez le portable complètement puis pressez la combinaison de touche suivante : pressez le bouton doré puis sans relâcher, le bouton on/off. Dès que l’écran s’allume, vous pouvez relâcher les boutons. Vous voilà en recovery.
  4. Affichez le menu du recovery en pressant la touche ‘volume up’ puis sans relâcher le bouton dorée. Un menu s’affiche, vous pouvez relâcher la combinaison de touches.
  5. Sélectionnez ensuite l’entrée ‘apply sdcard:update.zip’ avec les touches directionnelles puis validez.

Quelques informations sur cette mise à jour.

Le recovery du Milestone 2.0 présente une faille permettant de lui faire accepter des mises à jour mal-formées. Pour faire court, en accolant un zip officiel et signé à un zip contenant le nécessaire pour le root, on obtient un autre zip valide (accepté par le recovery) qui est la fusion des deux zips précédent. Ce zip final contient un script d’installation permettant l’ajout de su avec les bons droits et SuperUser.apk.

Pourquoi rooter son téléphone ?

Si vous ne connaissez pas la réponse à cette question, il est plus prudent de ne pas faire cette manipulation.%%%
Sinon les réponses sont assez diverses pour ma part :

  • flinguer les mises à jour OTA
  • naviguer dans le système de fichiers Android sans aucune restrictions
  • récupérer les *.apk (les applications du market) pour en faire une sauvegarde, y compris les apk chiffrés
  • tuner en profondeur le matériel comme l’utilisation cpu avec SetCPU (undercloacker lorsque le téléphone n’est pas utilisé par exemple)
  • ne pas attendre le bon vouloir de Motorola et faire de mon téléphone ce que je veux

Un grand merci à SeraphimSerapis, Andrea et Zinx Verituse pour avoir trouvé cette faille et avoir su l’exploiter.

Voir aussi

SHA-1 du fichier update-root.zip : 07DA7B71420D013D12885BD148BF3E9661034CC0

Enjoy