Newsgroup: it.comp.lang.delphi
Titolo: OTperchè usate delphi nelle applicazioni client-server?

Un po' OT ma soprattutto curiositą:xchč quasi tutti i ...trojan
migliori (scusate l'argomento) sono fatti in delphi?Che cos'ha di + il
Delphi del VB o del C++?
Grazie
P.S.ovviamente non so programmare se no forse lo saprei,grazie ancora.

 Delphi del VB o del C++?
IMHO:
Rispetto al VB crea eseguibili piu' compatti e dispone di componenti di
rete ottimi (Indy).
Rispetto al C++ la sintassi e' piu' produttiva, e rispetto a MFC ha una
libreria di classi che e' un sogno. Altro discorso se lo confronti con
il C++ di Borland.
-- 
I'am what I'am, I do what I can

 Delphi del VB o del C++?
Un trojan deve essere piccolo, espandibile, veloce. Deve inoltre essere 
in grado di interagire a basso livello con il sistema.
VB lo scarti subito per ovvie ragioni (fallisce quasi in tutti i campi 
sopra citati).
Rimane il C++ che però, a volte, richiede la presenza di DLL esterne che 
con Delphi non necessiti.
Il risultato che ottieni con Delphi è un eseguibile piccolo e veloce... 
l'ideale per un software che non deve dare nell'occhio.
Ciao,
   Luca
-- 
Linux registered user #291568 (
http://counter.li.org/
)
Electronic Frontier Foundation Member (
http://www.eff.org/
)
Mandrake Club Member (
http://www.mandrakeclub.com/
)

 Delphi del VB o del C++?
Fondamentalmente perchè è un ambiente RAD e quindi si presta bene per
progetti di piccole/medie dimensioni. Un Trojan è decisamente un programma
di piccole dimensioni.
Visual Basic si trascina dietro troppi ocx e dll per poter fare un pe degno
di tal nome.
Tempo addietro scrissi un Trojan in Delphi; aveva delle funzioni simpatiche
come:
invio in email dell' ip del server
parziale controllo remoto con cattura immagine
scherzi (spegni il monitor, ruota lo schermo, muovi mouse, apri lettore)
Lo usai solo come test con dei miei amici, tanto è vero che il server è un
comune processo con finestra! :-)
Direi che non è proprio l' ideale per chi vuole fare "hacking" :-)
Bye
--
- Carlo -

con Delphi non necessiti.
Il C++ non richiede, di norma, alcuna libreria esterna.  
Dipende dalle diverse implementazioni.

Non volevo fare dell'hacking,non sono così bravo,ma mi hanno
incuriosito xchè ce ne sono alcuni che sono dei capolavori:
Beast non riesci a trovarlo,vedi solo la porta aperta ma non riesci a
trovarlo su disco,nè nei processi attivi.
CIA o Cold Fusion o LANfiltrator ti passano un firewall o un
proxy,cioè è il server che si connette al client non il viceversa.
Mi incuriosiva il fatto che tutti sceglievano il Delphi.
Scusate la divagazione+OT.
Grazie


Mi incuriosiva il fatto che tutti sceglievano il Delphi.
Bisogna però vedere in che modo i programmi vengono compilati.
Il C e il C++ sono linguaggi i cui compilati, a meno di usare (in C++)
tecniche che introducono un certo peso, come l'RTTI, sono generalmente
molto compatti.  Molto più di quanto normalmente riesci ad ottenere
con altri linguaggi.  Moltissimi virus sono scritti in assembly (di
CIH credo che si trovi anche il sorgente) che da, ovviamente, il
massimo delle garanzie in quanto a compattezza e velocità.  Non so
perché la scelta propendesse su Delphi.  Per scrivere un virus non hai
necessità di funzionalità RAD e tantomeno di eseguibili grandi
centinaia di Kb.  Personalmente, se dovessi proprio fare una cosa del
genere, propenderei per l'asm o, al limite, per il C.

 perché la scelta propendesse su Delphi.  Per scrivere un virus non hai
Perchè è l'unico ambiente con tanti componenti per internet (
p.es
. accesso
SMTP, DNS) che si integrano in un solo exe, senza alcun bisogno di
registrare ocx, activex e quantaltro.
Ideale per i virus via attachment, in effetti: è quasi banale scriverne uno
in Delphi..

