Manipulation de miniatures de fichiers jpg

Manipulation de miniatures de fichiers jpg

J'avais envie de jouer avec les miniatures intégrées aux photos au format jpg pour voir comment les différents OS réagissaient...

J'ai donc pris deux photos avec mon smartphone. Il s'agit d'une feuille blanche sur laquelle j'ai écrit une fois "petite" et l'autre fois "grande" :

petite et grande

J'ai donc deux fichiers jpg contenant chacun une miniature. J'appellerai l'image sur laquelle j'ai écrit "petite" la petite et celle sur laquelle j'ai écrit "grande" la grande. L'idée est de prendre la miniature de la petite pour la mettre dans la grande.

Muni d'un bon éditeur hexadécimal, j'avais trois parties à modifier :

  • La taille du marqueur APP1 à l'offset 0x4, qui correspond à la taille des métadonnées Exif,
  • La taille de la miniature, dans ce cas à l'offset 0x4B8,
  • le contenu de la miniature, dans ce cas à l'offset 0x4D0

grande hexadecimal

Dans la grande image, la miniature fait 6153 octets (0x1809). Dans la petite image, la miniature est légèrement plus grande. Elle fait 6418 octets (0x1912). Ainsi, j'ai effectué les manipulations suivantes :

  • suppression de la miniature entre l'offset 0x4D0 et 0x1CD8 pour la remplacer par l'autre miniature,
  • remplacement de la taille de la miniature à l'offset 0x4B8 : 0x1809 (6153) devient 0x1912 (6418) et on écrit donc 0x1219 (little endian)
  • remplacement de la taille du marqueur APP1 à l'offset 0x4 : on a ajouté 265 octets au fichiers et donc 0x1CD5 (7381) devient 0x1DDE (7646) et on écrit donc 0x1DDE (big endian)

On obtient donc ceci :

grande modifiée hexadecimal

L'idée est ensuite de voir comment les systèmes d'exploitations se comportent avec une telle image.

En ce qui concerne MacOS, voici ce que j'obtiens dans le finder et sur mon bureau : macOS finder

macOS bureau

En ce qui concerne Windows 10, voici ce que j'obtiens :

windows 10 explorer

En ce qui concerne Windows 7, en dehors du fait que l'image n'est pas pivotée, les résultats sont identiques :

windows 7 explorer

Enfin sous Android, voici ce que j'obtiens (en vidéo) :

On constate donc que les systèmes d'exploitations ne génèrent pas les miniatures, mais utilisent celles qui sont présentes dans les métadonnées des fichiers.

D'un point de vue de l'investigation numérique, il est important de faire attention à ce genre de choses, sinon on risque de passer à coté.

En bonus, à partir des captures de l'éditeur hexadécimal, ceux qui le souhaitent pourront tenter de me dire quand j'ai pris ces photos (plutôt facile) mais surtout où je les ai prises (un peu plus compliqué)...

Machine learning avec OVH prescience en quelques clics

Machine learning avec OVH prescience en quelques clics

Dans ses group labs, OVH a lancé prescience, une plateforme de machine learning. C'est gratuit pendant la phase alpha et j'ai donc décidé de tester le future produit.

Il faut demander un accès en bas de la page dédié à prescience et quelque temps après, on reçoit un mail avec le token pour s'identifier sur la pateforme :

mail prescience

J'ai utilisé un des dataset de base pour le machine learning : iris. Il s'agit d'un tableau contenant 150 entrées (disponible dans son intégralité sur cet article wikipédia).

On commence par créer un fichier csv avec les 150 entrées :

sepal_lenght;sepal_width;petal_lenght;petal_width;species
5.1;3.5;1.4;0.2;setosa
4.9;3.0;1.4;0.2;setosa
4.7;3.2;1.3;0.2;setosa
4.6;3.1;1.5;0.2;setosa
[...]
7.0;3.2;4.7;1.4;versicolor
6.4;3.2;4.5;1.5;versicolor
6.9;3.1;4.9;1.5;versicolor
5.5;2.3;4.0;1.3;versicolor
6.5;2.8;4.6;1.5;versicolor
[...]
6.3;3.3;6.0;2.5;virginica
5.8;2.7;5.1;1.9;virginica
7.1;3.0;5.9;2.1;virginica
6.3;2.9;5.6;1.8;virginica
6.5;3.0;5.8;2.2;virginica
[...]

En peut ensuite uploader ce fichier dans prescience :

source upload

Après avoir cliqué sur upload, le système télécharge le fichier et commence à le parser :

source parsing

Lorsqu'il a terminé, on peut préprocesser la source :

source preprocess

Le système nous demande alors quelques informations, notamment le label et le type de problème. Dans notre cas, tout est sélectionné automatiquement :

source preprocess détails

Lorqu'on clique sur sur preprocess, le système lance le préprocessing en quatre étapes :

preprocess

Les deux premières étapes sont plutôt rapides. Les deux suivantes peuvent prendre un peu de temps. Lorsqu'il a terminé le préprocessing, on peut lancer l’optimisation :

dataset optimise

Le système nous demande des paramètres que nous laissons tels quels :

dataset optimise détails

Lorsqu'on clique sur optimise, on obtient quelque chose comme ça :

optimise

Il faut maintenant le laisser travailler un peu. En effet, cette phase peut prendre du temps. À l'issue, on peut lancer l'entrainement :

dataset train

Le système nous demande un nom de modèle :

dataset train détails

Lorsqu'on clique sur train, on obtient cela :

trainning

Quand l'entrainement est terminé, on peut interroger le système. Par exemple, si on entre une longueur des pétales de 1.5 cm, une largeur des sépales de 3 cm, une largeur des pétales de 0.25 cm et une largeur des sépales de 5 cm, le système nous indique qu'il s'agit, avec une probabilité de 1, de l'espèce setosa(ce qui est le cas) :

query

Si on clique sur explain, on obtient le joli graphique suivant :

shap form

Enfin, il est possible d'interroger le système avec curl :

