Ton commentaire est très intéressant sur le plan technique mais aussi un peu déprimant :
Peut-être qu'une partie du problème vient aussi du fait que les gens qui font vraiment de la rétroingénierie (et donc savent ce qu'ils veulent) n'ont pas le temps de contribuer à un tel logiciel open source. En tout cas c'est mon cas.
Et donc votre plan à long terme c'est quoi, dans 20 ans vous conseillerez toujours d'utiliser IDA ? Et si des gens veulent expérimenter sur des façons nouvelles/différentes/avancées de faire de la rétro-ingénérie, ils se font embaucher par la boîte ou refont tout depuis rien ?
On parle souvent de "dette technologique" pour le cas de la base de code d'un logiciel donné (qui par accumulation de code peu maintenu devient impossible à faire avancer), mais je pense que certains domaines souffrent d'un "gouffre technologique" car tous les outils utilisés sont propriétaires. Au contraire, dans de nombreux domaines (par exemple les langages de programmation), il y a un mélange sain d'outils libres et d'outils propriétaires qui fait qu'une partie des outils du domaine font partie de notre savoir collectif. Si on veut écrire un compilateur aujourd'hui, pas besoin de tout reprendre de zéro ou de s'entendre dire "tu ne concurrenceras jamais ICC et personne ne veut utiliser un truc moins bien", on peut s'appuyer sur LLVM (par exemple).
Je pense que c'est sans doute un aspect négligé de certains logiciels libres comme Gimp ou LibreOffice. D'accord, entre quatre yeux, ils sont peut-être moins biens (sous plein d'aspects) que leur principal concurrent propriétaire. Mais ils sont là, ils n'ont pas abandonné le terrain, et chaque fonctionnalité qui leur est ajoutée entre dans notre propriété partagée des connaissances et des outils, d'où chacun pourra repartir pour créer son propre projet—en plus de rendre des services quotidiens aux utilisateurs moins exigeants.
Dans d'autres domaines au contraire, comme l'ingénierie inverse si on en croit ton message, nous sommes collectivement démunis, réduis à mendier l'offre d'un, deux ou trois grands outils, qui ont tellement d'avance qu'ils écrasent toute tentative d'enrichir l'offre publique.
Heureusement qu'il y a des gens assez fous, assez courageux ou ayant assez de temps à perdre pour se lancer à la poursuite de ces géants. Ils n'y arriveront peut-être jamais (mais la chance peut tourner; Sage peut concurrencer Mathematica, IPython+SciPy peut concurrencer Matlab, Blender peut concurrencer Maya, etc.), mais les retombées positives en valent la peine. C'est fou tout ce qu'on peut faire quand on est soudain libre de monter sur les épaules des géants.
(Remarque: dans certains écosystèmes, le rôle du savoir commun partagé est assuré par un accès à un SDK propriétaire mais standardisé. Par exemple, iOS n'a pas apporté la reconnaissance vocale à notre univers de connaissance, mais donné un moyen fiable pour les développeurs d'applications iPhone de s'en servir sur leur système. C'est la norme dans certains écosystèmes, comme les moteurs de jeu vidéo. Ça donne des systèmes plus cloisonnés, moins extensibles, moins appréciés sur LinuxFR, et moins durables dans le temps, mais c'est aussi une forme d'aide à la réalisaton qui est intéressante et appréciée.)
[^] # Re: Pourquoi les gens ne jurent que par IDA
Posté par gasche . En réponse au journal Disséquer du binaire sous linux. Évalué à 7.
Ton commentaire est très intéressant sur le plan technique mais aussi un peu déprimant :
Et donc votre plan à long terme c'est quoi, dans 20 ans vous conseillerez toujours d'utiliser IDA ? Et si des gens veulent expérimenter sur des façons nouvelles/différentes/avancées de faire de la rétro-ingénérie, ils se font embaucher par la boîte ou refont tout depuis rien ?
On parle souvent de "dette technologique" pour le cas de la base de code d'un logiciel donné (qui par accumulation de code peu maintenu devient impossible à faire avancer), mais je pense que certains domaines souffrent d'un "gouffre technologique" car tous les outils utilisés sont propriétaires. Au contraire, dans de nombreux domaines (par exemple les langages de programmation), il y a un mélange sain d'outils libres et d'outils propriétaires qui fait qu'une partie des outils du domaine font partie de notre savoir collectif. Si on veut écrire un compilateur aujourd'hui, pas besoin de tout reprendre de zéro ou de s'entendre dire "tu ne concurrenceras jamais ICC et personne ne veut utiliser un truc moins bien", on peut s'appuyer sur LLVM (par exemple).
Je pense que c'est sans doute un aspect négligé de certains logiciels libres comme Gimp ou LibreOffice. D'accord, entre quatre yeux, ils sont peut-être moins biens (sous plein d'aspects) que leur principal concurrent propriétaire. Mais ils sont là, ils n'ont pas abandonné le terrain, et chaque fonctionnalité qui leur est ajoutée entre dans notre propriété partagée des connaissances et des outils, d'où chacun pourra repartir pour créer son propre projet—en plus de rendre des services quotidiens aux utilisateurs moins exigeants.
Dans d'autres domaines au contraire, comme l'ingénierie inverse si on en croit ton message, nous sommes collectivement démunis, réduis à mendier l'offre d'un, deux ou trois grands outils, qui ont tellement d'avance qu'ils écrasent toute tentative d'enrichir l'offre publique.
Heureusement qu'il y a des gens assez fous, assez courageux ou ayant assez de temps à perdre pour se lancer à la poursuite de ces géants. Ils n'y arriveront peut-être jamais (mais la chance peut tourner; Sage peut concurrencer Mathematica, IPython+SciPy peut concurrencer Matlab, Blender peut concurrencer Maya, etc.), mais les retombées positives en valent la peine. C'est fou tout ce qu'on peut faire quand on est soudain libre de monter sur les épaules des géants.
(Remarque: dans certains écosystèmes, le rôle du savoir commun partagé est assuré par un accès à un SDK propriétaire mais standardisé. Par exemple, iOS n'a pas apporté la reconnaissance vocale à notre univers de connaissance, mais donné un moyen fiable pour les développeurs d'applications iPhone de s'en servir sur leur système. C'est la norme dans certains écosystèmes, comme les moteurs de jeu vidéo. Ça donne des systèmes plus cloisonnés, moins extensibles, moins appréciés sur LinuxFR, et moins durables dans le temps, mais c'est aussi une forme d'aide à la réalisaton qui est intéressante et appréciée.)