-[ Comment pieger un transfer Zmodem ]- ../ ou : Le NO-RATIO sur tous les boards du monde \.. ##[% Par Day of July %]## [((-----------------------------------------------------------------------))] LES INFORMATIONS CI DESSOUS SONT DONNEES A TITRE INDICATIF UNIQUEMENT, ET AFIN DE MIEUX COMPRENDRE LES TECHNIQUES DE COMMUNICATION, EN AUCUN CAS L'AUTEUR N'INCITE QUI QUE CE SOIT A UTILISER CE SYSTEME SUR DES SERVEURS COMMERCIAUX. CECI CONSITUERAIT UN VOL QUALIFI ALORS, NE LE FAITES PAS ! [((-----------------------------------------------------------------------))] :) Bon, ca fait longtemps qu'on te bouscule avec le terme "Hacking" T'es ok de ton cot‚ mais percer des systemes UNIX tu trouves que c'est pas vraiment a ta portee... Bon alors je vais te proposer un petit expos‚ sur la (une des) maniere(s) de pieger un zmodem... ca devrait te faire plaisir, toi qui passe ton temps a pomper sur le board warez local et qui a tant de mal a trouver quoi envoyer en retour... Bon, le but de la maneuvre est de faire croire au Zmodem distant que le transfert a foir‚ alors qu'il a parfaitement reussi... le fichier recu dormant bien sagement dans ton repertoire DOWNLOAD\ au moment ou tu vois sur ton ecran la phrase magique "Transfer aborted" :)) La technique en elle mˆme n'est pas tres compliqu‚e mais demande une connaissance minimum du principe de fonctionnment d'un protocol de transfer... en l'occurence le Zmodem puisqu'etant devenu un standart et pouvant etre utilis‚ sur quasiment 100% des boards dans le monde, il va constituer notre cible de choix... Petit rappel rapide du mode de fonctionnement du protocol Zmodem : Le zmodem (comme la quasi totalit‚ des protocols existants) marche sur le principe du "Receiver driven"... ce qui veut dire en gros que seul le Zmodem receveur (on va l'appeler le receiver) sera a mˆme de detecter les erreurs, d'envoyer les ordres de repositionnement et de renvoi des paquets erron‚s... le Zmodem expediteur (on va l'appeler le sender) ne se chargera que de la ligne de Flow Control, afin de ne pas surcharger les buffers... Voici en gros le schema de transaction d'un transfer Zmodem : SENDER RECEIVER Init Init En attente du receiver Envoit "PRET" au sender Envoi un file header Recoit le file header, verifie si le fichier n'existe pas deja, le cas echeant demande un CRC du fichier pour decider de la suite (Crash recovery, skip file ou Overwrite file) Accepte le fichier Envoi du 1er ko Reception du 1er Ko Envoi du 2e Ko Reception du 2e Ko : : : : : : Envoi du dernier Ko Reception du dernier Ko Attente de fin de transfer Confirmation de fin de transfer Bon ca c'est la theorie... ce qu'il faut savoir dans la pratique c'est que comme on a affaire a un "Receiver Driven" protocol, le sender ne s'occupe de rien des que le transfer est commenc‚... c'est a dire qu'il envoi le 1er Ko, puis le 2e, le 3e etc...sans attendre de confirmation du receiver... la seule chose qui puisse ralentir le sender, c'est le Flow Control... Mais que se passe t'il quand une erreur de transfer survient ? eh bien c'est tres simple, le receiver envoi au sender une requette de repositionnement : un paquet ZRPOS... A partir de ce moment l…, le sender recommence a envoyer tous ses paquets a partir de la nouvelle position... En general cela marche tres bien... mais parfois, en raison de tres mauvaises qualit‚ de ligne ou d'autres raisons plus sombres, le repositionnement repet‚ du zmodem foire et les deux protocols ne se comprennent plus.. en general, le receiver le detecte et envoi un ZCAN pour interrompre le transfer (en fait un CTRL-X 4 fois)... On a donc un cot‚ (sender) qui envoi ses donn‚es a la suite, et un autre cot‚ receiver) qui recoit et le cas echeant repositionne le sender. C'est l… que l'on va faire nos propres modifications au Zmodem classique... du precedent schema, notre zmodem va devenir le suivant : SENDER RECEIVER Init Init En attente du receiver Envoit "PRET" au sender Envoi un file header Recoit le file header, verifie si le fichier n'existe pas deja, le cas echeant demande un CRC du fichier pour decider de la suite (Crash recovery, skip file ou Overwrite file) Accepte le fichier Envoi du 1er ko Reception du 1er Ko Envoi du 2e Ko Reception du 2e Ko : : : : : : Envoi du dernier Ko Reception du dernier Ko Attente de fin de transfer Envoi ZRPOS (simulation erreur) R‚envoi a partir du Nøieme Ko Envoi ZCAN - Interruption de transfer ! Ce qui va nous donner un joli moyen de pieger notre zmodem :) Le probleme de ce systeme est qu'on ne peut plus faire de transfers Batchs coz le ZCAN interromp la totalit‚ du transfer. Heureusement pour nous, l'inventeur du zmodem a pens‚ que certains auraient envie d'interrompre des Zmodems commenc‚ sans interrompre completement un transfer et a donc inclus a la petite liste de fonctionnalit‚es du Zmodem le ZSKIP qui est utilis‚ dans deux cas : Le premier lorsque le file header est envoy‚ et que le receiver decide si il doit oui ou non accpter le fichier, lorsque le fichier existe deja, le receiver envoi un ZSKIP qui averti le sender que l'on ne veut pas de ce fichier... Le deuxieme cas s'utilise exactement comme nous en avons besoin puisqu'il permet d'interrompre un fichier en cours de transfer et de passer au suivant (User skipped)... Donc, plutot que d'utiliser un ZCAN, nous allons utiliser un ZSKIP : SENDER RECEIVER Init Init En attente du receiver Envoit "PRET" au sender Envoi un file header Recoit le file header, verifie si le fichier n'existe pas deja, le cas echeant demande un CRC du fichier pour decider de la suite (Crash recovery, skip file ou Overwrite file) Accepte le fichier Envoi du 1er ko Reception du 1er Ko Envoi du 2e Ko Reception du 2e Ko : : : : : : Envoi du dernier Ko Reception du dernier Ko attente de fin de transfer Envoi ZRPOS (simulation erreur) R‚envoi a partir du Nøieme Ko Envoi ZSKIP - Passage au fichier suivant Voila c'est aussi simple que ca... :) Attention : ce systeme ne va pas blouzer pas 100% des Zmodems, mais un bon nombre tout de mˆme (GSZ/DSZ, IceZmodem, etc...) L'experience montre qu'une reposition au premier bloc du fichier garanti un bien meilleur resultat plutot qu'un repositionnement a l'avant dernier paquet par exemple (qui passe beaucoup plus innapercu mais bon... tant pis hein ? on le fera de nuit ;)) J'ai pour l'instant trouv‚ un seul Zmodem qui ne se fait pas blouzer par mon systeme, il s'agit de ZMSEND, le Zmodem par defaut de PCBoard... et aparemment, il s'agit tout simplement d'un BUG! En effet, ZMSEND considere tres souvent qu'un transfer s'est deroul‚ correctement alors qu'il a reelement foir‚... parfois il se bloque carrement pendant plus d'une minute ! De toute facon, ce Zmodem est tellement bugg‚, lent et moche que vous ne le trouverez que sur des boards de lamers... ;) La raison pour laquelle ce zmodem ne se fait pas prendre c'est que des l'instant ou il arrive en bout de course (tous les paquets on ete envoy‚s), il considere que le transfer est ok... c'est carrement cretin coz si une erreur survient entre le moment ou pcbsz est arriv‚ au bout et le moment ou le receiver a fini de recevoir, ben quequette, le transfer est consid‚r‚ comme bon... :( On pourra quand mˆme blouzer ces zmodems en envoyant un ZCAN plutot qu'un ZSKIP mais au prix d'un transfer non Batch... Pour ceux qui n'ont pas envie de coder leur zmodem, on peut trouver "HACKTiON ZMODEM" sur certains boards, code par votre serviteur, il permet de faire tout ce que j'ai expliqu‚ plus haut... Evidemment ca se diffuse pas terrible coz les sysops sont pas press‚s de diffuser des softs comme ca :) alors si vous avez envie d'avoir le votre, eh bien... cherchez ! ou codez le ! Beaucoup de sources Zmodem sont disponibles en freeware... un petit changement de rien du tout vous permettra d'ajouter notre petite option :) Bon leeching! ----------------------------------------------------------------------------- Note pour Worm : Yo man! ton txt sur la VMB de FT etait tres cool, et le texte de la fin tres juste, alors j'espere que tu ne m'en voudras pas, mais je crois que je vais faire un petit couper/coller :) vala... :) ----------------------------------------------------------------------------- Note : Le txt qui suit est (honteusement) pomp‚ sur la fin du txt de Worm sur une VMB de FT accessible en RP... Je l'ai recopi‚ car c'est ce ptit bout de txt qui m'a fait bouger le cul, et j'espere qu'il en sera de meme pour toi qui me lit... sache que ce que tu trouves insignifiant est peut etre tres interessant pour les autres... ----------------------------------------------------------------------------- Maintenant toi qui a lu ce texte, tu va te bouger le cul pour que tu nous fasse partager ce que tu a deja decouvert et ce que tu decouvrira ! Parce que la je commence un peu a en avoir marre de lire des txts qui parlent de hacker des 800 etc... Inutilisable en france !!! J'espere que la scene francaise va vraiment se develloper et que les hackers, les vrais ne soient plus les detenteurs d'un savoir non diffuse ! Je sais pour certains je ne suis qu'un lamer mais bon... j'essaie a mon niveau de faire partager mon peu (TRES peu) de connaissances. Mais...peu de connaissances + peu de connaissances...Ca commence a devenir quelque chose d'interessant non ? :) [DIFFUSER CE QUE VOUS SAVEZ] [LES VRAIS LAMERS SONT CEUX QUI NE DISENT RIEN] (C)95 Worm ;) ----------------------------------------------------------------------------- Pour me contacter: Bal DAY OF JULY sur "The DeadLine" - (+33-1)4648-6763 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAjBwKqoAAAEEANJ9KYDKoXaddNmIWgJDzsNgqGaDQFG4XpHvNTlhxLPww2oZ qcYhW3kvEwB4Iaz37EqTAb1TfK9x+UjyDUzKaj79f/suZnbVVQLeCrjUBpWOT0Oo zHWoF2S+l7U+pd7tiAydu2reDSjc+RMZdAjYYXhVzd241EYcoTjl6hfJwHdRAAUR tAtEYXkgb2YgSnVseQ== =7mdt -----END PGP PUBLIC KEY BLOCK----- Greets: Neuralien - Pour N0WAY 1, 2, 3 et peut etre un jour les suivants... New iD - je vais maintenant pouvoir respecter tes ratios avec ca! ;)) Worm - Cool tes txt... tres cool... ton initiative m'a plu et tu vois, je m'y met aussi, j'espere que c'est le genre de reactions que tu attendais, j'en espere de meme maintenant des autres... Many greets to you man... cool... tres cool... Le reste... j'en oublie tout le temps...