$ curl -X POST "https://prescience-serving.ai.ovh.net/eval/iris/transform-model" -H "Authorization: $token" -H "Content-Type: application/json" -d '{"arguments":{"petal_lenght":1.5,"sepal_width":3,"petal_width":0.25,"sepal_lenght":5}}'
{"result":{"species":"setosa","probability(setosa)":1.0,"probability(versicolor)":0.0,"probability(virginica)":0.0},"arguments":{"imputed_petal_lenght":{"dataType":"double","value":1.5,"opType":"continuous"},"imputed_sepal_width":{"dataType":"double","value":3.0,"opType":"continuous"},"imputed_petal_width":{"dataType":"double","value":0.25,"opType":"continuous"},"imputed_sepal_lenght":{"dataType":"double","value":5.0,"opType":"continuous"},"scaled_imputed_petal_lenght":{"dataType":"double","value":-1.2266889625508433,"opType":"continuous"},"scaled_imputed_sepal_width":{"dataType":"double","value":-0.15118917210787064,"opType":"continuous"},"scaled_imputed_petal_width":{"dataType":"double","value":-1.1917094761129958,"opType":"continuous"},"scaled_imputed_sepal_lenght":{"dataType":"double","value":-1.0113190222659707,"opType":"continuous"}}}

C'est un exemple très simple mais cela fonctionne plutôt bien.

Ainsi, si on possède des données, on peut, sans rien connaitre ou comprendre à l'apprentissage automatisé, mettre en œuvre du machine learning en quelques clics.

Merci OVH.

Restaurer une stock ROM Samsung avec TWRP

Restaurer une stock ROM Samsung avec TWRP

Je voulais rooter mon téléphone. J'ai donc installé TWRP avec Odin. Jusque là pas de problème.

Avec TWRP, j'ai installé le zip de Magisk et j'ai redémarré mon téléphone. Et là, catastrophe, le téléphone ne démarre plus. J'avais oublié de formater data. Mon smartphone m'indique :

Échec de la vérification
Impossible de redémarrer votre appareil. La vérification de l'intégrité a échoué. Vous devez réinitialiser les paramètres par défaut de votre appareil. Cette opération effacera toutes vos données.

échec de la vérification

Bon, je me dit que ça n'est pas si grave que ça, que je vais utiliser Odin pour restaurer une stock ROM. Je télécharge donc la dernière ROM sur SamMobile et je me lance donc dans ce process. Dès le début, le flashage plante et le smartphone indique l'une des erreurs suivantes :

SW REV. CHECK FAIL
SYSTEM REV. CHECK FAIL
KERNEL REV. CHECK FAIL

Et lors du démarrage, j'obtient cela :

smart switch emergency

Bien évidement, Smart Switch n'a rien pu faire pour moi. Mon smartphone n'est pas pris en charge.

Je me dis que je n'ai pas le bon firmware. Cette fois, j'utilise donc SamFirm pour télécharger le firmware. Et je retente de flasher avec Odin. J'obtiens toujours le même genre d'erreurs.

Je décide de regarder de plus près le fichier téléchargé et plus particulièrement "AP_xxx_xxx_xxx_REV00_user_low_ship_meta.tar.md5". Il s'agit en fait d'un conteneur qui contient les fichiers suivants :

  • boot.img.lz4
  • recovery.img.lz4
  • system.img.lz4
  • userdata.img.lz4

Il s'agit d'images compressées au format lz4. TWRP permet de restaurer des images et j'espère qu'il permettra probablement de contourner les vérifications faites par le téléphone avec Odin. Je décompresse donc les fichiers img.lz4 pour obtenir :

  • boot.img
  • recovery.img
  • system.img

Je les copie sur la carte microSD, je formate tout proprement, avec TWRP je les installe et je redémarre.

Et là tout a bien fonctionné. J'ai pu réinstaller TWRP avec Odin, puis Magisk (en pensant bien à formater data avant).

J'ai donc maintenant, non sans difficulté et sans frayeur d'avoir briqué mon smartphone, un appareil rooté.

La construction du logo Lemnet expliqué en vidéo avec blender

La construction du logo Lemnet expliqué en vidéo avec blender

On me demande parfois à quoi correspond cette espèce de i-grec dans mon logo :

logo

En fait, il ne s'agit pas du tout d'un i-grec et j'ai donc décidé de faire une vidéo avec blender pour l'expliquer. Je ne l'avais jamais utilisé, mais après quelques heures de travail et encore quelques heures pour le rendu (en 4k), voici, en moins de trente secondes (1440 frames à 60 fps), comment j'ai construit mon logo :

J'espère que c'est clair et que ça vous a plu.

[Arnaque] Domain name search engine registration

Aujourd'hui, un de mes clients a reçu le message suivant et me l'a transféré en me demandant ce qu'il fallait faire :

De : info@shalleged.com [mailto:info@shalleged.com] 
Envoyé : samedi 14 avril 2018 08:45
À : [REDACTED]
Objet : Domain Alert: [REDACTED] This is your Final Reminder of Domain - [REDACTED].NET


Attention: Important, DOMAIN SERVICE
Domain Name: [REDACTED].NET

Call: 1-317-449-7469


ATT: Domain Owner [REDACTED]
ADMINISTRATIVE CONTACT
[REDACTED]
[REDACTED]@[REDACTED].COM
[REDACTED] - - [REDACTED] - - - [REDACTED] FRANCE WWW.[REDACTED].NET


Requested Reply Before
April 16, 2018


PART I: REVIEW SOLICITATION


Attn: Domain Owner [REDACTED]
As a courtesy to domain name holders, we are sending you this notification for your business Domain name search engine registration. 

This letter is to inform you that it's time to send in your registration and save.

Failure to complete your Domain name search engine registration by the expiration date may result in cancellation of this proposal making it difficult for your customers to locate you on the web.

Privatization allows the consumer a choice when registering. Search engine subscription includes domain name search engine submission. 

You are under no obligation to pay the amounts stated below unless you accept this proposal. Do not discard, this notice is not an invoice it is a courtesy reminder to register your domain name search engine registration so your customers can locate you on the web.

This Notice for: WWW.[REDACTED].NET will be terminated on April 16, 2018 Act today! 

[ ] 1 year 04/16/2018 - 04/16/2019 $75.00 
[ ] 2 year 04/16/2018 - 04/16/2020 $119.00 
[ ] 5 year 04/16/2018 - 04/16/2023 $199.00
[ ] 10 year -Most Recommended- 04/16/2018 - 04/16/2028 $295.00 
[ ] Lifetime (NEW!) Limited time proposal - Great value! Lifetime $499.00  


Payment by Credit Card or Check
Call our New York main office: (317)449-7469




-------------------------------------------------------------------------------------------

By accepting this proposal, you agree not to hold DS liable for any part. Note that THIS IS NOT A BILL. This is a solicitation. You are under no obligation to pay the amounts stated unless you accept this proposal. The information in this letter contains confidential and/or legally privileged information. This information is intended only for the use of the individual(s) named above. There is no pre-existing relationship between DS and the domain mentioned above. This notice is not in any part associated with a continuation of services for domain registration. Search engine submission is an optional service that you can use as a part of your website optimization and alone may not increase the traffic to your site. If you do not wish to receive further updates from DS reply with Remove to unsubscribe. If you are not the intended recipient, you are hereby notified that disclosure, copying, distribution or the taking of any action in reliance on the contents of this letter is strictly prohibited.

