Desserte des aéroports par les transports en commun

J’ai réalisé un document qui liste les moyens de transport pour se rendre d’un aéroport à un centre-ville, avec leurs tarifs, leurs fréquences, leurs temps de parcours. Il permet de comparer rapidement les différentes solutions avec leurs avantages et inconvénients.

Les aéroports traités sont ceux qui voient transiter plus d’un million de passagers par an, en France métropolitaine. Les informations proviennent des compagnies, des aéroports ou d’expériences personnelles.

Il s’agit d’une première version qui peut contenir des erreurs ou des approximations. Il est aussi possible que des moyens aient été oubliés. N’hésitez pas à me faire remonter vos impressions, remarques ou informations qui permettraient d’améliorer ce document.

Aéroliaisons – Principaux aéroports français – version 1

Licence Creative Commons
Ce document est mis à disposition selon les termes de la licence Creative Commons Attribution – Partage dans les Mêmes Conditions 4.0 International.

Mise à jour : je n’en ai pas parlé dans le document, il existe des billets « journée » pour les moins de 26 ans en région parisienne, valables les week-ends et jours fériés. Ces billets ne permettent pas d’accéder aux aéroports par Roissybus, Orlybus, Orlyval, le RER B ou les lignes Filéo, car ils n’incluent pas la taxe Aéroports de Paris. Ils peuvent être utilisés dans les bus 183, 351, Seine-et-Marne Express, le tram 7, etc.

Les recherches bizarres des gens

Comme à chaque fin d’année, WordPress m’envoie un récapitulatif des stats de ce blog. Je les survole sans trop m’y attarder. Mais là, des expressions de recherche m’ont particulièrement fait rire, surpris ou interloqué. En voici quelques unes en vrac et ce qui me vient à l’esprit quand je les lis.

« peut on espionner une boite mail et comment »

Oui, en regardant par dessus l’épaule de la personne qui consulte ses mails.

« supprimé appel masqué »

Éteindre téléphone.

« ouvrir son pc par smartphone »

Bientôt le tournevis connecté ?

« un bon message pour s’introduire a quelque que on se connait pas »

Wut

« violer boite mail »

Ça déchire.

 « ca veut dire quoi votre wifi est partage sur votre livebox alors que je suis chez bouygue »

Que tu as un souci.

« pirater une adresse mail wanadoo »

Cette recherche a mis 10 ans pour arriver.

« http://www.la methode de faire un boite imail »

Wut²

« comment marche le 0123456789 »

Avec ses jambes.

 

Ça, c’est pour l’année 2014, et ce n’est qu’une infime partie. Les années précédentes aussi, il y a eu des champions.

 

« free wifi secure si je me connecte avec mon pc il me demande un identifiant »

D’accord.

« la wifi sa marche sur un autre operateur? »

Wut³

« probleme avec mon server dans le virtualbox je ne peut pas acce de par ssh sans le cable reseau ne soi branche »

C sur ke san kable sa konect pa

 

En espérant avoir encore répondu à des questions intéressantes et pertinentes !🙂

Authentification automatique sur le SFR WiFi

[TL;DR : le script bash ici]

Vous êtes en vacances, loin de chez vous et de votre connexion à Internet. Vous voulez bidouiller sur votre ordinateur. Vous captez des réseaux SFR WiFi mais il faut ouvrir un navigateur, attendre que SFR renvoie sa page d’authentification, saisir ses identifiants, … C’est chiant, surtout quand vous utilisez un vieux netbook tout juste capable de faire tourner Firefox. Mais vous êtes ingénieux, malin, intelligent (au moins tout ça), vous êtes sous Linux donc vous allez étudier le fonctionnement de ce système et automatiser la procédure pour ne plus avoir à lancer une interface graphique ou pire, un navigateur juste pour faire un commit.

Et puis même si vous ne vous sentez pas de réaliser cela, quelqu’un l’a déjà fait pour vous et va vous expliquer tout ça dans cet article (en l’occurence, moi :-°).

Overview

Voyons comment le système fonctionne. On se connecte à un SFR WiFi Fon, on lance Firefox, on ouvre Tamper Data et on essaie d’aller sur un site web. Tamper Data est une extension Firefox qui permet de voir les requêtes HTTP émises par le navigateur, ainsi que les en-têtes des réponses. En tapant une adresse quelconque, on voit qu’on est redirigé (302) vers une page SFR qui contient des tas de paramètres dans l’URL.

Formulaire d'authentification SFR