SMTP, DNS) che si integrano in un solo exe
Ma Delphi produce, generalmente, degli eseguibili molto grandi.
In C/C++ o addirittura Assembly si possono fare esattamente le stesse
cose (chiaro che bisogna giocare con le API relative ai socket) in
meno spazio.

 Dipende dalle diverse implementazioni.
Bé, un programma semplice semplice che ho provato a fare con C++ Builder 
me lo ha fatto... mentre lo stesso programma in Delphi no.


me lo ha fatto... mentre lo stesso programma in Delphi no.
Innanzitutto specifica il compilatore: C++ Builder, appunto.
Quando parli di C o C++ non c'è nessuna implicazione diretta sul
compilatore utilizzato (gcc ? Borland C++ Compiler ? C++ Builder ?
Visual C++ ? MingW ? Lcc32 ?).  Poi, sei sicuro che non stessi
compilando con i run-time package ?  Nota che, sotto C++ Builder,
l'impostazione di default è quella (al contrario di Delphi).

me lo ha fatto... mentre lo stesso programma in Delphi no.
Una affermazione simile dice tutto come dice niente....
-- 
Morde. 
(morde at programmer dot net)

 l'impostazione di default è quella (al contrario di Delphi).
Io purtroppo adesso non ricordo, né che genere di DLL volesse né 
tantomeno perché (so che si trattava di una DLL e non un package stile 
Delphi). So solo che lo stesso identico programma in Delphi non 
richiedeva alcuna DLL, in C++Builder invece si (ovviamente questo lo 
noti solo quando provi a far eseguire il tuo software su un PC che tale 
DLL non ce l'ha).


 Una affermazione simile dice tutto come dice niente....
Bé, questo è tutto quello che ricordo. Non ricordo che programma 
fosse... era comunque qualcosa di molto semplice stile "hello world".


 meno spazio.
Questo lo puoi fare benissimo anche in Delphi... elimini tutte le unità 
e tieni solo l'unità Windows (e poche altre di contorno se necessarie) e 
ti fa EXE piccoli pure lui.


 ti fa EXE piccoli pure lui.
Considera inoltre che un trojan di 200/300k è una cosa normalissima al 
giorno d'oggi, i virus venivano scritti in assembly at tempo del dos... 
ora pure gli scrittori di virus preferiscono livelli d'astrazione 
maggiore perché gli permette, a parità di controllo sulla macchina, di 
scrivere meno codice e in modo più chiaro, e quindi di aggiungere 
funzionalità ai loro trojan.
Certo, c'è ancora qualcuno che preferisce scrivere in assembly, ma sono 
oramai una minoranza.


Luca T. wrote:
<snip>
Vorrei solo far presente che virus e trojan sono due cose completamente
diverse, per
favore non confondiamo.
I trojan servono a prendere il controllo della macchina, mentre i virus ad
auto-replicarsi.
Ciao,
Andrea

auto-replicarsi.
I trojan possono servire a qualunque cosa e non è detto che un trojan
non possa auto-replicarsi.  Da un punto di vista sufficientemente
generale, sono tutti identificabili come "virus".

oramai una minoranza.
Non capisco su che base si possa trarre un giudizio del genere: non
esiste una pratica diffusa di scrivere virus che sia alla luce del
giorno.

 giorno.
Sulla base della normale logica e buon senso.
Un tojan odierno spesso non solo è in grado di comunicare via 
internet... è anche in grado di usare periferiche (webcam, stampanti, 
etc), è in grado di di "loggare" le azioni dell'utente, è in grado di 
aprire porte FTP sul computer della vittima, è in grado di 
scaricare/uploadare file dal/al computer della vittima, è in grado di 
cancellare file, è in grado di eseguire screenshot, di registrare audio 
dall'ambiente circostante, è in grado di prendere il controllo di 
applicazioni tipo MSN/AIM/YAHOO, è in grado di "sciogliersi" all'interno 
di altri eseguibili, è in grado di fare ogni genere di trucchetti per 
fare diventare sclerotico l'utente, è in grado di spedire email, di 
leggere email, di leggere newsgroup, è persino in grado di ampliare i 
comandi a disposizione attraverso plugin (DLL) scaricare da siti web 
predefiniti o specificati da chi lo comanda... e non ti sto parlando di 
uno o due trojan... ma di tantissimi trojan che bene o male ricalcano le 
stesse caratteristiche... tu siceramente pensi che ci sia qualcuno così 
folle da voler implementare una cosa di questo tipo interamente in assembly?


 meno spazio.
Credo che scrivere un trojan in Assembly significherebbe tirarsi la zappa
sui piedi; tantopiů su un ambiente Win32!
La dimensione degli exe potrebbe essere si un problema ma non č detto che lo
sia. Ho visto Trojan composti da due parti; una piccolissima di pochissimi
kb che una volta attivata "scarica" in maniera totalmente invisibile all'
utente il vero "cuore" del virus. Attualmente un Trojan dispone di feature
avanzatissime difficilmente riscrivibili in assembly puro a livello
utente(Keylogging, Invio/Ricezione files etc). Se parli di C/C++ sono d'
accordo con te; tuttavia Delphi rimane imho un ottimo ambiente per questo
tipo di applicazioni in quanto fa risparmiare parecchio tempo sulla gui e
fornisce tutta una serie di componenti utili a rendere il codice piů
compatto.
--
- Carlo -
"Imparare senza riflettere o riflettere senza imparare non vi porta alla
buona comprensione" Confucio


Open Delphi Manual (
http://groups.yahoo.com/group/delphi_open_manual/
)

 in assembly per il puro e semplice gusto di farlo...non si sa mai. ;-)