Dans l'objet du message on lit "Domain Alert". Il s'agit de faire croire que l'enregistrement du domaine arrive à expiration. Mais dans le corps du message il parle clairement de Domain name search engine registration, et ça, ça n'existe pas. En tout cas, si ça existe, ça ne sert à rien. Il n'est absolument pas nécessaire de souscrire un quelconque service pour que les moteurs de recherches indexent un site web. Je les soupçonne d'utiliser les informations publiques WHOIS pour trouver leurs victimes.

Il s'agit donc d'une arnaque plutôt bien faite qui vise à soutirer de l'argent aux entreprises qui manquent de compétences dans le domaine informatique. Dans ce genre de situations, demandez à votre webmaster ou votre conseil informatique (moi). Il ne faut jamais payer un service que vous ne comprenez pas.

Mettez ce genre de messages à la poubelle et n'y répondez pas.

Interception passive (sans IMSI catcher) et décodage de flux GSM avec GR-GSM

Interception passive (sans IMSI catcher) et décodage de flux GSM avec GR-GSM

À la suite de mon article sur l'interception de SMS sans IMSI catcher, j'ai écrit un article plus détaillé dans le hors-série n°16 de MISC. C'est plus agréable sur papier et la mise en page est plus jolie dans le magazine, mais comme il a été publié sous les termes de la licence Creative Commons BY-NC-ND, voici l'article tel qu'il a été publié dans MISC.


Ce qu’on appelle GSM (pour Global System for mobile Communications) correspond aux normes encadrant la téléphonie mobile sur la bande des 900 Mhz. Elles datent des années 1980 et n’ont pas ou très peu évolué depuis. En décembre 2009, Karsten Nohl, avec quelques autres membres du Chaos Computer Club, a réussi à casser le système de chiffrement GSM : A5/1 (pdf et vidéo de la présentation Blackhat 2010). L’attaque permet de décrypter en quasi temps réel les communications. À l’époque, la GSM Association, en charge de la norme, indiquait que cela ne posait pas particulièrement de problème dans la mesure où l’interception ou la capture et le décodage des signaux radio restaient complexes. Aujourd’hui, avec les possibilités offertes par la radio logicielle (Software Defined Radio : SDR), cela n’est plus le cas.

1 - Matériel

En 2010, pour capturer les signaux GSM, Karsten Nohl utilisait une radio programmable de Ettus Research. Ce genre de matériel coutait plus de 1500 €. Aujourd’hui, une simple clé USB TNT DVB-T peut suffire. On en trouve à moins de 10 euros sur ebay. Il faut seulement qu’elle soit basée sur une puce Realtech RTL2832U. Le tuner qui équipe la clé USB TNT DVB-T est également important. C’est lui qui définit la gamme de fréquences. Pour la SDR, on considère que celles qui ont un tuner Elonics E4000 sont les meilleures parce que ce tuner propose la plus grande gamme de fréquences mais Elonics n’en fabrique plus. Elles sont, de ce fait, rares et plus chères.

Tuner Gamme de fréquences
Elonics E4000 65 MHz à 2,2 GHz (trou de 1100 MHz à 1250 MHz)
Rafael Micro R820T 24 MHz à 1766 MHz
Rafael Micro R828D 24 MHz à 1766 MHz
Fitipower FC0013 22 MHz à 1100 MHz
Fitipower FC0012 22 MHz à 948,6 MHz

Comme le montre le tableau ci-dessus, ces clés USB TNT DVB-T peuvent également servir à intercepter d’autres bandes de fréquences. Les bandes des 433 Mhz et 868 Mhz, libres selon la réglementation européennes, sont particulièrement utilisées pour des applications sans fils. On peut notamment citer les portes de garages ou les volets roulants.

Pour le GSM, même s’il offre une gamme de fréquences sensiblement moins importante que l’Elonics E4000, le Rafael Micro R820T est recommandé. En effet, il est moins cher et réputé mieux fonctionner pour les fréquences supérieures à 450 MHz, ce qui est le cas du GSM.

Il ne s’agit pas de matériel haut de gamme et prévu pour la SDR, mais tous les tuners présentés dans le tableau ci-dessus, couplés au démodulateur Realtech RTL2832U fonctionnent normalement très bien pour intercepter des flux GSM.

La fréquence d’échantillonnage maximale de ces clés USB TNT est théoriquement de 3,2 MHz. Mais à cette fréquence, la faible qualité de certaines clés risque d’engendrer des pertes. Ainsi pour éviter cela, il est recommandé de ne pas dépasser 2,4 MHz.

Il est aussi possible d’utiliser du matériel plus avancé et surtout dédié à la SDR, mais forcément plus onéreux. Il s’agit notamment du boitier HackFR One de Great Scott Gadgets ou de la carte bladeRF de Nuand, ou encore des produits Airspy ou SRDplay.

Note
Pour cet article, une clé USB TNT DVB-T sans marque équipée d’un tuner R820T a été utilisée.

2 - Rappels sur les communications GSM

Note
Les éléments ci-dessous ne se veulent pas exhaustifs et peuvent paraître très approximatifs pour les spécialistes. Ils sont uniquement destinés à la compréhension de la suite de l’article et de l’utilisation de gr-gsm.

Dans le cadre de la téléphonie mobile, les équipements des utilisateurs du réseau sont appelés Mobile Station (MS) et les équipements en charge de communiquer directement avec les MS sont appelés Base Transceiver Station (BTS).

Les communications GSM se font, en Europe, sur les bandes des 900 MHz et 1800 MHz. Sur la bande des 900 MHz, en fait, elles utilisent les fréquences entre 880 MHz et 915 MHz pour le lien montant, c’est-à-dire de la MS vers la BTS, et les fréquences entre 925 MHz et 960 MHz pour le lien descendant, c’est-à-dire de la BTS vers la MS.

Chacune de ces deux bandes de 35 MHz est divisée en 174 canaux de 200 kHz. Ils sont appelés Absolute Radio-Frequency Channel Number (ARFCN) et, pour la bande des 900 MHz, sont numérotés de 0 à 125 et de 975 à 1023 :

