Newsgroup: it.comp.programmare.win32
Titolo: E' possibile fare un programma del genere ?

La situazione e' questa:
Un server e un client che comunicano inviandosi pacchetti che supponiamo di
forma nota,una volta che ho scoperto su quale porta il client lavora , posso
fare un programma che intercetti i pacchetti mandati dal server, li
modifichi e li passi al client modificati?
Attendo suggerimenti, indicazioni, links..sorgenti o qualunque altra cosa
utile!
Vi prego di rispondermi via mail !!!!
--
Visita la mia pagina personale:
 
http://members.xoom.it/Ake
*** grafica - ingegneria - midi - humour ***
*** abandonware - emulatori - MUD  ****
Il Covo di Ake ora e' anche senza fili,
visitalo con il tuo cellulare WAP a:
 
tagtag.com/ake


Puo farlo realizzando un programma "filtro" che simuli il server  
intercettando la connessione (TCP) o i pacchetti (se il servizio non si 
basa su una connessione permanente). 
Il client si collegherà al tuo filtro-server e da questo avrai la 
possibilità di tracciare le varie request ed eventualmente modificarle 
(senza dover reimplementare tutto lo strato server).
Ovviamente le cose si complicano se il tutto deve essere fatto senza che 
server e client se ne accorgano (ma non credo fosse questa la tua 
intenzione...).
Se vuoi fare queste operazioni su un server WEB IIS, considera l'ipotesi di 
realizzare un filtro ISAPI.
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)

> 
VM> Puo farlo realizzando un programma "filtro" che simuli il server  
VM> intercettando la connessione (TCP) o i pacchetti (se il servizio non si 
VM> basa su una connessione permanente). 
Scusa, ma il  server originale si è già accapparrato la  porta ed è in
listen... Dovresti  spostarlo dalla well  known port e mettere  il tuo
filtro al  suo posto (è  la tecnica usata  da alcuni antivirus  che si
mettono a monte di Sendmail, sulla porta 25 risponde l'antivirus e non
sendmail) ma  il server perde l'informazione sull'IP  del chiamante in
quanto lui  si trova  una richiesta di  servizio che di  solito arriva
dall'interfaccia di loopback.
Una tecnica più  fetida consiste nell'alterare il routing  (the man in
the middle...), ma questo non è usare un programma filtro...
\begin{avviso}
 
Attenzione: Leggersi lo header riguardo al mio e-mail!
Warning: read header for infos about my e-mail.
\end{avviso}
+----------------------------------------------------------------+
| Gian Uberto Lauri * "So, are you working on fixing that bug    |
| 
sa...@eng.it
      *  *now* or leaving it until later ?" - YES  |
+----------------------------------------------------------------+

 intenzione...).
Invece si, cioe' il filtro dovrebbe essere trasparente al server, quindi in
pratica dovrebbe comportarsi come server nei confronti del vero client e
come client nei confronti del vero server?



Comunque devi avere accesso a un componente "critico" della rete.



Se deve essere trasparente solo al server, puoi far "puntare" i tuoi client 
al filtro, spostando la porta TCP/IP del server "vero" e sostituendola con 
quella del tuo filtro, che redirigerà poi le chiamate al server (ovviamente 
il tutto funziona se il server non si basa sull'indirizzo IP del 
client...). 
Se non puoi spostare la porta di rx del server, sei costretto a modificare 
le impostazioni dei client e, se questo non è possibile, utilizzare due PC 
(uno per il filtro e una per il server).
Se non puoi cambiare nessuno dei fattori, puoi mettere un PC con il 
"filtro" al posto del server originale e collegare lo stesso in una rete 
locale con il vecchio server. In questo modo il "filtro" potrà rigirare al 
server i pacchetti di rete ricevuti dai client (senza alterarne l'indirizzo 
IP), ricevere le risposte (a livello di pacchetti di rete) e "rimbalzarle" 
(dopo le eventuali modifiche) ai client. 
In questo caso l'operazione si complica di parecchio perchè dovresti andare 
a interfacciarti direttamente con i driver di rete...
Se non hai accesso nè al server nè ai client, ci sono buone possibilità che 
quello che vuoi fare sia illegale :) o (più probabile) che io non abbia 
capito un fico secco del problema che descrivi...


> 
VM> Comunque devi avere accesso a un componente "critico" della rete.
Decisously :) critico.


 come client nei confronti del vero server?
