Les secrets du bus CAN de la Renault Clio III

J'ai déjà parlé un peu des dongles OBD2 et des quelques expériences que j'ai faites avec ce dongle sur ma voiture.

Cependant, je me suis assez rapidement rendu compte des limitations du dongle OBD2. Par exemple, la liste des paramètres que l'on peut récupérer est assez limitée. J'ai par exemple pu constater que je ne dispose pas des indications du MAF (flux de mélange air-essence à l'admission) sur mon véhicule. Finalement, mis à part la vitesse, le compte-tours et la température du moteur, il n'y a pas grand-chose avec quoi travailler si on veut fabriquer une planche de bord alternative, par exemple.

La norme OBD2 est conçue pour fonctionner quelle que soit la couche physique sous-jacente, de la même manière que le protocole HTTP reste le même, que l'on soit sur un réseau Ethernet, ATM ou MPLS. Dans le cas de ma Clio III, il y a en réalité un véritable réseau informatique avec un trafic assez conséquent (entre 10 et 100 trames par seconde) avec parfois des contraintes temps-réel. Ce réseau (ou bus) s'appelle CAN (Controller Area Network) et est de plus en plus répandu dans les véhicules en circulation. Sur la Clio, il s'agit de la variante avec des adresses de 11 bits. Le débit est de 500 kbps, même si certaines trames semblent être à 250 kbps.

La puce ELM327 de mon dongle possédant une fonction d'écoute, je me suis amusé à regarder ce qui passait sur le bus. Et c'est là que je me suis rendu compte de l'énorme quantité de données qui circule sur le bus. Lorsque le moteur tourne, j'irais même jusqu'à estimer le taux d'occupation du lien à au moins 20%. Devant cette découverte, je me suis senti obligé de me lancer dans une analyse et voir à quoi correspondent toutes ces trames.

Constatant que je ne suis pas la seule personne à être aussi curieuse (et c'est d'ailleurs ce topic qui a titillé ma curiosité initiale), je publierai donc les résultats intermédiaires de mes recherches, dans l'espoir qu'elles pourront être utiles à certaines personnes. Bien entendu, si vous disposez de renseignements complémentaires, j'en serai toute ouïe.

Je commencerai donc par exposer la méthodologie et les outils de ce travail de rétroingénierie, pour ensuite dresser la liste des adresses CAN que j'ai vues passer sur le bus, pour enfin en déduire le format de chacune des trames CAN. Le code source de mes outils est bien entendu public.

Méthodologie

La méthodologie est relativement simple. Il m'a d'abord fallu régler de façon permanente le dongle pour qu'il communique à 230 400 bauds avec l'hôte. Cette mesure est nécessaire afin d'éviter les erreurs "BUFFER FULL".

J'ai ensuite codé un outil qui envoie automatiquement toutes les commandes nécessaires (dont ATH1, ATCAF0 et ATMA) au dongle, et qui écrit toutes les trames reçues sur la sortie standard, sauf celles qui ont un contenu entièrement identique. Cela permet d'analyser plus facilement les trames qui changent de contenu en fonction des actions que je fais.

J'ai ensuite écouté pas mal de trafic réseau afin de distinguer les adresses CAN qui communiquent même contact coupé, celles qui communiquent avec la clé en position "accessoire" et celles qui communiquent avec la clé en position "marche".

L'étape suivante consistait à appuyer sur tous les boutons, actionner tous les leviers et toucher à tous les réglages, afin de voir quels étaient ceux qui modifiaient des contenus de trames CAN.

Adresses CAN obtenues

Les tableaux suivants résument les différentes adresses CAN que je vois passer, la fréquence (très approximative) de rafraîchissement, la vitesse de ligne utilisée et un résumé succinct de leur contenu.

AdresseDébitFréquenceDescription succincte
0x215500 kbps50 s-1?
0x35d500 kbps40 s-1?
0x60d500 kbps40 s-1État d'interrupteurs et de capteurs divers
0x625500 kbps10 s-1?
0x645500 kbps10 s-1Rétroéclairage tableau de bord
0x6e4500 kbps? s-1?
0x715500 kbps3 sKilométrage total et autres
Adresses CAN présentes à l'arrêt
AdresseDébitFréquenceDescription succincte
0x27f500 kbps50 s-1?
0x284500 kbps50 s-1Vitesse angulaire des roues
0x285500 kbps50 s-1Vitesse angulaire des roues
0x2a0500 kbps50 s-1?
0x354500 kbps25 s-1Vitesse de la voiture, distance parcourue
0x511500 kbps10 s-1?
0x551500 kbps10 s-1Température moteur, consommation
0x5c5500 kbps10 s-1Kilométrage; état frein à main
0x5fd500 kbps50 s-1Kilométrage; âge du véhicule
Adresses CAN présentes en position "accessoire"
AdresseDébitFréquenceDescription succincte
0x0c2500 kbps100 s-1Position et vitesse angulaires du volant
0x161500 kbps??
0x181500 kbps100 s-1État du moteur et des pédales
0x1f9500 kbps100 s-1Régime moteur
0x500500 kbps10 s-1?
0x5e4500 kbps100 s-1?
0x651500 kbps10 s-1État ceinture conducteur et airbag passager
Adresses CAN présentes en position "marche"

Il faut néanmoins noter les choses suivantes :

  • les données sont cumulatives; c'est-à-dire qu'en marche, on verra passer l'ensemble des vingt-trois adresses CAN différentes et pas seulement celles qui sont listées dans le tableau correspondant ;
  • la position "marche" correspond à la position de la clé (celle où toutes les diodes du tableau de bord s'allument pendant quelques secondes), et non pas à l'état du moteur (qui peut être arrêté).

J'ai relevé que certaines trames faisaient l'objet d'un contrôle d'intégrité à l'aide d'un checksum en fin de message. Pour calculer le checksum, faire la somme sur 8 bits de tous les autres octets du message et prendre le complément à 1.

Dissection

J'ai remarqué une première chose, et c'est que tout n'est pas forcément relié au bus CAN. Par exemple, le réglage électrique des rétroviseurs ou le réglage de l'heure ne provoquent pas de trafic ou ne modifie pas de trames. On peut donc conjecturer que Renault a adopté un « principe de parcimonie » : si un paramètre n'intéresse pas un autre calculateur ou système dans la voiture, celui-ci ne sera pas diffusé sur le bus CAN. Le câblage coûte certes cher, mais les transceivers CAN aussi.

Voici pour le moment les informations que j'ai pu déduire de mes observations.

Plage 0x000-0x1ff

0x0c2 -> 8108 7FFF 5B 9D
         └─┬┘ └─┬┘    ─┬
           │    │      │
           │    │      └─── Checksum
           │    └────────── Vitesse de rotation du volant (1)
           └─────────────── Angle du volant (2)

(1): soustraire 0x8000 (unité exacte inconnue)
(2): soustraire 0x8000, résultat en incrément de 0,1°

0x161 -> 30 30 65 00 10
         ─┬
          │
          └──────────────── Couple moteur estimé volonté conducteur (1)

(1): multiplier par 2 puis soustraire 100, résultat en Nm



0x181 -> 4174 4C 52 4D 20 3A 00
         └─┬┘    ─┬    ─┬
           │      │     │
           │      │     └─ Position pédales embrayage/frein (1)
           │      └─────── Position pédale accélérateur (2)
           └────────────── Régime moteur (3)

(1): bit 3 = pédale d'embrayage enfoncée
     bit 0 = pédale de frein enfoncée
(2): varie entre 0x10 (relâché) et 0xe0 (en butée)
(3): diviser par 8 pour la valeur réelle



0x1F9 ─> 22 00 3BA1 CA FF
               └─┬┘
                 │
                 └──────── Régime moteur (1)

(1): diviser par 8 pour la valeur réelle

Plage 0x200-0x2ff

0x215 ─> 42 40 1C 03 0F 0F
            ─┬
             │
             └──────────── Position marche arrière (1)

(1): bit 6 = marche arrière enclenchée

Plage 0x300-0x3ff

0x354 ─> 1815 3312 00 00 04 00
         └─┬┘ └─┬┘       ─┬
           │    │         │
           │    │         └─ État frein (1)
           │    └───────── Distance depuis démarrage (2)
           └────────────── Vitesse (3)

(1): bit 4 = pédale de frein enfoncée
(2): multiplier par 0,1 m
(3): multiplier par 0,01 km/h

Plage 0x500-0x5ff

0x551 ─> 7B 26 6A 00 FF 72 00
         ─┬ ─┬
          │  │
          │  └──────────── Carburant utilisé (1)
          └─────────────── Température du moteur (2)

(1): mesuré depuis le dernier démarrage, avec 12 500 unités = 1 L
(2): soustraire 40 pour obtenir la valeur en °C



0x5C5 ─> 40 0 0C633 06 B0 00 13
         ─┬   └─┬─┘
          │     │
          │     └───────── Kilométrage 
          └─────────────── État frein à main (1)

(1): bit 3 = frein à main enclenché



0x5FD ─> 0C633 235618 0 00 20
         └─┬─┘ └──┬─┘
           │      │
           │      └─────── Âge du véhicule (en min)
           └────────────── Kilométrage

Plage 0x600-0x6ff

0x60D ─> 003618 00 41 7C 02 00
         └──┬─┘    ─┬ ─┬ ─┬ ─┬
            │       │  │  │  │
            │       │  │  │  └─ Inputs (1)
            │       │  │  └──── État marche arrière (2)
            │       │  └─────── Température moteur (3)
            │       └────────── Température extérieure (3)
            └────────────────── État capteurs divers (4)

(1): bit 0 = appui sur bouton "haut" du comodo droit
     bit 1 = appui sur bouton "bas" du comodo droit
(2): bit 4 = marche arrière engagée
(3): mesuré en °C (soustraire 40)
(4): bit 23 = coffre ouvert
     bit 22 = porte arrière droite ouverte
     bit 21 = porte arrière gauche ouverte
     bit 20 = porte avant droite ouverte
     bit 19 = porte avant gauche ouverte
     bit 18 = (FP) feux de position allumés
     bit 17 = (FC) feux de croisement allumés
     bit 14 = (CD) clignotant droit allumé
     bit 13 = (CG) clignotant gauche allumé
     bit 11 = (FR-AL) feux de route allumés (ou appel de phare)
     bit 10 = clé en position marche
     bit 9  = clé en position accessoire
     bit 8  = (PA) feux de brouillard avant allumés
     bit 5  = condamnation des portes enclenchée
     bit 4  = condamnation du coffre enclenchée
     bit 2  = (FBA) feu de brouillard arrière allumé



0x645 ─> 00 FF FF 0900
            ─┬    └─┬┘
             │      │
             │      └────────── Vitesse (× 0,01 km/h)
             └───────────────── Intensité rétroéclairage instruments (1)

(1): Varie entre 0x00 (minimum) à 0xfe (maximum), ou 0xff (éteint)



0x651 ─> 04 F0
         ─┬ ─┬
          │  │
          │  └───────────────── État ceinture (1)
          └──────────────────── État airbag (2)

(1): bit 0 = ceinture conducteur non attachée
(2): bit 2 = 0 si clé en accessoire, 1 si marche
     bit 1 = airbag passager désactivé

Plage 0x700-0x7ff

0x715 ─> 0 0C633 18 1E 3A 99 42
           └─┬─┘
             │
             └───────────────── Kilométrage

Conclusion

À ma grande déception, les informations que l'on obtient sont assez superficielles, à l'image de ma méthodologie qui se contente, in fine, de comparer des actions et des réponses à des entrées précises. Je peux néanmoins être satisfait du fait d'avoir trouvé la plupart des éléments que je pourrais afficher sur un HUD maison, comme la vitesse et le compte-tours.

On peut ensuite ranger le reste des valeurs non décodées en deux catégories : d'une part, celles qui dépendent d'options dont ma voiture n'est pas équipée (par exemple les radars de recul qui donneraient des valeurs de télémétrie, etc.) ; d'autre part, celles qui dépendent de situations que je ne peux que difficilement reproduire à moins d'être sur un circuit fermé (déclenchement des systèmes de sécurité comme l'ABS ou les prétentionneurs, par exemple).

Je pourrais peut-être obtenir des informations intéressantes en injectant des fausses trames à l'aide de mon dongle. La peur de bricker accidentellement ma voiture ou de déclencher des dispositifs pyrotechniques comme les airbags me retient cependant de le faire. Je laisserai l'initiative à une personne plus intrépide que moi.

Posté par x0r à 75 commentaires • Tags : renault clio obd2 elm327 diagnostic can bus

siproxd-orange version 0.1.2

Mise à jour : RIP siproxd_orange :(

Après avoir corrigé quelques bugs impactant la version 0.1.1 et après avoir mis à jour la documentation, j'ai décidé de packager une version 0.1.2 de siproxd_orange. Merci à Maxime Marais, imval et tous ceux que j'aurais pu oublier pour leurs bugreports, contributions et feedback de manière générale.

Cette version résoud un segfault qui peut se produire dans des conditions encore obscures, met à jour la documentation et corrige certains bugs et omissions dans le script ./configure.

Téléchargements

Vous pouvez télécharger la version 0.1.2 de siproxd_orange ici :

Appel aux contributeurs

Mise à jour du 14 novembre 2014 : après analyse et confirmation par un autre utilisateur, la manipulation décrite ci-dessous n'est pas nécessaire.

J'ai également entendu dire que le plugin siproxd_orange ne fonctionnerait que si l'application Livephone sur PC a été exécuté au moins une fois auparavant, comme si l'application officielle était capable de demander une activation du service. Comme je ne peux plus reproduire cela chez moi, je serais curieux de savoir comment cela se produit. Si vous êtes en mesure de fournir des logs de débogage de siproxd avec le plugin chargé (en supprimant, bien entendu, les informations sensibles), je vous saurai reconnaissant de m'envoyer un exemplaire par mail. Vous pouvez utiliser GPG pour chiffrer votre message, le cas échéant.

Si vous pensez avoir trouvé un bug dans siproxd_orange ou si vous avez une proposition d'amélioration, vos patchs et bugreports sont les bienvenus.

Posté par x0r à 5 commentaires • Tags : sip orange livebox voip livephone hack cisco paramètres siproxd linphone

Un proxy SIP pour le téléphone Livebox d'Orange

Mise à jour : RIP siproxd_orange :(

Moins d'une semaine après avoir publié mon dernier article, certaines personnes ont probablement déjà pu observer ma page BitBucket et voir que j'avais créé un nouveau dépôt public intitulé siproxd_orange.

Après avoir passé près de deux mois à analyser le fonctionnement du client SIP officiel d'Orange (j'ai nommé le Livephone), il n'y a rien de plus naturel que de valider le fruit de mes recherches en fabriquant une implémentation indépendante des mêmes extensions au protocole SIP.

Voici donc ma première deuxième release, la version 0.1.1 de ce plugin, qui est le fruit de maintenant presque trois mois d'intense recherches. Je vous le propose en téléchargement, tout en précisant néanmoins qu'il est très important de lire le fichier README qui l'accompagne.

Le résultat ? J'ai pu téléphoner via le numéro géographique (en 01) attribué pour ma Livebox, directement via Linphone et via un téléphone SIP Cisco 7960G. Le téléphone Cisco trône d'ailleurs fièrement sur mon bureau depuis que je l'ai acheté sur Leboncoin.

Cisco 7960 sur mon bureau
Faire mumuse avec du SIP est une bonne excuse pour faire de genre de craquages. C'est juste un peu moins "girlfriend-compliant".

Mon plugin se contente généralement de réécrire certains des paquets SIP qu'il reçoit. Comme Orange utilise des URI "tel:" dans certains de ses messages et que siproxd fait mal la vérification syntaxique lorsque de tels URI figurent dans les messages SIP (ils font pourtant l'objet de la RFC 3966), j'ai été parfois obligé de réécrire les messages avant même l'étape de parsing de siproxd. Ces réécritures modifiaient la longueur des paquets reçus et provoquaient un bug pour lequel j'ai soumis un patch, qui vient tout juste d'être accepté.

Ce qui signifie que tant qu'une hypothétique version 0.8.3 de siproxd n'est pas encore sorti, il faudra compiler soi-même une version patchée du code source pour que le plugin fonctionne correctement. Cette restriction rend malheureusement la mise en œuvre de ma solution beaucoup plus difficile (et croyez-moi, j'ai vraiment voulu faire le plus de choses possibles sans devoir patcher siproxd ou libosip2), en attendant une éventuelle prochaine version 0.8.3. Cette procédure est néanmoins documentée (du mieux que je peux) sur la page du projet siproxd_orange. En attendant, le code source intégrant mon patch est déjà disponible (choisir une snapshot postérieure au 26 mai).

Est-ce que cela signifie qu'on peut désormais brancher son téléphone SIP préféré directement sur l'infrastructure d'Orange ? Tout à fait. Est-ce que cela signifie qu'on pourra débrancher définitivement le câble RJ11 à l'arrière de sa Livebox ? Je ne sais pas. C'est pourquoi je compte aussi sur vous afin de trouver les bugs que je n'aurais peut-être pas pu repérer moi-même.

(Note à moi-même : ça m'apprendra à faire des releases avant de tout tester correctement.)

Mise à jour du 23 janvier 2015 : correction factuelle sur la question de la mauvaise prise en charge par siproxd des URIs "tel:" ; merci aymeric !

Posté par x0r à 25 commentaires • Tags : sip orange livebox voip livephone hack cisco paramètres siproxd linphone

Le SIP par Orange : analyse technique

Mise à jour : Orange n'aime pas trop ça. Allez savoir.

Il y a SIP, et SIP par Orange.

Orange : not open !

Source image : trollab.org

En effet, l'opérateur historique a décidé de migrer une partie de ses clients ADSL et Fibre vers le protocole SIP pour la signalisation téléphonique de la téléphonie par Internet de la Livebox.

Orange propose ainsi trois manières d'exploiter la téléphonie par IP incluse dans ses connexions Internet :

  • on peut tout simplement brancher un bon vieux téléphone analogique (ou une interface FXO) en insérant la prise RJ11 à l'arrière de la Livebox ;
  • on peut aussi connecter directement des téléphones DECT compatibles à la box ;
  • enfin, et potentiellement le plus intéressant : on peut aussi utiliser l'application Livephone pour utiliser son PC comme un "softphone" qui a l'avantage de sonner lorsqu'un appelant externe compose le numéro fixe associé à la Livebox.

Cette application, uniquement disponible sous Windows malheureusement, n'est pas compatible avec toutes les connexions, et je conjecture qu'elle ne fonctionne qu'avec les abonnés utilisant la signalisation SIP pour le téléphone. Ce qui signifie qu'il serait théoriquement possible d'utiliser n'importe quel softphone avec ce service. Pour moi, cela me permettrait de m'affranchir du câble RJ11 entre mon serveur et la box, et de bénéficier d'une méthode plus élégante pour détecter le début et la fin d'un appel téléphonique.

Hélas, il n'en est rien ! Une analyse plus détaillée révèle en effet que le Livephone implémente une version modifiée du mécanisme d'authentification SIP, que je n'ai pu relever qu'après un long travail d'ingénierie inverse (légale, dans ce cas particulier). Ces modifications violent bien entendu la RFC 3261, cassant de fait la compatibilité avec les clients SIP autres que le Livephone.

Constatant que des demandes d'informations antérieures ont été infructueuses, j'ai donc été contraint de me lancer dans une analyse technique plus poussée. Les informations que je publie ici sont principalement des résultats d'analyses de trames réseau et de traces de débogueur ; néanmoins, j'ai également été amené à décompiler le programme pour comprendre entièrement le mécanisme d'authentification.

C'est dans une démarche d'interopérabilité que j'exposerai dans les grandes lignes le fonctionnement de l'authentification SIP par Orange. Nous constaterons très rapidement pourquoi un téléphone SIP conforme à la RFC ne pourra jamais utiliser en l'état le réseau SIP Orange, puis j'expliquerai dans une dernière partie une solution possible pour contourner ces modifications propriétaires.

Certains paragraphes seront délibérément vagues ou peu détaillés, par manque de recherches, ou afin d'éviter les ennuis (comme ceux que j'aurais pu avoir avec la SNCF il y a quelques temps et qui m'ont conduit à censurer des morceaux d'article).

Le SIP par Orange en trois étapes

Le schéma ci-dessous résume le processus d'authentification du Livephone auprès du proxy SIP Orange.

MSC décrivant l'authentification SIP Orange
Échange de messages entre le client et les différents serveurs

On voit déjà immédiatement que le processus est beaucoup plus compliqué qu'une simple requête REGISTER auprès du proxy. Reprenons chacune des trois étapes en plus de détails.

Login

Tout d'abord, le client envoie en HTTPS (mais sans vérifier le certificat, ce qui est bien pratique pour faire du sslstrip comme un gros dégueulasse) une requête au serveur d'authentification. On dirait que celui-ci reconnaît l'utilisateur en se basant sur l'IP source (du moins, je crois), mais substituer ses propres serveurs DNS à ceux d'Orange permet de "forcer" un downgrade vers une authentification par login et mot de passe. Il semblerait que la toute première authentification se fait toujours par login et mot de passe.

Récupération de la configuration

Si l'authentification passe, le client reçoit entre autres un token qui est une chaîne hexadécimale tellement longue qu'il faut trois segments TCP pour la transmettre. Il envoie ce token (concaténé à d'autres variables, comme le nom et les versions de l'OS et du client) à un serveur de paramètres par HTTPS lui aussi, cette fois pour récupérer une liste de paramètres SIP : nom du proxy SIP, URI SIP de l'utilisateur (de la forme +33123456789@orange-multimedia.fr) entre autres, mais aussi une étrange chaîne de caractères en base64 appelée AuthentData.

Enregistrement auprès du proxy SIP

Enfin, la troisième étape consiste à faire l'enregistrement du client auprès du proxy SIP. Cela se fait avec un message REGISTER, comme le décrit la RFC 3261. Comme on peut le voir, l'authentification se déroule par challenge-response, de la même manière que l'authentification HTTP Digest, décrite dans la RFC 2617.

En réalité, le calcul de la réponse au challenge est un peu compliquée. La seule différence est que le paramètre H(A1) n'est pas égal à md5("${username}:${realm}:${password}"). Il faut en effet (censuré).

En conclusion, j'ignore si cela a été fait sciemment ou par flemme, mais le résultat ressemble presque à un échange conforme à la RFC 2617, alors qu'il n'en est rien en réalité.

Récapitulatif

En résumé, on dégage les informations suivantes :

  • l'authentification se fait en trois étapes auprès de trois serveurs différents, au lieu du seul proxy SIP ;

  • un des paramètres pour le calcul de la réponse au challenge envoyé par le proxy SIP ne correspond pas à ce qui est prescrit par la RFC. Au lieu de ça, il s'agit d'un bloc binaire, récupéré depuis une source extérieure, et chiffré avec un algorithme dont je suis à peu près sûr que (censuré).

  • de fait, il est impossible de se passer des deux premières étapes de l'authentification car celles-ci permettent d'obtenir des informations essentielles à l'authentification SIP.

Se défaire des extensions propriétaires

Se pose maintenant la vraie question : quelle est la solution la plus simple pour assurer l'interopérabilité entre l'infrastructure SIP Livephone d'une part, dont on a vu qu'elle ne respecte pas les RFC, et l'ensemble des clients SIP d'autre part ?

Une première possibilité aurait été de mettre au point des patchs pour Asterisk, car c'était dans l'optique de faire fonctionner le Livephone avec ce serveur de téléphonie que je m'étais lancé dans ce travail.

Cependant, j'ai préféré privilégier la solution d'un proxy SIP, qui serait alors utilisable directement avec n'importe quel client SIP, y compris Asterisk, et éviterait à ceux qui souhaiteraient tenter la même chose d'être obligé d'installer Asterisk chez eux, et d'avoir juste besoin de ce proxy et d'Ekiga ou de Linphone.

Le proxy ne ferait que du bête forwarding de requêtes et de réponses entre les deux parties, sauf dans le cas du REGISTER qu'il intercepterait pour faire l'authentification « à la sauce Orange » à la place, tout en répondant "OK" au client si tout s'est bien passé.

Le seul problème restant est la dernière étape d'authentification. Cet aspect risque de rendre l'interopérabilité bien plus difficile à obtenir que ce que j'aurais espéré. La réalisation d'un proxy en devient à la limite de la légalité, car à part décompiler l'algo de hachage pour l'analyser plus en détail et voir avec quels paramètres il est appelé, je vois mal comment faire autrement.

Conclusion

Ces recherches sont incomplètes, dans la mesure où je n'ai pu valider mes analyses que partiellement à l'aide de preuves de concept incomplètes.

Bien que je puisse comprendre qu'Orange ait pu décider de fournir une méthode centralisée de distribution d'éléments de configuration (après tout, j'imagine qu'ils font la même chose pour la Livebox elle-même de toute façon), une modification aussi lourde au processus d'authentification SIP proprement dit (c'est-à-dire le challenge-response) a tout d'une action délibérée. Modification difficilement justifiable d'un point de vue technique, qui plus est.

Comme je le disais au-dessus, la prochaine étape consistera bien évidemment à concevoir et implémenter un proxy SIP faisant le lien entre un client SIP lambda, et l'infrastructure SIP propriétaire du Livephone. Ce proxy ne fonctionnera que sur la connexion Internet Orange de l'utilisateur, entre autres parce que beaucoup de noms de serveurs que j'ai pu voir passer dans tcpdump ne sont résolvables que par le biais des serveurs DNS Orange (rappelez-vous du serveur SMTP d'Orange, par exemple). Tous mes essais sont concluants jusqu'à maintenant, et si je parviens à implémenter un proxy qui fonctionne, le résultat fera bien entendu l'objet d'une autre publication sur ce site.