ARFCN Lien Montant Lien Descendant
975 880,2 MHz 925,2 MHz
976 880,4 MHz 925,4 MHz
977 880,6 MHz 925,6 MHz
...
1021 889,4 MHz 934,4 MHz
1022 889,6 MHz 934,6 MHz
1023 889,8 MHz 934,8 MHz
0 890 MHz 935 MHz
1 890,2 MHz 935,2 MHz
2 890,4 MHz 935,4 MHz
...
122 914,4 MHz 959,4 MHz
123 914,6 MHz 959,6 MHz
124 914,8 MHz 959,8 MHz

Les autres ARFCN (entre 125 et 974) ne sont pas utilisées ou sont utilisées sur d’autres bandes de fréquences (GSM 450, GSM 480 et DSC 1800).

Les 174 canaux comportent chacun huit time slots (TS) d’environ 577 μs. Ils sont numérotés de zéro à sept. Ce sont ces canaux physiques qui sont utilisés pour transmettre la voix ou la signalisation. Ils contiennent des données appartenant à trois catégories :

  • Traffic CHannels (TCHs) :
    • Full rate Traffic CHannel (TCH/F) ;
    • Half rate Traffic CHannel (TCH/H) ;
  • Dedicated Control CHannels (DCCHs) :
    • Standalone Dedicated Control CHannel (SDCCH) ;
    • Fast Associated Control CHannel (FACCH) ;
    • Slow Associated Control CHannel (SACCH) ;
  • Common Control CHannels (CCCHs) :
    • Broadcast Control CHannel (BCCH) ;
    • Access Grant CHannel (AGCH) ;
    • Random Access CHannel (RACH) ;
    • Paging CHannel (PCH) ;
    • Synchronization CHannel (SCH) ;
    • Frequency Correction CHannel (FCCH).

Les TCHs sont des canaux point à point. Ils sont l’équivalent du canal B du RNIS. Ils sont utilisés pour trans- porter la voix ou des données.

Les DCCHs sont également des canaux point à point. Ils sont l’équivalent du canal D du RNIS. Le SDCCH est notamment utilisé pour la mise en place des appels et le transfert de SMS. Les FACCH et SACCH sont essen- tiellement utilisés pour la signalisation pendant les appels.

Les CCCHs sont des canaux de diffusion et point à point. Ils n’ont pas d’équivalent RNIS. Ils sont utilisés quasiment exclusivement pour gérer l’aspect radio. Le BCCH est utilisé par la BTS pour diffuser des infirmations sur le réseau. Le RACH est utilisé par les MS pour demander un canal à la BTS. Le AGCH est utilisé pour la BTS pour répondre aux demandes faites via le RACH. Le PCH est le canal par lequel la MS est informée qu’elle reçoit un appel.

La figure ci-dessous reprend une partie de ces informations sous forme schématique.

Schéma simplifié des fréquences et des time slots dans les communications GSM

Afin de garantir la confidentialité des communications, ces dernières sont normalement chiffrées. L’A5/1, développé en 1987, est censé remplir ce rôle. En 2009, il a été cassé en utilisant des ressources accessible à tous . En 1989, l’A5/2 a été développé pour les pays où la loi ne permettait pas d’utiliser l’A5/1. Du fait de sa faiblesse, il n’est pas utilisé. Publié en 1999, l’A5/3, utilisé pour les communications 3G, est censé remplacer l’A5/1. Bien que des attaques théoriques sur l’A5/3 existent, en pratique, elles ne sont pas significatives. Dans les faits, en France, l’A5/1 reste très majoritaire.

3 - Présentation des outils de gr-gsm

Gr-gsm est un projet libre développé depuis février 2014 par Piotr Krysik. Il utilise GNU Radio et est basé sur une partie du projet Airprobe : le gsm-receiver, également développé par Piotr Krysik. Gr-gsm fournit notamment des outils permettant de recevoir, décoder et déchiffrer des flux GSM.

Il est composé des cinq programmes suivants :

  • grgsm_scanner ;
  • grgsm_livemon ;
  • grgsm_channelize.py ;
  • grgsm_capture.py ;
  • grgsm_decode.

Grgsm_capture.py et grgsm_decode ne sont pas traités dans ce paragraphe. Ils seront abordés dans les paragraphes suivants. Cependant, leurs noms sont plutôt explicites. Grgsm_capture.py permet de capturer les signaux et de les stocker dans un fichier afin de les analyser par la suite avec grgsm_decode.

3.1 - grgsm_scanner

Grgsm_scanner est un outil en ligne de commande qui permet de scanner, entre autres, la bande GSM. Il affiche les informations des BTS environnantes. Il peut prendre des arguments mais fonctionne très bien sans. Voici un exemple des informations qu’il peut afficher :

$ grgsm_scanner
linux; GNU C++ version 6.3.0 20170221; Boost_106200; UHD_003.009.005-0-unknown


ARFCN:    1, Freq:  935.2M, CID: 36576, LAC:  6147, MMC: 208, MNC:   1, Pwr: -47
ARFCN:    8; Freq:  936.6M, CID: 64988, LAC:  6147, MMC: 208, MNC:   1, Pwr: -37
ARFCN:   15; Freq:  938.0M, CID: 55029, LAC:  6147, MMC: 208, MNC:   1, Pwr: -42
ARFCN:   80; Freq:  951.0M, CID: 24843, LAC: 49308, MMC: 208, MNC:  10, Pwr: -34
ARFCN:   85; Freq:  952.0M, CID: 58410, LAC: 49308, MMC: 208, MNC:  10, Pwr: -39
ARFCN:  121; Freq:  959.2M, CID: 24844, LAC: 49308, MMC: 208, MNC:  10, Pwr: -29

Le Location Area Code (LAC) permet de grouper des cellules appartenant à une même zone, afin d’optimiser la signalisation. Le Mobile Country Code (MCC) correspond au code du pays. En France, il a toujours la valeur 208. Le Mobile Network Code (MNC) permet d’identifier le réseau d’un opérateur. Sur la bande GSM, Orange utilise les MNCs 1 et 2, SFR utilise les MNCs 10 et 13, Free utilise le MNC 15 et Bouygues Telecom utilise les MNCs 20 et 88.

Sur l’exemple ci-dessus, on constate que l’on capte des signaux de six cellules : trois cellules Orange (MNC 1) et trois cellules SFR (NMC 10).

Les cellules Orange utilisent les fréquences à 935,2MHz (ARFCN 1), à 936,6 MHz (ARFCN 8) et à 938 MHz (ARFCN 15). Elles partagent le même LAC et ont chacune un identifiant unique (CID).