Formulaire d’authentification SFR

On saisit ses identifiants et on voit qu’une requête POST est soumise, contenant en paramètres les identifiants bien sûr, mais aussi les paramètres précédemment transmis dans l’URL.

Une page HTML nous est alors envoyée en réponse. Elle contient un morceau de Javascript qui veut nous rediriger vers une page du réseau local, à priori pour confirmer le succès de l’opération. Une fois que cette page a été demandée, on peut enfin sortir sur le net.

Début de script

Deux opérations nous seront vitales dans l’automatisation : la récupération de pages en HTTP et la récupération de valeurs dans une URL. Nous utiliserons respectivement wget et awk pour cela. Sous Linux, il y a de fortes chances pour que vous ayez déjà ces outils.

La première étape consiste à récupérer l’URL de redirection, car elle contient un challenge (token ou jeton) qu’il faudra réinjecter dans le formulaire (les autres informations sont normalement toujours les mêmes, mais nous les récupèrerons quand même pour ne pas à avoir à modifier notre code si cela changeait du jour au lendemain). On va donc chercher une page quelconque avec wget et récupérer cette adresse.

wget -O /dev/null -o loc http://perdu.com
echo `grep Location loc` > loc
location=`awk 'BEGIN { FS=" " } { print $2 }' loc`

Pour isoler l’adresse, n’étant pas trop doué pour cela, j’ai jonglé avec grep et awk pour obtenir un truc qui fonctionne. C’est sûrement pas très propre mais ça marche. Je ne vais pas m’étendre sur le fonctionnement de awk, j’ai cherché rapidement un exemple sur Google que j’ai adapté aux circonstances…

Histoire de ne pas tout condenser en une seule ligne, j’ai préféré enregistrer la sortie de wget dans un fichier pour n’en garder que la ligne indiquant la localisation de la page de redirection (d’où le « grep Location »). Si vous ne voulez ou ne pouvez pas utiliser de fichier temporaire de sortie, rien ne vous empêche de chainer les instructions (bon courage pour reprendre le code plusieurs mois après).

Les paramètres

On a récupéré l’adresse dans une variable. Il faut isoler les différents paramètres contenus dans cette URL pour pouvoir les injecter par la suite, quand il faudra soumettre les identifiants. Pareillement, on va profiter de la puissance de awk pour stocker cela dans des variables.

challenge=`awk 'BEGIN { FS="&" } { print $4 }' loc | awk 'BEGIN { FS="=" } { print $2 }'`
nasid=`awk 'BEGIN { FS="&" } { print $6 }' loc | awk 'BEGIN { FS="=" } { print $2 }'`
mac=`awk 'BEGIN { FS="&" } { print $7 }' loc | awk 'BEGIN { FS="=" } { print $2 }'`
uamport=`awk 'BEGIN { FS="&" } { print $3 }' loc | awk 'BEGIN { FS="=" } { print $2 }'`
uamip=`awk 'BEGIN { FS="&" } { print $2 }' loc | awk 'BEGIN { FS="=" } { print $2 }'`
mode=`awk 'BEGIN { FS="&" } { print $8 }' loc | awk 'BEGIN { FS="=" } { print $2 }'`
channel=`awk 'BEGIN { FS="&" } { print $9 }' loc | awk 'BEGIN { FS="=" } { print $2 }' | awk 'BEGIN { FS=" " } { print $1 }'`

Préparation du POST

Pour soumettre des paramètres en POST avec wget, on utilise l’option –post-data key=value (avec autant de paramètres qu’on souhaite tant qu’on les sépare par des esperluettes (&)). Histoire d’éviter d’avoir dans notre script une commande suffisamment longue pour relier la Terre à la Lune, on va stocker la postdata dans une variable.

postdata="choix=neuf&username=$uname&password=$pass&conditions=on&challenge=$challenge&username2=$uname&accessType=neuf&lang=fr&mode=$mode&userurl=http://perdu.com&uamip=$uamip&uamport=$uamport&channel=$channel&mac=$nasid|mac&connexion=Connexion"

Bien entendu, les identifiants font partie de ces données. Pour simplifier le code, ils sont définis dans des variables en début de script (à vous de le faire avec les vôtres).

Envoi de la demande de connexion

Il ne reste plus qu’à envoyer la requête. L’adresse est définie par l’attribut « action » du formulaire de la page d’authentification, il suffit de jeter un œil au code HTML. Cette adresse semblant immuable (pas de challenge), on la met directement dans le code (mais quand même dans une variable pour la retrouver facilement). Hop, on envoie tout ça !