E tutto cio` dovresti farlo da una terza macchina, sulla stessa rete ma
distinta dalle macchine del client e del server? Se la rete e` una
normale Ethernet al massimo puoi "sniffare" i pacchetti, ma di certo non
li puoi fisicamente rimuovere e sostituire (forse potrebbe funzionare in
una rete ad anello come la Token Ring).
L'unica soluzione e` quella gia` detta da Gian Umberto, ossia ingannare
il server, alterargli le tabelle di routing (magari facendo qualche
giochino sporco con ARP/RARP) e farsi spedire i pacchetti per poi
rispedirli modificati al client, "spoofando" il proprio indirizzo IP.
---
Bye! Lorenzo Lutti
http://antani.virtualave.net/

Uhm mi sembra tutto abbastanza complicato...
In fondo il filtro che voglio fare io e' una specie di firewall, una
barriera che riceve dei pacchetti, li modifica e li spedisce al destinatario
originale..un programmino che intercetta questi pacchetti e me li mostra
gia' ce l'ho, me ne servirebbe uno che pero' mi permetta anche di alterarli
e rispedirli, non c'e' niente di simile in giro ?
Lorenzo Lutti <lorenz...@DOHtiscalinet.it> wrote in message
M2fT5.27378$FV2.8...@news.infostrada.it...


>>>>> "LL" == Lorenzo Lutti <lorenz...@DOHtiscalinet.it> writes:
LL> L'unica soluzione e` quella gia` detta da Gian Umberto, ossia ingannare
Gian Uberto, scusa ma ci tengo alla mancanza di quella m
LL> il server, alterargli le tabelle di routing (magari facendo qualche
LL> giochino sporco con ARP/RARP) e farsi spedire i pacchetti per poi
LL> rispedirli modificati al client, "spoofando" il proprio indirizzo IP.
Una cosa che si puň fare, se  non si puň intervenire sul server (che č
una versione minimale del man in the middle) č mettere una macchina in 
mezzo ovvero
	|
	R
	E--[Man in the middle]---[server originale]
	T
	E
	|
su  questa macchina  o hai  un sistema  operativo opensource(*)  e gli
skill per alterare il codice del kernel che si occupa di routing o piů
facilmente fai girare un programma  che sul lato rete si comporta come
un server e verso un server si comporta come un client.
(*) piů che  sul driver della scheda credo  si debba intervenire sullo
stack TCP/IP,  in particolare sulla  parte dedicata alla  gestione del
routing su piů schede...
Per quel poco che ne so io di spoofing (ho letto una volta un articolo
e  basta)  mi  pare  si  tratti  di una  tecnica  che  si  basa  molto
"sull'intuito"  in quanto  si dialoga  con un  host senza  sentirne le
risposte. D'altro canto  nel caso di un man-in-the-middle  ci si trova
sulla route  dei pacchetti indirizzati all'host  impersonato, quindi č
possibile lavorarci sopra, ma a livello di kernel.


 ha scritto nel messaggio
news:u3dghlrfd.fsf@MERCURIO_115.eng.it...

Alla fine della fiera io patcherei il client su un'altra porta e tanti
saluti. Se si conosce la porta del client l'operazione e' piuttosto
semplice con un buon disassemblatore.
Ciao.
Il Michett@
--

 writes:
IM> Alla fine della fiera io patcherei il client su un'altra porta e tanti
Intendevi il server  ? Che sappia io il client si  alloca un socket di
numero generalmente maggiore di 1024 poi contatta il server sulla well
known port, in alcuni protocolli  riceve dal server un nuovo numero di
porta su cui continuare il discorso con una nuova connessione...





 originale..