Les cellules SFR utilisent les fréquences à 951 MHz (ARFCN 80), 952 MHz (ARFCN 85) et 959,2 MHz (ARFCN 121). De la même manière que pour les cellules Orange, elles partagent le même LAC et ont chacune un identifiant unique (CID).

On remarque que grgsm_scanner indique également la puissance du signal reçu pour chaque cellule. Normalement la MS se connecte à la cellule qu’il capte le mieux, c’est-à-dire celle dont la puissance du signal est la plus importante. Dans ce cas, pour un abonné Orange, elle se connectera sur la cellule 64988 et sur la cellule 24843 pour un abonné SFR.

Les arguments qu’il est possible de fournir à grgsm_scanner sont les suivants :

  • la fréquence d’échantillonnage avec -s ou --samp-rate=. La valeur par défaut est 2000000.
  • une correction de fréquence avec -p ou --ppm=. La valeur par défaut est zéro. Elle permet de pallier des défauts matériels du récepteur.
  • le gain avec -g ou --gain=. La valeur par défaut est 24. Il peut être utile d’augmenter cette valeur en cas de mauvaise réception du signal.
  • la vitesse à laquelle le logiciel scanne avec --speed= entre zéro et cinq. La valeur par défaut est quatre. Zéro correspond à la vitesse la plus lente et cinq à la plus rapide.

Avec -v, on obtient des informations supplémentaires, notamment la configuration CCCH, les ARFCNs de la cellule et des cellules environnantes.

$ grgsm_scanner -s 2e6 -p 0 -g 50 --speed=3 -v
linux; GNU C++ version 6.3.0 20170221; Boost_106200; UHD_003.009.005-0-unknown


ARFCN:    1, Freq:  935.2M, CID: 36576, LAC:  6147, MCC: 208, MNC:   1, Pwr: -40
  |---- Configuration: 1 CCCH, not combined
  |---- Cell ARFCNs: 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 47, 48, 49
  |---- Neighbour Cells: 4, 8, 11, 14, 515, 517, 599, 601, 603

ARFCN:    8, Freq:  936.6M, CID: 64988, LAC:  6147, MCC: 208, MNC:   1, Pwr: -28
  |---- Configuration: 1 CCCH, not combined
  |---- Cell ARFCNs: 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 47, 48, 49
  |---- Neighbour Cells: 1, 2, 3, 4, 5, 6, 7, 9, 10, 13, 14, 15, 512, 514, 515, 516, 517, 523, 600, 601, 606, 607, 609

ARFCN:   15, Freq:  938.0M, CID: 55029, LAC:  6147, MCC: 208, MNC:   1, Pwr: -28
  |---- Configuration: 1 CCCH, not combined
  |---- Cell ARFCNs: 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 47, 48, 49
  |---- Neighbour Cells: 1, 4, 5, 8, 10, 13, 14, 512, 514, 516, 521, 523, 599, 601, 603, 606, 609, 610

ARFCN:   80, Freq:  951.0M, CID: 24843, LAC: 49308, MCC: 208, MNC:  10, Pwr: -31
  |---- Configuration: 1 CCCH, not combined
  |---- Cell ARFCNs: 80, 119
  |---- Neighbour Cells: 77, 80, 82, 83, 84, 85, 87, 113, 114, 115, 117, 118, 119, 121, 122, 124

ARFCN:   85, Freq:  952.0M, CID: 58410, LAC: 49308, MCC: 208, MNC:  10, Pwr: -30
  |---- Configuration: 1 CCCH, not combined
  |---- Cell ARFCNs: 85, 116
  |---- Neighbour Cells: 77, 79, 80, 81, 82, 83, 84, 85, 113, 114, 116, 119, 120, 121, 122, 124

ARFCN:  121, Freq:  959.2M, CID: 24844, LAC: 49308, MCC: 208, MNC:  10, Pwr: -28
  |---- Configuration: 1 CCCH, not combined
  |---- Cell ARFCNs: 76, 121
  |---- Neighbour Cells: 77, 78, 80, 81, 83, 84, 85, 113, 115, 116, 119, 120, 121, 122, 124
$

Cet outil va donc permettre de savoir quelles ARFCNs ou fréquences sont utilisées par les BTS environnantes et ainsi de savoir quelle(s) fréquence(s) il est utile de tenter de capturer.

3.2 - grgsm_livemon

Grgsm_livemon est un outil graphique qui permet de surveiller en temps réel les données transmises sur une fréquence donnée. La surveillance peut s’effectuer simplement dans la console qui a lancé le programme, mais elle peut également s’effectuer avec wireshark. En effet, grgsm_livemon, envoie les données au format GSMTAP sur l’interface loopback sur le port UDP 4729. Ainsi pour effectuer la surveillance avec wireshark, avant d’exécuter grgsm_livemon, on l’exécute avec la commande suivante :

$ sudo wireshark-gtk -k -f udp -Y gsmtap -i lo &

Cette commande exécute wireshark avec les droits root (avec sudo), en lançant immédiatement la capture (avec -k) sur l’interface loopback (avec -i lo). De plus, on active un filtre de capture sur les paquets udp (avec -f udp) et un filtre d’affichage sur les paquets de type GSMTAP (avec -Y gsmtap). Le & à la fin de la commande permet simplement de garder la main sur le shell.

Note
En dehors d’un environnement de test, pour des raisons de sécurité, il n’est pas recommandé de lancer wireshark en tant que root. Il existe des solutions pour qu'un utilisateur standard puisse l'exécuter.

Une fois cette commande lancée, on peut exécuter grgsm_livemon et choisir graphiquement la fréquence qui nous intéresse. La capture ci-dessous montre ce que cela peut donner.

capture d’écran grgsm_livemon avec wireshark

De la même manière que pour grgsm_scanner, il est possible de spécifier la fréquence d’échantillonnage (avec -s ou --samp-rate=), une correction de fréquence (avec -p ou –ppm=) et le gain (avec -g ou --gain=). La valeur par défaut du gain n’est pas la même que pour grgsm_scanner, elle est fixée à 30 pour grgsm_livemon. On peut également spécifier la fréquence avec laquelle le logiciel démarre avec -f ou --fc=. Il est à noter que la fréquence s’écrit en notation scientifique, c’est-à-dire avec « e » pour l’exprimer en puissance de dix. Par exemple pour la fréquence 951 MHz, on noterait 951e6.

Cet outil va donc permettre de vérifier que des données transitent bien sur la fréquence que l’on souhaite tenter de capturer.

3.3 - grgsm_channelize.py

