C'est tout à fait texact en théorie. En pratique, lesdits deux clics, je ne les ai pas souvent vus. Bien peu de gens savent changer les options par défaut, même les plus triviales. Et je ne parle même pas d'ajouter un moteur de recherche…
Donc je ne pense pas que ce soit nous le produit, si par "nous" on entend nous, DLFPiens, un peu culturés et qui maîtrisons (globalement) notre machine. Mais nous sommes une infime minorité, et je vois régulièrement des utilisateurs paniquer devant un message d'erreur sans même chercher à le lire, alors que ça fait quand même un paquet de temps que, même sous Windows, les messages d'erreur sont devenus assez clairs (sous Linux, ils le sont depuis encore longtemps, mais c'est un autre débat). Et ça, Yahoo, Google and co le savent très bien, c'est pourquoi ils se battent pour être le choix par défaut : très peu de gens savent qu'ils peuvent changer les choix par défaut.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
alors que tu ne les verra jamais parce que tu as déjà un historique
Sauf si, comme moi, il surfe avec l'option "Toujours utiliser le mode de navigation privée". Les raisons de le faire sont multiples, ne serait-ce que quand on n'a pas envie que le collègue qui veut vite fait regarder un truc sur mon poste voie plus de visites sur DLFP que sur des sites pro…
Ça, ce sont les sources. Le mouton que tu veux est dedans.
est-il possible de patcher un faille de sécurité sans en révéler l'exploit associé?
Pour faire court, pas si le code source est public. La raison en est simple : si tu publies un patch, il suffit de lire le patch pour voir la vulnérabilité (ou même encore plus simple : tu appliques le patch, tu fais un diff "à l'envers" (en passant le code final en code intital et vice versa) et tu obtiens un patch qui implémente la vulnérabilité).
En pratique, ça peut être plus compliqué. Sur un projet complexe, si la vulnérabilité est elle-même complexe et le diff conséquent, ça peut être difficile de comprendre en quoi un logiciel est faillible. L'attaquant doit donc :
Lire le patch
Lire le code source initial
Connaître le protocole implémenté
Trouver en quoi le comportement corrigé nécessitait une correction
Déterminer une attaque contre ce code
Implémenter cette attaque
Le tout dans un temps limité puisqu'à chaque minute consacrée par l'attaquant à attaquer, ce sont des centaines de serveurs qui sont patchés (et donc le périmètre de l'attaque se réduit).
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Si la banque met des restrictions à l'utilisation d'outils non-autorisés pour accéder aux données bancaires, c'est pour des raisons marketting, mais aussi pour des raisons de sécurité
Si elle met des restrictions légales à des failles de sécurité techniques, alors il y a un problème (puisqu'on parle de violer les CGU, pas d'attaquer des sites via Weboob).
Corrige-moi si je me trompe, mais je vois vraiment weboob comme un cliqueur automatisé de liens : il va sur le site web et clique sur les liens que verrait l'utilisateur (c'est un poil plus compliqué quand il y a des bouts de javascript, mais c'est l'idée). Et si ça révèle des bugs du site web, tant mieux ! Ils seront signalés et (on l'espère) corrigés.
par exemple, effectuer automatiquement un virement mensuel n'a pas forcément le même coût pour la banque que la mise en place d'un virement automatique
Ben justement, pour la banque, un virement ça a un coût marginal quasi-nul. il est des centaines de fois plus intéressant pour elle d'avoir un petit malin qui fait ça en ligne (où ça n'impliquera que des ordinateurs) que d'avoir un client peu versé dans l'informatique qui va tenir la jambe d'un conseiller pendant 10 minutes. Et si virement automatique et virement unique répété n'ont pas le même coût (ce que je peux comprendre), je fais confiance à la banque pour répercuter ce coût sur ses tarifs.
La norme, ça devrait être "si tu n'es pas content, tu vas voir ailleurs".
Ça, c'est la théorie, dans un monde où chaque service et chaque produit est blanc ou noir. Il se trouve qu'on est sur DLFP, où traînent quand même un paquet de gens qui cherchent à hacker. Si je ne suis pas content, pourquoi ne pas chercher à améliorer l'existant ? On ne parle pas de conflit, juste de rendre efficace un produit (site web) qui n'est pas conçu pour être efficace mais pour être accessible au plus grand nombre. Mon grand-père et moi n'avons pas les mêmes besoins, pas les mêmes facilités d'utilisation d'un site web. L'existant vise à ce que lui et moi puissions utiliser le site, pas à ce que je puisse l'utiliser au mieux et que lui soit exclu. Avec Weboob, je peux l'utiliser au mieux et lui reste cantonné au site "de base" qui lui convient. Tout ça à coût nul pour le fournisseur de service. Tant mieux !
même quand tu es sur Internet, tu es en conflit avec les fournisseurs des services qui tu utilises?
Je suppose que tu surfes sans adblock et que tu lis attentivement chaque publicité. Parce que cette problématique est bien plus ancienne que weboob ;)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Le truc d'une méga-tempête solaire, c'est que c'est un événement bref mais intense, et que ça induit des courants (intenses donc) dans les matériaux conducteurs branchés en circuit. Autrement dit, ça brûlera les composants électroniques (et les matériels électriques) sous tension et seulement ceux-là (bon, je suppose que le champ magnétique peut aussi effacer des disques durs éteints et débranchés)au moment de la tempête, qui peut durer de quelques secondes à quelques heures, mais pas plus (ne serait-ce que pour des raisons astronomiques : une tempête solaire est un événement localisé spatialement, et la Terre est en mouvement, donc même dans le cas d'un faisceau continu, elle passerait à travers).
Donc il n'est pas nécessaire d'avoir des composants résistants si on ne les utilise pas au moment de la tempête, et vu que c'est un événement imprévisible, la seule façon de s'en prémunir serait de les utiliser en permanence. Ce qui est difficile, au vu du besoin permanent de puissance de calcul.
je crois pas qu'elle ai eu de mise a jour Philae
Philae (l'atterrisseur) n'a été sous tension que peu de temps. Rosetta a été sous tension tout du long, mais dans un but d'économie d'énergie, Philae n'a été mis sous tension qu'à l'approche de la comète 67P. Ceci dit, ton commentaire s'applique si on prend en compte Rosetta et non Philae.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Oui et non. Le problème, c'est que dans l'espace, tu as tout un paquet de flux de particules chargées, qui causent des erreurs dans les composants électroniques. Notamment, ça interdirait l'utilisation de l'architecture x86 (c'est du conditionnel, je ne fais que répéter ce que j'ai lu, et si quelqu'un peut sourcer, je lui en saurais gré)
La plus part n'ont jamais approché les normes médicales ou d'aéronautique, pour affirmer cela.
On pet difficilement comparer ce qui n'est pas comparable… Le matériel médical comme aéronautique, c'est 100 ans d'expérience, des millions de répétitions de chaque procédure (alors que chaque voyage spatial est spécifique), des procédures de déclaration d'événements indésirables, et surtout, quand ça foire, tu peux analyser les débris/les cadavres. Quand une sonde foire son atterrissage sur Mars, bon courage rien que pour analyser ce qui a cloché !
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Honnêtement, que Google and co. fassent de l'évasion fiscale, c'est un problème entre eux et Bercy. Ça me pose beaucoup moins problème que l'utilisation qu'ils font de mes données, qui est, elle, un problème tout à fait différent.
J'ai l'impression que s'ils rentrent dans les clous au niveau fiscal ils deviendront d'un coup de gentils bisounours d'un point de vue médiatique. Ce n'est pas le cas, et le problème vient plus de leur activité de surveillance (même "bienveillante") que de leur non-paiement des impôts.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Sur Arch, le principal problème est généralement entre la chaise et le clavier. Et si tu casses sans arrêt ton Arch, interroge-toi sur tes propres pratiques :
Si tu utilises l'option --force en routine, il y a un problème.
Si tu utilises l'option --force dans n'importe quel contexte, il y a probablement un problème.
Si tu utilises l'option --sucre de yaourt pour tes mises à jour, il y a un problème vu que c'est un alias de (entre autres) --force.
Mets archlinux.org (ou même .fr) dans tes flux RSS et oublie-le. Chez moi, il est dans mes flux RSS, 9 matins sur 10 il n'a rien de nouveau et je le vois en un coup d’œil en lisant le dernier XKCD, un jour sur 10 il y a une intervention manuelle requise et là encore, 3 fois sur 4 elle ne me concerne pas. Quand une intervention manuelle est requise, elle est tellement détaillée qu'il est difficile de se planter.
Honnêtement, en 3 ans d'utilisation d'Arch, j'ai eu 2 cassages complets. Un était dû à la bronsonisation de mon disque dur (j'avais un backup), l'autre à une ISO corrompue lors de la réinstall (ma faute, j'aurais dû vérifier le checksum). Au final, j'ai retéléchargé une archive propre et ça s'est installé en 20 minutes, lecture de la doc comprise (ok je triche un peu, je l'avais déjà lue une première fois pour installer mon ISO corrompue).
Bon après, c'est vrai que c'est facile de casser son Arch. En root, si on suit pas la doc ou qu'on fait n'importe quoi, on a vite fait de casser un truc. D'où l'intérêt de lire les bonnes pratiques et d'y coller. Arch est relativement stable, à l'utilisateur près.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
En fait, ça crée un nouveau fichier nommé ls avec comme contenu l'unique ligne de code entre guillemets, du coup, quand on appellera la commande ls, ça aura pour seul effet d'afficher le contenu du fichier cat /challenge/binary/binary1/.passwd. Pourquoi on fait ça ? Je ne le sais pas, ça ne semble pas permettre une élévation de droits en soi. Peut-être que ça sert à contourner une limitation autre, mais dans ce cas autant appeler directement cat. Quoi qu'il en soit, ça ne change pas ma conclusion : n'exécute pas ces commandes (ou dans une machine virtuelle jetable :P).
(je voulais éditer mon commentaire mais pas eu le temps, d'où l'auto-réponse)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Je vais faire court : n'exécute pas ces commandes, ça pue le soft malveillant.
rm –rf ./ls
Ça supprime le fichier ls dans le répertoire courant. Si tu te trouves dans /bin, ls est un binaire essentiel, que tu appelles dans tous les cas où tu veux lister les fichiers d'un répertoire (y compris dans un paquet de scripts shell que tu n'as pas écrits toi-même). Si tu n'es pas dans /bin, ça ne trouvera pas le fichier et ça te retournera une erreur.
On lit le fichier /challenge/binary/binary1/.passwd et on colle son contenu dans un nouveau fichier appelé ls, qui se situe précisément à l'endroit où a été supprimé le fichier ls précédent. Pourquoi on fait ça ? En effet, on pourrait tout à fait, en théorie, modifier le fichier sans le supprimer avant. Sauf que c'est une modification du fichier et qu'on n'a pas les droits pour ce faire sans être root. Alors que si on supprime un fichier appartenant à root, rm affichera simplement une demande de confirmation, qu'on force via l'utilisation de -f à la ligne précédente. Ainsi, on a remplacé un binaire très fréquemment utilisé, protégé par le système de droits, par notre binaire à nous, en contournant le système de droits.
chmod+x ./ls
On a notre binaire, mais il n'est pas exécutable. Qu'à celà ne tienne ! On le rend exécutable. Comme on a créé le binaire nous-même, on en est propriétaire : on peut modifier les droits dessus. Tout le monde peut donc désormais exécuter le binaire pourri qu'on a collé sur notre disque, et pire : tout le monde l'appellera de fait quand il croira appeler la commande ls, commande innocente s'il en est.
cd ~
pwd
On retourne dans notre dossier /home. On ne remonte pas d'un cran : on va dans le répertoire personnel de l'utilisateur courant. pwd sert à vérifier qu'on est dans le /home de l'utilisateur courant, si on en doutait.
./binary1
On exécute binary1. Rien que cette ligne devrait te mettre la puce à l'oreille : tu es en présence d'un programme exécutable, dont tu ne sais rien. Cette ligne l'exécute, tout simplement. Ce que fait binary1 ? Je n'en sais strictement rien, c'est un binaire. Mais je n'irais pas le tester.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: C'est nous le produit ?
Posté par Liorel . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à 0.
s/encore longtemps/encore plus longtemps
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: C'est nous le produit ?
Posté par Liorel . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à 2.
C'est tout à fait texact en théorie. En pratique, lesdits deux clics, je ne les ai pas souvent vus. Bien peu de gens savent changer les options par défaut, même les plus triviales. Et je ne parle même pas d'ajouter un moteur de recherche…
Donc je ne pense pas que ce soit nous le produit, si par "nous" on entend nous, DLFPiens, un peu culturés et qui maîtrisons (globalement) notre machine. Mais nous sommes une infime minorité, et je vois régulièrement des utilisateurs paniquer devant un message d'erreur sans même chercher à le lire, alors que ça fait quand même un paquet de temps que, même sous Windows, les messages d'erreur sont devenus assez clairs (sous Linux, ils le sont depuis encore longtemps, mais c'est un autre débat). Et ça, Yahoo, Google and co le savent très bien, c'est pourquoi ils se battent pour être le choix par défaut : très peu de gens savent qu'ils peuvent changer les choix par défaut.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Pages sponsorisées
Posté par Liorel . En réponse au journal Yandex, Baidu et Yahoo, un point commun ?. Évalué à 1.
Sauf si, comme moi, il surfe avec l'option "Toujours utiliser le mode de navigation privée". Les raisons de le faire sont multiples, ne serait-ce que quand on n'a pas envie que le collègue qui veut vite fait regarder un truc sur mon poste voie plus de visites sur DLFP que sur des sites pro…
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Sécurité et confiance
Posté par Liorel . En réponse au journal Sécurité de l'open source Vs closed source: MS14-066. Évalué à 6.
Pour faire court, pas si le code source est public. La raison en est simple : si tu publies un patch, il suffit de lire le patch pour voir la vulnérabilité (ou même encore plus simple : tu appliques le patch, tu fais un diff "à l'envers" (en passant le code final en code intital et vice versa) et tu obtiens un patch qui implémente la vulnérabilité).
En pratique, ça peut être plus compliqué. Sur un projet complexe, si la vulnérabilité est elle-même complexe et le diff conséquent, ça peut être difficile de comprendre en quoi un logiciel est faillible. L'attaquant doit donc :
Le tout dans un temps limité puisqu'à chaque minute consacrée par l'attaquant à attaquer, ce sont des centaines de serveurs qui sont patchés (et donc le périmètre de l'attaque se réduit).
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: le bon coin
Posté par Liorel . En réponse à la dépêche Weboob atteint la maturité. Évalué à 10.
Si elle met des restrictions légales à des failles de sécurité techniques, alors il y a un problème (puisqu'on parle de violer les CGU, pas d'attaquer des sites via Weboob).
Corrige-moi si je me trompe, mais je vois vraiment weboob comme un cliqueur automatisé de liens : il va sur le site web et clique sur les liens que verrait l'utilisateur (c'est un poil plus compliqué quand il y a des bouts de javascript, mais c'est l'idée). Et si ça révèle des bugs du site web, tant mieux ! Ils seront signalés et (on l'espère) corrigés.
Ben justement, pour la banque, un virement ça a un coût marginal quasi-nul. il est des centaines de fois plus intéressant pour elle d'avoir un petit malin qui fait ça en ligne (où ça n'impliquera que des ordinateurs) que d'avoir un client peu versé dans l'informatique qui va tenir la jambe d'un conseiller pendant 10 minutes. Et si virement automatique et virement unique répété n'ont pas le même coût (ce que je peux comprendre), je fais confiance à la banque pour répercuter ce coût sur ses tarifs.
Ça, c'est la théorie, dans un monde où chaque service et chaque produit est blanc ou noir. Il se trouve qu'on est sur DLFP, où traînent quand même un paquet de gens qui cherchent à hacker. Si je ne suis pas content, pourquoi ne pas chercher à améliorer l'existant ? On ne parle pas de conflit, juste de rendre efficace un produit (site web) qui n'est pas conçu pour être efficace mais pour être accessible au plus grand nombre. Mon grand-père et moi n'avons pas les mêmes besoins, pas les mêmes facilités d'utilisation d'un site web. L'existant vise à ce que lui et moi puissions utiliser le site, pas à ce que je puisse l'utiliser au mieux et que lui soit exclu. Avec Weboob, je peux l'utiliser au mieux et lui reste cantonné au site "de base" qui lui convient. Tout ça à coût nul pour le fournisseur de service. Tant mieux !
Je suppose que tu surfes sans adblock et que tu lis attentivement chaque publicité. Parce que cette problématique est bien plus ancienne que weboob ;)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Ben ca valide
Posté par Liorel . En réponse au journal L'astronomie à la portée de tous : Philae. Évalué à 2.
Le truc d'une méga-tempête solaire, c'est que c'est un événement bref mais intense, et que ça induit des courants (intenses donc) dans les matériaux conducteurs branchés en circuit. Autrement dit, ça brûlera les composants électroniques (et les matériels électriques) sous tension et seulement ceux-là (bon, je suppose que le champ magnétique peut aussi effacer des disques durs éteints et débranchés)au moment de la tempête, qui peut durer de quelques secondes à quelques heures, mais pas plus (ne serait-ce que pour des raisons astronomiques : une tempête solaire est un événement localisé spatialement, et la Terre est en mouvement, donc même dans le cas d'un faisceau continu, elle passerait à travers).
Donc il n'est pas nécessaire d'avoir des composants résistants si on ne les utilise pas au moment de la tempête, et vu que c'est un événement imprévisible, la seule façon de s'en prémunir serait de les utiliser en permanence. Ce qui est difficile, au vu du besoin permanent de puissance de calcul.
Philae (l'atterrisseur) n'a été sous tension que peu de temps. Rosetta a été sous tension tout du long, mais dans un but d'économie d'énergie, Philae n'a été mis sous tension qu'à l'approche de la comète 67P. Ceci dit, ton commentaire s'applique si on prend en compte Rosetta et non Philae.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: But de l'exploration spatiale
Posté par Liorel . En réponse au journal L'astronomie à la portée de tous : Philae. Évalué à 5.
Oui et non. Le problème, c'est que dans l'espace, tu as tout un paquet de flux de particules chargées, qui causent des erreurs dans les composants électroniques. Notamment, ça interdirait l'utilisation de l'architecture x86 (c'est du conditionnel, je ne fais que répéter ce que j'ai lu, et si quelqu'un peut sourcer, je lui en saurais gré)
On pet difficilement comparer ce qui n'est pas comparable… Le matériel médical comme aéronautique, c'est 100 ans d'expérience, des millions de répétitions de chaque procédure (alors que chaque voyage spatial est spécifique), des procédures de déclaration d'événements indésirables, et surtout, quand ça foire, tu peux analyser les débris/les cadavres. Quand une sonde foire son atterrissage sur Mars, bon courage rien que pour analyser ce qui a cloché !
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Rolling release et Chakra Linux
Posté par Liorel . En réponse au journal Une idée de distribution Linux. Évalué à 1.
Et si tu as peur de balancer ton adresse mail dans la nature, les flux RSS c'est le bien.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
# Oui, et ?
Posté par Liorel . En réponse au journal "Comment les multinationales (y compris françaises) font de l’évasion fiscale au Luxembourg". Évalué à -10.
Honnêtement, que Google and co. fassent de l'évasion fiscale, c'est un problème entre eux et Bercy. Ça me pose beaucoup moins problème que l'utilisation qu'ils font de mes données, qui est, elle, un problème tout à fait différent.
J'ai l'impression que s'ils rentrent dans les clous au niveau fiscal ils deviendront d'un coup de gentils bisounours d'un point de vue médiatique. Ce n'est pas le cas, et le problème vient plus de leur activité de surveillance (même "bienveillante") que de leur non-paiement des impôts.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Rolling release et Chakra Linux
Posté par Liorel . En réponse au journal Une idée de distribution Linux. Évalué à -1.
Sur Arch, le principal problème est généralement entre la chaise et le clavier. Et si tu casses sans arrêt ton Arch, interroge-toi sur tes propres pratiques :
--forceen routine, il y a un problème.--forcedans n'importe quel contexte, il y a probablement un problème.--sucrede yaourt pour tes mises à jour, il y a un problème vu que c'est un alias de (entre autres)--force.Honnêtement, en 3 ans d'utilisation d'Arch, j'ai eu 2 cassages complets. Un était dû à la bronsonisation de mon disque dur (j'avais un backup), l'autre à une ISO corrompue lors de la réinstall (ma faute, j'aurais dû vérifier le checksum). Au final, j'ai retéléchargé une archive propre et ça s'est installé en 20 minutes, lecture de la doc comprise (ok je triche un peu, je l'avais déjà lue une première fois pour installer mon ISO corrompue).
Bon après, c'est vrai que c'est facile de casser son Arch. En root, si on suit pas la doc ou qu'on fait n'importe quoi, on a vite fait de casser un truc. D'où l'intérêt de lire les bonnes pratiques et d'y coller. Arch est relativement stable, à l'utilisateur près.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: N'exécute pas ces commandes
Posté par Liorel . En réponse au message questions sur differentes commandes. Évalué à 3.
Je me suis planté dans l'interprétation de la ligne
En fait, ça crée un nouveau fichier nommé
lsavec comme contenu l'unique ligne de code entre guillemets, du coup, quand on appellera la commandels, ça aura pour seul effet d'afficher le contenu du fichiercat /challenge/binary/binary1/.passwd. Pourquoi on fait ça ? Je ne le sais pas, ça ne semble pas permettre une élévation de droits en soi. Peut-être que ça sert à contourner une limitation autre, mais dans ce cas autant appeler directementcat. Quoi qu'il en soit, ça ne change pas ma conclusion : n'exécute pas ces commandes (ou dans une machine virtuelle jetable :P).(je voulais éditer mon commentaire mais pas eu le temps, d'où l'auto-réponse)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # N'exécute pas ces commandes
Posté par Liorel . En réponse au message questions sur differentes commandes. Évalué à 5.
Je vais faire court : n'exécute pas ces commandes, ça pue le soft malveillant.
Ça supprime le fichier
lsdans le répertoire courant. Si tu te trouves dans/bin,lsest un binaire essentiel, que tu appelles dans tous les cas où tu veux lister les fichiers d'un répertoire (y compris dans un paquet de scripts shell que tu n'as pas écrits toi-même). Si tu n'es pas dans/bin, ça ne trouvera pas le fichier et ça te retournera une erreur.On lit le fichier
/challenge/binary/binary1/.passwdet on colle son contenu dans un nouveau fichier appeléls, qui se situe précisément à l'endroit où a été supprimé le fichierlsprécédent. Pourquoi on fait ça ? En effet, on pourrait tout à fait, en théorie, modifier le fichier sans le supprimer avant. Sauf que c'est une modification du fichier et qu'on n'a pas les droits pour ce faire sans être root. Alors que si on supprime un fichier appartenant à root,rmaffichera simplement une demande de confirmation, qu'on force via l'utilisation de -f à la ligne précédente. Ainsi, on a remplacé un binaire très fréquemment utilisé, protégé par le système de droits, par notre binaire à nous, en contournant le système de droits.On a notre binaire, mais il n'est pas exécutable. Qu'à celà ne tienne ! On le rend exécutable. Comme on a créé le binaire nous-même, on en est propriétaire : on peut modifier les droits dessus. Tout le monde peut donc désormais exécuter le binaire pourri qu'on a collé sur notre disque, et pire : tout le monde l'appellera de fait quand il croira appeler la commande
ls, commande innocente s'il en est.On retourne dans notre dossier /home. On ne remonte pas d'un cran : on va dans le répertoire personnel de l'utilisateur courant.
pwdsert à vérifier qu'on est dans le /home de l'utilisateur courant, si on en doutait.On exécute
binary1. Rien que cette ligne devrait te mettre la puce à l'oreille : tu es en présence d'un programme exécutable, dont tu ne sais rien. Cette ligne l'exécute, tout simplement. Ce que faitbinary1? Je n'en sais strictement rien, c'est un binaire. Mais je n'irais pas le tester.Ça, ce sont les sources. Le mouton que tu veux est dedans.