target=https://hotspot.wifi.sfr.fr/nb4_crypt.php # Cette variable devrait être en début de script
wget -O debug $target --post-data="$postdata"

Une page HTML nous est retournée. Elle contient un morceau de Javascript voulant nous rediriger vers une page du réseau local (en cas de succès). Il est nécessaire de suivre cette page pour pouvoir commencer à naviguer. On isole donc cette adresse pour pouvoir la suivre.

<script type="text/javascript">
     window.location = "http://192.168.2.1:3990/logon?username=*USERNAME*@ssowifi.neuf.fr&amp;response=*CODE*&amp;uamip=192.168.2.1&amp;userurl=http%3A%2F%2Fperdu.com%3Bneuf%3Bfr%3B4%3Bhttp%3A%2F%2Fperdu.com%3B";
</script>

 

newloc=`grep location debug | awk 'BEGIN { FS="\"" } { print $2 }'`
wget $newloc -O newloc

Comme au début, j’ai préféré utiliser un fichier temporaire pour raccourcir les instructions.

Et voilà ! On a un beau code permettant de s’authentifier sur le réseau SFR WiFi sans avoir à ouvrir un navigateur ou même cliquer sur le bouton de connexion ! L’idéal est de lancer ce script à chaque connexion sur un réseau de ce type. Cela est faisable avec Wicd en interface graphique (propriétés du réseau – script de post-connexion).

Prochaine étape : la redistribution du réseau pour pouvoir connecter plusieurs machines au même réseau communautaire sans qu’elles n’aient à s’authentifier. On peut aussi peaufiner le code pour qu’il n’utilise pas de fichier temporaire.

Le code final, aussi téléchargeable ici :

#!/bin/bash

# Auto-connect to SFR WiFi
# To use in combination with wicd

# VARS
# location: URL associated with 302 reply (contains challenge)
# challenge: part of POST data to be sent
# target: target URL for POST
# nasid: hotspot's MAC address (part of location)
# mac: client's MAC address (part of location)
# uamport: same here
# uamip: same here
# mode, channel: ...
# uname: username
# pass: password
uname=#SFR ADDRESS OR TELEPHONE NUMBER
pass=#ACCOUNT PASSWORD
target=https://hotspot.wifi.sfr.fr/nb4_crypt.php

# Step 0: wait for the connection to establish
sleep 2

# Step 1: get the location with wget
wget -O /dev/null -o loc http://perdu.com
echo `grep Location loc` > loc
location=`awk 'BEGIN { FS=" " } { print $2 }' loc`

# Step 2: extract challenge, MAC addresses, ... from location

challenge=`awk 'BEGIN { FS="&" } { print $4 }' loc | awk 'BEGIN { FS="=" } { print $2 }'`
nasid=`awk 'BEGIN { FS="&" } { print $6 }' loc | awk 'BEGIN { FS="=" } { print $2 }'`
mac=`awk 'BEGIN { FS="&" } { print $7 }' loc | awk 'BEGIN { FS="=" } { print $2 }'`
uamport=`awk 'BEGIN { FS="&" } { print $3 }' loc | awk 'BEGIN { FS="=" } { print $2 }'`
uamip=`awk 'BEGIN { FS="&" } { print $2 }' loc | awk 'BEGIN { FS="=" } { print $2 }'`
mode=`awk 'BEGIN { FS="&" } { print $8 }' loc | awk 'BEGIN { FS="=" } { print $2 }'`
channel=`awk 'BEGIN { FS="&" } { print $9 }' loc | awk 'BEGIN { FS="=" } { print $2 }' | awk 'BEGIN { FS=" " } { print $1 }'`

# Step 3: prepare POST with target URL (set in the code)
postdata="choix=neuf&username=$uname&password=$pass&conditions=on&challenge=$challenge&username2=$uname&accessType=neuf&lang=fr&mode=$mode&userurl=http://perdu.com&uamip=$uamip&uamport=$uamport&channel=$channel&mac=$nasid|mac&connexion=Connexion"

# Step 4: send POST request
wget -O debug $target --post-data="$postdata"

# Step 5: get a page on local AP
newloc=`grep location debug | awk 'BEGIN { FS="\"" } { print $2 }'`
wget $newloc -O newloc

# DEBUG
echo START DEBUG
echo challenge $challenge
echo nasid $nasid
echo mac $mac
echo uamport $uamport
echo uamip $uamip
echo mode $mode
echo channel $channel
echo location $location

