Da Geek Contest #3

Posté par Anonyme le 13 septembre 2001 à 18:11. Modéré par oliv.

Étiquettes : aucune

sept.

2001

Pour la troisième fois consécutive, des développeurs ont déversé leur science, bafoué les GNU coding standards et ruiné toutes les règles de bienséance au service de notre Défi'con mensuel.
Ils sont deux cette fois à rivaliser à coup d'inodes et de binaires pour la réalisation d'un agenda *convivial*. Face à ce choix difficile, toute l'équipe du défi vous invite à élire en ligne celui qui trônera tous le mois durant aux cotés de son animal porteur de force...(i.e. le cochon)

Les scripts et solutions des deux candidats sont en ligne, vous pouvez les tester... à vos risques et périls :)

Aller plus loin

Le site parinux (sondage en page de garde, à droite) (2 clics)
Enoncé du défi #3 (2 clics)
Les solutions (4 clics)
Historique des défis (2 clics)

# Trop trop fort !

Posté par Obi MO (site web personnel) le 13 septembre 2001 à 18:35. Évalué à 6.

Vraiment là fallait oser !
stocker des données avec des devices ou dans des binaires, miam ! On pourrait remplacer mySQL ... et même faire tourner daCode avec, non ?!
- [^] # Re: Trop trop fort !
  
  Posté par Anonyme le 13 septembre 2001 à 19:07. Évalué à -1.
  
  C'est en voyant des trucs comme ça que je me dis que j'ai encore quelques progrès à faire sous Linux :)
  
  "It's just a question of time"
- [^] # Re: Trop trop fort !
  
  Posté par Nicolas Vabo le 13 septembre 2001 à 19:35. Évalué à 1.
  
  Pas drôle ils ont enlevé la soluce du 2ème déficon (envoyer des points Godwin à neuneu) qui était basé sur ILOVEYOU (eh oui neuneu utilise Outlook)...
  
  Je l'ai adoré (mais pas mon antivirus), tous les autres sont aussi bien :-D
  - [^] # Re: Trop trop fort !
    
    Posté par Benjamin Drieu (site web personnel) le 13 septembre 2001 à 20:07. Évalué à 6.
    
    si si, elle y est toujours, il suffit de suivre le lien sur l'historique des defis.
    
    Sinon c'est sur http://www.parinux.org/article.php?sid=48(...)
    - [^] # Re: Trop trop fort !
      
      Posté par Anonyme le 13 septembre 2001 à 20:27. Évalué à -1.
      
      Oui il doit encore y être, mon antivirus a supprimé le fichier dans le cache de mon navigateur...
# Mortel

Posté par dguihal le 13 septembre 2001 à 19:17. Évalué à 5.

Trop fort les scripts, ceci dit, heureusement qu'il y a des explications pour savoir ce que ca fait exactement. Un kamikaze pour tester si ces scripts fonctionnent correctement ?
- [^] # Re: Mortel
  
  Posté par un nain_connu le 13 septembre 2001 à 19:39. Évalué à 10.
  
  Si t'as peur, teste dans un environnement chrooté. Avec de la chance les scripts resteront en prison...
  - [^] # Re: Mortel
    
    Posté par gle le 14 septembre 2001 à 10:01. Évalué à 2.
    
    Je pense pas qu'un chroot te protègera beaucoup vu que le script doit tourner en root, et qu'il tripatouille les devices.
    Même dans un chroot, tu as accès à l'ensemble du disque dur si tu as accès à dev/hdX.
    - [^] # Re: Mortel
      
      Posté par un nain_connu le 14 septembre 2001 à 10:28. Évalué à 2.
      
      J'ai pas vu de script qui "tripatouillait" les dev, juste un petit /dev/stdout, qu'il est facile de créer dans le chroot sans mettre en péril l'intégralité du système.
      - [^] # Re: Mortel
        
        Posté par un nain_connu le 14 septembre 2001 à 10:38. Évalué à -1.
        
        Ooops j'ai dit une grosse connerie.
        J'avais pas du tout regardé comment marchait les scripts de leto, et effectivement une création de device est nécessaire au fonctionnement.
        
        Le chrootage ne servira pas à grand chose dans ce cas...
        
        [^] # Re: Mortel
        
        Posté par Leto le 14 septembre 2001 à 14:06. Évalué à 1.
        
        En tous cas, je confirme : en ce qui concerne la version utilisant des inodes, il n'y a *aucun* problème. Ca a été testé et approuvé sur plusieurs machines sans aucun problème.
        
        Pour que ce soit plus propre, il est mieux de créer un sous-répertoire à part, mais ce n'est pas du tout obligatoire. Et la commande ne fait que créer et/ou effacer des fichiers, même si ceux-ci sont assez ... particuliers !
        
        Voilà, bonne aspirine !
  - [^] # ou dans un vmware
    
    Posté par B. franck le 14 septembre 2001 à 10:01. Évalué à -1.
    
    :)
    - [^] # Re: ou dans un vmware
      
      Posté par Anonyme le 14 septembre 2001 à 13:22. Évalué à 0.
      
      Ou sur une VM d'IBM/3090 ou AS/400