Grgsm_channelize.py est un outil en ligne de commande. Il est surtout utile lorsqu’une communication vocale utilise des sauts de fréquence. Il permet de séparer une capture à large bande en plusieurs fichiers contenant chacun une ARFCN. Par exemple, la commande suivante va générer deux fichiers, un pour l’ARFCN 80 et un pour l’ARFCN 85, à partir d’une capture centrée sur la fréquence 951.5 MHz et dont la fréquence échantillonnage est de 2 MHz.

$ ls *.cfile
capture_951.5_2M.cfile
$ grgsm_channelize.py -c capture_951.5_2M.cfile -f 951.5e6 -d . 80 85
Input sample rate: 2M
Output sample rate: 1M
==> using resample rate of 0.5
Extracting channels [80, 85], given that the center frequency is at 951.5M
ARFCN 80 is at 951.5MHz -500KHz
ARFCN 80 is at 951.5MHz +500KHz
Done!
$ ls *.cfile
capture_951.5_2M.cfile  out_80.cfile  out_85.cfile

À l’issue de cette commande, on constate que deux nouveaux fichiers ont bien été créés avec une fréquence d'échantillonnage divisée par deux. Il est ensuite possible de les décoder avec grgsm_decode, ce qui n’était pas le cas avec la capture originale.

4 - Capture

La capture s’effectue avec grgsm_capture.py. Il s’agit d’un outil en ligne de commande. Il ne nécessite que deux arguments : la fréquence ou l’ARFCN et un fichier de sortie.

$ ls *file
ls: impossible d'accéder à '*file': Aucun fichier ou dossier de ce type
$ grgsm_capture.py -f 951e6 -c capture_951.cfile
linux; GNU C++ version 6.3.0 20170221; Boost_106200; UHD_003.009.005-0-unknown

gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy soapy redpitaya
Found Rafael Micro R820T tuner
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
^C$ ls *file
capture_951.cfile
$ grgsm_capture.py -a 80 -b capture_a80.bfile -c capture_a80.cfile
linux; GNU C++ version 6.3.0 20170221; Boost_106200; UHD_003.009.005-0-unknown

gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy soapy redpitaya
Found Rafael Micro R820T tuner
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
^C$ ls *file
capture_951.cfile  capture_a80.bfile  capture_a80.cfile

On spécifie la fréquence avec -f ou --fc=. De la même manière que pour grgsm_livemon, la fréquence s’exprime en puissance de dix. Pour utiliser un ARFCN plutôt que la fréquence, on utilise -a ou --arfcn=. Il est à noter que, dans ce cas, la fréquence du lien descendant sera sélectionnée.

Le fichier de sortie peut être écrit dans deux formats, soit sous forme de burst avec -b ou --burst-file=, soit sous forme d’un fichier ne contenant que les données avec -c ou --cfile=. Il est possible d’utiliser l’un ou l’autre ou les deux en même temps. Grgsm_decode peut décoder ces deux types de fichiers.

De la même manière que pour grgsm_scanner et grgsm_livemon, il est possible de spécifier la fréquence d’échantillonnage (avec -s ou --samp-rate=), une correction de fréquence (avec -p ou --ppm=) et le gain (avec -g ou --gain=). Le fait d’augmenter la fréquence d’échantillonnage permet d’augmenter la largeur de la bande capturée pour éventuellement ensuite utiliser grgsm_channelize.py. De plus, il est possible de spécifier la durée de la capture en seconde avec -T ou --rec-length=.

5 - Décodage

Note
Grgsm_decode ne permet pas de décoder le lien montant s’il n’est pas synchronisé avec le lien descendant. Pour cela, Piotr Krysik propose un autre projet utilisant gr-gsm. Il est nommé multi-rtl. Pour pouvoir l’utiliser, il faut posséder deux clés USB TNT DVB-T basées sur la puce Realtech RTL2832U et réussir à synchroniser leurs horloges. Cet article est réalisé avec une seule clé. Ainsi le décodage ne concerne que le lien descendant.

Le décodage de la capture s’effectue avec grgsm_decode. Il s’agit d’un outil en ligne de commande. Au départ, il ne nécessite que deux arguments : la fréquence (avec -f ou --fc=) ou l’ARFCN (avec -a ou --arfcn=), et un fichier de capture (avec -b ou --burst-file, ou -c ou --cfile=). Par défaut, il n’affiche rien.

$ grgsm_decode -c capture_936.cfile -f 936e6
$ grgsm_decode -c capture_936.cfile -a 5
$

Mais, de la même manière que grgsm_livemon, il envoie les données au format GSMTAP sur l’interface loopback sur le port UDP 4729. Ainsi, pour visualiser les données, avant d’exécuter grgsm_decode, on exécute wireshark avec la commande suivante :

$ sudo wireshark-gtk -k -f udp -Y gsmtap -i lo &

5.1 - Décodage d’un SMS

Après avoir exécuté wireshark en fond, on peut exécuter grgsm_decode. Par exemple pour une capture réalisée sur la fréquence 936 MHz (ARFCN 5), on exécute l’une ou l’autre des deux commandes présentées ci-dessus.

Dans wireshark, on obtient essentiellement des paquets (RR) Paging Request Type 1 parmi lesquels il faut trouver un paquet (RR) Immediate Assignement (cf. filtre de la capture). Cela va permettre de trouver le time slot du SDCCH dans les paquets qui contiennent un Channel Description. La capture suivante montre que, dans notre cas, il s’agit d’un SDCCH/8 sur le time slot 1.

capture d’écran wireshark montrant un Immediate Assignement

À partir de là, on relance wireshark et grgsm_decode en lui spécifiant que l’on souhaite décoder du SDCCH/8, sur le time slot 1.

$ grgsm_decode -c capture_936.cfile -a 5 -m SDCCH8 -t 1

Dans wireshark, il faut trouver un paquet (RR) Ciphering Mode Command (cf. filtre de la capture). Cela permet de déterminer le mode de chiffrement (A5/1 ou A5/3) dans Cipher Mode Setting. S’il s’agit d’A5/3, bien que grgsm_decode le prenne en charge, comme il n’est pas possible de le casser, on ne pourra pas lire le contenu du SMS sans connaître la clé. En revanche, s’il s’agit d’A5/1, on peut casser la clé avec kraken et on pourra lire le contenu du SMS. La capture suivante montre que, dans notre cas, il s’agit d’A5/1 :

capture d’écran wireshark montrant le mode de chiffrement

Après avoir obtenu la clé, on relance une nouvelle fois wireshark et grgsm_decode en ajoutant le mode de chiffrement et la clé.