Voilà, un code sûrement affreux mais qui a le mérite de fonctionner et de m’avoir dépanné plus d’une fois !🙂

aDNSblock, la suite

En fin d’année dernière, j’avais codé un script qui modifiait la configuration du serveur DNS bind de manière à ne pas répondre aux requêtes vers les domaines d’annonceurs publicitaires. Je l’avais publié sur ce blog et j’avais appelé ça « aDNSblock ». Je l’ai repris récemment et l’ai déployé sur un serveur.

L’objectif est d’arriver à avoir un serveur DNS qui bloque un maximum de requêtes vers les annonceurs, de manière à pouvoir renseigner simplement l’adresse de ce serveur dans son smartphone pour ne plus avoir de pubs. L’idée est, au final, d’avoir une application Android ou autre qui peut modifier le serveur DNS (ou, à défaut, détourner les requêtes DNS) pour utiliser un aDNSblock.

Je vais arrêter de parler de ce projet sur ce blog. Maintenant, les nouvelles seront sur le nouveau site dédié adnsblock.info. Au moment où je tape ces lignes, l’objectif est d’éprouver le serveur pour obtenir un maximum d’adresses d’annonceurs pour pouvoir les bloquer. Si vous pouvez m’aider, n’hésitez pas !

Changer de serveur DNS sur un Android non rooté ?

Un petit article rapide pour vous informer que je cherche un moyen de changer les serveurs DNS sur Android sans le rooter. On peut le faire manuellement dans les paramètres avancés de la connexion Wi-Fi, mais ça ne fonctionne qu’avec le Wi-Fi et nécessite de définir un adressage statique pour chaque point d’accès qu’on utilise.

Après recherche, j’ai trouvé une application sur le Play Store, DNSet, qui propose cela. Dans la description, on nous explique que l’application crée un VPN local pour dérouter le trafic DNS vers le serveur de son choix. Bon, pour 99 centimes, je tente.

J’ai un serveur DNS personnel. Je me connecte dessus en SSH et lance une écoute avec tcpdump pour capter le trafic DNS. Je lance l’appli, précise l’adresse de mon serveur. Le VPN s’établit, je lance Twitter pour tester. Résultat :

root@XXX:~# tcpdump -i XXX udp port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on XXX, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
22:13:15.141006 IP XXX.62129 > XXX.net.domain: 61136+ A? settings.crashlytics.com. (42)
22:13:15.163342 IP XXX.net.56316 > l.gtld-servers.net.domain: 52203% [1au] A? settings.crashlytics.com. (53)
[…]

Ahem. C’est quoi, ça ? Ça ne ressemble pas à Twitter. Si je configure mon DNS manuellement dans ma connexion Wi-Fi, ça donne quoi ?

root@XXX:~# tcpdump -i XXX udp port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on XXX, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
22:38:58.292666 IP XXX.6736 > XXX.net.domain: 5743+ A? twitter.com. (29)

Ah oui. Ok. Donc cette application pue à mort. Ne l’utilisez pas. Je l’ai immédiatement désinstallée après ce test. Et elle m’a été remboursée. Je n’en demandais pas tant !

TL;DR : DNSet altère vos requêtes DNS !

Voilà. Au passage, quand vous configurez vos paramètres DNS du Wi-Fi, ne vous plantez pas dans l’adresse. J’ai eu le malheur de mettre un zéro en trop, ça a fait crasher Android. Et ça crashait continuellement tant que le Wi-Fi était activé et que le smartphone tentait de se connecter au point d’accès mal configuré. J’ai dû aller dans un autre endroit, où le réseau maudit n’était pas, pour pouvoir faire « Oublier » et rétablir sa configuration par défaut.

Du coup, je cherche un développeur Android qui saurait faire une application où on peut changer le serveur DNS et qui n’altèrerait pas les requêtes. N’hésitez pas à me contacter !

[POC] Tweeter sans réseau (ou presque)

Dans le train, qu’il peut être difficile d’envoyer un tweet… Le réseau est fluctuant dès qu’on s’éloigne d’une ville, et pour quelque chose d’aussi bref qu’envoyer un tweet, ça devient très compliqué sans 3G ou 4G !

En effet, l’envoi d’un tweet se fait sur TLS (chiffrement) et TCP (transport fiable). L’établissement d’une connexion au serveur nécessite de nombreuses communications qui doivent toutes passer en un intervalle de temps réduit, sous peine de devoir tout recommencer ! Alors qu’en principe, il suffirait d’envoyer une seule requête…

