[Ebook] Hacking et Forensic Développez vos propres outils en Python.pdf

[credo]

T'es pas trop vieux pour télétubbies ?!

Merci, ça marche!

[K.M4RX]

J'ai hâte de le lire

[rowe]

super

[Icarus]

Merci beaucoup rowe pour avoir déterré ce sujet. Cela m'a bien fait rire. Je m'explique :

J'ai commencé à lire l'ouvrage et lu les premiers scripts en Python. Oui, Python. Cela fait longtemps que je me dis que je devrais regarder un peu ce langage très usité et en particulier dans les exploits (non sans oublier la tonne de logiciels écrits avec Python).
J'ai donc pris l'un des premiers scripts fournis (je l'ai quelque peu adapté car j'ai un serveur NGINX en local) :

import socket
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('localhost', 80))
s.send("GET /index.html\r\n\r\n")
d = s.recv(2048)
print d
s.close()

% python2.7 pysc.py

Et ça marche ! Cool. Mais Python 2 est mort depuis l'an dernier si je ne me trompe pas. Alors, ça donne quoi avec Python 3 ?

% python3.7 pysc.py
File "pysc.py", line 6
print d
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(d)?

Hum... print (d) alors ?

% python3.7 pysc.py
Traceback (most recent call last):
File "pysc.py", line 4, in <module>
s.send("GET /index.html\r\n\r\n")
TypeError: a bytes-like object is required, not 'str'

Alors, la première erreur est juste due à des parenthèses qui manquent ? J'y reviendrai...
La fonction send() attend une suite d'octets.. Une chaîne de caractères n'est-elle pas une suite d'octets ?
Ouai, pas tout à fait. Cela dépend de l'encodage des dits caractères...
Alors, on le refait :

import socket
s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('localhost', 80))
s.send("GET /index.html\r\n\r\n".encoding('utf-8'))
d = s.recv(2048)
print (d)

Et, miracle, ça marche !

Où est la chute me direz-vous ? Ben, en fait que ce code modifié pour Python 3 marche parfaitement pour Python 2. L'inverse n'étant pas vrai, pas vrai du tout.

Alors que la plupart des langages tendent vers la rétro-compatibilité (avec plus ou moins de succès), les développeurs de Python ont - pour ainsi dire - inventé l' Ante-compatibilité. A savoir que python 2 peut exécuter certains morceaux de Python 3 mais pas l'inverse.

A commencer par générer une erreur parce qu'il n'y a pas de parenthèses autour de la fonction print. Franchement... Ils n'avaient que ça à faire ? Comment foutre en l'air des millions de lignes de code sur une envie grotesque d'épurer le code Python en général.