$ grgsm_decode -c capture_936.cfile -a 5 -m SDCCH8 -t 1 -e 1 -k F5C55DB5E6E8B694

Dans wireshark, en recherchant un paquet (SMS) CP-DATA (cf. filtre de la capture), on peut lire le SMS en dépliant TP-User-Data. La capture suivante montre un SMS contenant un code 2FA du manager OVH :

Capture d’écran wireshark montrant le contenu d’un SMS

Comme indiqué dans la note en début de paragraphe 5, il n’est actuellement pas possible de décoder le lien montant seul avec grgsm_decode. Mais, on peut noter que, lorsque que la MS envoie un SMS, sur le lien descendant la BTS en accuse réception avec un paquet (SMS) CP-ACK.

5.2 - Décodage d’un appel

Note
Cet exemple est plutôt simple car il n’y a pas de saut de fréquence. Si tel est le cas, il faut pouvoir effectuer une capture à plus large bande, idéalement à 35MHz, et utiliser grgsm_channelize pour séparer les ARFCNs. De plus, dans ce cas, le décodage de la voix ne peut pas encore se faire directement avec grgsm_decode.

Le début du processus est le même que pour un SMS. On commence par rechercher un paquet (RR) Immediate Assignement. Cela permet de trouver le time slot du SDCCH puis le mode de chiffrement et la clé.

$ grgsm_decode -c capture_936.cfile -a 5
$ grgsm_decode -c capture_936.cfile -a 5 -m SDCCH8 -t 1
$ grgsm_decode -c capture_936.cfile -a 5 -m SDCCH8 -t 1 -e 1 -k B2176AE3590758A6

Dans wireshark en recherchant un paquet (RR) Assignement Command (cf. filtre de la capture), on obtient tous les éléments permettant d’extraire la voix. Il s’agit du type du Traffic CHannel, son time slot et le codec. Dans la capture ci-dessus, on constate qu’il s’agit d’un TCH/F utilisant un codec GSM-FR, sur le time slot 5.

capture d’écran wireshark montrant une Assignement Command

Pour extraire la communication descendante, on relance grgsm_decode en lui spécifiant que l’on souhaite décoder du TCH/F, sur le timeslot 5. De plus, on lui indique le codec et un fichier de sortie :

$ ls *.gsm
ls: impossible d'accéder à '*.gsm': Aucun fichier ou dossier de ce type
$ grgsm_decode -c capture_936.cfile -a 5 -m TCHF -t 5 -e 1 -k B2176AE3590758A6 -d FR -o voix.gsm
$ ls *.gsm
voix.gsm

Si wireshark est lancé, dans ce dernier, on remarque qu’on obtient, entre autres, un paquet (CC) Connect Acknowledge, marquant le début de l’appel.

capture d’écran wireshark montrant un Connect Acknowledge

Au final, on obtient un fichier audio au format GSM-FR lisible avec VLC ou tout autre lecteur audio prenant en charge le codec.

Conclusion

Il est peu onéreux et plutôt simple d’intercepter passivement et de décoder des flux GSM. Pour cela, comme on l’a vu dans les paragraphes quatre et cinq, il faut, d’une part, être capable de capturer toutes les données pertinentes et, d’autre part, pouvoir les décoder et les décrypter.

Afin de compliquer la capture, les opérateurs peuvent mettre en place des sauts de fréquence et des séquences de sauts peu prédictibles. Pour empêcher le déchiffrement des données, ils mettent progressivement en place le chiffrement A5/3, pour lequel aucune attaque pratique n’existe à l’heure actuelle.

Dans ce dernier cas, une interception passive n’est plus possible et les attaques se doivent d’être actives, c’est-à-dire qu’il faut mettre en place une fausse BTS à laquelle les MS cibles vont se connecter. Cette dernière servira de proxy entre les MS et la BTS de l’opérateur. On appelle cela un IMSI-catcher. Il est possible d’en fabriquer un avec le matériel dédié à la SDR présenté en fin de paragraphe un et des logiciels libres.

Les possibilités offertes par la SDR en terme de capture et la facilité de décodage des données avec gr-gsm, en particulier pour les SMS, permet de dire que depuis quelques années, la téléphonie mobile est compromise. Ainsi, bien qu’un bon nombre d’acteurs de l’Internet l’utilisent comme deuxième facteur d’authentification, ou dans leurs procédures de récupération du mot de passe, aujourd’hui, elle ne devrait plus être considérée comme un canal de communication sécurisé.

Secteurs défectueux dans une image disque et x-ways forensics

Secteurs défectueux dans une image disque et x-ways forensics

Lorsqu'on réalise une image d'un disque dur, il peut arriver que l'on soit confronté à des secteurs défectueux. Il s'agit généralement de secteurs dont le CRC ne correspond pas aux données. C'est surtout un signe que le disque est en fin de vie. Dans ce cas, c'est donc particulièrement une bonne chose de travailler sur une image plutôt que directement sur le disque. Bon nombre de logiciels permettant de faire des images de disque ne gèrent pas toujours cela très bien, surtout lorsque les problèmes sont nombreux.

X-Ways Forensics gère cela plutôt bien.

X-Ways Forensics General Options

Dans les options générales, on remarque :

  • une case à cocher qui permet d'utiliser deux méthodes alternatives de lecture et surtout d'ajouter un timeout,
  • un champ nommé "Surrogate pattern for unreadable sectors" qui correspond au motif qui sera écrit à la place du contenu d'un secteur défectueux.

À l'issue de l'image, on obtient toujours un fichier texte portant le même nom que les fichiers de l'image. S'il y a des secteurs défectueux, ils sont indiqués dans ce fichier :

[...]
Destination: H:\img\ST750LM0 30-1KKL42.e01
[x] Split image into segments of 1,0 GB

25/12/1970  02:46:14  Cannot read from Sector 2 081...2 087 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:06:50  Cannot read from Sector 39 124 144...39 124 151 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:11:36  Cannot read from Sector 39 157 288...39 157 295 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:16:41  Cannot read from Sector 39 193 408...39 193 415 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:21:37  Cannot read from Sector 39 226 552...39 226 559 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:25:57  Cannot read from Sector 39 244 480...39 244 487 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:30:27  Cannot read from Sector 39 277 616...39 277 623 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.
25/12/1970  04:32:56  Cannot read from Sector 39 310 760...39 310 762 of ST750LM0 30-1KKL42. The request could not be performed because of an I/O device error.

Number of unreadable sectors: 58