Étant donné que ces modifications protocolaires sont manifestement intentionnelles dans le but de casser la compatibilité avec les matériels et logiciels respectant les normes, cet effort de reverse engineering en est d'autant plus légitimisé.

Mise à jour du 4 mai : correction de quelques inexactitudes, notamment liés à l'authentification.

Mise à jour du 28 mai : faire un plugin pour siproxd : ça, c'est fait.

Posté par x0r à 8 commentaires • Tags : sip orange livebox voip livephone paramètres asterisk téléphone reversing

monrer.fr : ouverture à toutes les lignes Transilien SNCF

Vous attendiez tous ce moment (ou pas), mais l'API Prochains Départs Transilien fournie par la SNCF a été ouverte aujourd'hui à toutes les lignes Transilien SNCF !

Ceci a pour conséquence principale que monrer.fr fournit désormais les horaires temps réel des prochains trains sur toutes les gares desservies par l'ensemble des lignes Transilien SNCF, à savoir les lignes Transilien C, D, E, H, J, K, L, N, P, R et U. Presque comme avant donc. Les lignes A et B, gérées par la RATP, sont encore exclues des horaires en temps réel pour le moment.

Il y a encore quelques gares pour lesquels je dois peaufiner l'accès API et la mutualisation de plusieurs sources de données, mais je résoudrai ces problèmes en temps et en heure.

Je n'ai pas encore eu le temps d'écrire d'autres posts ces derniers temps, car j'ai été très occupé pour des raisons diverses et variées. J'ai néanmoins pas mal avancé sur un petit projet de reverse engineering dont je serai certainement tenté de partager les résultats dans un futur proche.