Allora devi spiegare meglio come sono collegati il server e il client e
in quale macchina dovrebbe girare il tuo programma, perche` non l'ho
capito.


 routing su piů schede...
Beh, sotto a Windows c'e` un modo abbastanza semplificato per farlo:
anziche` agire sul routing, ti puoi "mangiare" del tutto i pacchetti che
ti arrivano [1] e poi generarne altri ex-novo con le caratteristiche che
vuoi [2].
[1] Basta installare un packet filter driver, col quale puoi segare
tranquillamente qualsiasi pacchetto dopo averlo letto. I firewall per
Windows come ZoneAlarm funzionano cosi`.
[2] Finalmente anche sotto a Windows si possono spedire pacchetti raw,
arrivando a mentire anche sul MAC address, quindi puoi spoofare a piu`
non posso. ;-)


 saluti.
Il fatto e` che l'utente che ha generato il thread non ha specificato
quale "livello di controllo" abbia sulla macchina server, sulla client e
sulla rete in cui si trovano. Ripeto, servono piu` informazioni. :)


Dunque: non ho nessun accesso al server che e' remoto e collocato non so
dove.
Ho a disposizione il client (eseguibile, senza sorgenti), e nessuna rete
locale con cui  usare una specie di  pc-filtro come veniva suggerito.
Mi e' sembrato interessante il packet filter driver di cui qualcuno ha
parlato, mi sembra fatto al caso mio...posso avere qualche informazione in
piu'? (dove si trova, quale conviene usare etc...)
Lorenzo Lutti <lorenz...@DOHtiscalinet.it> wrote in message
kaDT5.35762$FV2.1...@news.infostrada.it...


 qualcuno ha parlato
Forse in questo caso e` eccessivo usarlo. Inoltre di solito sono a
pagamento (ad esempio ZoneAlarm ne usa uno che si chiama "TrueVector"),
l'unico che forse potrebbe essere free e` quello che hanno usato per il
porting di tcpdump:
http://netgroup-serv.polito.it/windump/install/Default.htm


 
http://netgroup-serv.polito.it/windump/install/Default.htm
Grazie, daro' un' occhiata!


> qualcuno ha parlato
LL> Forse in questo caso e` eccessivo usarlo. Inoltre di solito sono a
LL> pagamento (ad esempio ZoneAlarm ne usa uno che si chiama "TrueVector"),
LL> l'unico che forse potrebbe essere free e` quello che hanno usato per il
LL> porting di tcpdump:
Fammi un po' capire. Con queste cose puoi arrivare a manipolare i pacchetti
o solo a mettere regole di blocco ?
LL> 
http://netgroup-serv.polito.it/windump/install/Default.htm
	  ^^^^^^^^^^
Toh, guarda chi si vede...


 porta su cui continuare il discorso con una nuova connessione...
No, io intendevo modificare la porta del client verso il server (e, visto
che non si puo' accedere al server, anche l'IP) per crearmi un  caposaldo
per l'applicazione di "bridging". Ammetto che mi ero spiegato male.
Mi sembrava fosse una soluzione tra quelle discusse oltre al routing.
Il problema e' la conoscenza del meccanismo di autenticazione al server
che necessariemente deve avvenire tramite l'applicazione filtro. A meno
di cose turche il resto si risolve istradando i pacchetti modificati
piu' o meno come un NAT.
Ciao.
Il Michett@
--

 
http://netgroup-serv.polito.it/windump/install/Default.htm
Brilliant! Da usare quando non ti pagano le fatture! B)
Ciao.
Il Michett@
--

 o solo a mettere regole di blocco ?
Sul manipolare direttamente non saprei (non mi e` mai capitato di
doverli usare in un programma); comunque come dicevo in un altro
messaggio, puoi sempre bloccarli e poi generarne degli altri al posto
loro... ovviamente e` una forzatura immensa. :)


> o solo a mettere regole di blocco ?
LL> Sul manipolare direttamente non saprei (non mi e` mai capitato di
LL> doverli usare in un programma); comunque come dicevo in un altro
LL> messaggio, puoi sempre bloccarli e poi generarne degli altri al posto
LL> loro... ovviamente e` una forzatura immensa. :)
Senza rompere la connessione porta:address ---> porta:address originaria ?
(add-to-post 'spack-mode "Decisamente interessante, grazie")


 porta:address originaria ?
Hmmm, in effetti tale connessione e` "identificata" semplicemente dal
contenuto di certi campi nell'header TCP (quelli in cui c'e` il numero
di sequenza del pacchetto, e altri che si perdono nella memoria e in
appunti molto polverosi dentro al mio armadio). Quindi se tu generi un
pacchetto 'raw' puoi anche clonare i campi che ti servono nell'header
TCP e "far finta" che esso provenga in tutto e per tutto dal "canale
virtuale" a cui era associato quell'altro.
Oh, io sto facendo delle congetture; magari non e` vero niente, pero` e`
verosimile. ;-)
