samedi 4 juillet 2009

Récupération mot de passe aMSN

J'ai pour habitude d'oublier régulièrement les mots de passe de mes comptes MSN, car je ne les utilise que pour « chatter » avec certains de mes contacts, à l'aide d'une adresse externe (i.e. par une hotmail ou live). Bien entendu, j'utilise un mot de passe différent que celui associé au webmail associé à cette adresse, pour raisons de sécurité.
La plupart des clients MSN offre l'option "se souvenir du mot de passe", ce qui fonctionne tellement bien, que tu fais que je ne tape jamais mon mot de passe, je l'oublie.
Certains clients proposent une option pour le récupérer (notamment Kopete, à l'aide de kwalletmanager), mais pas aMSN.

J'ai longtemps chercher sur internet pour trouver un moyen simple de le récupérer depuis les préférences d'aMSN, mais la plupart des sujets sur des forums sont soit sans réponse, soit "tu ne dois pas oublier tes mots de passe"...

J'ai donc décidé d'aller regarder dans les sources de aMSN (qui sont en fait des scripts TCL) pour regarder comment les mots de passe étaient chiffrés et déchiffrés (ce qu'on peut appeler du reverse-engineering).

Je l'ai fait sur ma Gentoo/Linux, et la technique est assez facile, il y a juste besoin d'accès root, où à la rigueur à la commande sudo, pour éditer un fichier.


Premièrement, il vous faut localiser le fichier config.tcl, dans le répertoire système de aMSN, il s'agit de /usr/share/amsn/ sur mon système.
Après une petite recherche sur le mot encpassword devrait vous amener vers les lignes 690 (683 exactement de mon côté).
Quelques lignes en dessous, on peut observer deux lignes qui commencent par un #.

Ligne 693:
#puts "Password is: $password\nHi\n"
Ligne 704:
#puts "Password is: [::config::getKey remotepassword]\nHi\n"

(En réalité, le premier suffit).

Il suffit alors de décommenter ces lignes, (i.e. d'enlever le caractère #), d'enregistrer le fichier, et de lancer amsn dans un terminal.

Lorsque que aMSN va se charger, le mot de passe va apparaître sur la console, suivi d'une ligne contenant juste "Hi".
Pour faire afficher les mots de passe des autres comptes, il suffit de choisir l'adresse e-mail dans la liste déroulante associée.

Voilà, c'est fait, il ne reste plus qu'à remettre les # dans config.tcl.



PS: Pour info, les message sont chiffrés en AES, en utilisant les 8 premiers caractères de l'adresse e-mail en tant que clef. L'implémentation d'AES utilisée et fournie avec aMSN directement, donc ça peut éventuellement changer dans les futures versions (j'utilisais la 0.97.2).

jeudi 25 juin 2009

aMSN Password Recovery

I often forgot the passwords for my msn accounts, as I only use them for chatting over the MSN protocol, using an external e-mail address, with another password that my main mailbox have (for security reasons). So, as aMSN has the "remember password" feature, I use it, and it does perfectly its job as I forget it because I'm never typing my password.

I looked a lot over the internet to find a nice way to recover them, but the given response is "you shall not forget your passwords". So I decided to look at the aMsn TCL scripts (yes, aMSN is mostly written in TCL) to take a look onto how the passwords were enciphered and deciphered.

I did it on Gentoo/Linux, and the hack is really easy, you just need a root account, or either an access to the sudo command.

First step, locate the amsn config.tcl script, I have it in /usr/share/amsn/, then look for the word 'encpassword' (line 686 on my file), then you should find a few lines below :

Line 693:
#puts "Password is: $password\nHi\n"
and, or Line 704:
#puts "Password is: [::config::getKey remotepassword]\nHi\n"

(Actually, only the first one should be necessary.)

Then, just edit that file, by only removing these # at the beginning of the lines, save it, open a console, then run amsn from the console.

You will see a magical output giving your password. If you use several accounts, just choose the right account in the combobox, the password will appear on the console.

Now, don't forget to undo the changes you made to config.tcl !



NB aux lecteurs français : J'ai écrit ce billet en anglais, je prépare une traduction en français

lundi 25 mai 2009

Changement de thème

Le précédent était trop centré, et les lignes pas assez longues compte tenu de la longueur de mes précédents billets...

mardi 17 février 2009

De la réforme des universités...

...dont on parle beaucoup

Aujourd'hui, le département d'informatique de l'Université de Nice Sophia-Antipolis a décidé d'afficher clairement sa position face aux événements récents, c'est par ici. Enfin, je dis clairement, l'image est certes un peu floue, mais le message lui est clair.

Sinon, un bon argumentaire sur les raisons de la mobilisation m'a été transmis par un de mes enseignants. Le titre « Une période de glaciation intellectuelle commence » est expliqué dans le texte.

lundi 16 février 2009

wifi intel et noyaux >= 2.6.27

Chose étrange, quand j'ai voulu migrer mon noyau de 2.6.26 vers 2.6.27, mon wifi ne fonctionnait plus avec la nouvelle version.

Je suis sous Gentoo, j'utilise donc leurs patchs pour le noyau, et j'ai une carte wifi intel 4965.

Sous les noyaux .26 et inférieurs, le driver s'appelait iwl4965, et pas de problèmes à signaler, si ce n'est de devoir exécuter la commande suivante pour que l'association se fasse.
# iwconfig wlan0 ap auto

Passé au .27 et plus, le driver a été entièrement recodé pour supporter le 801.11n en plus du .11g. Le nouveau driver s'appelle désormais iwlagn.

Une fois le module chargé, impossible de m'associé à un hôte, et Google n'a pas su m'aider dans cette quête du wifi sur les noyaux récents.

/var/log/messages me mettais les messages d'erreurs suivants :

Feb 15 11:17:39 lambda iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Feb 15 11:17:39 lambda iwlagn 0000:03:00.0: irq 1272 for MSI/MSI-X
Feb 15 11:17:39 lambda Registered led device: iwl-phy0:radio
Feb 15 11:17:39 lambda Registered led device: iwl-phy0:assoc
Feb 15 11:17:39 lambda Registered led device: iwl-phy0:RX
Feb 15 11:17:39 lambda Registered led device: iwl-phy0:TX
Feb 15 11:17:40 lambda ADDRCONF(NETDEV_UP): wlan0: link is not ready
Feb 15 11:17:41 lambda wlan0: authenticate with AP 00:1a:2b:0f:14:1e
Feb 15 11:17:41 lambda wlan0: authenticated
Feb 15 11:17:41 lambda wlan0: associate with AP 00:1a:2b:0f:14:1e
Feb 15 11:17:41 lambda wlan0: RX AssocResp from 00:1a:2b:0f:14:1e (capab=0x411 status=0 aid=1)
Feb 15 11:17:41 lambda wlan0: associated
Feb 15 11:17:41 lambda ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Feb 15 11:17:41 lambda wlan0: disassociating by local choice (reason=3)
Feb 15 11:17:41 lambda iwlagn: index 0 not used in uCode key table.
Feb 15 11:17:42 lambda phy0: failed to restore operational channel after scan
Feb 15 11:17:42 lambda phy0: failed to restore operational channel after scan
Feb 15 11:17:43 lambda wlan0: privacy configuration mismatch and mixed-cell disabled - disassociate



Un ami m'a indiqué irqpoll à ajouter à la ligne de boot, et Miracle! ça a fonctionné.

Autre fait, j'utilise de temps en temps powertop, pour mesurer les programmes qui réveillent le processeurs, et donc consomme plus d'énergie quand je suis sur batterie. Ce programme me conseillait de désactiver l'option de compilation CONFIG_IRQBALANCING sur mon noyau, parmis d'autres optimisations nécessaires selon lui.

J'ai tenté le rapprochement irq-poll/irq-balancing, même si je reconnais ne pas trop savoir les conséquences sur la gestion du matériel sur l'OS. J'ai donc recompilé mon noyau sans IRQBALANCING, et tenté de démarrer sans irqpoll, et idem, ça fonctionne. Youpi!

dimanche 15 février 2009

Broker

Broker est un mot anglais qui désigne un intermédiaire entre deux parties. Le terme vient du vocabulaire commercial anglais qui représente un tiers entre des vendeurs et des clients.

Le sens informatique est le même, sauf qu'au lieu de vendeurs on a des serveurs, et il ne s'agit plus d'échange de biens, mais de données.

Le Broker est donc un méta-logiciel, qui a deux comportements. Méta, parce qu'il agit comme client pour les serveurs, et comme serveur pour les clients.

Les outils google sont des exemples de broker, pour google reader, ou google mail par exemple.

Google Reader va chercher des flux RSS/Atom sur différents site, et vous permettre soit de les lire depuis son site internet, soit de récupérer l'ensemble des items dans un flux unique pour le lire avec un autre outil.
De façon similaire, Google Mail permet d'aller relever différentes boîtes de courrier, et ensuite de récupérer le tout à travers le serveur imap de GMail. La plupart des Webmail (Horde par exemple) permettent cette fonctionnalité d'ailleurs, n'allez pas croire que j'ai des actions chez Google.

Hop est un broker générique, principalement basé sur http, mais il est capable (à travers Bigloo qui lui sert de base) d'aller ouvrir n'importe quelle socket, pour peu qu'on lui dise comment agir avec le serveur distant, puis comment agir avec les clients. L'API de Bigloo étant assez riche, il peut aussi gérer les mails, le multimedia, les bases de données...

C'est là où j'essaie d'apporter ma pierre à l'édifice, en implémentant le protocole IRC (RFC1459 Internet Relay Chat) sur Bigloo, afin qu'Hop puisse ensuite faire le broker.

A terme, je souhaite que Hop puisse se connecter à différents serveurs, et canaux, Irc, et autoriser des clients à se connecter à lui, afin de leur retransmettre les parties "manqués" des conversations. Bien entendu, si le flux de donnée est trop grand, il faudrait ajouter quelques commandes pour obtenir les X derniers messages, ou les messages des dernières Y minutes par exemple.

Le but étant que le client IRC se connecte au Broker et qu'il croit parler directement au serveur distant...