Je ne veux pas aller très loin dans la comparaison mais PHP n'a jamais fait telle chose. Et, en ce qui me concerne, je veux dire ce que je connais le mieux, C++ (nouvelles versions) se contente d'avertissements la plupart du temps, laissant le code se compiler (et donc s'exécuter).

Bref... Cela me dissuade d'apprendre Python. Déjà que je n'y voyais que peu d'intérêt...

[fred]

Bonjour et désolé d'intervenir aussi tard...

A savoir que python 2 peut exécuter certains morceaux de Python 3 mais pas l'inverse.

Si on peut, en utilisant un script spécifique pour faire cela: 2to3

Mais après ce détail, qui en est vraiment un, je connais python depuis sa version 2.4 et je bosse professionnellement avec la 3.5 à 3.8, je n'ai jamais eu de problème à m'adapter à la version 3. Rien de choquant, de cassant mais beaucoup de superbes évolutions comme la vérification des types, les tests, efficacité des dictionnaires avec les objets view, le multiprocessing, asyncio, .... et tout ça, toutes ces évolutions ont forcé le choix de casser la compatibilité de la version 2. Quitte à casser autant réparer quelques erreurs, comme print qui devait être une fonction et non une instruction, les problèmes d'encodage pénibles avec python2 disparus en plaçant tout en unicode, etc.

Des fois il faut prendre des décisions, et avouer que certaines choses ne vont pas... Et quand ça va pas, rien ne sert de continuer dans son caca et partir d'une base bancale, mieux vaut reprendre, rétablir, améliorer quitte à un peu désorienter. Sans oublier que les documentations sont mises à jour, et quelles sont plutôt bien faîtes pour Python.

Qu'on aime ou qu'on aime pas Python, c'est un choix, on l'accepte sans discuter, mais attention de ne pas critiquer sans connaître l'historique derrière...

[Icarus]

Python est un langage très pratique pour ce que j'en sais. Mais, à la lumière de cette expérience, je comprends mieux la colère des développeurs lorsque la version 2 a été enterrée.

Honnêtement, s'il faut récrire le code à chaque version majeure, mon point de vue est que cela est dissuasif (oui, car 2to3 ne doit certainement marcher que pour les programmes les plus simples). D'autant plus que ce ne sont pas les langages de script qui manquent, la concurrence est rude : perl, ruby, php pour ne citer que ceux qui me viennent à l'esprit. Pour moi, si le développement de Python continue avec cette politique (de la terre brûlée), nous n'entendrons plus parler de ce langage d'ici quelques années.

Mais ce n'est qu'un avis d'un non-utilisateur. Il vaut ce qu'il vaut.

[fred]

Python est un langage très pratique pour ce que j'en sais. Mais, à la lumière de cette expérience, je comprends mieux la colère des développeurs lorsque la version 2 a été enterrée.

Honnêtement, s'il faut récrire le code à chaque version majeure, mon point de vue est que cela est dissuasif (oui, car 2to3 ne doit certainement marcher que pour les programmes les plus simples). D'autant plus que ce ne sont pas les langages de script qui manquent, la concurrence est rude : perl, ruby, php pour ne citer que ceux qui me viennent à l'esprit. Pour moi, si le développement de Python continue avec cette politique (de la terre brûlée), nous n'entendrons plus parler de ce langage d'ici quelques années.

Mais ce n'est qu'un avis d'un non-utilisateur. Il vaut ce qu'il vaut.

Je comprend pas où tu veux en venir avec ta première affirmation, les développeurs n'ont pas été en colères, mais déçus que la maintenance soit importante dans leurs applications. Toutes montées en versions a ses lots de difficultés. Par exemple au taf, on a actuellement des difficultés dans la montée en version de PostgreSQL 9.5 à la version 11 ou 12. On est aussi en difficulté dans le passage de la version 1.11 à la version 2.2 Django ou même mieux dans la tentative de la version 3.x

Pour Django ça implique l'obligation de renseigner pour tous les modèles d'y ajouter l'option "on_delete" qui est un travail exorbitant quand on connaît la taille de l'application à mettre à jour.

Python3 a maintenant 12 ans, et je connais peu d'applications non obsolètes après tant d'années, en règle générale une refonte complète est appliquée afin de suivre les évolutions actuelles. On a encore une application en version 2.7 et on en veut plus, on prépare son remplacement avec python3.7 minimum

On ne réécrit plus de code depuis 12 ans, Python 3 évolue et cela sans casser sa base. En fait cette base est tellement solide, que je ne vois pas ce qu'une nouvelle version pourrait apporter de plus à celle-ci. Ce n'était pas du tout le cas pour la version 2.x

Pour ta dernière phrase, on ne peut pas savoir, mais aux vues des annonces pour recruter des développeurs Python que se soit dans le web et DevOps, j'ai des doutes sur cette affirmation.

À propos des langages,

1. Perl n'est depuis plus de 10 ans plus un concurrent
2. Ruby a trop peu de développeurs professionnels (très bien payés, mais rares "moins que le COBOL mais rare tout de même")
3. PHP oui en tant que serveur Web, mais pour le reste... je vois pas de concurrence.

Pour conclure, Python ne rentre plus dans cette politique (elle ne l'a jamais réellement voulue, pas le choix), d'ailleurs la politique et les politiciens Python ont changé (les vieux remplacés par les jeunes) et ça se passe très bien comme ça.

[Icarus]

Ben, j'ai vu au moins un fil où une personne hurlait à la mort après la suppression annoncée de Python2.7 dans FreeBSD par exemple. Il disait qu'il avait un tas de logiciels à réécrire. J'avoue que je n'y ai rien compris sur le coup.

Php n'est pas utilisé que pour les applications web. pfSense, par exemple, repose en grande partie sur php.

Le truc, c'est que tu vois, tous les scripts du bouquin titre de ce fil ne fonctionnent plus. Et je suppose que ce ne doit pas être le seul. C'est dommage parce que je pense vraiment que python est pratique et puissant. Pour mettre cette tragédie en relief, je n'imagine pas un seul instant prendre un livre avec des exemples en C et/ou en C++, aussi ancien soit-il, ne pas se compiler avec les versions actuelles de ces langages.

[fred]

Ben, j'ai vu au moins un fil où une personne hurlait à la mort après la suppression annoncée de Python2.7 dans FreeBSD par exemple. Il disait qu'il avait un tas de logiciels à réécrire. J'avoue que je n'y ai rien compris sur le coup.

Des solutions existent, on dockerize son application, on met son projet sur Github avec un Travis et on check les montées en version, ...

Je pense pas que se soit des logiciels mais des scripts, et quand c'est en grand nombre, effectivement ça peut être pénibles, je le conviens, mais l'adaptation est généralement plus simple.

Php n'est pas utilisé que pour les applications web. pfSense, par exemple, repose en grande partie sur php

Je n'ai pas dis cela, je parlais de concurrence réelle, je ne considère pas PHP comme concurrent direct sur des langages de script tels que Python ou même Ruby et Perl.
Par contre PHP est un concurrent réel sur la partie serveur Web avec Python et ses Frameworks Django ou Flask. C'est une sacré guerre actuellement dans le monde professionnel.

Il est clair que Django et Flask (WebServices) commencent à prendre pas mal de place dans le développement Web.

Le truc, c'est que tu vois, tous les scripts du bouquin titre de ce fil ne fonctionnent plus. Et je suppose que ce ne doit pas être le seul. C'est dommage parce que je pense vraiment que python est pratique et puissant. Pour mettre cette tragédie en relief, je n'imagine pas un seul instant prendre un livre avec des exemples en C et/ou en C++, aussi ancien soit-il, ne pas se compiler avec les versions actuelles de ces langages.

Tous non, à moins de considérer l'instruction print comme un dysfonctionnement... Ce qui est important est de toujours pouvoir comprendre ce qu'on a écrit au niveau de son code. C'est plus compliqué quand on ne met pas de docstrings sur ses fonctions, qu'on ajoute pas de commentaires dans les parties algorithmiques complexes, ...

Python est pratique et puissant, preuve, je développe du Web, mais ici on est sur un forum de sécurité où l'on en parle aussi. Il est très flexible, on l'utilise pour tout et n'importe quoi, au détriment parfois de langages plus adaptés (c'est un tort et une grossière erreur).

Quand je débute en python, j'essaye de prendre un bouquin cohérent avec la version Python que j'utilise. Si je débute en C11, je vais pas prendre un livre avec du C89, même si je sais qu'une compatibilité existe...

[Icarus]

Tiens, j'ai retrouvé par hasard le fil que j'avais vu : https://forums.freebsd.org/threads/e...-issues.73387/
La personne prend à partie FreeBSD qui n'y est pour rien et qui ne fait que suivre les pérégrinations de Python.

Fort heureusement, comme mentionné dans le fil en question, il y a des gens un peu moins c.ns que les développeurs de Python qui ont dérivé Python 2 pour faire un nouveau langage intégrant certaines des nouveautés de Python 3 et qui est compatible Python 2 : https://github.com/naftaliharris/tauthon

Je ne saurais dire quel avenir a Tauthon. C'est sûr qu'il semble un peu seul et part de presque rien. Qui plus est, beaucoup de personnes sont passées à la version 3. Mais, à apprendre quelque chose, Tauthon me paraît avoir une meilleure philosophie. Car il ne s'agit pas que de garder son code en version 2 mais aussi de se demander combien va encore coûter le passage à la version 4 de python...

Après, personnellement, je n'en dis pas grand-chose mais cela me laisse songeur...

[fred]

J'ai déjà donné le fond de ma pensée... Python 3.x existe depuis plus de 10 ans, je ne connais pas beaucoup de logiciels de cette âge n'étant pas obsolètes.

Il est rare de voir des logiciels avec une grande infrastructure en Python 2.7. J'ai le cas dans mon taf et il est mis à jour avec une nouvelle implémentation liée soit à des besoins métiers qui de toute façon seraient inadaptés sur l'ancienne version de l'appli, soit à des besoins technologiques n'étant plus compatibles avec n'importe quelles applications de cet âge. On est passé naturellement à la version 3.x et on essaie régulièrement de suivre une compatibilité avec les nouvelles version Python, PostgreSQL et Django.

Je ne crois pas à ce mécontentement qui fait croire qu'un créateur d'un langage quel qu'il soit, serait un devin sachant déterminer les nouvelles technologies qui existeront 10 ans plus tard. Ça n'existe pas ! Sinon pourquoi verrait-on Rust, Golang apparaître comme langages de demain ? On parle actuellement de remplacer les parties de codes du kernel linux en C par du Rust...

Après chacun à son avis, on peut pas aller contre... cependant il faut ressortir un avis avec bon sens, et dans tes liens, j'ai pas cette impression !

Quand à Tauthon, je ne connaissais pas, mais ce qui est rassurant c'est le suivi de contributeurs tels que Van Rossum, Hettinger ou Peters qui sont des grands nom de Python. Cependant, ça reste donc dans la même idée que le créateur Python du coup...

[Icarus]

Python 3.x existe depuis plus de 10 ans, je ne connais pas beaucoup de logiciels de cette âge n'étant pas obsolètes.

C, C++ entre autres. Mais il y en a plein d'autres.

Je crois que cette dynamique de tout changer, de décider que ce qui a été doit être jeté est une très mauvaise idée.

J'ai trouvé d'autres liens en cherchant. Cette personne n'est pas la seule. Certains programmes se débarrassent de Python dans leurs dépendances. Et cela va s'accentuer jusqu'au moins la fin de cette année. Franchement, c'est la seule chose sensée à faire avant la version 4 même si c'est encore dans 10 ans...

[fred]

Je crois que cette dynamique de tout changer, de décider que ce qui a été doit être jeté est une très mauvaise idée.

Changer pour évoluer ne me pose pas de problème, ce qui doit changer pour que le langage reste l'un des plus utilisés sur le marché du travail me semble logique...
Ce qui deviendrait gênant, c'est des changements comme le print par exemple qui casse tout un programme alors qu'on là juste remplacé par le même nom pour faire les mêmes choses, c'est plutôt pénible, c'est pourquoi ils ont inventé pour ce type de remplacement basique 2to3.

Certains programmes se débarrassent de Python dans leurs dépendances

Cette affirmation est facilement contredite pour de multiples projets sur GitHub par exemple.

Et surtout qu'en plus maintenant certains logiciels comme Ansible (logiciel python) sont devenus des incontournables dans le métier de dev pour l'automatisation.

[Icarus]

C'est sûr que si le logiciel est écrit en Python, on va dire que c'est pour le moins compliqué de se débarrasser de la dépendance. C'est plus simple de convertir le code à python 3 même si ça prend du temps.

Je faisais allusion à des dépendances de fonctions annexes écrites en python et aussi à des dépendances de construction (Build dependencies). Régulièrement, des utilisateurs viennent se plaindre sur les tags EOL python 2.7 qui apparaissent pour des logiciels qui n'utilisent pas vraiment python comme Chromium ou Firefox hormis pour leur construction. Nous verrons bien les choix qui seront fait upstream pour effacer ces tags : passer à python 3 ou changer de langage.

[docteur_bravo]

Svp un lien pour les scripts
Merci d'avance