------------------------------------------------------------------------------- NoRoute #1 ¦ Recuperer des comptes PPP ¦ 4767 ¦ Hotcode ¦ NoRoute #1 ------------------------------------------------------------------------------- Comment recuperer des comptes PPP Par HoTCoDe ----------------------------------------- J'ai decouvert tout ce qui va suivre sous ma distrib Linux RedHat 4.0, mais je pense qu'elle doit marcher dans le cas d'autres distributions, voire meme avec d'autres UN*X. Cependant, j'ai constate que cela ne marchait visiblement pas pour MkLinux :( [Sorcery: Voui.. Tout depend du script de connection... =) Si chat est appele avec l'option -v lors de la connection, alors toutes ces infos sont loggees dans le fichier en question. Remarquez rien ne vous empeche de chopper le root et de lire le script de connection =)] -METHODE UN- Voila donc... Le probleme se situe au niveau des permissions du fichier /var/log/messages (ou /var/adm/log/messages, ca depend) qui est en world readable (o+r). PPP (ma version est la 2.2) notifie toutes ses actions durant la connexion, et si on regarde bien, on voit qu'il envoie au modem le numero de telephone du provider, le login et le password correspondant a l'account. Voici donc ce qui se passe chez moi... % cat /var/log/messages | grep "chat" (j'ai decoupe ici une seule sequence de connexion, il y en a plusieurs dizaines sinon... J'ai aussi modifie les infos, histoire de quand meme garder mon compte confidentiel :) Feb 9 20:23:40 HoTMaCHiNe chat[924]: expect (OK) Feb 9 20:23:40 HoTMaCHiNe chat[924]: ^M Feb 9 20:23:40 HoTMaCHiNe chat[924]: ATH0^M^M Feb 9 20:23:40 HoTMaCHiNe chat[924]: OK -- got it 1> Feb 9 20:23:40 HoTMaCHiNe chat[924]: send (ATDT0140354512^M) Feb 9 20:23:40 HoTMaCHiNe chat[924]: expect (CONNECT) Feb 9 20:23:40 HoTMaCHiNe chat[924]: ^M Feb 9 20:24:01 HoTMaCHiNe chat[924]: ATDT0140354512^M^M Feb 9 20:24:01 HoTMaCHiNe chat[924]: CONNECT -- got it Feb 9 20:24:01 HoTMaCHiNe chat[924]: send (^M) Feb 9 20:24:01 HoTMaCHiNe chat[924]: expect (ogin:) Feb 9 20:24:01 HoTMaCHiNe chat[924]: 115200^M Feb 9 20:24:11 HoTMaCHiNe chat[924]: ^M Feb 9 20:24:11 HoTMaCHiNe chat[924]: Login: -- got it 2> Feb 9 20:24:11 HoTMaCHiNe chat[924]: send (foo^M) Feb 9 20:24:12 HoTMaCHiNe chat[924]: expect (assword:) Feb 9 20:24:12 HoTMaCHiNe chat[924]: foo^M Feb 9 20:24:12 HoTMaCHiNe chat[924]: Password: -- got it 3> Feb 9 20:24:12 HoTMaCHiNe chat[924]: send (bar^M) On voit donc en (1) le numero de telephone envoye (0140354512). En (2), le login (ici, "foo") et enfin en (3) le pass correspondant, "bar". C'est aussi con que ca ! On peut egalement chercher ces infos avec un % cat /var/log/messages | grep "send" Et on verra toutes les informations envoyees au modem. -METHODE DEUX- La methode deux est plus hypothetique, mais jouable quand meme. J'ai trouve des becanes ou elle fonctionnait... Hehe ! Il faut deja trouver les scripts de connexions PPP (ppp-on en general) a l' aide d'un `find -name "ppp-on" -print'. Sinon, il arrive qu'il soit dans /etc/ppp ou dans /sbin (ou encore /usr/sbin). Enfin bon, je vais pas vous macher tout le travail quand meme ! Il suffit des les recuperer, et si votre cerval fonctionne correctement, vous aurez compris que toutes les informations de connexion sont a l'interieur, vu que c'est un script. Donc, vous le dissequez, et la, Oh joie... TELEPHONE=0140354512 # The telephone number for the connection ACCOUNT=foo # The account name for logon (as in 'George Burns') PASSWORD=bar # The password for this account (and 'Gracie Allen') Je vous ai mis ici les scripts d'exemple que j'ai trouve dans `/usr/doc/ppp/scripts', et que j'utilise pour me connecter, mais je me doute que vous en avez plutot rien a cirer :) -CONCLUSiON- Voila deux methodes tres simples a mettre en oeuvre, qui ne coutent rien et qui permettent de recuperer facilement des comptes PPP, ce qui est toujours utile quand on veut hacker sans trop se faire reperer, en utilisant la connexion d'un illustre inconnu. Enjoy diz phile, continue loving Bernard Menez and have phun ! [Nota deux: =) Dans le deuxieme cas il faut etre root sur la machine en general pour avoir acces a ce script ultra confidentiel... Ces deux methodes vous permettent de chopper des logins dans tout cybercafe connecte par telephone au net et tournant sous linux... (pratique pour gerer les abos...)] ------------------------------------------------------------------------------- NoRoute #1 ¦ TCP/IP ¦ 4768 ¦ Kewl ¦ NoRoute #1 ------------------------------------------------------------------------------- --== Ben kesako c le tcpip ??? ==-- Intro. ===== Hello tout le monde! Tout le monde entend parler de TCPIP partout, donc j'y met mon grain de sel aussi... (attention faut avoir ca en tete pour capter des choses ki vont sortir dans certains numeros de Norout) En fait, c un protocole qui a ete cree pour pouvoir partager des ressources a travers un reseau. Son interet est qu'il peut etre utilise par tout type de machine (Sparc, Alpha, Silicon, etc...) et tout type de support (X25, Hyperchannel, PPP, FDDI, Ultranet, ...). Nous verrons l'exemple d'utilisation d'un pc sous Linux avec un support ethernet. Protocoles ========== Ben en fait, on dit toujours TCP/IP mais en fait les protocoles TCP et IP sont les plus utilises, si c'etait ICMP et UDP p'etre kon appellerai ca ICMP/UDP :o) En fait c pas par hasard, c car il existe une hierarchie entre les protocoles.. dont voila un petit dessin ki montre ke les RAW sockets permettent l'interfacage a la couche IP, ceux du type DGRAM a UDP, ainsi que ceux du type STREAM a la couche TCP. |------------------|--------------| Les protocoles utilises sur Internet | TELNET RWHO | RUSERS | sont bien decrits par les RFC (Requests | FTP TFTP | RSTAT | for Documents), disponibles sur les | | | protocoles sur la gauche de ce texte, | | | et quand on dit pas mal, c pas faux :o) | RLOGIN TALK | WALL | ftp.ibp.fr/pub/rfc, il decrivent avec | RSH DNS | RQUOTA | pas mal de precision. Donc je vais | | | decrires maintenant les principaux | | | protocoles .. | REXEC SMNP | NIS | | SMTP | NFS | 1. IP | |--------------| Ben c'est celui a qui on doit le | | | routage et la fragmentation des | | | paquets, il est sans connection. | | XDR | Quand on dit routage, en fait on va | | | dir que son boulot est de trouver | |--------------| trouver le routeur qu'il faut pour | | | atteindre la destination, alors | | | c'est grace a lui que la bonne | | RPC | interface est choisie. Donc aussi | | | il gere la fragmentation des |---------------------------------| paquets, ben ouais il faut bien, car | | les protocoles superieurs (TCP/UDP) | | sont coupes en fragments IP de tailles | Socket STREAM Socket DGRAM | maximale qui depend de l'interface | | utilisee. En reception, IP reassemble |---------------------------------| les fragments. Cette taille depend | | (pc de cod4 plante) du support utilise | RCP UDP | (1500 octets sur l'ethernet et 4352 | | sur une fibre optique FDDI). |---------------------------------| | Interface RAW Socket | 2. ARP et RARP |---------------------------------| ARP = Adress Resolution Protocol, | | il permet de faire une correspondance | | entre une adresse IP de 4 octets | ARP ICMP <------> IP | (A.B.C.D) vers une forme ethernet | | en 6 octets (A:B:C:D:E:F) et de savoir |---------------------------------| quelle carte est sur quelle IP. | | RARP, (Reverse ARP), ben soyons pas | ETHERNET ISO 8802.3 X25-3 | bete, tout le monde a devine son | | utilite ! ----------------------------------- 3. ICMP (cod4 a fait un restore de copine, mouahahahahha top).. Bon disons plutot que ICMP c Internet Control Message Protocol. En bref il permet d'analyser les blemes de communications. Grace a lui, on peut aussi savoir si une machine est en marche (ex : ping -s 65000 -f warez.2-go.com). Encore, un routeur peut donner des directives a une machine pour lui donner une meilleure route pour atteindre une machine (ICMP redirect). ICMP c le protocole regged en tant ke # 1. 4. UDP C'est le protocole numero 17. Il est oriente datagramme qui achemine les messages tels quels, sans ouverture de connection, et sans garantie de port egalement. Il peut etre utilise en point a point (vers un seul destinataire), ou en mode diffusion. (arf le pc de cod4 lui dit kil a un 386sx) En mode diffusion, UDP est utilise par talkd, tftpd et encore NFS. 5. TCP TCP = Transmission Control Protocol, il est oriente connexion, dont la vie est l'etablissement de la connection, la transmission des donnees et enfin la liberation de la connection. TCP ramene les segments sans decoupage ni regroupement, et garantie le bon port. En cas d'erreur de transmission, ben c'est tout simplement retransmi :), biensur grace a un controle de flux. TCP est utilise par les protocoles ftp, telnet, rlogin, lpd, X11. TCP est le protocole #6. Le niveau TCP ============= Donc TCP est le responsable de la fracture de messages en datagrammes, les reassemblant a l'autre bout, dans le meme ordre. IP est le responsable du routage de chaque datagramme. On pourrait dire que TCP fait tout le travail, dans les petits reseaux cela est vrai, mais sur Internet, envoyer un datagramme vers une autre machine n'est pas un simple boulot. Une connection peut forcer le datagramme a passer a travers toute une serie de reseaux, tels qu'une ligne Serie a 56 kbit/s, ensuite un reseau ethernet pour enfin arriver sur une FDDI, etc.. Garder la piste du chemin vers toutes les destinations et transporter les incompatibilites de differents medias de transport sont un travail pas tres simple... Notons que l'interface entre TCP et IP est quand meme assez simple. TCP fait simplement un datagramme avec une destination. Il ce peut (surement meme), qu'il manque quelque chose ici. On a tous parle d'adresses Internet, mais jamais comment gerer des multiples connections vers un systeme donne. Clairement, ca suffit pas de faire des datagrammes vers la bonne destination. TCP doit savoir quel datagramme fait parti ce cette connection (merci cod4 pour cette phrase). Cette tache est le demultiplexage. En fait, il y a toute une serie de de demultiplexages qui vont sur TCP/IP. Les informations dont on a besoin pour ce demultiplexage sont contenues dans des series de headers. Un header est simplement quelques tout petit octets places au debut de chaque datagramme par quelques protocoles dans le but de garder une piste de lui. C'est un peu comme mettre une lettre dans une enveloppe et mettre une adresse a l'exterieur de l'enveloppe. Sauf avec les reseaux modernes cela arrive souvent. C'est comme quand tu veux mettre une lettre a l'interieur d'une enveloppe, ta secretaire la met dans quelque chose plus gros qu'une enveloppe, puis le service du courier met encore ce truc plus gros qu'une enveloppe dans un encore plus gros.. Voici un appercu des headers qui font coller un message ki passe a travers un reseau TCP/IP : On commence par une simple donnee, par exemple tu essaies (oui je dis bien essaies :>) d'envoyer un fichier vers un autre ordinateur : ................................................................... TCP lui casse ca en morceaux dont il peut s'occuper. (biensur pour pouvoir le faire, il doit savoir quelle taille maximum un datagramme peut avoir sur ton type de reseau) .... .... .... .... .... .... .... .... .... .... TCP met un header au debut de chaque datagramme. Ce header contient au moins 20 octets, mais les plus importants sont les numeros de ports d'emission et de destination et le sequence number. Les numeros de port sont utilises pour garder une piste de differentes conversations. Suppose voir que trois personnes transferent des fichiers. Ton TCP peut etre leur donnera les ports numero 1000, 1001 et 1002 pour ces transferts. Quand tu envoies un datagramme, ca devient le port de source, puisque tu es sur la source du datagramme. Et biensur TCP de l'autre extremite a assigne un port des siens pour la conversation. Ton TCP doit aussi savoir quel port est utilise sur l'autre extreme. (Il le trouve quand la communication commence.) Il envoie ca dans le "champ" port de destination. Biensur si de l'autre cote est rerenvoye vers toi, les ports de source et de destination seront inverses, ensuite il sera le source et toi tu seras la destination. Chaque datagramme a un sequence number. Ceci est utilise alors l'autre fin afin d'etre sur que la datagramme a ete recu dans le bon ordre, et qu'en en a loupe aucun. TCP ne numerote pas les datagrammes (bon cod4 arretes un peu l'irc ca rend fou :), mais les octets. Donc s'il y a 500 octets de donnees dans chaque datagramme, le premier sera "numerote" 0, le second 500, le suivant 1000, le suivant 1500, etc........ Finalement, on va parler du Checksum (somme de controle). C'est un nombre qui est calcule en ajoutant tout les octets du datagramme. Le resultat est mit dans le header. TCP de l'autre cote verifie ce checksum aussi, et si ils ne sont pas d'accord, c'est que kelke chose de mauvais est apparu lors de la transmission, et il est jete au loin. Voila a quoi ressemble un petit datagramme : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Source | Port de Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | donnees ... prochains 500 octets | | ...... | Si on abregeait l'entete TCP par "T", le fichier ressemblairait a ceci : T.... T.... T.... T.... T.... T.... T.... Tu noteras qu'il y a des choses dont j'ai pas parle dans le header.. Ils sont generalement invoques avec la gestion de la connection. Pour etre sur qu'un datagramme est arrive a sa destination, le receveur as a renvoyer un "acknowledgement". C'est un datagramme dans lequel le champ "Acknowledgement number" est rempli. Par exemple, envoyer un paquet avec un acknowledgement de 1500 indique que tu as recupere toutes les donnees jusqu'a 1500. Si l'envoyeur ne recoit pas un acknowledgement dans un delais raisonnable, il renvoie les donnees. La fenetre (Window) est utilisee pour controler combien de donnees peuvent transiter a un moment. Il n'est pas pratique d'attendre que chaque datagramme soit acknowledged avant d'envoyer le suivant. Et aussi faut dire que ca ralentisserait, et pas qu'un peu, n'est ce pas sorcery ? D'autre part, tu ne peux pas que envoyer, ou un ordinateur rapide pourrait subir des indigestions a un plus petit qui recoit les donnees. Alors il y a un champ "Window", et des qu'un ordinateur a envoye des donnees, ce champ diminue, et s'il est vide, il arrete d'envoyer. Quand le recepteur recoit les donnees, il augmente sa fenetre (Window), en indiquant qu'il est pret a recevoir plus de donnees. Le niveau IP ============ TCP envoie chaqun de ces datagrammes a la couche IP. Biensur on doit dire a IP l'adresse de la machine de l'autre bout. Note quand meme que c'est tout ce qu'IP est concerne de faire. Il s'en fiches de ce qu'il y a dans le datagramme, ou meme dans le header TCP. Son boulot est simplement de trouver le chemin pour que le datagramme arrive jusqu'a sa destination. Pour permettre aux routeurs intermediaires d'envoyer le datagramme, il ajoute son propre header. La principale chose qu'on y trouve sont les IPs de source et de destination (adresses 32 bit, comme 128.6.4.194), le numero du protocole, et un autre cheksum. L'adresse source est simplement l'adresse de ta machine, c'est necessaire pour que l'autre sache d'ou ca vient. L'adresse de la machine de destination est l'adresse de l'autre machine, ce qui est necessaire aux routeurs entre pour connaitre ou tu veux que le datagramme ailles. En debit du fait que le trafic IP utilise TCP, il y a d'autres protocoles qui peuvent etre utilises avec IP, donc il faut dire a IP quel protocole il faut envoyer sur le datagramme. Finalement, le checksum permettra a IP de l'autre cote de verifier que le header n'a pas etre bousille lors du voyage. Note aussi que TCP et IP ont des checksums independants. IP a besoin d'etre capable de verifier que le header (entete) n'a pas etre endommage durant le transport, sinon il pourrait envoyer un message a un mauvais endroit. Pour des raisons que je ne vais pas expliquer, il est plus efficace et plus sur d'avoir TCP qui calcule son cheksum separement pour le header TCP et les donnees TCP. Quand IP a mit son header, voila a quoi le message ressemble : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP header, then your data ...... | | | Si on represente le header IP par un "I", ton fichier ressemblerait a ca : IT.... IT.... IT.... IT.... IT.... IT.... IT.... (Bon CoD4 est banni de #france, mort de rire !! :)) Aussi, le header contient des autres champs sont j'ai pas cause avant.. Le "flag" et "Fragment Offset" sont utilises pour garder une piste des pieces quand un datagramme doit merder. Ca peut arriver quand les datagrammes sont envoyes a travers un reseau pour lequel ils sont trop gros. La duree de vie "Time to Live" est un numero qui decroit lorsque que le datagramme passe a travers un systeme. Quand il devient nul, il datagramme est detruit. Ceci est fait en cas de deplacement en boucle du paquet. A ce point, c'est possible qu'il y ait plus de headers necessaires, si ton ordinateur est parfois connecte via une ligne modem vers l'ordinateur de destination, ou via un routeur, il pourrait simplement envoyer les datagrammes hors de la ligne.. Descriptions generales ====================== ben ouais, si la c'est pas clair, relit depuis le debut :).. Bon aller rapidement.. TCP/IP est une serie de protocoles. On va voir un petit exemple plutot que d'expliquer encore la meme chose. Avant tout, il y a un mail. Donc des commandes a envoyer vers une autre machine, par exemple les commandes qui disent qui est l'envoyeur, a ki il va et le texte du message. Ben euh, ce protocole n'assume pas le chat entre les 2 machines ? Et ben, c'est que le Mail, comme un autre protocole utilise sur le net, utilise simplement des commandes et de messages a etre envoyes. Il est concu pour etre utilise avec TCP et IP, et TCP est responsable de faire passer les commandes vers l'autre bout, puis IP de les envoyer... voila en bref. (compris maintenant ???) Dit tu aimes le mail ? Sockets et Applications ======================= Avant on a cause de la decomposition des donnees en paquets, pour etre envoye ailleurs, et reassemble de l'autre cote. Avant de continuer, je vais boire un coup, puis donner quelques detail sur des applications. Suppose voir que tu veuilles envoyer un fichier a ton pote qui est sur la machine dont l'adresse est 128.6.4.7. Pour commencer le processus, tu dois savoir plus qu'une adresse internet. Tu dois te connecter sur un serveur FTP a l'autre bout. En general, les programmes reseau sont specialises dans ce type de boulot. La plupart des machines ont plein de programmes qui tournent pour gerer le transfert de fichiers, le login a distance, courier, serveur fsp warez (arf), etc... Enfin quand tu te connectes sur 128.6.4.7, tu dois dire que tu veux parler au serveur FTP. Ce qui est fait en avant des sockets connus sur chaque serveur. Ye Rappelle que TCP utilise le numero de port pour garder une trace des conversations en cours. Les programmes de l'utilisateur utilisent normalement plus ou moins de ports au hasard, bienque les ports specifiques sont assignes pour les programmes qui attendent une demande particuliere. Par exemple. si tu veux envoyer un fichier, tu commences a lancer ftp, il ouvriera une connection sur un port au hasard, par exemple 1234, pour le port utilise a l'autre bout. Enfin il specifiera le port 21 de l'autre cote, qui est le port officiel des serveurs ftp. Note quand meme qu'il y a deux differents programmes en cours.. Tu lances ftp de ton cote, Il y a un programme dont le but est d'accepter des commandes depuis ton terminal et qui les balances de l'autre cote, ce programme qui te cause c'est le serveur FTP. Il a ete designe pour accepter des commandes depuis la connection reseau. Aussi une connection est decrite par ces 4 nombres : Addresses Internet Ports TCP connection 128.6.4.194, 128.6.4.7 1234, 21 ||333|o|| | | | O - O | | I | <--- CoD4 | \___/ | |_______| Et ben donc on peut dire FTP c nul a chier !! Il a besoin de deux connections, il commence comme le mail, et on lui dit "connecte moi sous tel utilisateur", "tiens voila mon mot de passe", "envoie moi ce fichier avec ce nom"... Et des que tout ca est fait, une seconde connection est ouverte pour les donnees seules. Il serait certainement possible d'envoyer les donnees sur la meme connection, comme SMTP fait, mais bon c comme ca et c tout et arrete de poser des questions ! :). En fait je vais dire plutot c car les transferts de files sont souvent long (merci a billou pour son gros win97 que tout le monde s'envoie en ftp et sature notre pov'rezo). Ceux qui ont cree le ftp ont voulu permettre a l'utilisateur de permettre d'envoyer des commandes pendant le transfert, tel que abandonner le transfert en cours, arf.. D'autres protocoles utilisent un principe plus ou moins similaire.. Et si ca te passionne, matte toujours les RFCs... Le rewtage facile (routage) =========================== Bon donc c'est IP qui est responsable du routage. Et pour plus d'infos voir http://www.cisco.com/ si tu as besoin d'un routeur par exemple :) (non je ne fais poa de pub!) Adresses Internet (petite notion) ================= Donc les adresses internet sont codees sur 32 bits, ecrites sous la forme de 4 octets (en decimal), par ex. 128.6.4.7. Actuellement il y a 3 types d'adresses. Le probleme est que l'adresse doit indiquer a la fois le reseau ainsi que la machine a l'interieur du reseau. Donc on a les classes IP. La classe A, pour les reseaux immenses, tels que Arpanet, cette classe est limite a 126 reseaux au total. Pour les gros reseaux, il y a la classe B, qui correspond a tous les reseaux entre 128.1 et 191.254, ce qui permet d'adresses le reseau local sur 16 bits, donc d'avoir 64516 machines, ce qui suffit pour la plupart des organisations, en si ca ne suffit pas, on peut avoir plusieurs classes B :). Finalement, la classe C, dont la partie reseau est codee sur 3 octets, de 192.1.1 et 223.254.254, permet d'avoir 254 machines sur chaque reseau, mais on peut avoir beaucoup de tels reseaux. Les adresses au dela de 223 sont reservees pour un futur usage, en tant que classes D et E, qui ne sont pas encore definies (enfin p'etre..) Quelques valeurs speciales qui sont reservees dans les adresses IP, 0 et 255 qui ont des significations particulieres, 0 pour les machines qui ne connaissent pas leur adresses. 255 est utilise pour le broadcast, qui est un message que tu veux que chaque machine sur le reseau voie, c'est utilise par exemple quand tu ne sais pas a qui parler, par exemple suppose que tu dois trouver l'adresse internet d'une machine a partir de son nom. Parfois tu ne sais pas quelle est l'adresse du serveur de noms le plus proche. Dans ce cas, p'etre tu envoie une requete au broadcast. A moins que ce soit une universite martienne, t'auras pas de machines en 255, arf... To be continued.. =================