Quanto dici è vero, tuttavia è innegabile che certi ambienti sono
maggiormente adatti ad un certo tipo di sviluppo.
Il RAD non si presta per progetti di grosse dimensioni (quando parlo di
piccole, medie e grosse dimensioni faccio riferimento a quelle che sono
prese in considerazione dagli autori dei testi di s.e.) ma garantisce uno
sviluppo altamente performante per i progetti di piccole dimensioni;
tantopiù quando puoi contare su un framework come quello che Delphi ci
fornisce!
Poi certo, non dico che in assembly sia impossibile scrivere quanto
richiesto; ma è possibile anche prendere le mosche con le bacchette dei
cinesi! Io preferisco il Raid! :-)


 Io preferisco il Raid! :-)
Io il RAD :)
--
Jax
Journeying Artificial Xenomorph

Il RAD non si presta per progetti di grosse dimensioni [...]
Questo non è vero.  Perlomeno, non è vero a livello generale.
A parte che "RAD" non significa una sola cosa, lo sviluppo di progetti
di medie/grosse dimensioni è invece aiutato moltissimo.

 di medie/grosse dimensioni è invece aiutato moltissimo.
Faccio un po' fatica a comprendere il significato del tuo ultimo periodo.
Sul fatto che possa "contribuire" allo sviluppo di un progetto di dimensioni
consistenti siamo d' accordo.
Se mi dici che risulta il solo ambiente RAD può andar bene per lo sviluppo
di applicazioni di dimensioni notevoli allora non la vedo così.


di applicazioni di dimensioni notevoli allora non la vedo così.
Certo, può andare bene.  Una domanda: quante applicazioni di
dimensioni "notevoli" hai sviluppato prima di fare un'affermazione del
genere ?  

 genere ?
Esattamente zero.
La mia affermazione non nasce dalla mia esperienza ma dalla cultura
informatica che mi sono fatto sui vari testi.
Potrei adesso sapere cosa è per te una applicazione dalle dimensioni
"notevoli" (in termini di linee di codice) e quante ne conosci di
sviluppate_esclusivamente_con ambienti RAD?
Quante ne hai sviluppate in prima persona?


Quante ne hai sviluppate in prima persona?
Io ho sviluppato (e partecipato allo sviluppo) di diversi sistemi di
"media grandezza", dove per "media grandezza" si intende orientati ad
aziende medio/grandi.  Si tratta, per lo più, di "sistemi", cioè non
applicazioni singole, ma diversi moduli (ad. es. il modulo usato per
la produzione, quello per la fatturazione, ecc...) che si
interfacciano tra loro.  Resta ancora da stabilire che cosa tu intenda
per "RAD".  Delphi ha aiutato moltissimo nello sviluppo di questi
sistemi, per la semplicità del linguaggio (facilmente lo stesso si
sarebbe potuto fare in C/C++ avendo a disposizione opportune librerie)
ma ha richiesto l'affiancamento di altri tool che personalmente
definirei ugualmente "RAD".