C’est sur ces pensées que m’est venue l’idée d’exploiter l’IP over DNS. Grâce à ce principe, on peut envoyer une seule requête à un serveur qui, ensuite, enverra effectivement le tweet. Le concept est d’envoyer le tweet sous forme d’un nom de domaine encodé en base64. Le serveur qui recevra finalement cette requête DNS ne répondra pas mais interprétera le sous-domaine en le décodant et le tweetant. Cela nécessite un client Twitter sur le serveur. J’ai trouvé TTYtter qui fait très bien l’affaire.

S’agissant d’une preuve de concept (en anglais POC pour Proof Of Concept), j’ai (encore) fait du code sale à l’arrache en quelques heures. Mais ça marche. La POC combine deux petits programmes en C, qui récupèrent le sous-domaine, avec un script bash qui pilote le tout. Voici les codes sources :

  • recvdns.c : écoute sur le port 53 et enregistre dans un fichier une requête DNS
  • sousdom.c : détermine le sous-domaine en lisant dans un fichier
  • tod.sh : le script shell qui reçoit une requête DNS, décode le tweet et l’envoie
  • Le code perl du client Twitter, TTYtter

Avant tout, il est nécessaire de configurer le DNS et TTYtter. Pour ce dernier, c’est simple : lancez-le une première fois et laissez-vous guider ! Pour le DNS, vous devez avoir un enregistrement de type A qui pointe vers votre serveur et un enregistrement de type NS qui pointe vers le premier. Exemple :

Nom de l’enregistrement Type Pointe vers…
xxx.vincesafe.fr A 1.2.3.4
yyy.vincesafe.fr NS xxx.vincesafe.fr

Dans cet exemple, le serveur qui lancera le script a pour adresse 1.2.3.4.

Compilez les fichiers source C et placez tous les exécutables (sousdom, recvdns, tod.sh et ttytter) dans le même répertoire. Assurez-vous que le droit d’exécution est bien présent. Il n’y a plus qu’à lancer tod.sh.

… Et maintenant ? En fait, je n’ai pas (encore) développé de client… J’ai juste testé si ça fonctionnait en encodant un tweet en base64 et en lançant une requête du style tweetencode.yyy.vincesafe.fr… Et ça a marché ! J’ai utilisé le compte Twitter de mon serveur, vinceserv, pour immortaliser le moment.

Je rappelle qu’il s’agit là d’une preuve de concept (POC) codée à la va-vite et que tout reste à faire ! On peut facilement améliorer le code (et je vous encourage à le faire et à le partager), coder un client pour Android… J’entrouvre une porte, faites-en ce que vous voulez.

Ah, un détail : s’agissant d’IP over DNS, ce « truc » fonctionne sur les hotspots Wi-Fi sans avoir à s’identifier, ainsi que sur les réseaux de données (3G…) même si on n’a plus de crédit…😉

aDNSblock, un serveur DNS qui bloque la pub

Dans un précédent article, je vous parlais d’une technique pour ne pas recevoir les pubs sur les applications smartphone. J’ai étendu le principe utilisé, à savoir le blocage de DNS, pour aller plus loin : utiliser son propre serveur comme serveur DNS et bloquer les domaines des annonceurs. Cela nécessite évidemment d’avoir son propre serveur. En fouinant un peu, j’ai vu que je n’étais pas le premier à avoir l’idée et j’ai trouvé un fichier de zones pas mal rempli que j’ai réutilisé.

J’ai codé (à l’arrache) un script bash dégueulasse mais qui marche chez moi (Debian + bind9, vous l’arrangerez suivant votre configuration). Voici pour vous aDNSblock. Je place ce code dans le domaine public, on va quand même pas foutre une licence sur un torchon pareil.

L’avantage de cette solution est qu’il vous suffit de configurer votre ordinateur en renseignant l’adresse d’un serveur aDNSblock et pouf ! Plus de pubs… Enfin, il faut maintenir la liste à jour manuellement. On doit pouvoir automatiser ça en se basant sur les filtres AdBlock+, je me pencherai dessus un de ces quatre.

Si quelqu’un laisse tourner son serveur aDNSblock et veut en faire profiter ceux qui n’en ont pas, n’hésitez pas à laisser l’adresse du serveur en question dans les commentaires.

Suivre

Recevez les nouvelles publications par mail.

%d blogueurs aiment cette page :