Hash of source data: B371B93D056DC3D5D74809578EC36437 (MD5)

25/12/1970, 05:30:52
Imaging completed: 147 GB
[...]

Le hash de la source ("Hash of source data") est celui qui est stocké dans les fichiers E0x. Il est important de noter qu'il est calculé en tenant compte du motif de remplacement indiqué dans les options. Il ne s'agit donc pas réellement du hash du disque source puisqu'il est de toute façon incalculable. Il permettra surtout de vérifier que l'image est bien intègre.

Lorsqu'on regarde le contenu d'un secteur défectueux, on constate bien la présence du motif de remplacement :

X-Ways Forensics UNREADABLESECTOR

La difficulté principale est ensuite de trouver quels sont les fichiers affectés par les secteurs défectueux. On peut se déplacer aux offsets spécifiés dans le fichier texte et lire les métadonnées du fichier dans le panneau info, mais cela devient très vite fastidieux si les secteurs défectueux sont très nombreux. Il est plus simple d'utiliser plutôt le motif de remplacement dans une recherche par mots clés avec les paramètres suivants :

X-Ways Forensics Simultaneous Search

Il est à noter que pour accélérer le processus :

  • on utilise une recherche physique (sector-wise)
  • Cond.: offset mod est coché. Avec les paramètres 512 = 0, on indique que la recherche ne doit s'effectuer qu'en début de secteur.

Selon la taille de l'image et le débit du disque qui la stocke, la recherche peut être longue. On peut l'annuler dès que le nombre de hits correspond au nombre de secteurs défectueux. Dans le cas en question, il n'y a que 58 secteurs défectueux uniquement situés en début de disque :

X-Ways Forensics Searching

À l'issue de la recherche ou après l'avoir annulée, on obtient les résultats. En cochant "List 1 hit per item only", on a tout de suite la liste des quatre fichiers qui risquent de ne pas s'ouvrir.

X-Ways Forensics Search results

Ainsi, en utilisant un motif de remplacement facilement identifiable, même si les secteurs défectueux sont très nombreux, il est assez facile d'obtenir les fichiers en contenant au moins un, et ce de manière automatisée.

Configurer postfix avec un Exchange non autoritatif sur le même domaine

Ma problématique était la suivante : un client avec un serveur de messagerie sous postfix souhaitait migrer une grande partie de ses utilisateurs sur un serveur exchange, sans changer de domaine.

L'idée a été de prendre du Hosted Exchange chez OVH et de le configurer en mode non autoritatif : enter image description here

Une fois que l'entrée DNS MX du domaine est modifiée pour pointer sur le serveur Exchange et propagée, cela devrait fonctionner. Lorsque le serveur Exchange reçoit des courriels, il regarde dans sa liste d'utilisateurs et si l'utilisateur est connu, il délivre le message dans la boite de réception. S'il n'est pas connu, il transmet le message au serveur postfix, soit mail.domaine.tld dans la capture ci-dessus.

Jusque la tout semble bien fonctionner, du moins pour tous les messages venant de l'extérieur. En effet, lorsque les utilisateurs du serveur postfix souhaitent envoyer un message à une adresse qui est présente sur les deux serveurs, il est délivré en local. Lorsque les utilisateurs du serveur postfix souhaitent envoyer un message à une adresse qui n'est que sur le serveur Exchange, dans les logs postfix, on obtient le message suivant : Recipient address rejected: User unknown in local recipient table et le message n'est pas délivré. Tout cela est normal. En effet, le serveur postfix ne sait pas qu'il existe un autre serveur sur le domaine.

La solution consiste à modifier le fichier /etc/postfix/main.cf pour indiquer à postfix qu'il doit agir comme un relais pour ce domaine. Pour cela on retire le domaine de mydestination pour l'ajouter dans relay_domains :

Voici cette partie du fichier avant :

mydestination = domaine.tld autredomaine.tld
relay_domains =

Et le voici après :

mydestination = autredomaine.tld
relay_domains = domaine.tld

Ensuite dans le fichier /etc/postfix/transport, on indique tout d'abord les adresses des utilisateurs du serveur Exchange puis le mode de transport (smtp) et le saut suivant, soit le nom du serveur Exchange . Ensuite, pour toutes les autres adresses, on indique qu'ils doivent être traités localement. On obtient un fichier qui ressemble à cela :

exchange.user1@domaine.tld smtp:ex3.mail.ovh.net
exchange.user2@domaine.tld smtp:ex3.mail.ovh.net
exchange.user3@domaine.tld smtp:ex3.mail.ovh.net
[...]
exchange.usern@domaine.tld smtp:ex3.mail.ovh.net
domaine.tld local

On relance postfix et on peut utiliser le nouveau serveur Exchange, aussi bien en interne que depuis l'extérieur.

Se connecter à un VPN PPTP avec le chiffrement optionnel sous macOS Sierra

Se connecter à un VPN PPTP avec le chiffrement optionnel sous macOS Sierra

Pour un client, je devais me connecter à un VPN Point-to-Point Tunneling Protocol configuré pour ne pas supporter le chiffrement. Sous Windows, cela ne pose pas particulièrement de problème, dans les propriétés de la connexion, il suffit de sélectionner chiffrement optionnel :

propriétés connexion VPN

Le problème, c'est que je suis essentiellement sous macOS Sierra et, pour des raisons de sécurité, Apple a supprimé le support PPTP dans Sierra et iOS 10. Après quelques recherches on trouve deux alternatives :

  1. Shimo (payant : 49 €)
  2. Flow VPN (gratuit)

Ils supportent tous les deux le PPTP mais lorsqu'on tente de se connecter à un serveur configuré pour ne pas supporter le chiffrement, on obtient le message d'erreur suivant :

MPPE required, but MS-CHAP[v2] auth not performed.

Dans les deux cas, cela vient du fait que ces logiciels activent par défaut le chiffrement obligatoire. En fait ils contiennent la ligne suivante dans leur configuration :

require-mppe

Il faut donc trouver un moyen de ne pas tenir compte de cette ligne lors de la connexion.

Pour Shimo, c'est assez simple, on ajoute nomppe dans l'onglet "expert" des propriétés de la connexion :

shimo nomppe

Pour Flow VPN, c'est un peu plus compliqué. Il faut mettre des # aux lignes 92 et 93 du fichier "FlowVPN Connect.app/Contents/MacOS/FlowVPN Connect" (en utilisant "clic droit -> Afficher le contenu du paquet") :

flowVPN nomppe commentaires

Et voilà, dans les deux cas, après, on peut se connecter.