# meuh ...

Posté par Remi Cellier le 13 septembre 2001 à 20:01. Évalué à 3.

Il me semble pas ( mais je peux me tromper ) qu'on nous ai prevenu de l'énoncé du prochain Defi'con ... pourtant je suis sûr que je me serai amusé comme un petit fou ( peut etre pas avec une solution viable ...).

A mon avis, il y avait un truc à faire avec un lancement de programme en mémoire, et de récupérer les donner avec un ps parsé ou faire joujou avec les ports réseau pour coder les informations ... ou ... ou ... ou ... bon c'est moins crade qu'eux ... encore que ;)

Est ce que la prochaine fois on pourra être prevenu ( même si la news est dans la section autre ?)
- [^] # erreur news précédente : je parlais du défi'con en cours
  
  Posté par Remi Cellier le 13 septembre 2001 à 20:02. Évalué à -1.
  
  tout est dans le titre
# une solution possible ... ?

Posté par AlphA le 13 septembre 2001 à 20:41. Évalué à 10.

Arf, excellente les solutions. Je suis en train de penser à une autre qui aurait pu être sympa : reprendre le principe des linux kernel root kit.
Ca consisterait en un prog écrit en C avec deux fonctions :
init_module et cleanup_module.

De plus, on rajoute une fonction lancée par init_module qui intercepte les appels à "/sbin/rmmod" pour remplacer cette fonction par un rmmod prenant un argument.

Puis, on modifie la fonction qui liste les modules de la même façon, de façon à ce que /proc/modules contiennent les infos
passées à insmod.
Pour rajouter quelqu'un : la page man de insmod nous montre
que l'on peut passer des arguments lorsque l'on charge le module. Donc, un petit (en root) :
insmod LKM_agenda num=XXXXXXXX name="toto"
pemettrait de faire une entrée dans l'agenda.

Pour récupérer une info :
rmmod LKM_agenda nom (c'est notre rmmod modifié).

Pour lister les infos :
cat /proc/modules | grep "ce_qu'on_veut".

Et voila !
P.S.: c'est presque plus propre que les solutions proposées :)
- [^] # Re: une solution possible ... ?
  
  Posté par Olivier M. le 13 septembre 2001 à 22:55. Évalué à 3.
  
  Superbe. Dommage que cela doive être en shell...
  - [^] # Re: une solution possible ... ?
    
    Posté par AlphA le 14 septembre 2001 à 09:33. Évalué à 1.
    
    Effectivement, il est indiqué qu'il faut utiliser les commandes de base.
    
    Damned. Bon, une solution :
    inclure 2 choses dans un script shell :
    le code asm obtenu avec gcc -S, que l'on extrait du script shell avec dd if/of/bs/skip
    un compilateur C écrit en sh : ftp://linux01.gwdg.de/pub/cLIeNUX/interim/shasm.TGZ(...) que l'on extrait de la même façon.
    Puis on passe le .s extrait à l'assembleur extrait et hop,
    on récupère le module et l'on revient à la solution.
# A du mal à comprendre

Posté par harbort le 13 septembre 2001 à 23:19. Évalué à 1.

Quelqu'un a-t-il compris ce que trafficait vraiment manu avec les fichiers binaires ?
Bon, il modifie la taille, mais sa ligne est tellement compliquée que c'est un peu trop difficile pour moi là !
- [^] # Re: A du mal à comprendre
  
  Posté par Antoine Labour le 14 septembre 2001 à 08:43. Évalué à 10.
  
  il rajoute des lignes du type
  #|prenom|nom|telephone| à la fin des éxécutables pris au pif dans le répertoire donné.
  Si les "binaires" sont des scripts shell (ou perl), les lignes sont comprises comme des commentaires, et si ce sont des éxécutables ELF, les lignes sont purement ignorées (tu peux ajouter du padding arbitraire à la fin des ELF)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.